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 cms colinear. 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 SAXO FPGA 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.
