Radio Adventures @ G4GUO

DATVExpress further update

2012-01-14T10:05:00.002Z

I have decided to change the buffering in the FPGA code.
I am moving to FX2 synchronous slave mode and am reading
the samples into a FIFO within the FPGA then reading the
samples out of the FIFO as required by the DACs. Of course
this means a complete change to the FPGA software.

My O.U maths course MST209 starts in a few days time so
I will have to scale back the amount of work I am doing on
the Express project. Hopefully this year I can plan my time
more efficiently.

Further DATVExpress Update

2011-12-26T17:26:00.006Z

I now have some proper comms between the Linux host
and the PCB. EP1 is being used to download the FPGA
code and then for sending I2C commands to the various
chips on the board.

EP2 is being used in slave asynchronous mode with quad
buffering to communicate between the USB interface and
the FPGA.

I am getting more consistent samples across the USB
interface but am still dropping samples. It seems to have more
to do with the libusb-1.0 library than the FX2 firmware as
the buffer sizes seem to cause a behaviour that I was not expecting.
I think I need to know a bit more of how best to use the USB libraries.

UPDATE

It seems as if the sample dropping issue is being caused by how

my code internally queues it's samples, in other words the problem

can be fixed. Phew!!!

DATVExpress Update

2011-12-24T12:34:00.005Z

I have had the DATVExpress board for a while now.
So far a small number of minor mistakes have been
found and fixed. The one outstanding problem is the
PLL for the modulator is not locking. This is due to a
misunderstanding about the circuitry around the chip
and is being fixed.

On the software side I have added code to my Linux
DATV transmitter program which allows me to download
the FX2 firmware to the board, start it running and then
download the FPGA code. All appears fine at the moment.
The next stage is for me to actually output something.

The first version of the FPGA code will simply write to the DACs
samples sent to it over the USB interface by the P.C. This will
be a very thorough test of the system. The final version of the

FPGA will not work that way (to reduce the USB load).

I hope the initial raw mode works as I would like to use the
board for DVB-T and DVB-T2 which will require use of the
a raw interface.

The modulator does produce output at 1.3 GHz but because
it is unlocked it drifts about the band. When that is fixed I
am hoping to be able to transmit some DATV with the board.

That is all for now, hopefully some news in the new year.

DATVExpress world exclusive!

2011-12-08T11:47:00.002Z

This is the very first DATVExpress board in the entire universe.
Now the real work for me starts getting the software to work!

GB3VR on Alford slot

2011-11-30T11:36:00.001Z

Just to give an idea of how strong GB3VR is at this location
I managed to get a P4 picture from the repeater using an Alford
slot antenna at a height of about 10 feet AGL and I am about 17 feet ASL.

Finally success with GB3IV

2011-11-21T22:36:00.002Z

I thought I would post a little note to say that I have finally managed to
get into the GB3IV repeater on the Isle of Wight using DVB-S at 4 Msps.
This evening I was able to join the SCART club's Monday evening net on
GB3IV. Everyone was very welcoming but then ATVers are a friendly lot.

VR is everywhere

2011-11-18T16:38:00.004Z

I am now able to receive GB3VR over at Brighton using an Analogue receiver
board from 13cms unfortunately it is so strong that it wipes out GB3IV and they
never seem to turn it off unlike GB3IV. Also I have included a picture of the
mast fully extended with a small Tonna antenna on the top for ATV.

7.6M Tennamast is finally up

2011-11-11T12:04:00.010Z

First the hole

Then some concrete

Then the base

Mast retracted

Mast extended

I would like to thank my next door neighbour Peter for helping me lift the structure in place.

This weekend I will add the rotator and DATV antennas.

Still life in old software

2011-10-06T09:33:00.010+01:00

Suddenly there has been renewed interest in some HF modem
code I wrote a few years ago. About 6 years ago I wrote an application
that implements the MIL-STD 188-110A serial tone modem protocol.
It was based on some Stanag 4285 code I wrote. The main reason for
the renewed interest has been the change of mission of U.S MARS
and their move away from Amateur Radio protocols towards military
protocols.

H.F channel equalisation is an interesting problem, simplistically an HF
channel can be modelled as a FIR (Finite Impulse Response) filter. What
follows is an overly simplistic description, sorry if I ramble on.

There are basically two ways of solving the problem. You either take the
received signal pass it through a filter compare it to what you are
expecting then use the error to optimise the coefficients of the receive
filter to reduce the error, this is the technique DFE uses.

The second technique is to estimate the channel response apply the
channel response to what you think should have been transmitted and
compare that to what you have received, update the channel response
accordingly to reduce the error, this is the technique DDE uses.
You then use something like the generalised Levinson-Durbin algorithm
to decode the data. It solves for a block at a time and then uses the
decisions to update the impulse response and then resolves the problem.
It does this a number of times before spitting out the results.

The new high speed MIL-STD HF waveform uses a technique called
Block Decision Equalisation BDE. This is an improvement on DDE,
the biggest change being the way it solves the block of data. The idea
was developed by CRC in Canada (I think).

Obviously estimation is fine when you are receiving the preamble and any
training information. When you are receiving unknown data you make a
decision on what you have received and assume that your decision is correct
and that is what you use to update your coefficients. I will let you dear reader
work out the consequences of this.

Often the channel impulse response changes faster than the equaliser can
update its coefficients.

There are many techniques to solve this estimation problem and each has
its own advantages and drawbacks. One major problem is the deep spectral
nulls caused by selective fading. These nulls cause issues with most algorithms
used to update the equaliser coefficients. Some assumptions are also made
in the nature of the impulse response to allow for mathematical short cuts
to be made, these assumptions are quite often the reason the modems don't
work as well as they could. The Eigenvalue spread of the channel impulse response
is often used as a measure of how easy a channel is to equalise when comparing
equaliser implementations.

So far I have tried 3 techniques for channel estimation and equalisation.
DFE decision Feedback Equalisation, DDE Data Directed Equalisation
and finally I used an FFT (Fast Fourier Transform) and worked in the
frequency domain rather than the time domain. All with mixed results.

Every now and then a new technique comes out to solve this problem,
most of the new techniques are really applications of old techniques in
novel ways, at least it keeps patent offices around the world in business.

One of the latest techniques is turbo equalisation, which uses an idea
similar to that used with turbo code decoders. The idea is to repeatedly
improve the the estimation (of coefficients and data) using iteration.
I have not investigated this idea yet.

Many PhDs are been granted for work in this field and I expect many
more will, I just play with this stuff for fun.

The reason I still remain fascinated with this topic is that it combines a knowledge
of nature (The HF channel), Linear algebra, numerical methods, computer
optimisation and just pure suck it and see (the last bit is the bit I like most).

One idea I have rolling around in my head is the idea of using a manifold of short
active antennas feeding a multichannel FPGA based receiver then separating out
the angle of arrival of the different paths and combining this with the modem
equaliser. As well as mitigating the effects of multipath it could also be used for
interference mitigation, another bane of HF radio. Like a lot of my ideas there
is probably some flaw in it that my brain is too small to realise!

Planning Permission

2011-09-21T18:39:00.003+01:00

Well I have some good news. I have received planning
permission for my 9 metre radio mast. I know 9m is
not huge but it should be adequate for my needs.
I had objections from 4 of my neighbours mainly on
the grounds of potential TVI. As I only intend operating
on 24 cms and above with about 15 watts I am sure I
won't be causing them any problems.

Of course now that I have drawn attention to my activities
I am sure I am going to get blamed every-time a mouse
squeaks (We live in an area that is very poor for TV reception).

TAPR/ARRL DCC and DATVExpress

2011-09-18T11:46:00.004+01:00

Yesterday Ken W6HHC and I gave a talk remotely via Skype
to the 2011 TAPR/ARRL DCC about DATVExpress the low cost
DVB transmitter board that we have been working on.
The slides will be available on the TAPR website sometime
in the near future. You will also be able to buy a DVD of the
whole conference later and listen to my 5 minutes of fame.

We are hoping that by the next DCC we will have some production
boards to show. Now that we have officially announced our efforts
I will be able to start blogging about them.

I have not been too active on here recently as I have been taking a
University level maths course and that has severely curtailed my R&D
activities. Hopefully I will be able to rectify that omission in the next
few months.

One step closer to getting a decent signal out

2011-08-05T16:05:00.002+01:00

I finally got a response from my local council about erecting a
proper mast for my DATV activities. The council in fact replied
to me about a month ago but the letter appears to have got lost
in the post. The view of the planning officer is that they are likely
to grant me permission as the plans are in line with the local
development plan and the structure is not excessive. It is likely
that the mast will have to be retracted when not in use as a
condition of the permission.

One slight fly in the ointment is that they will require a
"Telecommunications - Supplementary information" form to
be submitted with the application. This appears to be a
document design for cellphone antennas and asks many
questions which are not applicable to Amateur Radio.
Including whether I have coordinated my installation with
others operators, expected coverage maps, technical reasons
for the site selection and a load of other similar information.
I am trying to clarify with the local council if they really do need
this form with the application or whether they are just practising
a tick-box methodology.

A few steps forward and a few steps back

2011-08-02T20:05:00.002+01:00

First the good news, I now have 3.125 and 4.167 M Symbols per sec
working for DVB-S. Those are used by the Columbus Ohio TV repeater.

I have also been working on designing a four output switch mode power
supply. I am trying to just use parts from my junk box so the design does
not use any specialist chips just a load of op-amps. The original idea was
that it would take a 13.8v input and supply 12v, 10v 5v and -12v. That has
now changed and the PSU will probably produce 18v for my old laptop,
6v for the SDR, 5v for the MPEG encoder and 12v for the PA. Whether
I will be brave enough to trust a load of expensive equipment with my
SMPSU build on Veroboard is another matter!

Now for the bad news.

I have added code for 8 MHz and 6 MHz DVB-T channels, sadly the
interpolation and decimation ratios means that the processor
load has gone up considerably, unless I can find a way of reducing this
I am stuck. This is all due to the USRP2 having a fixed sample rate and
any weird rates have to get to that rate through interpolation and decimation.
The 7 Mhz version of DVB-T works well but that does not need the high
ratios that the others do.

The person that was going to supply me with a PA for 3.4 GHz is no
longer able to find it so it looks like I may have to go back to plan B which
is to use some of the pHEMTs I have to design a suitable amplifier.

3.4 GHz here I come

2011-07-27T10:21:00.004+01:00

These are 3.4GHz consumer units which are available on eBay for about £6 each.
They come in a sealed unit and consist of a transceiver board and patch antenna.
Out of the box they receive on around 3.45GHz and transmit on 3.35 Ghz.
The units are full duplex. For Amateur use it will probably be necessary to remove
the input and output diplexers replace the input with a cable for transmit and one
for receive. On the output insert a coax relay. The units are quite broadband
otherwise and should make a quite good transverter for 3.45 Ghz provided you use
an IF of around 900 MHz. The output is about 300 mW and the PA module can
be linearly biased. I am also expecting delivery of an ex-Ionica 15 watt PA.
Initially I will try both of them out on DATV but eventually I may use them on
SSB using the USRP2 SDR as the IF.

4M Dipole and AIM 4170 Antenna analyser

2011-07-15T22:48:00.009+01:00

For a change I put back up the 4M vertical dipole I use on FM. After I found
a duff connector in the feed line and did some adjustment to the antenna I
got the following plot, 70 MHz is in the centre. Yes when I connect the antenna
up to a real radio I get the same results as the 4170 measured. This is a great
piece of kit and the latest version of the software includes a TDR function. Which
correctly showed the position of the problem in my feedline. I have had this unit
for a number of years but as I don't do much antenna work this was the first time
I have used it in anger. I think I may be making some more antennas after this
pleasant experience.

The reason for the two overlaid plots is that they show the dipole with about
1cm change in length.

More on my S2-3600 software

2011-07-04T20:31:00.005+01:00

I have been adding the ability to parse the transport stream
from the dongle to my code. Once it has found the PAT it
finds the PMT and from that the Video and Audio PIDs.
It requires this information to tell the demux which transport
stream elements it needs to extract.

Currently I am waiting for some SMA and N crimp
connectors from China. Then I will be able to install
proper leads between the various modules rather than
the trees of adapters I am using at the moment.

The Chinese connectors have arrived (very quickly)
Unfortunately with the N connectors the centre pin
is slightly larger than the PTFE hole. With the SMAs the
centre pin hole is smaller than the RG58 cable inner. Both
problems can be fixed but considering I am using MIL-SPEC
RG58U from a proper source and that the connectors were sold
as RG58 cable ones I am a bit disappointed, but hey they were
cheap!

The Full DVB-S Monty

2011-06-30T18:25:00.003+01:00

This is a picture of my Linux box running transmit and receive on DVB-S.
Top left is the Xine display window showing a live picture, below that is the
DVB-S transmit program, to the right of that is the DVB-S receive program
(actually it controls a DVB-S card) and above that is the system load.

DATV Sender

2011-06-29T08:47:00.003+01:00

Here is a front and back picture of the nearly completed DATV Sender.
My first job was working for BBC Transmitter group this is why it is a
Sender rather than a transmitter.

Those of you that are not yet on digital TV, you don't need a radio this big to
get on. I have just been watching too many Hot Rod programs on Quest!

DVB API

2011-06-26T22:20:00.003+01:00

Well some progress, I have managed to write a simple program
using the DVB API to tune my S2-3600 dongle and to output
TS data (both video and audio) to the DVR device. Then read the
DVR byte stream and output that into a fifo which I can then open
using Xine and Voila I can receive DVB-S. I am certain there is a
better way to do all this.

I also got the Alford slot up on a pole in the backyard and can now
transmit DTV into a proper antenna. This is just a temporary antenna
but should be good enough for me to share pictures with the very locals.

When I have re-arranged all the junk in the 'transmitter hall' I will boost
the power from 0.5W to about 12 W. Well that was my weekend.

VLC

2011-06-25T22:09:00.002+01:00

I managed to get my QT4 app to open an embedded player window
and then play a movie file from disk. Next I will have to get the app
main window and the video window to appear as one program rather
than two floating windows. Then I will need to add the various buttons
to control the DVB-S/S2 dongle then pipe everything together to display
the received signal.

Of course the version of VLC from Red Hat is not the latest and the VLC
guys have changed the interface spec. Oh how I love Linux. I will just use
the old version of libraries for now.

I managed to get Jean-Pierres Tutioune program to work on the small dual
core Atom P.C that I built last week. With a bit of fiddling it locks onto the DVB
signal but as yet I have not managed to get a picture despite getting a good
lock and not dropping any transport packets. Tutioune seems to have a fixed
sized and my screen is quite small so it does not look very good at the resolution
I am using. I know how difficult it can be to write programs that work properly
on all screen sizes.

I am starting to get a fair amount of interest locally in digital TV so I am going to
have to get the Alford slot I bought up on a temporary mast just to give the locals
a test signal before they all loose their enthusiasm.

S2-3600 again

2011-06-24T06:32:00.002+01:00

After talking to Jean-Pierre F6DZP about his Tutioune software.
I had another look at the S2-3600 DVB-S/S2 USB dongle I bought.
I have managed to hack some code, that using the Linux DVB API
can tune the dongle to 1.3 GHz and lock onto my SDR generated DATV
signal. Next I am going to have to look at embedding Video inside a
QT4 application so I can make a homebrew DATV receiver. Most of the
Linux Apps for DTV are designed for broadcast reception and are not
convenient for amateur use. I have found an example of using the VLC
library for embedding Video so I will have a hack at that.
I will keep the transmit app and receive app separate

Planning consent

2011-06-16T08:45:00.003+01:00

In my pursuit of transmitting a decent DATV signal I have
decided to apply for planning permission to install a telescopic
mast at the G4GUO QTH. I have paid my £30 for pre-planning
advice and now await to be assigned a case officer. My application
is very modest, low profile mast and some UHF/SHF antennas.
I have done an artist's impression of the antenna and included
that with the other details.

In the past I have not bothered with planning permission and have
not had any complaints from my neighbours but as I am going to have
to spend a fair amount on the 'antenna support structure' (mast)
this time I thought it would be better to go the whole way and do
the job properly.

I used to have a 3 ele HF yagi on a pole attached to the end of the house
but in 1986 the winds blew, the antenna came done and brought with
it part of the wall of the building. Thankfully the insurance paid for the
damage. This time I aim to use a free standing mast!

Testcard first version

2011-04-24T18:08:00.001+01:00

I thought I would share the first version of the testcard with you.
At the moment it is not very complex but I will add further features.
I am currently using about 2% of the available RAM on the FPGA.

We have colour bars!

2011-04-15T16:11:00.003+01:00

Well believe it or not the FPGA testcard generator now generates some colour.
I promise you it has RGB then a grey scale, it is just the angle I took the photo
that makes it look strange.

It took me a while to get it to work because there appears to be a mistake in the
spec I was working from and also Verilog does not seem to like combining a
signed multiply operation and a register bit select operation on the same line.

There are still some timing glitches to work out before I can add all the fancy
stuff like my callsign. The program takes RGB input and converts that into
composite video.

FPGA Testcard prototype

2011-04-03T10:49:00.005+01:00

Well here is the prototype test-card generator with the Verowiring added.
So far so good as when the power is applied the Vref output from the chip
is at the right voltage indicating I probably haven't blown the whole thing
up yet. Next I will have to find and drill a suitable box. Next time I will do
a PCB for it. The wiring was tricky, at least there were only 48 to do. My last
attempt at this type of thing was in the 1970s when I Verowired my own
microcomputer! It did work btw.

Now it will just be software! Yippee

Well after a bit of hacking of FPGA code I am pleased to say the board seems
to work. Just a grey scale at the moment and the timing is not quite right but
it is going in the right direction. I only found one short on the board too!
I think it needs to be boxed next before I mess it up!

24 cms preamp

2011-03-19T12:17:00.004Z

Well after a real struggle with the semi-rigid cable I managed to finally
get the preamp into some sort of a box. The unit is powered up the coax,
the preamp has been slightly modified to extract the DC supply from the coax.
This also feeds the 18 GHz 12v relay. I managed to find a small quantity
of 12v relays rather than the usual 24v ones.

I must admit I don't really want to put the preamp outside any more instead
I am going to place it where the coax enters the building. That will still cut
down on the distance between the antenna and the preamp.

When no supply is applied to the coax the transmitter is switched straight
through to the antenna in a fail safe manner.

Comet CYA1216 16 element Yagi

2011-03-15T15:13:00.004Z

Well I couldn't resist it. While browsing eBay I found someone selling a load
of Comet antennas at about 1/2 price, so I now own one.

Having spoken to the keeper of my nearest ATV repeater G4PAP it seems
as if there are a few people in the area that are QRV on 10 GHz ATV so maybe
that is something to look at. The receive side doesn't look too difficult
(modified LNB) but the transmit side looks a bit more of a challenge.

It also seems like the repeater group would be interested in upgrading their
digital TV capabilities.

Alford Slot

2011-03-07T10:55:00.002Z

The G6NHG 1.3 GHz Alford slot antenna has arrived and very professional it looks too.

DVB-S Linux now working

2011-03-06T15:32:00.004Z

Finally I have managed to get my S2-3600 DVB-S/S2
USB Dongle to work! I was missing some codecs. I installed
FedoraPlus and then used that to install the codecs.

I have yet to try it with an Amateur TV Signal but it seems to
perform well with a satellite signal. My Laptop works well with
SD video but struggles a bit with HD video.

When I get the time I will have a go with szap2 and see if I can get
it to operate a 2 MSymbols/s. The card is capable of doing it so it
should all work. When I tried telling my Windows Viewer to scan
a satellite with a 2M transponder it froze!

More S2-3600

2011-03-04T07:52:00.002Z

I have now tried the USB tuner on a 32bit Ubuntu system
and I am getting exactly the same problem. It detects the
device but is unable to do anything with it. So now I know it
is not a 64bit Linux issue. At least I have good old Windows
to fall back on! A Google search was of little help so the problem
remains unsolved.

I have never used Ubuntu before. I am impressed with it's
ease of configuration compared to the Red Hat offering.

DVBS2 code update

2011-02-28T22:21:00.003Z

Well I finished writing the C++ DVB-S2 transmitter class today.
The final thing to do was to add the Gold code based symbol
scrambler. Next will be the difficult part, testing it!

It is interesting to note that S2 includes a 26 symbol preamble,
64 symbol modulation and code rate indication and the option of
sending pilot sequences in the transmission. This allows automatic
mode identification and enough information for a DFE (Decision
Feedback Equaliser) to be deployed in the receiver. Which makes it
suitable for channels with multipath.

The UHD driver for the Ettus USRPS has been upgraded, the main
improvement has been to further reduce the CPU load. I have not had
time to test it but a couple of releases ago the UHD load dropped
considerably, so much so that it became viable to transmit DVB-S using
my dual core Lenovo laptop.

I still have to get the 64 bit version of my DVB-T code to work. It will be
interesting to see whether I can get that to run on the laptop with the new
UHD.

S2-3600 and Linux

2011-02-26T18:50:00.003Z

Well that was a waste of time! I can't get it to work with Fedora 13 64bit.

After compiling the drivers and loading them. The green light comes on
to say it is working. Tried to use Kaffeine, it found the device but that was it.
The IR remote works and the dvb-utils indicate the front end is locked to
a satellite and receiving but no video or sound and when Kaffeine is scanning
it detects no signal but it does seem to detect transponders.

Other people have managed to get it to work maybe they
are using 32 bit Linux or something.

Enough time wasted on this I think.

TechnoTrend S2-3600 DVB-S2 USB receiver

2011-02-25T17:48:00.004Z

Well one of these arrived in the post this morning.
It is a USB based DVB-S2 receiver that uses the ST
chipset, one of the few chipsets that will decode DVB-S2
down to 2M Symbols/sec. Whether the BDA driver for it
supports that I don't know yet.

I have tried the unit under Windows7 with various DVB
receiving programs and it seems to work with them
However software decoding of MPEG4 leaves a lot to be
desired. Each program seemed to struggle in its own unique way.

I will have a go at running it on my Linux system in a couple of
days. I know that the chipset is supported as a PCI device.

On the transmit side of things I have done some more work on
DVB-S2. So far I have done the BB header encoding, CRC8,
required BCH codes, scrambler and the required
LDPC encoders for the different code rates. What I have still
to do is the modem layer for DVB-S2 and eventually for DVB-T2.
It is being done as a C++ class. I may migrate my DVB-S/T code
to a similar structure when I have the time.

For a test antenna I am going to install an Alford slot on one of the
"masts" at least I will be able to get out a signal while I figure out
how best to install the Yagi antennas. The Alford is coming from
Stuart G6NHG . I looked at making my own but I reckoned I would
end up spending more doing it that way.

Finally I notice that Ettus research are going to release a transceiver
board that will operate from 400 MHz to 4.4 GHz. That will give me access
to a couple more ATV bands. I better start saving!

Thats all for now.

Break over, testcard generator continues

2011-01-04T14:37:00.003Z

The lower of the two boards above is the cheap Altera EP2C5144 FPGA board
I bought from China. The board at the top is some perf board with a 3 channel
DAC soldered to it using an SMT adapter. It was not too easy to solder the SMT
part down due to the design of the cheap adapter board. The top board plugs
into the FPGA board. Hopefully I can get the grounds short enough.

I should now be able to wire the whole thing together with Vero prototype wire,
keep the connections short and not need to buy any Vero combs.

I plan to add a sync separator chip to the board so the unit can be used as a text
overlay generator as well as a test card generator.

Ti SHOP

2010-12-11T11:53:00.003Z

I noticed that TI are currently offering to pay the shipping
charges for items from their online shop. So I took the opportunity
to order a 16 bit 200 MSPS ADC card (ADS5485EVM) and
Altera adapter board from their shop (before UK VAT goes up).
That will be a project for next year.

I finally got the EP2C5 board and JTAG adapter from China it
all appears to work. I wrote a little program to test it out and
that works fine.

Next I have to wire up a board so I can use the Analog Devices video
DAC with it. I decided to use the Vero wiring system, unfortunately
I found my old wire pen but I couldn't find the combs used to hold the
wires in place. Vero only sell them in 100s and I only need about 10.
Consequently the project is on hold while I search every nook and
cranny of the house for the combs. That is always the way here,
finding things takes much longer than doing things!

As you may recall I intend using the EP2C5 board for a test card generator.
I had planned to use an external Xtal to generate the colour burst signal.
I have shelved that idea now and instead I am going to use a low precision
Cordic to generate the I&Q Colour Burst signal. By reducing the resolution of
the Cordic I can reduce the number of LE's required.

Still experimenting

2010-11-29T14:15:00.002Z

I have not updated the blog for a few days so here is what is going on.
Currently I am working on a simple SDR using the Terasic DE1 board
and the ADC/DAC board I bought.

Please bear in mind I am a novice FPGA programmer so this is taking
some time to do / learn. I have a working implementation of the Cordic
algorithm running on the board. It produces a sine and cosine output for
a given input angle. By accumulating the angle you can generate an oscillator
with two outputs that have a 90deg phase difference between them.
Looking on a spectrum Analyser the output is as clean as would be expected
for a 14 bit implementation.

The oscillator is used with a half complex mixer to translate the wanted
frequency down to baseband. The I and Q channels are then filtered and
decimated. I have the CIC filters written but not tested. A CIC filter is a type
of filter that is implemented solely with additions and subtractions.

Currently I am working on the I2C code to control the audio output codec
which will enable me to hear whether I am receiving anything!

The test card project is on hold at the moment. I am waiting for delivery of
a simple FPGA board from China. I have soldered the 3 channel DAC I received
from Analog Devices onto a small PCB. When I get the FPGA board from
the Middle Kingdom I will post some pictures and maybe a short Video when I
get the code working.

New toy update plus book recommendation.

2010-11-17T14:50:00.003Z

The Terasic board is now up and working.
I had a bit of a glitch, I initially fitted the board
incorrectly into its socket. Everything was offset
by 1 pin. Thankfully I didn't break anything but
it is a warning to anyone that buys one of these
boards be careful.

One other issue I noticed was that they (ADC/DAC)
are not DC coupled so the output of my testcard
generator code looks very strange. That is not
important as I am going to use a Analog Devices
Video DAC chip (ADV7123) eventually anyway.
I already have a couple of sample chips from
Analog Devices. I just need to layout the board now.
The 7123 has 3 x 10 bit DACs and a sync and blanking
input.

Today I received a used copy of "Digital Signal
Processing with Field Programmable Gate Arrays"
3rd edition written by U. Meyer-Baese, published
by Springer ISBN 978-3-540-72612-8 (774 pages).
Although I have only had a chance to glance at a few
pages of the book it looks like a book I can recommend
to others. It covers all the basic DSP and number theory
and has example code in both VHDL and Verilog.
The 3rd edition is reasonably up to date and covers the
latest developments in the use of FPGAs for high speed
DSP applications. It is also an accessible book (G4GUO
speak for even I can understand it).

New toy!

2010-11-09T11:05:00.003Z

The nice man from DHL arrived this morning bringing a new toy.
The toy which is at the top of the photo is a Terasic Highspeed AD/DA card
for my Altera starter kit. The board has a dual channel 65 Msps 14 bit A/D
and a dual channel 125 Msps 14 bit D/A. I ordered it on Friday and it came
first thing Tuesday morning all the way from Taiwan.

The Altera starter kit as well as having a reasonably large Cyclone II chip on it
has a USB interface, keyboard interface, VGA out, SD card, 24 bit Audio codec,
RS232 interface and a GPIO interface (which the AD/DA card plugs into) as
well as all of that it also has an EP2C20F484 FPGA, 8-Mbyte of SDRAM,
512K SRAM and 4-Mbytes of Flash memory. Plus loads of tutorials and
examples of how to use all these goodies.

I think you can see where I am going with all this! Looks pretty good as the
basis of a standalone SDR. I actually bought it to help me prototype an FPGA
DVB-S transmitter but more of that later.

On the move again!

2010-10-24T08:13:00.002+01:00

After a slight break from DATV, so I could revise for a maths exam
I am back. I started doing the maths for fun but things got a bit hectic
as the exam approached. Next year it is pure maths but whether I
will have the time to do that yet I don't know.

This week I bought a copy of "Advanced FPGA Design" by Steve Kilts.
I will post a mini review after I have read it. The book tries to show
you how to do FPGA designs rather than how to actually code (in Verilog).

I started doing some work on the FEC codes for DVB-S2 mainly building
the polynomial tables required for the BCH code (some have coefficients
to the order of 192). It is increasingly looks like the best way to implement
DVB-S2 and later DVB-T2 is in an FPGA.

I am also starting to get interested in the idea of using the DVB protocols for
transmitting blindingly fast computer data as well as for video. Probably
I will have to use DVB-S/T for the down channel and conventional packet
radio for the up channel in a similar way to how ADSL works.
Another idea would be a modified version of the PACSAT protocols. Just
using the slow return path to send fill requests for missing blocks.

I have an article appearing in the next issue of the TAPR PSR magazine
which will be available for download on the 1st of November. For those that
follow this blog there won't be anything new to read but I thought I should
try to spread the light of DATV to the unconverted.

DVB-S2

2010-10-08T11:06:00.003+01:00

I have started to look at the DVB-S2 specification again.
After a bit of research, the new error correcting schemes
and format don't look too difficult to do. The draft spec
I have could do with some clarification but I think I have
figured most of it out now.

The main concern I have is that the majority of the receiver
chipsets available seem to have a minimum symbol rate of
10 M Symbols per sec. The only one that seems to be able to
operate at a lower rate is the 6899 set from ST.

10 M Symbols per sec looks like it will heavily load the Linux
box. So I am a bit concerned as to whether it will be possible.
I need to be able to operate at that rate so that I can verify
my implementation is correct using an off the shelf STB.

I understand that the idea is being mooted of transmitting
1 M Symbol per sec DVB-S2 from the ISS. This should not cause
a problem for my Linux / USRP2 system. However at those low
symbol rates it is probable that I will have to implement a
decoder as well. Most of the presentations I have seen on DATV
from the ISS are for DVB-S but I also hear rumours.

DVB-S2 modules from Comtech

2010-09-12T15:37:00.002+01:00

I spent a while looking at DVB-S2 modules from Comtech
They do a number of DVB-S / S2 modules. The modules
are controlled using I2C and supply their decoded data in
Transport Stream format using an 8 bit parallel port.

The modules consist of an RF to baseband down converter
chip which outputs IQ data which is fed into the decoder chip.
They use a range of decoders DVB-T,DVB-S2,ISDB-T
8VSB etc from a number of different manufacturers.

Worth exploring?

FPGAs

2010-09-05T10:47:00.004+01:00

I am currently investigating the use of FPGAs for DATV applications.
Above is a small development board sold by KNJN . The picture shows the
basic Saxo board. With a few extra components these could be used for
caption generators or tescard generators. Larger FPGAs can of course
be used for DVB encoders.

My blog has been a bit sparse recently so I thought I better post what
I have been up to. Currently I am using Verilog and the Altera QuartusII
tool to play FPGAs. Verilog seems easier to understand than VHDL but
whether I have chosen the best one for a hobby engineer I don't know.

I am still here!

2010-08-27T18:12:00.003+01:00

I have not abandoned the blog. I have just been fiddling
with antennas and playing with FPGAs.

Here is an interesting link that will be worth watching

One more DATVer in the world

2010-08-09T08:26:00.002+01:00

I would like to congratulate Al W8KHP on getting
his USRP2 DATV system up and running for the first
time this weekend.

64 Bits

2010-08-07T12:18:00.004+01:00

This is a picture of the 'portable' setup which consists of a Laptop running
64 bit Linux, a USB video capture / mpeg encoder, JVC camcorder and of
course the USRP2. The system is sitting on top of my big rig rack.

To get the system to run on 64 bit Linux I had to make some slight changes
to the Assembly code (mainly to replace push %eax with push %rax).
At the moment only the DVB-S mode works under 64 bit, DVB-T will require
a bit more work. So far it seems better under 64 bit than it was under 32 bit.

I have also almost completed the K1FO designed 70cms Yagi. I am just waiting
for a few bits to complete the driven element. I have changed the design slightly
in order to make the feed arrangement more robust. Electrically it should be the
same. I bought the tubing and insulators from Sandpiper Aerials which made it a
doddle to put together. Without the drill press I bought a couple of years ago
I would not have been able to achieve the required accuracy for the element
mounting holes.

1080i HD

2010-07-28T14:57:00.003+01:00

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.

A short video

2010-07-26T21:33:00.004+01:00

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.

70 cms here we come!

2010-07-25T17:05:00.003+01:00

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

2010-07-20T08:16:00.003+01:00

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!

I can see

2010-07-18T10:19:00.004+01:00

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.

OFDM Tone correction

2010-07-15T16:02:00.004+01:00

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!

Look no ears!

2010-07-13T22:18:00.004+01:00

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.

when is HDMI not HDMI?

2010-07-12T21:28:00.004+01:00

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.

Hauppauge PVR-HD Board shots

2010-07-11T14:59:00.003+01:00

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.

HD-PVR assimilation

2010-07-10T16:39:00.004+01:00

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!

IEC/ISO 13818-1 and H.264

2010-07-09T22:16:00.004+01:00

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.

Further thoughts on HD video

2010-07-06T22:02:00.002+01:00

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.

My July 4th DVB-T2 ramblings

2010-07-04T22:27:00.005+01:00

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.

Comtech module dead end

2010-07-02T16:30:00.002+01:00

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.

Comtech BSU479LX1DS Modules

2010-06-27T16:18:00.005+01:00

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.

CUDA continues

2010-06-26T07:35:00.003+01:00

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.

NVIDIA CUDA

2010-06-23T22:22:00.003+01:00

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.

Teletext part 1

2010-06-21T22:29:00.002+01:00

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.

DVB-T EPG now works

2010-06-20T14:57:00.004+01:00

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.

DVB-S EPG now working

2010-06-18T17:50:00.005+01:00

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.

WBX power issue fixed

2010-06-17T22:12:00.002+01:00

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

LDPC

2010-06-16T22:11:00.002+01:00

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"

STBs are not all the same

2010-06-15T22:06:00.004+01:00

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 :-).

Spectral re-growth

2010-06-12T11:06:00.005+01:00

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.

1.3 GHz Driver amp

2010-06-11T14:08:00.003+01:00

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.

DVB-T on 436 MHz

2010-06-09T11:25:00.005+01:00

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.

DVB-S2 and DVB-T2

2010-06-08T08:19:00.003+01:00

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).

Success at last DVB-T works

2010-06-06T15:45:00.008+01:00

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.

Frustration

2010-05-29T21:45:00.002+01:00

Well I have had a frustrating few days. With little progress.
First problem was the FFT routine I am using. There appears to
be some artefacts in the iFFT output in the bins around N/2.
Whatever I do I can't get rid of them. They are not in the bins
I am using for the OFDM but they produce unwanted out of band
signals.

The next problem is trying to calibrate out the DC offset in the
WBX up-converter. I was told it was easy to do just a few lines
of code! It is more complex than that. The principal is simple
getting it to work reliably is not.

On the bright side I received the 7660 negative voltage converter
chips I ordered from Taiwan all 30 of them. A life times supply at the
speed I build things.

I am going to have to take a break from all thing Amateur radio in the
next week or so. I have some maths homework to finish, I have already
put it off for far to long, playing with the USRP2 is just too much fun.
I will be back after June 9th.

DVB-T

2010-05-25T17:38:00.004+01:00

I have now started to debug my DVB-T implementation. As you can see
from the picture it looks like the P.C is fast enough to do real-time DVB-T
encoding. The iFFT used to generate the OFDM signal is a piece of MMX
code I found in an Intel appnote. The signal is about 7 MHz wide.

UHD Updates

2010-05-21T22:08:00.007+01:00

Re-did some of my code which dropped the CPU load from 70% to 45% on one core.
Then upgraded to the latest version of UHD which caused the load to drop to 35%.
Of course the UHD upgrade broken everything and I had to spend a while figuring
out what had changed in the libraries. The ATC chip capacitors arrived this
morning for the driver amp. I need to find a suitable heat sink. The ones I wanted
were out of stock.

More GUI

2010-05-19T22:11:00.004+01:00

I managed to get some more work done on the GUI today.
I added the ability to configure the transmitter to
operate at 2,3,4,5 and 6 M Symbols/s and I can also control
the frequency and power level. I am starting to really like
the QT4 development environment.

PUFF

2010-05-15T21:25:00.003+01:00

I have been playing with PUFF http://tiny.cc/j14ne for a couple
of days. I need to boost the output of the USRP2 to fully drive the
24 cms PA. I bought some FPD4000AF 4 GHz pHEMTs they are
4 watt devices and you can get them for about £1 each. Whether I
will be able to design a suitable amplifier only time will tell. At £1 a
pop it's worth a try. Will keep you posted.

More Xine!

2010-05-12T10:34:00.003+01:00

In the picture above the left screen is the Linux monitor. It shows the DVB
transmitter application running. The window to the right is Xine and is
displaying the transport stream generated by the DVB software.
The screen to the right is the same signal being decoded by the satellite STB.

The next challenge is to write the DVB-S demodulation code so the USRP2
can be used both for transmit and receive.

Xine

2010-05-11T17:58:00.003+01:00

After a day spent deep in the entrails of my Linux box
I managed to take the transport stream generated
by the M0DTS DVB-S system and feed it into Xine.
This allows me to display the transport stream as
a picture in a Linux window.

So what you might say.Well, I know about transport
streams, in fact I generate them in my own code.
So when I get around to implementing the receive side
of DVB-S I now know I will be able to display the
audio / video in a Linux window from the demodulated
transport stream.

I had to use a tool called Autoten to get a suitable codec as
Xine kept telling me it didn't have an MPEG 1/2 codec.
I also had to fix the auto update in my Fedora 12 installation
but that is another story.

U.H.D

2010-05-10T14:52:00.002+01:00

I am pleased to report that the software is now working
with the new Universal Hardware Driver (UHD) from
Ettus Research. This will allow me to have much greater
control over the USRP2 + WBX from within the GUI.

1.3 GHz GH Engineering PA on test

2010-05-08T19:11:00.003+01:00

Finally the missing parts arrived and I was able to do some testing of
the 1.3 GHz power amplifier. The output is only about 1 watt at the moment.
There was a lot of lossy RG58 cable between the USRP2 and the test bench hence
the low power.

One thing I found was that if the SMA connectors are not screwed tight you loose
quite a lot of RF. The two black cables inside the amplifier are scrap semi-rigid
cable covered in heat shrink sleeving that I bought on eBay.

I am not the worlds best metal worker but the case, which was made from
pieces of U channel aluminium and flat plate is enough to maintain the PAs
modesty.

I also made some changes to the Software. The idea was to reduce the amount
of memory it requires so it would work better on the laptop. A nice by-product
of the change has been a significant reduction in the system latency.

Hauppauge WinTV USB2 PVR and a Laptop

2010-05-07T19:49:00.002+01:00

The used USB PVR arrived this morning so I thought I
would try it out with my laptop. The laptop is a dual core
2GHz machine with 2G of memory. After a few teething
problems (I had to reduce the ram usage of my program)
I managed to get it to work transmitting 4Msps video. So it
looks like I now have a way of going mobile. The CPU load
is around 60% on both cores.

Interestingly the port ids on the USB2 PVR and on the
PCI PVR seemed to be swapped. Took me a few minutes
to figure out why I was getting a black screen. I also noticed
that the USB2 PVR seems to work a bit better than the PCI
one does with the software. The PCI unit does not like changing
parameters when streaming video. The USB2 unit does not seem
to care.

This is not what I meant to do today. I had hoped to do a bit
more on the GUI. Yesterday I managed to get the DVB-T code
to compile and run. It is no where near working correctly though.

System block diagram

2010-05-04T07:35:00.007+01:00

This is the block diagram of the system. The bold text in the centre box
shows the parts of the system that have been implemented in the software.
The block diagram was drawn using free schematic software from PCBExpress.

Although using a USRP2 for Digital Television may appear expensive,
the USRP2 SDR can be re-programmed to implement virtually any type
of radio you desire. I consider it the best value radio I have ever bought.
The USRP2/WBX cost about the price of a new TS2000.

A picture paints a thousand words

2010-05-03T15:21:00.004+01:00

The SI tables are now working (all except the EPG information) and I have
also fixed a bug in the interpolation filter. It won't be long before I make my
first transmission at full power (10 watts). I am just waiting for a 99p part to
finish off the amplifier.

DVB Primitive GUI

2010-05-01T14:56:00.007+01:00

Above is the first primitive GUI for the DVB-S transmitter.
The GUI is based on QT4. The visible tab is the one for the
various FEC rates available in DVB-S.

I now have direct control of the Hauppauge PVR500 card using
the v4l2 API. This is necessary as the video bitrate needs changing
when any of the parameters are changed like the FEC code rate.

Originally I wrote the program in standard C but to make it easier
for me to integrate with the GUI I have changed the files to C++.
The whole DVB transmitter can now be developed from within the
QT4 development environment. For someone that is not a Linux natural
(I have used Visual C++ before) being able to use a visual development
environment again is nice. I know I have just upset the Linux hardcore
but that is the way it is.

Before I can proceed much further with the development I need the
new UHD for the WBX board. This will allow me to control the
transmitters frequency from the GUI.

I will probably finish off the 1.3 GHz PA next and will also have a think
about the GUI layout. Eventually I want to add DVB-T and when I have
figured out how best to do it, DVB-S and DVB-T receive.

Still no cigar

2010-04-29T14:11:00.007+01:00

The SI tables are still not working. I have a set of SI tables provided by
Rob M0DTS and they work.

I have code that provides identical tables, same contents, checksums etc
and they don't work. Obviously I am missing something. I will figure it
out eventually.

On the theme of GUIs I have decided to use QT4 developed by Trolltech
(now owned by Nokia). http://qt.nokia.com/ I am setting up the
development environment as I type so more on that later.

I have also been looking at all the DVB applications available for Linux.
I just wish I knew what they all did. Hopefully down the line it will be possible
to add receive support to my software using a suitable Linux tool.
I will have to do the demodulator but once I have the program stream extracted
it should be possible to feed that to a 3rd party tool for display.

I am ramping up my enthusiasm for the new UHD (Universal Hardware Driver)
from Ettus Research http://www.ettus.com/

This will allow cross platform support for their products. It will also allow closer
integration between my code and the USRP2. Currently no support for the WBX
transceiver board I use exists but it is coming. So watch this space.

I am always keen to hear from anyone reading this Blog, if you have any
comments, criticisms, advice or questions please contact me, I don't byte.

I am getting there

2010-04-26T15:14:00.003+01:00

Today I have a picture of the Tonna 24 cms 23Ele Yagi
that I am going to use for TV transmission. I know some
of you have seen these before but some haven't.

Minor success to report today, I finally managed to get
my code to read Elementary stream packets from the
Hauppauge PVR card, turn them into transport stream
packets, then do all the FEC etc and transmit the result
using the USRP2.

The waveform you can just about see on the Spectrum
analyser under the antenna is the resulting 4 Msps
DVB-S signal. It is a lot more stable than it was before.
The CPU load to do all of this was 50% on one of the
cores. The others are doing virtually nothing.

I still have to fix some problems with the SI packets I am
sending but I am pleased with how things are going.

I am starting to think about a GUI for it :-)

Me and my DATV system

2010-04-22T18:14:00.003+01:00

This is me sitting in front of the camera!
This is being sent at 2Msps.

This is the DATV system located at the end of the workshop.

Visible is the Linux monitor, the TV monitor, camera and STB.
Below the STB is the DATV rack with the exciter and Linux machine.

Work progresses

2010-04-20T06:48:00.004+01:00

I have ordered a load of aluminium angle
to build boxes to go around the GH Engineering
PA amplifiers. I will post some pictures
when the job is done.

USRP2 Topless photo!

2010-04-09T14:47:00.004+01:00

I am sure you all want to see what my USRP2 looks like with it's top off!

Things are going a bit better now, having changed the way my
software talks to the USRP2 I am now getting a much more reliable
DATV transmission. I still have a load of code to write but it looks
as if the whole thing is going to work (a huge relief).

The last couple of days I have received some 18 GHz SMA relays
from the U.S and some bulkhead N to semi-rigid cable units from
the far east as well as a waterproof plastic box for the preamp.
So on the hardware side all that is missing is the PA module which
should be here soon.

G4DDK 24cms preamp

2010-04-06T16:12:00.003+01:00

As promised I have uploaded a picture. This is of the G4DDK ultra
low noise preamp I built for use on DATV.

Work on sorting out the drop outs of the DATV signal progresses.
After some testing it seems the Ethernet link between my P.C
and the USRP2 is fast enough to sustain the DATV signal so
there is hope that I will be able to get the whole to work reliably.

More DVB

2010-04-05T11:32:00.004+01:00

I spent far more time that I meant to on
DATV S/W development yesterday.
I have started to integrate some of the MPEG2
transport stream code into my DVB-S modulator.

One problem is keeping the modulator fed with the
correct number of bits. The original S/W I used
required calculation of the various stream bit rates
so that the correct number of null packets can be
added to pad it out to the wanted transmission bit rate.

To automate the process I have added the ability
for my code to monitor it's transmit queue length.
When the queue length falls below a certain threshold
it will now inject null transport packets into the
transmitted bit stream to pad the bit stream out to
the wanted transmit bit rate.

Gradually I will add more of the required packets
into the bit stream from my MPEG2 code and drop
the corresponding packet types from the original
set-up.

I still have a problem though, the link between
the USRP2 and the P.C keeps dropping out for
a fraction of a second which causes the
transmission to momentarily break up.

What I am trying to do is well within the capabilities
of the USRP2 so I suspect I have not set my Linux
box up correctly to deal with the Ethernet interface.
Hopefully I can get this sorted out otherwise I am
going to have a very very major problem.

I know this Blog is getting a bit dull without any
pictures but most of the hardware I am using is
standard off the shelf stuff that can be found using
Google but I will try and put up some pictures later
in the week. I have not figured out how to take sexy
pictures of software yet (suggestions on a post card).

DVB-S Encoder

2010-04-01T18:39:00.006+01:00

Not much done since my last blog.
I still need to figure out the best way
to do the sample rate conversion.

Tested the code puncturing modes in
DVB-S all of them worked except the
7/8 rate code. The comments in the
code and the code matched, unfortunately
the puncturing mask in the spec didn't!
Now fixed (both code and comments).
The code puncturing is used in -S and -T.

Spent some time looking for a suitable
waterproof box for the mast head preamp.
All the ones I could find in my workshop
had the wrong type of holes in them.

2010-03-30T07:54:00.002+01:00

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.

2010-03-28T16:04:00.002+01:00

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.

2010-03-22T08:09:00.002Z

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.

2010-03-20T08:55:00.002Z

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.

2010-03-16T07:18:00.002Z

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.

2010-03-14T11:44:00.003Z

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.