Electronics > Projects, Designs, and Technical Stuff
Digital FPV video for drone racing
<< < (25/28) > >>
ogden:

--- Quote from: Marco on January 23, 2019, 12:25:03 am ---You would be using an existing transmitter and receiver, you aren't touching anything over 6 MHz. The ADC/DAC's I mentioned are 1$ parts ... this is more equivalent to a RTLSDR software project than anything else.

--- End quote ---

You most likely will *not* use existing transmitter and receiver, unless you want to have hilariously bad sensitivity specs or hilariously slow speed. Their SNR, linearity and phase noise specs are insufficient for high order modulations at high symbol rate resulting in > 2bits/1Hz spectral density. You keep persistently dreaming your uneducated dreams about plugging ADC and DAC into 6MHz baseband of video transceiver and easily demodulating 20Mbit or so, data with same ease as RTLSDR is showing spectrum and playing FM radio. All this to addition of video decompression using same CPU's BTW. You really shall study much more about what it takes to develop functioning hi-speed demodulator of digital radio.


--- Quote ---Everything is so much more difficult in FPGAs, starting from attaching the camera.

--- End quote ---

Well.. obviously. After all you shall compress video coming at 640*480*120*2 = 73.7 MBytes second (120Hz, 16 bit color). 720p will require even higher bandwidth. H.264 video compressors of rPI uses GPU as coprocessor, but as I know, GPU of rPI is not Cuda compatible. So - good luck with rPI GPU development. I would love to see how easy as you say, is compression of such video stream using just ARM cores.


--- Quote ---If you're doing compression on the ARM, what's the point of a FPGA any more any way?

--- End quote ---

Why would you suggest that in FPGA solution I offered video compression using ARM? It is kinda dumb to have FPGA but not use it :D


--- Quote ---The only thing a FPGA makes a little more compact is attaching the DAC/ADC, since you can forego the EZUSB workaround.

--- End quote ---

That EZUSB workaround for ADC/DAC with SDR modem is no better than common USB WiFi dongle with proper radio/modem ASIC.
Kilrah:

--- Quote from: ogden on January 23, 2019, 03:37:44 am ---Well.. obviously. After all you shall compress video coming at 640*480*120*2 = 73.7 MBytes second (120Hz, 16 bit color). 720p will require even higher bandwidth. H.264 video compressors of rPI uses GPU as coprocessor, but as I know, GPU of rPI is not Cuda compatible. So - good luck with rPI GPU development. I would love to see how easy as you say, is compression of such video stream using just ARM cores.

--- End quote ---

The cores are unlikely to be fast enough especially not given the latency requirement (can't make good use of the multiple cores by spliting tasks), and as said the Pi's video pipeline / encoder and GPU are "black boxes" so you can't do fancy stuff with them like encoding a 8px high line from the frame at a time, you've fot to feed it one of the standard supported frame sizes as a whole.

But while a high res full frame encoder takes a lot of FPGA fabric we have the advantage that since we precisely want to encode small portions the encoder block can likely fit in a smaller area.
Marco:

--- Quote from: ogden on January 23, 2019, 03:37:44 am ---20Mbit or so

--- End quote ---
That's about an order of magnitude off from the last bandwidth I mentioned for video compression.

--- Quote ---All this to addition of video decompression using same CPU's BTW.
--- End quote ---
Compression tends to be the harder part.

--- Quote ---H.264 video compressors of rPI uses GPU as coprocessor, but as I know, GPU of rPI is not Cuda compatible. So - good luck with rPI GPU development. I would love to see how easy as you say, is compression of such video stream using just ARM cores.
--- End quote ---
It might be possible to encode slices with the videocore without adding too much latency (part of the OpenMAX API AFAICS). So say encode 128 lines at a time as a slice, that way you don't have to queue up an entire frame. Would require some experimentation. Still easier than getting video coding to work on a FPGA.

--- Quote ---That EZUSB workaround for ADC/DAC with SDR modem is no better than common USB WiFi dongle with proper radio/modem ASIC.

--- End quote ---
It fulfils the design parameters set in the OP, in that it is better.
TheDane:

--- Quote from: TheDane on January 22, 2019, 12:15:03 pm ---
--- Quote from: Marco on January 22, 2019, 10:29:06 am ---Who needs sync signals every line when you have crystals? You can throw a reference pulse in there every couple of ms and calculate the path response and correct for it, etc.

--- End quote ---

Crystals are NOT perfect, and will change frequency when subjected to g-changes (acceleration, deceleration, rotation). Ah relativity  :box:


--- End quote ---

Late last night I remembered about MEMS - Microelectromechanical system oscillator - https://en.wikipedia.org/wiki/Microelectromechanical_system_oscillator
When compared to a crystal, a MEMS oscillator is relatively immune to random vibration and has much better phase and jitter specs.

This might be a good replacement for the existing crystal oscillators on already flying drones, to improve video quality?

Some tests and conclusion - page 10 is about random vibration:
www.sitime.com/api/gated/AN10032-Shock-Vibration-Comparison-MEMS-and-Quartz-Oscillators.pdf


Oh, just don't use them with your helium filled blimps - they will crash

ogden:

--- Quote from: Marco on January 23, 2019, 05:34:05 am ---
--- Quote from: ogden on January 23, 2019, 03:37:44 am ---20Mbit or so

--- End quote ---
That's about an order of magnitude off from the last bandwidth I mentioned for video compression.

--- End quote ---

2Mbit was not just example but actual offer of data bitrate? 640*480*120*2=73MByte/sec is 584 Mbits/sec coming out of camera. Even half that (8bit grayscale) is huge number. You offer to compress video with fast vertical panning using 292:1 compression? - You sound like those 21-st century teens who declare that there's no need for education/experience/skills other than trained thumbs and internet :)

I have to remind that 120fps h.264 cannot reach better latency than analog TV transceivers (60Hz half frames). By 100% saturating data channel you are adding one more frame time, so absolutely best delay of such h.264 120FPS system would be 3/120=1.5/60 sec while analog NTSC TV currently have better latency of 1/60 sec!
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod