# Why do most FPV 5.8 GHz video transmitters use PAL or NTSC?

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?

• I've understood that latency is an important consideration; analog can basically transmit pixels as they're being read from the CCD, digital requires encoding first. I have no reference to back up that claim though. – marcelm Feb 2 '18 at 15:06
• Then it is mainly for simplicitys sake. However, I wonder whether it would be possible to pimp NTSC/PAL by increasing resolution/FPS? – user52836 Feb 2 '18 at 15:11
• pimp NTSC/PAL by increasing resolution/FPS Theoretically possible: yes. But then it might not be PAL/NTSC anymore as those support only certain FPS and resolutions. Also you'd need the electronics, meaning the chips, to support that "not PAL/NTSC". It would surprise me if you can buy these. For making your own you'd need to be a millionaire. So in practice: no it is not possible to pimp PAL/NTSC. – Bimpelrekkie Feb 2 '18 at 15:39
• Also there has never been a good plug and play low cost digital camera interface. – user3528438 Feb 2 '18 at 19:44

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!

• Converting to digital, transmitting as a digital signal and displaying the digital video doesn't have to add significant latency by itself. The vast majority of that massive delay comes from video compression and decompression, while composite video is completely uncompressed. – jms Feb 2 '18 at 23:37
• ^ Yes, if it was a simpler digital transmission method (like uncompressed, but with chroma decimation), or even simpler compression than the typical MPEG - for example, the MJPEG used in DV - it would be more than capable of sub-1-frame latency, or even barely more than a few pixels (or 16 video lines for DV, which is still a small fraction of one frame), compared to whatever the regular analogue video path may add. The problem is, those types of digital encoding are pretty inefficient, and aren't particularly robust, making them unsuitable for low-power OTA links. Analogue is actually better. – tahrey May 7 '19 at 19:01
• Also, small correction: PAL is 25fps. If your video runs at 24fps, that's some flavour of NTSC "pulldown" and will look weirdly jerky for high-motion content like drone feeds, unless it's a fully custom transmission mode that reduces the sync rate (and probably resolution) in order to increase the range, reliability and power consumption... – tahrey May 7 '19 at 19:04
• NB 282ms is a pretty severe amount of latency, at least in terms of either analogue video or one of those purely "I-frame" (and indeed individual macroblock or even individual pixel-group) based digital modes. That's more than 8 frames of a 30fps or 7 frames of a 25fps feed. But it's quite good for an MPEG feed; given that a typical picture group (that needs to be almost completely received before decoding can start) consists of 15~18 frames, that suggests either it uses a reduced GOP or a doubled-up framerate in order to reduce the effective code-transmit-decode latency as much as possible... – tahrey May 7 '19 at 19:09

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.

• A similar issue these days is audio lag with wireless headphones; I have a rhythm game on my phone that is incredibly hard to play when using a Bluetooth connection because the audio note feedback is off compared to when I actually touch the screen. – JAB Feb 2 '18 at 22:59
• "Digital video is compressed": not necessarily. Raw "NTSC" video, when transmitted over a digital link, is a digital video signal. Apart from quantization and basic signal processing such as bandwidth limiting, it is not inherently compressed. – sleblanc Feb 3 '18 at 2:54
• @sleblanc - the occupied bandwidth of an HDMI connection is an order of magnitude greater than that of an analog NTSC video signal. Compression is used in over-the-air digital video for a reason. – Chris Stratton Feb 3 '18 at 8:16
• Yes. If you want to transmit decent digital video over a radio link in a practical manner, which is the topic here, then it will have to be compressed. Otherwise there is no way. The bandwidth requirements are just too humongous to be practical. And if it fits in the same bandwidth as analog video and it is not compressed, then it won't be better quality than analog. – peufeu Feb 3 '18 at 23:41
• @JAB yeah, musicians on stage run their instruments through digital processors and they experience the same effects as you do, for example a guitar player will go nuts if what he hears in his headphones is too laggy compared to what he plays. The gear is optimized for lowest latency. – peufeu Feb 3 '18 at 23:44

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.

• Although I agree with the other points, I don't understand how you can possibly say "digital signal is less reliable on long distance". The primary reason that digital signaling has been invented was to solve reliability problems associated with analog, and be able to transmit and store the information anywhere without degradation. – dim lost faith in SE Feb 2 '18 at 20:47
• @dim Usually digital signals are send using packages. So for example we send one frame of the picture and we send it using 10 packages than one package hasn't been received. And becouse of the compression that should be used to transmit high quality video one lost package can affect the whole image when in analog transmission you will only get some noise or the picture will loose it's collor but you will be able to see what is going on. – Coder_fox Feb 2 '18 at 21:07
• You meant "packet". Well, I understand now. But you should reformulate because the "long distance" term was very confusing. If you want to send a video stream to the opposite side of the Earth (this is long distance), I would sure go digital. Because there's just no way to transmit it conveniently and without degradation with analog means. – dim lost faith in SE Feb 2 '18 at 22:01
• It's common for digital schemes to simply shut off in the presence of a bad signal to noise ratio. FPV pilots demand not only an analog signal, but a monitor which does not substitute a blue or black screen when given a poor signal, because even a static-laden image can be enough to see the horizon and major obstacles, and allowable signal strengths mean that brief dropouts are very frequent. If you see noise-free drone footage, that was recorded on-board the aircraft; what the pilot actually saw over the radio link during the flight was a lot noisier. – Chris Stratton Feb 3 '18 at 2:19

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...