Does anyone know of a relatively ready-to-use solution for sending serial data over an existing SD video stream? Maybe during the vblank section of each frame?
I'm hoping there might be an existing solution that would let me stream in serial data, encode it into the video, which would be transmitted and received, and then decoded out of the video, and sent to a microcontroller as serial data.
Or maybe I'll just have to bite the bullet and add another radio system on yet another frequency...
Thanks for any ideas!
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...
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 .
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."
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)
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.
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,