Installed Linux on my dual core laptop.
Moved MPEG,DVB-S and DVB-T source
code to the laptop. Hopefully I can start
testing the DVB-T code by the end of the
week. I still need to add the sample rate
conversion code but the rest of it is done
(bar the bugs).

I am hoping I will eventually be able to run
the DATV code on the laptop which will make
the whole system more portable.

I noticed someone local to me is selling a DVB-S
commercial system on eBay apparently it used to
be used in Turkey to relay BBC/ITV from a satellite
feed. At £3600 I won't be putting in a bid.

I decided in the end to build one of
G4DDK's 1.3 GHz LNAs rather than
to use the pHEMTS I bought. To be
honest it would have been more
expensive to order the small quantities
of chip components than to build one of
Sam's kits. Also with Sam's LNA it should be
possible to achieve a NF of about 0.3dB
which is much better than I would have
got with the parts I was using.

I ordered the kit on Friday,
received it on Saturday and built it
Saturday afternoon. Everything biases
up correctly so I expect it to work.
It was a bit of a challenge to build as the
SMT parts were so small.

On Sunday I build a small 144 LED light
for use in the 'studio'. The LED units were
really meant as courtesy light replacements.
But I used 4 to make a small light to go on top
of the camera.

Next I have to sort out some Polyphase filter
banks to efficiently do the required sample
rate conversion for the USRP2.

The MMX based FFT routines are now working.
Next I need to write code to place the OFDM
pilot tones and TP information in the frames.
I intend pre-computing as much as possible
at the expense of extra memory. The reason
being to keep the processing load as low as possible.

I spent rather longer than I had hoped on the
FFT code but I did learn a bit about the differences
in AT&T and Intel assembler formats and a bit
about stack handling by the GCC compiler.

I got the new lens for my CCTV camera on Saturday
unfortunately it didn't come with a plug so I have to
buy one of those. Maplin sell them, but the postage
costs more than the plug.

I have also been scouring the internet for cheap
sma coax relays. There don't seem to be any, even
the used ones are expensive. I have a 24v one but
it is always nice to have spares.

Things are progressing slowly.

I have the Tonna 23 element Yagi put together.
I am waiting on the GH Engineering kit which should
be here before the end of the month.
The various table packets are starting to be recognised
by an MPEG2 analyser I downloaded.

Yesterday I started looking at DVB-T. I have spun
the numbers and it looks as if it will be possible to get
it to work on the USRP2 with a bit of fiddling.

In a mad rush I started to write the code for DVB-T.
I have the bit interleaver, the symbol interleaver, the
BCH encoder for the TP data and the TP data formatter done.

If I have time this weekend I am hoping to get the
2048 and 8192 FFT MMX code done. After the fun I
had with pipe-lining the complex FIR code I wrote I have
decided to stick to using a modified version of an Intel
application note I found, otherwise it would take me forever
to write the FFT code. The MMX code should be about 5X
the speed of a C implementation.

What is left to do is the mapping of the symbols onto the
carriers, the inclusion of the pilot tones and the addition of
a x5 interpolator /4 decimator to get the 8 Msamples/s of the
encoder to 10 Msamples/s so it can then be interpolated up
to 100 MSamples/s as required for the USRP2.

My DVB-T implementation will be secondary to my DVB-S
one so don't hold your breath. It just gives me a break from
writing MPEG2 code which is soooooo boring.

Receiving DVB-T @ 24 cms is going to require some thought.
I will have to do initial tests under suppressed radiation
conditions inside the broadcast band so I can use a domestic
STB to decode the signal.

Yesterday I etched some small PCBs using
the "Press and Peel" system. Of the 12 boards
I laid down only 6 were viable and that was after
a fair amount of re-work. I tried very hard to
do everything right too. Still practice makes perfect
and I do have 6 viable boards and only 5 devices.

I am using the reference circuit in the data sheet.
I blew up the part of the PDF I needed. Used the
snapshot facility in Adobe to copy it into another
file. Edited that with Microsoft Paint to get rid of
the components. Then I blacked in all the tracks.
Flipped the picture and finally scaled it down to the
correct size and then printed it onto the 'Press and Peel'.
It all took a lot longer than I had hoped!

I did a bit more work on the MPEG SDT tables at bedtime.
At the moment all the values are hard coded but
I am going to add support for a configuration file.
At least that means other people will be able to use
the software when it gets finished.

This picture has nothing to do with DATV.
I thought I would show it anyway.
It is a picture of one of my eBay purchases.
It is in fact an 8.5 GHz YIG oscillator.
Starting top left is a dual voltage PSU then the YIG itself
followed by the PLL unit for controlling it.
Below that is one of my old Vocoder boards.
The AMBE chip is not being used, I am just using the
PIC microcontroller to drive the PLL chip.
The whole thing is controlled from a Windows GUI App.
The YIG swings by about 1 GHz.

There I got that off my chest.

Back to DATV. It now seems I need more than just
ISO 13818-1 to understand DATV. A lot of the
information like the service descriptor tables
(SDT) are encoded as 'private' data which is not
included in the MPEGII spec.
Enter ETSI EN300 468 this is where it is described.

I have some working transport packet files *.ts which
came with the M0DTS package and I have been using
these to figure out what I need to send.

First thing this morning I jumped out of bed (all keen like)
and wrote a little utility which I have called "Bitnapper"
Bitnapper allows me to pull to pieces transport packets
bit by bit. I pass it the *.ts packet, a simple syntax file
and it then creates an output file for me with the packet
broken down.

A lot of the mpeg analysers on the internet seem to
want to massage the data before they display it.
Bitnapper is not like that, it is dumb and shows you
exactly what is in the packet.

Last night I wrote what seemed like reams and reams
of code to format DVB descriptor files. I am going to
have to take a break from doing DVB as I am falling
behind with some more important stuff like my
O.U assignments.

I bought a slightly wider angle lens for my video
camera, again on eBay.
Hopefully I will be able to have everything in focus at
once just to annoy the BATC committee.
I though CQ-TV this quarter was a lot better than it has
been for a while. I do sympathise with the editor about
the lack of material. In the past I have tended to get my
stuff ghost authored.

I think that is enough waffle for today.

Well the camera arrived it is a Philips LCT 600/10.
It is a bit better than the old B/W camera I used
to use on TV about 20 years ago. However it is
not as good as the JVC camcoder camera I have.

Won the auction for the pHEMTS, paid 99p + £1.50
P&P for 5 devices.

Still struggling with MPEG2. I am doing the PMT
(Program Map Table) at the moment. I think I
understand the part of the table with the program
descriptors in but I am not sure about the associated
information tables. I think I can leave those blank.
After all I am just telling the STB which video and
audio elementary streams belong to the program.

I did find a program to analyse MPEG transport
streams http://tiny.cc/ukhub it recognises my
PAT program access table but seems blind to the
PMT. The author managed to get a copy of the BBC's
MPEG training course notes to help him with his final
year project.

My first job was in BBC transmitter group so I have
done their 'B' course so I know how good the BBC stuff
can be. If I can find a suitable contact address I might
try and beg a copy of the notes. Anything is better
than the spec itself! I wasted a hour last night trying
to find a copy of the MPEG -5 spec which has the
software reference in, no luck, I found all the other
specs.

Looks like I may have re-awakened some interest locally
in ATV. If nothing else I have found someone that is
prepared to monitor my DATV transmissions when I am
ready.

Well back to coding PMTs.

The modification to the DirecTV SUP2400 went well.
I can now receive on 436 MHz. The frequency the STB
needs tuning to is 2400 - 436 MHz. The SUP2400 is
a lot smaller than I thought but with my OptiVisor and
some daylight it took about 30 mins.

I am beginning to fathom out the MPEGII stream
formats now. I pretended I was a STB and thought
what information do I need to display a picture.
Looking at it that way the specification does not
seem so bad. Making a list of the necessary
packets and which page they appear on makes a
huge difference.

Should get my used colour camera soon.
I put a bid on some FPD750SOT343 pHEMTs
yesterday. They are good to 7 GHz and should
have around 0.5 dB NF. The seller seems to have
loads of them. It should be possible to make a
simple board using some double sided PCB and a
sharp knife. The App note has a reference circuit
for use just above 24 cms. Looking at the S-params
it should be fairly easy to get it to go on 24.
With some component changes it should be fine
on 70 cms as well.

The modulator program I wrote (using MMX opcodes)
is now working. There was a slight bug in the
convolutional interleaver but the Reed-Solomon
encoder and the convolutional FEC encoder work.

I have not played with RS codes before and Galois
fields took me a while to understand. With the
help of a BBC white paper on RS codes which
conveniently gave the required polynomials in
the expanded form required to do the encoder all
is well.

The only slight problem is the shape of the transmitted
signal is not as good as it could be. Either I have made a
mistake in the code or more likely I need to use a few
more filter coefficients. The filter is a combined RRC filter
and x5 interpolator. The x5 interpolator is needed to get
the sample rate to something that divides into 100 M.
Unfortunately the fractional interpolator in GNU Radio
uses too many CPU cycles for the job.

2 Msps DATV using a USRP2 and WBX transceiver

I am now experimenting with DATV. The picture shows my first DATV transmission on 24 cms using Fedora 12, a USRP2 and a Hauppauge PVR500 MPEGII encoder card. The transmit rate is 2 Msps. The Linux box is a Core 2 Quad clocked at 2.8 GHz.

Most of the code I am using was written by others. I only had to write about 15 lines of Python to get it all going.

The receiver is a standard Fortec Star DVB-S set top box (STB). The small 5" screen on the left is the received signal and shows the transmitter's spectrum. The signal was local leakage picked up with a bit of wire plugged into the STB.

To get 4 Msps however I am going to have to change the interpolator and RRC filters. To get the speed I will be using MMX assembler. Which is proving more difficult than I first thought because to get maximum efficiency the code has to be arranged to reduce the number of pipeline stalls. This can involve some really strange ordering of the instructions. I have already re-written the code 4 times each time dropping another stall. I don't think there is much more I can do.

I am currently waiting for a surplus DirecTV B Band converter I bought on eBay to be delivered. This will be modified to allow the STB to receive 436 MHz transmissions. The USRP2/WBX can already transmit at 436 MHz if required.

A GH Engineering 1.3 GHz PA kit is also on order. I have not decided on an antenna yet.

I think I am going to have my work cut out to gather any viewers!