Dennis Frie created the DIY_OSD to run on Arduino for RC plane FPV. It also runs on a current Flytron board and on the older board with a couple of hardware mods. The main discussion thread on RC Groups.

The Flytron board is available here.

GPS Problems

I’ve been using V17 on a older Flytron board for some months when one day recently the GPS data became unreliable. To help solve the problem I wanted to display satellite numbers during flight. As I’ve not done any serious Arduino programming, it was time to learn at least enough to get it done. So I got the latest code and started reading. I’m using the latest Arduino 1.something, running on Kubuntu 10.04 Linux and a USB-ttl interface that came with the Flytron board.

It only took a few hours of reading and experimenting to get the information I wanted on the screen. So I’m still working on the GPS problem.

The trick with loading the sketch to the Flyron board is to click to start the load, count to 3 then power up the Flytron board. This gets the bootloader and the Arduino programmer in sync. It seems to take ages to load a 30K sketch as I’m used to a few seconds for the PIC programmer.

Data in unused image lines

While looking at the code I decided to see if I could send GPS data back to the ground station embedded in some unused lines of the video signal. It didn’t look too difficult so I set to work.

There’s not much CPU time or memory left available for adding features. I tried making a pattern to shift out effectively reducing the bit rate but this didn’t work; I think it was running out of RAM. The next attempt was to clock the GPS data directly into the video line. The clock rate was too fast and would make decoding more difficult, if it wasn’t distorted on the way through. It is possible to reduce the SPI clock rate during the data output which effectively slows the data. I also added a header to assist with decoding and a simple check character on the end.

I wanted the data asyncronous, having a fixed bit rate to simplify decoding. The problem was that although the SPI clocked the data bytes out steadily, it was too difficult to make all the gaps between bytes the same. The SPI transmit is not double buffered and I didn’t want to use the ready flag so the answer was to make the gaps larger and make every byte begin with a rising edge, in this case a 1. The header includes a pattern that will let the receiver asses the bit rate before the data arrives for each line. I did find that if I loaded the SPI data register before the last byte was sent the data output stopped.

The dimming is applied during data transmission to provide better contrast for the bits and hopefully easier detection. The camera I’m using for testing, a HobbyKing $20 CCD, outputs reasonably quiet black lines for the first 19 or 20 lines. So detection shouldn’t be too difficult as long as the shortest bits are not distorted. I don’t know yet how noise on the video link will affect this but suspect it will introduce extra bits.

The data sent includes latitude, longitude, altitude and a couple of alarm bytes. The data bytes are all 7-bit ascii with a 1 for bit 8, sent MSB first (I think). It’s sent in 3 video lines; 14, 15 and 16. With header, check and gaps it’s about 20 bytes in 80% of a line.

For testing I set the lines to 75, 76 and 77 so that they appear in the image. Also the LED is turned on for the header of the first line providing a sync for the oscilloscope for easy viewing of the data. During testing a lens cap on the camera provides a black background; well low level noise actually.
.

Decoding

.
– updated 21-May-2012

The main problem is that although the data can seen on the received video signal, the amplitude varies and it’s rounded off almost to a sawtooth shape. This may become worse in real use.

Decoding is tricky time critical during the data capture from the video but this is only for 3 video lines per frame and we don’t need to capture all frames. One frame per second would be enough for antenna positioning and data logging. If the RC plane is nearby, antenna direction is not so critical as the signal level is quite high. When the RC plane is further away the apparent movement is slower and updates can be less frequent.

Decoding will use a PIC micro. The video signal is AC coupled to a high speed comparator with adjustable level to square up the data. The video is also AC coupled to a LM1881 to detect frame and line start. The LM1881 interrupts the PIC on frame start, the PIC counts to the data lines and waits for the rising edge of the data then immediately starts the SPI to clock in one byte. It disables the SPI and waits for the next rising edge etc. Once enough bytes have been buffered in the data is checked and flagged as good or bad.

The PIC knows which three lines contain data and how many bytes to capture on each line. A new line interrupt before all the bytes are captured indicates a problem and the line is discarded.

I’m designing a circuit board for the decoder as it’s easier than modifying an existing board. The new board will include the video input, comparator, LM1881, PIC18F2525, GPS receiver, 24LC512 for logging and serial port. It will operate from 9-15V DC and eaves-drop on the video signal from the receiver or diversity controller.

The board will drive two servos and an alarm. I thought about stepper drive, but servos are cheap and easy to use. A standard servo can directly drive tilt and can be geared or modified to drive pan.

I’ll probably write the PIC code in assembler. I may also have a look at Pinguino again. This is a PIC version of Arduino but it only supports a couple of PIC chips with internal USB and no UART. A major shortcoming from the Pinguino developers.
.

In Use

.
– updated ..

As the antenna needs to be stationary and aligned, probably to north. It has a GPS receiver so it knows where home is.

The alarm can indicate loss of track or a voltage alarm from the plane.
.

A bit more detail

.
Putting the data into the video stream is the easy part in the DIY-OSD. Detecting the data reliably at the decoder is more tricky.

This is still a work in progress. I don’t know yet if it is going to work or be reliable. In theory, it should work if the video image is OK and there is lots of redundancy. It would only need a good frame every few seconds to keep up with a distant model. With the data split into 3 lines, a bad line only looses 1/3 of the data, which could be corrected on the next line.

With the HK ckeap CCD camera that I am testing with, the first 18 lines contain no video ie. a quiet black level. This means that data has good definition against the background. A data 1 is the same as a white text pixel.

[B]Encoding[/B]

It waits for video line 14 then places 3 lines of bytes (1=white, 0-black) by writing bytes to SPDR. Delays are needed between bytes so they don’t overwrite and the SPI clock is reduced back to 1/2 speed (4MHz) for the data lines. Data includes lat, log, sat-cont, batt-alarm and mah-alarm.

A header pattern of “11111111 10101010” starts each line of data and a check character of the XOR of all data bytes with the msb =1 (OR 10000000).

The gap between bytes is variable depensing on the code and timing delays between bytes. Longer gaps make the bytes easier to see by less data per line. So that the decoder can find the start of each byte the msb (1xxxxxxxx) is set high. This leaves 7 bits for each character which is OK for acsii; just do “AND 01111111” on received data.

I may have to adjust the byte spacing timing as I work on the decoder.

[B]Decoding[/B]

This uses a LM1881 to detect frame and line syn and interrupt the CPU. The CPU counts to line 14 and waits for a rising edge. It starts the SPI transmitting 1 byte which clocks in 8 bits of data on MISO. If it’s fast enough to start the SPI it will read all 8 bits but if not a 1-bit delay will allow it to read 7 bits + 1 from the gap. This would need a simple rotate-right to correct.
Every byte starts with a rising edge of the first bit (1); so after receiving 8 bits the SPI is stopped and the CPU looks for the next rising edge to repeat the process for the number of bytes expected for each line.

When 3 lines have been received and checked the actual position data is updated. Bad lines are counted and could be alarmed or other action taken. The CPU is very busy during receive of each line, looking for rising edges and delaying. I will disable interrupts during each of the 3 lines and just run, probably with a timer based exit for when something goes wrong.

After the 3 lines are received there is plenty of time to work with the data or do other things. The OSD sends XX frames per second but only updates the data occasionally, so there are repeats sent of the data. The decoder could decode all frames or just occasionally. I thought about adding a counter or update flag to the 1st line header to signal the decoder that new data is available, but I haven’t done this yet.

I have designed a pcb (VAT_1A1) with a high speed comparator to detect the data from the composite video. The board also has eeprom, gps and a 5V servo power supply.

• This topic was modified 11 years, 11 months ago by PMB.
• This topic was modified 11 years, 11 months ago by PMB.
• This topic was modified 11 years, 11 months ago by PMB.
• This topic was modified 11 years, 11 months ago by PMB.
• This topic was modified 11 years, 11 months ago by PMB.
• This topic was modified 11 years, 11 months ago by PMB.