Remote video dumb questions.

[izaktj]

How would one go about say connecting a webcam to the axon, and have the image feed display on one's laptop or another display?
I've been on google for a bit, and I've seen stuff like FPV sets but are extremely overpriced for people that do RC flying beyond visual range.
What options of transmitting video are there?

[jwatte]

The Axon does not have enough processing power to deal with video.

There are two ways of getting video into a PC:

1) Use a webcam and a single-board computer, like the Raspberry Pi, to turn the webcam into compressed video, and send the compressed video over WiFi.

2) Use an analog camera and analog "FPV" transmitter to turn the video into analog radio; then use an analog radio receiver and a analog video capture device to digitize the video on the receiving (PC) end.

Option 1) would probably cost you about $75 for RPi + WiFi adapter + webcam. Option 2) would probably cost you about $100 for camera + transmitter + receiver + digitizer, and would get you better range without needing any WiFi infrastructure.

Btw: The FPV solutions are not "overpriced" -- they are priced at the cost of manufacture and sale of the components involved. If you don't want to pay the price, then that's how the market works, but that doesn't make them "overpriced."

[izaktj]

The Axon does not have enough processing power to deal with video.

There are two ways of getting video into a PC:

1) Use a webcam and a single-board computer, like the Raspberry Pi, to turn the webcam into compressed video, and send the compressed video over WiFi.

2) Use an analog camera and analog "FPV" transmitter to turn the video into analog radio; then use an analog radio receiver and a analog video capture device to digitize the video on the receiving (PC) end.

Option 1) would probably cost you about $75 for RPi + WiFi adapter + webcam. Option 2) would probably cost you about $100 for camera + transmitter + receiver + digitizer, and would get you better range without needing any WiFi infrastructure.

Btw: The FPV solutions are not "overpriced" -- they are priced at the cost of manufacture and sale of the components involved. If you don't want to pay the price, then that's how the market works, but that doesn't make them "overpriced."

Thanks. Yeah option 2 is what I'm looking for. I already have a camera for use. How does the process of moving the data: camera->transmitter->receiver->digitizer work?
I assume I need to encode/decode data around. Are the software libraries for that?
Lastly, would this be UHF or VHF? Or?

[jwatte]

If you send the video through an analog radio, then there is no encoding/decoding needed.
Just make sure your camera has a compatible analog video output signal (NTSC or PAL, typically.) Often this comes on a yellow RCA-style connector.
Whether you use VHF, UHF, 2.4 GHz or 5.8 GHz depends on which transmitter and receiver (Tx and Rx) you choose. I would recommend 5.8 GHz.

The once piece that needs software is the digitizer. You need a video digitizer that works with your OS (Linux, Windows, or MacOS X? USB?) and then a video capture program.
On Linux, you can easily write your own video capture program using the video4linux2 library. On the other OS-es, there are similar video capture APIs, but I don't remember the details.
Or you can just use the video camera viewer application that comes with the OS on the PC side, because the video capture card/dongle will look like a webcam to the PC.

[izaktj]

I see.
How about sending more than one "type" of data? Would I need to then encode data into little packets, then send them?
I'm very naive to how radio communication works.
Assume I want to have video and telemetry (GPS coords, temperature, sensor info in general) being sent back. The first "way" of doing it would have an Rx Tx pair for video, and one for telemetry.  Is this the way it's done?
Or is it more like, gathering the data from sensors, digitize it into packets, then convert this packets to analog to be sent over radio. Afterwards, the receiver gets the analog signals, then the processor "decodes" this into separate packets.

How is this done?

[jwatte]

For an analog video signal, it is hard but not impossible to add additional telemetry data. Consider teletext, or closed captioning data, sent on analog TV signals. However, equipment to add that data is typically neither cheap nor lightweight.
It might be better to add a separate device for just the data part. The Xbee Pro series of radio modules could work well, for example.

[izaktj]

I see. Why is other equipment needed? Can't the video be converted to digital chunks of data, then combine telemetry and video data into a string of bits. Then, this new combined chunk, be converted to analog and transmitted. On receival, the analog signal gets converted back to digital, then take separate those chunks into video and data?

[jwatte]

Why is other equipment needed?

Because the Orangutan, or other AVR-based microcontrollers, don't have the bandwidth to do that.

Can't the video be converted to digital chunks of data

This requires significantly higher bandwidth in the ADC than the AVR has.

combine telemetry and video data into a string of bits.

This requires more processing power than the AVR has.

this new combined chunk, be converted to analog

This requires a much faster DAC than can be built out of PWM and RC filters on the AVR output pins.

On receival, the analog signal gets converted back to digital,

Again, needs fast ADC.

take separate those chunks into video and data?

Again, needs faster processing.

[izaktj]

Why is other equipment needed?

Because the Orangutan, or other AVR-based microcontrollers, don't have the bandwidth to do that.

Can't the video be converted to digital chunks of data

This requires significantly higher bandwidth in the ADC than the AVR has.

combine telemetry and video data into a string of bits.

This requires more processing power than the AVR has.

this new combined chunk, be converted to analog

This requires a much faster DAC than can be built out of PWM and RC filters on the AVR output pins.

On receival, the analog signal gets converted back to digital,

Again, needs fast ADC.

take separate those chunks into video and data?

Again, needs faster processing.

I see, thanks so much for the input.
I think what I'll do is have a separate Rx for video and telemetry. Then when I receive it on my computer, make a program that overlays text over video for telemetry.

[izaktj]

I forgot to ask, why is 5.8Ghz recommended? More range?

[jwatte]

5.8 GHz has higher quality video and less interference from cell phones, WiFi access points, and microwave ovens in my (limited) experience.
If you want signals that can go through walls, though, you might want to look at 900 MHz systems.

Also, if all you want to do is display some data from the remote end, rather than encode it in a computer-readable form, then you can do that with cheaper equipment. Google for "FPV OSD" for some such circuits. You can build one yourself with a small microprocessor and a small "injector" circuit to overlay the video signal. However, if you do it that way, then you can't read out the data electronically, and all your captured images will have that overlay "burned in" on it, so you can't record a non-overlaid version.

[izaktj]

Yeah I've looked into OSD but I want raw data. so I assume I need a different Rx Tx pair. How does one go about that? Maybe I should make a new thread about it.

[jwatte]

Buy two Xbee Pro modules. Problem solved!

[izaktj]

Ah, it goes up to 10KM only. I need around 40KM.

[waltr]

Ah, it goes up to 10KM only. I need around 40KM.

Use directional antennas.

[jwatte]

What are your cost and weight restrictions?

40 km is very far -- as in, 10x horizon distance at eye height (which is about 4.2 km, depending on how tall you are :-)