Project 10 - Telemetry data sent in Vertical Blanking Interval of a video signal

(Chris, feel free to move this discussion to a different section of the forum..don't know if you want to do a separate section for these forums or whatever)

I'm looking forward to working with Remzibi on this :-)

Chris, it would be helpful to me to understand what you're goal is for this project. I'll toss out a couple of ideas I've had and some background on related technologies.

This capability could be used to permit a system with an autopilot and FPV that sends telemetry from the aircraft to the groundstation/laptop via the FPV video signal rather than requiring a separate XBee link? This would only be a one-way data link, of course, from the aircraft to the ground.

This would also permit you to move the video overlay function to the ground unit if that was desirable (i.e. send telemetry and the camera video in a single video channel and then do the overlay on the ground rather than in the aircraft which would save some weight/space in the aircraft. This might also address the situation where the autopilot and the OSD both want to connect to the same set of sensors (gps, airspeed, etc).

Here's some background on combined video/data technologies from my own knowledge -- I worked on some of this technology a long time ago -- and wikipedia. There are at least two different services that currently transmit ancillary data in the (non-visible) lines of a standard NTSC or PAL video signal. Those non-visible lines are referred to as the vertical blanking interval (VBI).

In the US, the Closed Captioning service uses line 21 of the VBI to send text subtitles along with the video and audio. It has a data rate of 960 bits per second. Most if not all NTSC television receivers decode the closed captioning and can optionally display the text on the screen overlayed on the video images. You can specify the position on the screen where you want to the text to appear but I believe it is a fixed character set.

In the UK a service called Teletext was developed in the UK and, as I understand it, is/was in use throughout Europe to embed digital data for information services in the PAL video transmissions. This standard supports significantly higher data rates than the Closed Captioning service -- up to 7k bits per second per line used with the potential to use up to 17 or 18 lines in the VBI. I believe that many PAL televisions include hardware to decode and display the teletext data with the ability to overlay it on the main display.

For our purposes, of course, we would like to insert serial data from the autopilot or other airborne device into the transmitted video from the aircraft and then extract that serial data stream from the video receiver on the ground and feed it into the groundstation, laptop, or other hardware. We might be able to use existing Closed Caption or Teletext solutions or just do our own insertion and decoding of data into the video signal using custom hardware/software.

As a next step, I thought I would check out video transmitter/receiver hardware used for FPV to see if the components they use happen to support VBI data insertion/extraction. Any favorite video tx/rx hardware I should look at first?

Comments welcome!


Views: 2141

Reply to This

Replies to This Discussion

Hi Dave,

From Project 4 (Design the hardware for the ArduPilot Mega ground station)
The GS will only have an XBee, at this stage, and be Rx and Tx. This implies that there must be XBee on board as well. The self contained GS, ie. no PC/Laptop, won't have the hardware to decode Video or rather it may be to expensive to do the video decode.

Its early days yet, so I may be wrong here, the team has not started yet ;) and may decide otherwise :)

Sarel Wagner
The idea is to use the closed caption or Teletext to control a directional antenna on ground. We only need to transmit around 40 bytes for second (and maybe less), including latitude, longitude, altitude, speed, heading (the last two for antenna dead reckoning) and checksum. Also this information can be "recycled" to display the actual position of the aircraft on google earth and datalog the flight.

Some other requirements:
-Must be an independent and easy to adapt system (optional product).
-Compatible with PAL and NTSC
-Keep the original OSD system on the aircraft (no overlay the video on ground).

Also some other OSD like Dakar, Eagle Three and RangeVideo OSD already have this feature.

I really think in the long run it will be necessary to have a bidirectional telemetry link (channel). Instead of using the unidirectional path of the video link, why not concentrate on establishing an efficient protocal with the serial ports. Simple, easy to understand, no additional HW, and easily expanded. IMO, just dumping the raw GPS, sensor data, and status to a downlink serial port and post-processed by a ground station would be ideal. It off-loads any extra processing the AP has to do. It will also open up the ability to upload realtime information such as waypoints, configurations, or other data to the AP in realtime. As the hardware improves and changes, the legacy HW/SW could still be compatible.

Thoughts? Dedadz
Jordi, Why add the complexity when you can get the necessary data using the serial links for just 40 bytes of data? You wouldn't have to worry about PAL/NTSC compatibility or mucking with the OSD and video.
I presume the answer is: so you don't have to have two wireless downstream links (video and telemetry). In other words, you wouldn't have another serial link.
and so you can see the football scores?? teletexts prime use ;-)

All I'm saying is keep the system simple and efficient. Having an independant video path is very clean. With the current system, if you want to add video/FPV/OSD, go for it. If you don't want to put video on the plane, that's fine too. Putting control/status info in the video path is not only unnecessary, it possibly forces additional hardware to be present for the system basic AP to function.

The serial channel on the existing Ardupilot is already sending limited, unidirectional filtered/formated telemetry information to the ground station but is not able to utilize the uplink on the same serial channel due to the hardware design. IMHO, it would be best to expand and improve this link instead of searching for a more complex and unneeded solution.

Migration Path:
1. Ardupilot Code: Modify the existing code to transmit raw data from the GPS and sensors on the serial download link and post-process it anyway you want. This data would in addition to the current download data being dumped for the groundstation.
2. Megapilot Code: Utilize an independant serial port and download the same data as before. Data and status information could then be uploaded on this serial port and not interfer with existing HW and S/W.

If additional bandwidth and/or redundancy for telemtry is required, just connect another serial port from the CPU to an additional Xbee. The Mega has 4 serial ports so that should not be a problem if it is implemented in the board design.

Please don't take my suggests as being negative. I really think DIYDrones - you / Jordi / Bill and all of others are doing a terrific job. I just wanted to throw out my ideas and hopefully help the cause.


For the average have an extra radio modem is not possible, at least that is my case. I use 2.4gz for TX, and 900mhz for video. I can't add 900mhz for telemetry, i would but you know.. 1.3ghz may block the GPS and is illegal here in the US, 5ghz is way to expensive. EasyStar is small, but why you want an electromagnetic flying ball anyway?

So basically is optional and completely different project, i don't even know why we are discussing this. If you like the normal telemetry system you can have it. If you only want OSD and see data from the Ardupilot you can too (with tracking antenna).

For ardupilot mega project I will develop a more complex telemetry, that i guess you may be interested... (I can even taste it now ;-) )

Also I'm working with the Xtent 900mhz radios to make a PPM decoder for Futaba/JR so you can have radio control and telemetry in one line (with 40 miles range). ;-) But this one will cost around 400 buck just because the modems. Finally i will be able to use 2.4Ghz video an go up to 10 miles away!
Jordi, these 900mhZ XBee are FHSS so 2 modules can operate in Tx together, the range may be reduced but they should still work just fine.

Sarel Wagner

I understand the problem - frequency bands. I'm running 2.4G Tx, 1.3G video, and 900M for the Xbee's. I have my Amateur FCC Technical licence (KG6ZLS) so I can use 1.3G in the US. As Sarel mentioned, you can run multiple Xbees at 900M which was my thinking we could do. Sorry for the distraction.

Just a side note - the FCC Technician license is very easy to get. Just take an exam and it's yours.
I will investigate about that license. Sounds good. ;-)

The video transmitter is different from the Xbee. Why you mention using two Xbee's together?
This is done in Immersion RC EZOSD already. Should look at was has been done to date by other OSD vendors to learn from.

Reply to Discussion



Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service