Above is a photo of the inside of one of the Comtech modules I bought.
I plan using this module as a 1.3 GHz down converter so that I can
receive 1.3 GHz DVB-T on a domestic digital TV. Rather than using a PIC
controller to program the synthesiser I am considering using a USB chip
in its parallel port mode. I have a couple of DLP2232M-G development
modules. These can either be programmed as 2 serial ports or as two 8 bit
parallel ports. The spare lines I can use to control RF relays etc. I have used
these devices in the Windows environment but never under Linux.
Talking about DVB-T. I have now managed to get a stable transmission.
To do this I had to increase the size of the Kernel buffers that the UHD module
uses to communicate with the USRP2. I can now send up to 19 Mbits.
The TV reports a BER of zero. You can have too much of a good thing
though, if I increase the kernel buffers too much the whole program locks up
because all the internal queues empty and my program tries to fill them
with NULL transport packets.
I managed to compile in CUFFT (the CUDA FFT library).
There was no noticeable performance boost but that is not
the fault of CUDA. To get a meaningful benefit I would
have to re-organise my entire program to benefit from
parallel processing. At the moment that would be too
disruptive. Maybe when I start a new project.
I did learn that my original FFT problem is not the fault
of my FFT code as CUFFT has exactly the same problem.
I am beginning to think the problem lies with the anti aliasing
filters in my output interpolator.
I will be back to all matters DATV in my next post, after all
computers are just a tool.
I managed to install the CUDA toolkit on
my Fedora 12 Linux system today. Not
totally successfully though as the release I
had to use was for Fedora 10. I can compile
some of the test applications.
CUDA allows you to use NVIDIA graphics
processors for parallel computing, ideal for
the sort of thing I want to do. Arrays of these
GPUs (Graphics Processor Units) are used in
some supercomputers. The board I have has
20 processing cells and each cell can have
32 threads running on it.
I expect now to have the type of brute force
computing power I need to implement DVB-T2
if I decide to do it. The board can also be used
for spectral analysis, direction finding etc.
The basic DVB-S code I have written does not
need GPU support.
Well, the teletext descriptor has been added to
the PMT (that is the table that defines the PIDs
for the video, audio and PCR elementary streams
for a program). Now when I press the teletext button
on the remote it goes into teletext mode and waits.
Before it just said "service not available".
Next I have to figure out the format of the Teletext
PES packets so I can load some pages.
OpenCaster has an application that generate a PES
packet from a text file. That would be an easy way
to add the pages but when I tried it I could not
get it to work. More research needed.
Another day another picture! I finally managed to get the
EPG to work for DVB-T as well. The problem was I had not
tagged all the required SI tables with the correct program ID.
I also added a content type information descriptor (leisure/hobby).
I might also add a parental guidance descriptor.
Yesterday I connected my old camcorder up to the transmitter
and I can now say that the stereo sound works as well. That was
the first time I had tested it!
I am still getting picture drop outs. I need to spread the load
between all 4 of my CPU cores at the moment only one core
is doing all the work. I guess I am going to have to read up
about how scheduling works under Linux.
I am glad to say that the EPG information for DVB-S now works.
DVB-T EPG does not seem to work. Somehow the fix to the power
problem has swapped the I and Q channels. The DVB-S STB can cope
with this but DVB-T cannot. I only discovered the problem when I was
trying to test the EPG for DVB-T.
A rebuild of the UHD driver using the latest git version
seems to have fixed the power level problem. I can
now drive the output into saturation and am getting
60mW @ 1.3 GHz
I spent some time today looking at LDPC
"Low Density Parity Check" codes. These are
the codes used in DVB-S2 and DVB-T2. I
think I understand the concept of them now.
To work well the messages have to be very
long, in DVB-S2 they are 64800 bits long.
Their performance is similar to Turbo codes
(which I played with over the new year) but
they have some advantages and in certain
instances can exceed the performance of
Turbo codes, also they are not littered with
patents.
I took the FPGA development board I bought
a while ago out of its box and looked at it.
I have written a couple of FPGA programs
but nothing major.
Apart from that I have been installing various
versions of Gnuradio to try and get to the
bottom of the missing 6dB.
Oh yes, I put another shelf in my 19 inch rack
to house the 2nd STB. I am after some DVB
stickers to go on the outside of the rack to make
it look like a real DTV sender. Maybe I will
make up a label using my labelling machine
that says "DTV Sender A"
I have 2 STBs, a Fortec Star Lifetime Classic and a
Fortec Star Ultimate PVR. I have been using the
Classic but I swapped to the Ultimate today. The
received picture quality is much better and I am
getting less motion glitches on the picture. You
would think that two STBs made by the same
company and bought about the same time would
have similar performance. It appears not!
I corrected an issue with the FEC configuration
in the DVB-T mode. The actual FEC and that
being signalled in the TP information were not
the same. Consequently the TV would not lock to
anything other than 1/2. Long story simple fix.
I have added the bit-rate lookup table from the
DVB-T spec to my code so when you change DVB-T
modulation parameters a suitable video bit-rate
is chosen automatically. The audio bit-rate remains
constant for all modes.
I ordered a couple of Comtech analogue STB modules
from a retailer on eBay. The plan is to use them
as a cheap 24 cms down-converter as they have
an IF of 479.5 MHz. I will have to open them
up and put a vampire tap inside to pull out the IF.
Still I should be able to receive 24 cms DVB-T on
my TV when that is done.
I think the next job is to go through the
SI descriptors for DVB, as I am still not getting a
sensible EPG on the STB. I would also like to add
Teletext when I figure out the format. Just simple
stuff like QRA locator and a station description.
Those of you that follow the GNURADIO forum will
know I appear to be getting only about 25% of the
power I should be getting. It seems there is a
software bug somewhere. Hopefully this will be
sorted out soon but is not under my control.
That is the problem with all this bleeding
edge technology :-).
This shows the spectral re-growth seen sending DVB-S when the Mitsubishi
RA18H1213G module is driven to about 7 watts output. This is using
the standard bias arrangement.
This is the output of the same module when transmitting about 1 watt of DVB-T
The rubbish on either side of the signal is due to the problem in the iFFT I
mentioned a few days ago. I have not figured out a way around it yet.
As promised here is a picture of the 1.3 GHz driver amplifier I
have been working on. It is based on a FPD4000AF pHEMT
which I bought on eBay for about 1 pound. The device is rated at
4 watts and is good to 4 GHz. I am no RF guru so I was not expecting
much. It has about 8db gain at 1.3 GHz slightly more at the bottom
end of the band. It should have > 10 db gain at these frequencies.
It looks like the input match is not quite right. But it is stable so
that is a start.
Update. With a slight change to the input circuit I am now getting
13 dB gain @ 1.3 GHz and the gain across the band is flat within
1.5 dBs. Because of the long leads and low output of the WBX I
don't have enough to drive the PA beyond 100 mW output at the
moment.
Just out of curiosity I did a quick test of my
DVB-T software on 436 MHz. Output power was
under a mW. My Samsung TV when told to
monitor 436 MHz successfully received the signal.
As could be expected the DVB-T signal drowns out
everything above 432.5 MHz so that was the first
and last time I try it.
The output power on DVB-T is considerably below
what I can achieve on DVB-S, so I am going to have to
re-think the driver amplifier as it does not have enough
gain for 1.3 GHz DVB-T although it will be fine for DVB-S.
My DATV experiments have shown me that I really need to
get a much higher quality camera to fully utilise the benefits
of Digital. Have looked at the price of even used studio quality
cameras I don't think that is going to happen any time soon.
I spent yesterday evening looking at the DVB-T2
and DVB-S2 specifications. Very interesting. They
have replaced the convolutional code with
concatenated BCH and LDPC (Low Density Parity
Check) codes. DVB-T2 uses a 32K iFFT. It does not
look possible to implement either of these specs in
real-time on a P.C. They are a job for an FPGA.
Still it was interesting to read about them.
My next job will be to design and build the driver
amplifier based around the pHEMPT 4W transistors
I bought a while ago so I can drive my PA to about
10 watts (for DVB-S).
Well I am glad to report that after weeks of frustration I have managed
to successfully transmit my first DVB-T signal using my trusty USRP2!
The transmission was using 8K mode QPSK with 1/4 guard period. The channel
bandwidth was 7 MHz. The photo above is not very good because my hands
were shaking so much with the excitement.
The final bug was the fact I was had got the bit order of the symbols reversed.
Unlike the satellite box the Samsung TV either detects the signal or not so you
are pretty much working in the blind until it works.
The USRP2 has about 70% load on one of the cores to do this, so I am going
to have to optimise the code.
Update! I have now managed to test both 2K and 8K, QPSK, 16QAM,64QAM
various guard periods and FEC rates from 1/2 through 7/8 and all of them
decode correctly on the TV set. The tests were done under suppressed
radiation conditions on 177.5 MHz as I have not made a 1.3 GHz down
converter for the TV set yet.
