Replies to This Discussion

Permalink Reply by Lew Payne on January 17, 2011 at 3:08pm

I just noticed my link to the STM32 OSD is broken.  However, the URL consists of the guy's amateur radio callsign.  So, you could easily find his email address here (LZ4DF) and ask him to email you a copy of the PDF.  If you do that, I'd really appreciate you sharing it with me, as I didn't keep a copy.

 

Also, here's my technical blog.  Search for OSD and have a field day!

• ▶ Reply

Permalink Reply by Darren on January 17, 2011 at 3:45pm

I propose a next-gen solution...

Looking at whats coming down the pipe, these folks now have a light weight low power hdmi transmitter with 4.9-5.9ghz spectrum and auto switching of frequencies if noise exceeds x amount...

 

http://www.brite-view.com/hdelight.php

tx/rx set is 159.99 with a low range (5 meter) transmitter.

 

Just think if this was at the 200mw or higher power on the tx side like we have today on standard tx'ers...

theroreticly shouldnt we be able to get the extra bandwidth for data over the new 802.11n (wireless hdmi) standard and bumping up the range with power/antenna combo like we do today with standard video transmitters and omni/directional patch antennas on .

• ▶ Reply

Permalink Reply by Lew Payne on January 17, 2011 at 4:43pm

I don't get it... the range on this thing is roughly 30 feet, and the frequency it's on has high absorption losses. How would you use this for video beyond 30 feet (not to mention unit size and weight)? You postulate that, were this a 200mW device, it might fit the bill. However, the truth of the matter is - it's not. I could just as easily postulate that if a standard flytron 2.4GHz 50mW transmitter did HD video and put out 200mW for only $45, it too would be ideal.

 

I'm just trying to understand how this solves his problem of "sending serial data over an existing SD video stream." 

• ▶ Reply

Permalink Reply by Darren on January 18, 2011 at 1:43pm

I was using that product as an example of new high definition transmission protocols and point out they are using the same frequency as our standard 5.8ghz transmitters. Which DO have the range we are looking for, as thats what the mfg intended the product be used for. Get my drift?

For that paticular unit the mfg is intending that for in home use, so range isnt thier biggest concern.

But I suggest that this technology can be combined with higher power transmitters like other 5.8ghz video tx/rx systems, I think we can start getting wireless HD to the ground. Other 5.8 fpv transmitters are getting upto, and exceeding a kilometer on a 200mw with directional antennas and trackers etc.

 

But to answer your question, look at baud rates on the audio channels with that hdmi transmitter.  Just dont know if its bidirectional (doesnt really indicate)

 

• ▶ Reply

Permalink Reply by Ben Levitt on January 18, 2011 at 1:48pm

...it sure is too bad that DakarOSD is not open source...

• ▶ Reply

Permalink Reply by Lew Payne on January 18, 2011 at 1:54pm

Well Ben, if it were open source, you'd have nothing to do!  Don't you want the added thrill of having to develop a project from scratch, and research it through prototyping and the "school of hard knocks?"  Note: You don't have to answer that.  LOL.

• ▶ Reply

Permalink Reply by Paul G. on January 18, 2011 at 3:28pm

Its coming Ben, we have figured out all the details on exactly how to do it and even had boards laid out but then we changed the main video out amp (1W) so it has to be laid out again. The board on the plane will have the option to do OSD (graphical) along with the data feed (about 18k bytes per second) using the blank video lines at the beginning of each frame. Were going to do the design so it can be used with or without the on board video amp / antenna selector. Ground board is PIC32 based with USB and plain serial output for data and will have a couple servo outputs to drive an antenna pan / tilt. Video output available with and without OSD with data stripped out so normal display and recording devices work. Aircraft board is currently a 28pin 33fj but I think its going to change to a PIC32 as well so there is a common code base for it and the ground station, connection to the autopilot is CAN.

• ▶ Reply

Permalink Reply by Ben Levitt on January 18, 2011 at 3:34pm

"Well Ben, if it were open source, you'd have nothing to do!"

:)


So, another idea to avoid starting from scratch:

Use prebuilt closed-captioning encoder/decoder chips to encode data as closed captions in the video stream using an existing, standard data format.

So far I haven't found an encoder chip, but it looks like the Zilog Z86131 might be a great decoder for the ground side: http://www.zilog.com/docs/tv/z86129.pdf

Lew, any recommendations for a nice, simple, small encoder ic? :)

Thanks,
Ben

• ▶ Reply

Permalink Reply by Lew Payne on January 19, 2011 at 6:43pm

Ben... I've not studied it in-depth, so please verify what I'm about to say.  It seems to me the Z86129 provides a useful output of the encoded information, in addition to on-screen display of it.  But again, I didn't take the time to read everything carefully.  On another note, I'm not sure if using this IC makes things easier or more difficult for you.  You see, you don't need a character set encoder/decoder (which is part of what these things are).  All you need is to represent your data using a modulation scheme which includes error correction, and then stick that [binary] data into the available fields/frames.  I have a book on typical/popular binary modulation schemes upstairs, but I don't remember the name offhand.  It's all "been there, done that" stuff, however.  Doesn't mean writing the software for it will be fun.  All it needs is an LM1881 and a uProc.  I think that's what the Spanish guys are doing in their design (or at least one of the projects in my blog).

 

Anyway, I'm fighting a nasty flu so my energy for participation is at an all-time low right now.

• ▶ Reply

Permalink Reply by Lew Payne on January 20, 2011 at 12:30am

Book I referenced above is "Iterative Error Correction" by Sarah J. Johnson, ISBN 978-0-521-87148-8. You probably want to use a standard RA (repeat-accumulate) code, which combines the best features of both Turbo and LDPC codes... with simplicity.

Yea, I know... my "recreational reading" books aren't of much interest to most people.

• ▶ Reply

Permalink Reply by Ben Levitt on January 20, 2011 at 4:11pm

Yipes!  I hope you're already starting to feel better...

 

The Z86129 looks to me like it includes the OSD, but the Z86131 doesn't.  I liked the idea of encoding data as standard line-21 (EIA-608) captions, and then reading them back out with a chip like this, precisely to avoid the time-consuming task of building my own codec from scratch.  I'm digging deep, looking for shortcuts, as I'd rather spend my time adding autopilot features to MatrixPilot, and doing some actual flying, than slaving over yet another data-over-video codec.  :)

 

Still hoping to go the lazy route,

Ben

 

• ▶ Reply

Permalink Reply by Carlito Oliveira on January 17, 2012 at 11:38am

Hi guys, Any news on this thread????

One year has passed, did anybody found a solution?

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page