Poor Man's Digital ATV Transmitter Project
New USB Interface & Serialiser
March 2009 Update!
Thanks to Cesco HB9TLK for his implementation of a new serialiser chip i have now managed to send Digital ATV from pre-recorded files using the USB port of the pc rather than the parallel port in the original design, The information is below and still very much work in progress.....
The new version of the serialiser encorporates part of the software process to reduce the required bandwidth to the transmitter - this is the Viterbi FEC encoder and at 1/2 setting it reduces teh data sento to the serialiser by half, so for 1024 symbolrate it only requires 1024Kb/s transfer rate from the pc rather than the 2048Kb/s with F4DAY serialiser, this makes it easier to acomplish with a USB interface. It also uses an Atmel 2313 chip which is a lot cheaper and in a more friendly package!
The USB interface is based around the FT245 USB<>Parallel FIFO chip and provides a buffered data stream via the usb bus to the serialiser. This is far better than the original design using the pc's parallel port and DOS OS to make it work correctly.
The main problem with using the USB bus is the interrupts in the data flow, these cause some bytes to be lost and corrupts the overall data output of the FT245 if it is being used at high data rates. This is just a rough guess but i think that about 64KB/s is about the limit for lossless transfer, above that i see the RXF flag start to show that the FT245 FIFO is running empty. The TX buffer on the FT245 is 128 bytes and I guess this is obviously not enough for the high data rates that is says it can acheive on its own.
At 128KB/s I noticed *up to* 1.5mS 'gaps' on the RXF pin at random time intervals, by calculation you can see that this is 0.0015Seconds x 128000Bytes = 192 Bytes 'gaps', this is more bytes lost than the FIFO buffer is capable of holding so some errored data was still being read if the serialiser was connected directly to the FT245 chip.
The TX FIFO buffer in the FT245 is 128Bytes so when there is an interrupt the buffer can be empty briefly and no data could be read from the device, the data that is needed for the serialiser is a continous stream without any gaps. To fix this problem i have used another FIFO buffer in-between the FT245 and the serialiser, the buffer is 1K bytes long so in theory i should be able to transfer maybe 4 or 5MB/s without errors......
To control the clocking of each byte of data from the FT245 into the FIFO chip I had originally used a PIC16F84 but this proved to be too slow if I wanted to do higher data rates than 1024Kbit/s. I have since replaced this with some logic gates and another oscillator, the timing is not as good but seems to be good enough to clock data into the fifo at a few Mbit/s. I'm going to try and use another pc to read this data after the buffer at different read rates to check it is working correctly.
All of the parts mentioned are available from Farnell in one off pieces.
For the FT245:
The RD pin is pulled low to load a new byte of data on the FT245 parallel port.
The RXF pin goes high when there is no data available on the FT245
For the FIFO:
FF goes low when the fifo is not full.
WEN1 needs to go low before WCLK to enable a valid write to the fifo.
WEN1 is tied to RD so that a byte is presented on the FT245 parallel port before WCLK
WCLK is the main Write clock to the fifo, is is triggered on falling edge also.
The above effectively only lets a byte be written to the fifo if the fifo is not full and there is a byte available on the FT245, the main write clock runs quite fast on my test circuit @400KHz to overcome the data gaps upto maybe a few Mbit data rate.
I guess any FIFO chip could be used as long as it can read and write at the same time at different clock speeds.
Currently it takes two programs to make a valid video stream ready for the transmitter, this makes it very difficult to make a near real-time video stream as the delays between programs can be quite large. I use VLC to generate a MPEG TS stream and use TS188toIQ to convert the stream into the correct format for the serialiser.
VLC settings for 943Kbit TS: - These are rough settings, depends on video content - VLC does not do CBR encoding.
MPEG TS encapsulation
Video Bitrate = 768Kbit
Audio bitrate =32Kbit - Mono
These settings give you near enough the correct bitrate of 943Kbit to feed into the TS188toIQ program, if this bitrate is not right you will see stuttering of the video/audio as the symbol rate will not be the same as what the receiver is set to. You can use a transport stream analyser program to examine output stream file to check if you have the corret output bitrate.
To calculate the required TS bitrate for a certain Symbol rate and FEC:
Note: The RS ecoding adds 16 bytes per MPEG2 TS Packet (188 bytes) giving 204 bytes.
Required TS bitrate = (2 x symbolrate) x (188/204) x FEC
For symbol rate of 1024 and FEC of 1/2: = 2048 x 0.921 x 0.5 = 943.1Kbps
Work is in progress for an intermediate piece of software to take the UDP stream from VLC and put it into the correct format to drive straight into the serialiser via USB, this will give us near real-time DATV. Curerently I'm using a VB6 program to automatically sequence the recording/mux/encoding software and generate video but about 45seconds beheind real time.
Once I have tweaked the current setup I would like to make a new PCB layout to give IQ output from USB data input, I also hope to re-design the modulator board and possibly build it all onto one board so that we can have USB in and RF out!….. We shall see if i get time to do all that...........!
Development schematic...
Updated Schematic of USB Serialiser - 15th May 09 - Click to enlarge
Current setup:
Improved constellation with new serialiser, see original above:
Related documents: