The component video lead finally arrived today. Above is a 1080i HD transmission using DVB-T the bitrate was about 11 Mbits/s.
I have never seen HD video before but I can assure you the picture does not do justice to the quality of the image. I suggest you double click on the image and look in the top right hand corner. There is a bit of camera shake as I was not using a tripod.
Now I have that out of my system I can go back and concentrate on getting ready for the 22 Aug.
Here is a short video of the system. This is 70 cms DATV sent at 2 MS/s. I had to heavily edit it and the camera work is a bit shaky. But heck it is my first try at a video. The video was captured using the Hauppage HD-PVR then edited using Windows Live Movie Maker.
Finally managed to finish off the 70 cms PA unit. It is giving a reasonably clean 20 watts of 2MS/s DVB-S. Next I need to sort out an antenna, all I have at the moment is a 70 cmscolinear. I still need to put a lid on the PA. I think I will try bending a sheet of aluminium this time.
I had to get a new P.C last week. It has Windows 7 64 bit on it. At the moment I can't get the unsigned driver for the SAXOFPGA board to work.
I am on the hunt for an inexpensive FPGA board that I can try porting my DVB-S code onto. Mainly to learn about Verilog programming and to try and make an easy (cheaper) way into DATV for others. I suspect it is going to require some bespoke hardware.
The curse of using commercial off the shelf STBs. This will always mean we are behind the curve. Take for example DVB-S. The STBs are cheap but they force us to use a non optimal system. MPEG2 is inefficient compared to MPEG4. DVB-S is inefficient compared to DVB-S2. Unfortunately I have yet to find a DVB-S2 STB that operates below 10 M/S per sec and if I did I expect it would be expensive.
Of course with the SDR approach that is not really a problem but how many people are prepared to spend the money to buy such an item (not many).
This not only applies to what I am doing but also to the narrow band DATV modes now coming out of Europe. I am not complaining but it is simply one of the things I have to take into account when developing stuff. It is also the reason I am more interested in tinkering than actually working people!
It looks like I will be getting the final parts required to get onto 70 cms 2M DVB-S this week. So car door openers beware!
The picture is of my crude 24 cms -> TV band down converter. It uses an old G8LMW UV02 re-tuned to 800 MHz. The output of which feeds an ADE-11X mixer. The 24 cms band is down converted to 440 MHz - 525 MHz. I will need to add some filtering to it but at least I can see my 24 cms DVB-T signals on my domestic TV now. I don't intend adding a preamp in front of the mixer as the masthead preamp has enough gain to compensate for the losses. The UV02 has about 6.5 dBm output at 800 Mhz around the right level.
I notice yesterday that Xine (courtesy of ffmpeg) can decode H.264 video. Yes I have tried it and it works.
Rather than increase the filter length I decided to add compensation to the outer tones of the OFDM signal to mitigate the filter roll off. The results can be seen above.
I dug out an old LWM electronics universal local oscillator and retuned it to produce about 2mW at 725 MHz. I will probably use that in my receive converter.
I am still waiting for the lead so I can make my first HD transmission. The only other activity worth mentioning is that I managed to get Linux to recognise and load the firmware for one of those USB DVB-T receivers. The applications MyTV and Kaffeine don't seem to allow manual control of the Dongle. I guess they never had me in mind!
The ears around the DVB-T signal have gone. They were due to aliasing. I was being a bit optimistic in the filtering. After changing the filter and reducing the amount of decimation after the filter the signal looks much better. Unfortunately the software is now outputting samples at 20Ms/s. This would not have been necessary if the USRP2 was a bit more flexible in the way it does it's final D/A.
As you can probably see the filter is slightly too narrow now. What should be done is more taps added to the filter but I don't really want to do that because the P.C is operating near its limit already.
The blur on the photo is due to the fact I have lost the screw that attaches my camera to it's tripod so it is difficult to steady the camera in the low light of my shack.
Well the reconditioned Humax FOX-HD T2 arrived today. It seems that my HD ready TV and new STB don't like talking to one another using HDMI. I get the boot screen O.K but then it says un-supported format. I suspect it might be because my TV does not seem to support HDCP (content management).
Anyway The Humax can decode the H.264 DVB-T signal. The Samsung HD TV can decode the H.264 DVB-T signal too, despite what I said in a previous post. I had made a slight mistake in the code that modifies the transport headers.
Until I get the correct lead for my used JVC HD camera I won't be able to test the 1080i mode. I have been doing my tests using SD.
I was a bit thrown today because when I switched on the system I could not get a tx signal out of it. It turns out Linux had decided to re-arrange the mapping of the /dev/videoN ports while I slept.
Here are a couple of shots of the PCB inside the Hauppauge PVR-HD. These were taken of a defective unit and not my one. I thought the pictures might break up the monotony of all the text I have been posting recently.
I hope to have some more news next week after I try my first H.264 transmission.
I managed to find a corrigendum with the stream table in it so I was able to complete that part of the code.
I spent most of the morning trying to figure out why v4l2 returned error codes when I tried to control the Hauppauge HD-PVR. Eventually I figured out you need to use the extended controls to control the device.
Currently the program can ingest a transport stream from the HD-PVR alter the various elementary streams to the required value and then transmit the whole thing using DVB-T. It also amends the SI tables accordingly.
The TV receiver recognises the AAC audio but because it does not have an H.264 decoder, it displays service unavailable for the video.
Hopefully a used HD set top box will be arriving @G4GUO next week which has a H.264 decoder in it. I need a new box for the domestic TV anyway. Apparently we don't have HD in our area yet.
The HD-PVR is based on an H.264 encoder chip developed by Ambarella. Unfortunately it only supports 720p and 1080i. The company does do a chip that supports 1080p. I expect that eventually it will be possible to buy cheap hardware based on that. For the moment I won't be able to claim Full HD!
I am now looking at encapsulating H.264 Video in an MPEG 2 Transport stream. Unfortunately the copy of the spec I have is too old to have the stream ids for H.264. So far I have not been able to find a free copy on the net of the 2007 version of the spec.
I now have a Hauppauge H.264 encoder and I will have to analyse the transport stream it produces to figure out the values.
I was reading on the DVB consortium website that some countries are transmitting HD TV using DVB-T instead of DVB-T2. As Hauppauge make a hardware H.264 encoder that is supported by Linux it might be interesting to try sending HD that way.
Looking on the BBC's R&D site the original HD tests were done using a modified Humax DVB-S2 receiver modified to receive DVB-T.
I have been looking further into the wonderful world of CUDA programming. Trying to sort out my warps and half warps, memory broadcasts etc.
Also spoke to Sam G4DDK about the best way to power the LNA he produces up the coax. A 10 turn choke wound on a 2mm former is what he uses. I will make that happen tomorrow.
I spent sometime this weekend looking at the DVB-T2 specification. It is a couple of orders of magnitude more complex than DVB-T. I have not really decided whether it is worth making an attempt to implement it. It seems a lot of work for little gain. The specification does include some narrowband modes which would fit in on 70cms but the narrow modes are designed for professional use which means of course you will have to pay professional prices to obtain any commercial gear to use them. That of course reduces the number of potential viewers. They have made an attempt at mitigating PAR problem with OFDM and have employed more state of the art FEC. They have also reduced the various overheads in the waveform.
I am always open to collaboration on digital TV projects as there is no way I can do or know everything.
I also played about a bit with some more Cuda programming, thinking how to code parallel processors is certainly different. The biggest problem I can see with Cuda apart from the different way of thinking about programming is keeping data transfers across the PCI bus to a minimum. However I think about the DVB-T2 problem I end up having to move large amounts of data across the bus which kills performance.
I enjoyed the BGM walkabout video on the BATC streaming site. I can't wait for the lectures to appear. I thought the 3D TV demo looked pretty neat. I am also quite impressed that people bother to take all that heavy gear to demo it, it must be a lot of effort to do. I take my hat off to them.
After a couple of days work I can report that the Comtech modules won't be of any use to me. Their LOs are on the high side so the signal will get inverted. When I looked at them on the spectrum analyser I noticed that their phase noise is horrendous even with the synthesiser locked. Neither of which would be conducive to DVB-T operation. I suspect I am going to have to build some bespoke hardware. Looking in my magic box I see I have some 2 GHz ring diode mixers and some MMICs. I just need to sort out a clean source of RF in the 700 - 800 MHz range.
Moral to this story folks is don't waste your time putting your hardware in a box until after you have tested it! Still I did get to try out some new conical drill bits I bought.
