I am not much into the details of video transmission in general. However, I wonder since most displays and electronics are digital, why have suppliers for FPV equipment chosen an analog transmission system, which moreover is limited to 30/24 fps and low resolution?
Would it be possible to enhance the resolution by simply choosing a different (digital) protocol without changing the channel number?
As others have said, PAL and NTSC are analog and have virtually no latency. This is extremely important when flying FPV drones at high speeds. Having latency will tell you where you’ve been, not where you actually are.
I have a large video/photography drone (Yuneec Q500 4K). It transmits the video digitally on 5.8 GHz using the 802.11A protocol. (Just like your home Wi-Fi network.) I have measured the latency of the video feed at 282 milliseconds. This is because the video has to be converted from analog to digital, and then the back again at the receiver. That may not sound like a lot, but it is when you are traveling at high speed and trying to avoid obstacles.
Here is a quick chart that will show how 282 ms of latency affects where you think you are, compared to where you actually are.
Speed Error Speed Error
[MPH] [Feet] [km/h] [Meters]
----------------------------------------------
10 4.15 16 1.26
20 8.24 32 2.51
30 12.39 48 3.78
40 16.54 64 5.04
50 20.63’ 80 6.29
Considering that some FPV drones can travel at 60+ MPH, you can see how much of an impact that video latency would have.
As far as FPS goes, 30 for NTSC and 24 for PAL are standard frame rates and more than enough for a smooth picture. Higher resolution would also require larger/heavier hardware. When FPV racers are trying to shave fractions of a gram off of their drones, they will sacrifice resolution for a reduction in weight.
I hope my explanation helps!
I upvoted Nettle Creek's answer, but here is a quick explanation about why latency matters:
Piloting a drone is a feedback system with you in the loop. As in any other feedback system, the usual Nyquist stability critera apply. Video latency adds lag in the feedback loop, and the effect is the same as on any other feedback system (you are the opamp): it makes the system less stable. This can be compensated for by various techniques, the easiest of which is to lower the bandwidth, which makes the system slower.
Just imagine a car having a 1 second lag between turning the steering wheel and the wheels actually turning. This more or less equates to putting a blind person behind the wheel, and you in the passenger seat screaming directions. I bet you would take a lot longer to reach your destination...
For example, a few years ago LCD display lag was an issue. Some LCD screens would buffer a frame or two to apply digital processing to the image. This resulted in a lag of 1-2 frames. This essentially made all First Person Shooter games unplayable. One frame delay might not sound like a lot, but it is enough to severely upset the human control system (ie, brain) which is not used at all to having display lag between moving your finger and seeing the result.
Digital video is compressed, so the compressor must accumulate several frames in RAM and process them. You get very high quality, but high latency.
Analog video has basically zero latency. Just a few milliseconds for the display LCD to react. Much less for CRT. It does not have "one frame" (1/60s) latency, for a subtle reason: say your eye is looking at the very center of the screen. The CCD camera reads the image scanline by scanline. This means it will read a scanline, which is transmitted immediately and displayed. So the image which is displayed on screen at the spot you are looking at (say, in the center) appears only a few milliseconds after the camera acquired it. So, latency is very low.
Of course, it will only be updated at the next frame. But each update is very much real time. If your drone is speeding towards a tree trunk, the tree will look smaller at the top of the screen, and larger at the bottom, because during the frame scan the drone got closer.
From my experience playing FPS games, this allows extremely good control. Add one more frame (16ms) and everything breaks down. No more head shots! Aiming becomes impossible. It feels like playing console FPS.
Also for piloting a drone (or aiming in FPS games) image quality doesn't matter much. Crummy analog PAL will do just fine. Back in the day on an old underpowered PC, if excellent image quality settings yielded 30fps, everyone would set the textures to "atari 2600" quality to get more frames per second. 30fps is unplayable unless against a predictable computer opponent.
They choose this protocol, because it is universal so you can use different accessories from different manufacturers. Also, they choose it, because it is simply faster and needs less computing power to decode the image. And a third reason is that a digital signal is less reliable in fast moving objects where you need low latency.
I offer an additional reason to the others given (of established and extremely cross-compatible standards, mature affordable low-power chipsets, latency etc)... one of signal robustness. An analogue video signal can be quite badly degraded before it can no longer be received in some form, or understood to a sufficient extent for flight control (or review) by a human observer. The colour can drop out, the audio become completely meaningless, the visual noise level can increase to the point where there's barely a 2:1 contrast ratio of meaningful signal versus "snow", and the sync can be disrupted quite badly causing the image to waver up and down with each frame - and side to side with each line - and so long as the carrier hasn't dropped entirely you can still generally make some sense out of the feed. It's even possible that the video will keep sending in a recognisable form despite the control signal itself having failed.
Whereas digital video... well, anyone who was witness to the early days of digital OTA broadcasting (or even if you live in an area that still has a weak signal) can tell you how rapidly the signal becomes completely useless once the strength and quality falls below a certain not particularly low level, often without very much warning. In contrast to the gradual "graceful" degradation of analogue TV, the difference between a crystal clear and perfectly watchable digital signal, and one that is either so corrupted as to make no sense at all to a viewer (the encoding scheme means any random disruption to the bitstream can cause massive, unpredictable changes to the decoded image) or to completely fail to decode at all can be quite the knife-edge. Not really a characteristic that you want to have to deal with if flying FPV mode.
In other words, the analogue version will give you plenty of warning in terms of gradually degraded signal if you're coming to the edge of its usable range, so you can turn back in time. A digital one may pass over that knife edge in a couple of seconds, going from clear and smooth-running to jerky and broken up to leaving you flying completely blind in less time than you can react to the failing signal and turn the drone around. The analogue signal may be inherently lower resolution and noisier than the digital one, even at the point of takeoff, but the trade-off may prove to be very much worth losing absolute maximum video quality.
Another part is interference from the motor and control electronics and radios themselves. There's often visible artefacting on the video signal from the other electrical parts of the drone as it's running. That sort of thing just causes some visual noise and sync distortion on an analogue video signal... but it could cause a digital one to fail entirely.
Of course, you can add quite a lot of error correction encoding to the digital version to try and proof it against both of these issues, but that both reduces the available bandwidth for the actual signal (so limiting the possible resolution, as well as compression ratio, and even framerate), and adds additional latency (already a problem even without the EC) as typical FEC relies on spreading data out over a longer timespan through the continual data stream.
On top of which, most sufficiently efficient digital video codecs rely quite heavily on interframe / temporal redundancy, delta and motion-compensation techniques to greatly reduce the amount of data that has to be transmitted for a given perceptual quality, especially for low-motion content which is the largest part of most TV and recorded-video content. These of course add to the latency in the live video path (it's not really a problem for TV transmission where a little delay is accepted, or for stored/streamed video where the data is rapidly pre-buffered before decoding starts, but is deadly for remote control/presence applications)... and also mean that high-motion content, which is a rather large part of FPV footage, places an unusually high load on the data stream and compression engine, and something has to give - either the data rate gets sent through the roof (which is a problem for power consumption, chipset complexity, range and reliability of signal reception...), or the visual quality suffers, with smearing, macroblocking, interframe trails/ghosts, etc. Again, probably not something you want interfering with your vision whilst remotely piloting a fragile aircraft at speed, and the nature of the corruption would likely mean a greater loss of useful visual information than the more regular low-amplitude snow of a weak analogue signal.
Of course, low latency video codecs used for thin clients and remote-server gaming services show that it's possible to have reasonably high efficiency compression without lag sufficient to interfere with twitch reactions, but those belong to an entirely different electronic world in the main. The data links are typically wired end-to-end, or at least up until the last few metres, using transceivers that are either wired to the mains or using fairly heavy batteries that aren't being relied on to carry the machine through the air. The decoder is one small part of a larger piece of non-trivially powerful computing hardware, and more relevantly the encoder (much like that of a digital broadcaster would have been 20 years ago) is particularly beefy in order to capture the hi-def image, crunch it and fire it off down the network link as fast as possible. With the benefit of a few more years it might be possible to build a similarly capable encoder into the lightweight, low power consumption control and video sender board of an FPV drone, as well as a data stream transmitter that can sustain a high enough bitrate over a meaningful distance... but at the moment there's a heck of a difference between what can be built into small flying machine and what goes in a high-end server in a datacentre.
For the time being, a simplistic SDTV encoder/transmitter, that takes up about as much space (and just as crucially, weight) as a match from a nightclub matchbook (the head being the chip and the stick being the antenna) and consumes hardly any power beyond maybe a couple dozen milliwatts for the transmission itself, can feed a low (but still sufficiently "high") resolution, smooth framerate, effectively zero latency image from the similarly dinky burner-phone derived sensor (both parts being ludicrously cheap) to the FPV headset or handset with enough fidelity to be useful over several hundred metres. That's where the state of the art has got us, and when you think about it, it's already pretty impressive, much the same as being able to stream a hi-def recording to Youtube or Twitch with a couple seconds' latency from a handheld computer is. It just needs to advance a bit further to give a better quality image using digital transmission with suitably low latency and high reliability...
