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!
Dave
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!
Dave
Replies to This Discussion
-
Permalink Reply by Michael King on -
Our UAV "BorderHawk" has two separate channels. We used the 900mhz Maxstreams (prior to the release of the Xtend modules which i would use now). The autopilot was the now out of business UAV flight systems autopilot. It would send its telemetry once a second and then listen for commands between telemetry bursts. This worked out well for us.
For video we used a 2.4ghz 200mw transmitter. We easily go over 10 miles of video on that. Just remember to put your video receiver right up on the antenna and not down 30' of antenna cable. The only side point here is that at 200mw you need a license. Now introducing K1NGZ . You have to broadcast your callsign every so often. So i made up a little plate on the landing gear that held my callsign. Since the pan and tilt was 360 continuous, you would see my callsign everytime we orbited something which was very often. We tried the video overlay stuff but that took up precious space and weight.
Oh yeah, this video transmitter was very small and worked incredibly well.
Link:
200 mW SMALLEST VIDEO TRANSMITTER 2.4 GHz SINGLE CHANNEL
I just drilled a hole in the fuselage and stuck the SMA through and used the supplied 1/4 wave ducky to hold it all in place.
Yes, 10 MILES!
-
Permalink Reply by Jay Smith on -
You are correct about transmitting your call sign. It must be transmitted at 10 min intervals, if you are using OSD you only need program the display it include the call sign in the video stream and the call sign will be continuous. But I like the idea of panning by your id plate.
Cool project though (Our UAV "BorderHawk") I checked out the American Border Patrol web page. Good work and good for you. : )
-
Permalink Reply by Peter Meister on -
This is done in Immersion RC EZOSD already. Should look at was has been done to date by other OSD vendors to learn from.
-
Permalink Reply by remzibi on -
The telemetry in Video can be done on two ways .
First is to use existing ability of OSD of MAX7456 and define two symbols(fonts) in eeprom - representing 0 and 1 (ex, white and black square) , or maybe 16 graphics symbols representing 0,1,2,...D,E,F .
Then use a first(or last) line(usually covered by frame border of monitors or gogles) of OSD overlay to transmit any info .
That way can be used by OSD by his self or using Ardupilot and UART "$Mxxxxxxxx" message .
On the ground will be uC able to decode this info - the advantage is that if camera even will stop to work - OSD will still generate his picture without any transmition problems .
Second way is harder (need hardware modyfication ) - using H V outputs of MAX7456 chip - so then we able to use invisible lines on H sync to the same purpose (but only in time when they are invisible, rest will control chip by his normal way) , on ground the same - uC with H-V separator to decode the info . Advantage the same as max7456 still generate his own H-V sync picture after camera fault .
In both above ways the ground software will difference only by H lines counting after V sync signal , rest can be the same as hardware - so H-V separator and uC with signal on comparator .
As the Third possibility is to use in laptop computer on the ground software for digits recognizing and use this info as telemetry data .
-
Permalink Reply by David Sprague on -
Remzibi - I think the first solution you propose is a good one providing that you feel that giving up the top (or bottom) row of characters won't be too much of an issue. It's a nice simple solution with no hardware mods required. Since the plan is to use this to steer an antenna, it would probably be good to add some simple error detection like parity bits or check-sum to reduce the probability of using corrupted data. That should be easy to do in software.
On the ground-based receiver, the key issue will be the data slicing -- setting the threshold that is used to test whether the signal level is considered a zero or a one. The teletext project used a known sequence at the start of the line of data (such as 1010) to set the data-slicer threshold. We might be able to get by with a fixed threshold. We can do some experimentation to see what is needed.
-
Permalink Reply by Nick Sargeant on -
Remzibi, is there enough space on your OSD to implement your first idea?
-
Permalink Reply by remzibi on
-
This is already done and possible using existing $Mxxxxxxx function .
For future use will be easy way to add dedicated message 30char long only for transmition .
However I need to made some experiments basically with ground part - so I already ordered V-H separator to made and try with signal recognition (basically white and black levels on uC comparator) .
Having groud part any possible algo for de/coding is possible to implement .
As I like univesal solutions - this way will be possible to transmit data with combo Ardu-OSD or OSD alone (if firmware will be added) - as well as posible work with any OSD on the marked - of course if inventors will join our transmition protocol and technical soft-harware (timngs , H lines counts etc.) solution .
-
Permalink Reply by Nick Sargeant on
-
I don't want to be a distraction to you guys but if the remzibi OSD is out of memory to implement the first idea, what about designing an audio modem that transmits telemetry data through the audio channel of the Vtx?
Would It make things simpler because you don't have to worry about PAL/NTSC stuff?
That said, remzibi's solution would be better because it means less overall hardware.
Also, you could ask some of the developers of the DakarOSD to get on board, i cant recall if their code is open source but i know their hardware is.
Cheers,
Nick
-
3D RoboticsPermalink Reply by Jordi Muñoz on -
Nick,
Audio is very important for FPV.. Try to drive your manual transmission car without tachometer and without sound! We need to ear the motor to see if we are running fine... You can also ear your wind speed.
-
Permalink Reply by Carlito Oliveira on -
Thamm!! I wrote a bit history but my browser lost it!!
I´ve been researching about this subject (Closed Captioning) for some time now. The most successfull projects I found were:
http://www.brouhaha.com/~eric/pic/caption/
http://nootropicdesign.com/projectlab/2011/03/20/decoding-closed-ca...
The second project the guy implemented Remzibi first´s option, he created two chars for 0 and 1 bits and a char for the start bit.
At each frame he could transmit 2 Bytes, without errors 60B/s at 30 fps. That sound enought for GPS,mode and attitude data.
The two problems one might find are:
The sync separator:
In the first project the guy used at first LM1881 but he couldn´t split the signal properlly, so he used the EL4581C.
In the second project the guy had the same problem but he changed the resistors values and then it worked.
The bit 0 and 1 voltage level:
In the first project the guy made a comparator using two OP AMPs, that sounded very unreliable.
The second project the guy connected the video signal to a transistor and it worked fine.
If anyone could implement the Max part, Im able to try to decode the signal cause I already ordered the components too and I´m starting to build a PCB to decode the data.
Carlito
-
Permalink Reply by Carlito Oliveira on
-
Ahh... just to add...
@Remzibi: It wont work without the camera at all... The max need the sync pulses to work and they are generated by the video camera.
Carlito
- ‹ Previous
- 1
- 2
- Next ›
Social Networking
Top Content
Contests
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.A list of all T3 contests is here.
Groups
-
Documentation Editors
51 members
-
ROS User Group
75 members
-
Moderators
24 members
-
ArduRover User Group
184 members
-
ArduPlane User Group
685 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
