0
\$\begingroup\$

As the tittle suggest, I was thinking about making a wireless composite video transmission between a small camera (such as those sold for flying fpv) and a receiver. The two main specs it must have is near-0 latency (the lower, the better) and it must work well when the transmission is made at ground level (multipath is a thing to consider). I would not care about receiving a black and white image or a lower quality video (less bits in the ADC). The distance between transmitter and receiver will be at most 170m, but I can use almost any type of omnidirectional antenna. I know at first this may seem pretty difficult, but here there are the ideas I came with:

The first part of the system is the ADC. Here, as I do not need any sound nor color information (only luminance is needed), we could go fot two different options:

Idea 1: It consists on sending the signal as-is, with an ADC with a sampling frequency of nearly 9MHz (composite video's bandwidth is around 5MHz) and 8bit. Then, the bit speed at the output will be 70Mbit/s. Pros: The original image is sent, so it has good quality and is easier to work with it. Cons: 70Mbit/s is a lot.

Idea 2: It consists on a lowpass filter before the ADC, with a cutoff frequency of around 2.5-3MHz (only luminance is sent). The ADC would the need a sampling frequency between 5-6MHz, and it would also be chosen to code the info with 6bits. The bit speed at the output will be 36Mbit/s. Pros: 36Mbit/s is almost half of the 70Mbit/s. Cons: I am not sure if the filter would destroy the sync information, and that would be an issue.

Since we must fight multipath, the digital modulation to be used will be FSK. I know that before sending the image, it would be good to wait for the whole frame to be digitalized, saving the output of the ADC to a buffer, and the sending the image as a whole. However, on the one hand, I am afraid that this would add too much latency to the process and, on the other one, it seems to be too complicated to be implemented in an efficient way. As either the first 70Mbit/s or the latter 36Mbit/s are huge speeds, another two ideas on how to transmited arose:

Idea 1: Use hardware that works with an already studied protocol which can handle great speeds (maybe p2p WiFi or WiFi direct?). Pros: seems easier to implement and image quality can be great. Cons: distributing the data into packages can add a lot of latency to the whole comunications system. Moreover, if data rate is large, it is difficult to achieve 170m of distance.

Idea 2: As most of ADCs have one output per bit, and the total throughtput needed for each one would be by far lower than the total, the plan is to use, if the ADC codes the information in n bits, n transmitters at different frequencies simultaneously, that handle the ADC output as a serial input of data. My first idea was using NRF24L01 modules, but the can only trnasmit at 2Mbit/s. I would have to find an alternative. Pros: seems easier and faster. Cons: larger probability of receiving erroneous bits at the rx. Besides, I did not find many modules that fit the data rate requirements. If there were a transceiver that did not use package-structured data but some type of serial communicstion based on an input/buzzer it would be perfect.

Will this project work? What would be the best implementation? Do you find doing it in a non-industrial "homemade" way realistic?

Thank you in advantage and sorry for my bad English.

Edit: I also found this website, but I thinkn none of ht methods mentioned there are elementary enought to be developed in a homemade project.

\$\endgroup\$

closed as too broad by Elliot Alderson, RoyC, Voltage Spike, Dave Tweed May 21 at 17:48

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    \$\begingroup\$ Why digitally? None of your schemes provides better quality or better performance than transmitting it as an analog signal. \$\endgroup\$ – JRE May 18 at 20:31
  • 2
    \$\begingroup\$ None of the ideas you've come up with would make use of any of the advantages of digital transmission. You should expect worse performance rather than better. \$\endgroup\$ – JRE May 18 at 20:42
  • 1
    \$\begingroup\$ The advantage of digital transmission is that you can add checksums to the data to detect and recover from bit errors. Bit errors will happen - your analog signal shows corruption, so your digital transmission will be corrupted as well. But, you have nothing to correct the errors. What happens when the most significant bit has an error? It is as likely to happen to it as to the a lower value bit. \$\endgroup\$ – JRE May 18 at 20:49
  • 1
    \$\begingroup\$ @user3141592 But with an analog signal, occasional errors don't matter. They'll show up as minor imperfections in the image, which the viewer can ignore. \$\endgroup\$ – duskwuff May 18 at 21:11
  • 2
    \$\begingroup\$ If you only sample 2x the bandwidth at -3dB you most certainly will get massive ghosting from group delay and distortion from aliasing. Try 5x the -3dB BW or 2x the -43dB BW ! \$\endgroup\$ – Sunnyskyguy EE75 May 18 at 22:34
2
\$\begingroup\$

There are commercial chips that will digitize an NTSC (or PAL) signal for you a 8 to 10 bits of precision, but they typically do it at the standard rate of 27 MHz, giving a raw bit rate of 216 - 270 Mbps.

But after you have this digital signal, it is relatively straightforward to throw away the parts you don't care about (the chroma channels, the audio, etc.) and decimate the sample rate. You can even compress the data using an H.26x encoder to get the data rate down to 1 Mbps or less.

There are SoC chips with hardware video support that can do this sort of thing, or you could look into using an FPGA.

\$\endgroup\$
  • \$\begingroup\$ Thank you for your answer. Wouldn't compression/decompression add a lot of latency to the system? \$\endgroup\$ – user3141592 May 19 at 8:12
  • \$\begingroup\$ It depends on what you mean by "a lot". The added latency should be 1 frame or less. \$\endgroup\$ – Dave Tweed May 19 at 11:16

Not the answer you're looking for? Browse other questions tagged or ask your own question.