Radio Benchmark program and results.
 

Looking for info on real actual delay in radio systems is hard because there is no independent data available. A very few sheets pop up some times from manufactures claiming their is better than other but no info on how test is done and if it is fair play.
So I have developed my own arduino code to do it. The arduino is connected to the steering input on the radio and also connected to the servo output of the receiver. It sends a high signal making the steering go from full left top full right and starts a timer and stop the timer when it have a servo signal that is starting to move from full left position.
Arduino code at github: https://github.com/condac/RCRadioBenchmark
Results in the wiki section on git project: https://github.com/condac/RCRadioBenchmark/wiki

The arduino program have been verified with a logic analyzer so the times are very accurate. The reason for random delay times has to do with the fact that the receivers have a fixed update rate to the servo and depending on when the signal changes and the time to next update is due to happen the time is random. This is why maximum and minimum together with average values are of most importance. also the update rate of the signal to the servo.

If you have an arduino and a radio where you can access the steering pot or connector please help me out and fill in the results with more radios.

http://www.rctech.net/forum/attachme...1&d=1499544890

Just to clarify how the signal travels and what parts that are involved i want to type this chain of components. Understanding all steps will clarify that when manufactures claim they have made something 50% faster they are always just talking about one of many parts in the chain. And numbers they post that their radio delay is just 1ms, they are probably just talking about the delay in the TX module ignoring the delay in the RX module or any Radio and Receiver software. The key to getting knowledge is to question the data and claims.

Physical steering wheel/stick -> Potentiometer -> Signal filter -> Analog to digital converter -> Radio software/hardware -> Radio TX module -> Radio signal in the air -> Receiver RX module -> Receiver hardware/software -> Signal output to servo

Comparing the GT3B that have the hacked firmware you can see that they have managed to cut out 16ms from the radio software making that part say 100% faster, but the overall chain is just 40% faster because what happens in other parts.

Also a reason to why I end the time measure after the servo signal drops to 0 is because I think that if you want to push delays to a minimum you can change the state during the time you already have started to send the servo signal, because every signal is starting with 1ms of "header" and during that time if new information comes in you might be able to extend or shorten the pulse if there is enough time. I don't think any manufacture does this but it is possible so that is why I want to measure this way. Lets just say that if I was a s/w designer I would do it this way.

Just for fun i digged up an old 27mhz radio that came with a team AE RTR nitro car. It outperformed the GT3B.

Nice work!

Now please go and buy, borrow, or steal some real radios!
Sanwa, Kopropo, Futaba, etc.

I don't care how cheap Chinese knock-offs perform.....

I've had pretty good success measuring latency with the PPM monitor built into this gadget:
SkyRC 6 in 1 Program Box

Simply hook up the output from either Ch1 or Ch2 from Rx into the Program Box and switch to PPM mode and it will read out the frame rate in Hz, then I use this conversion tool here to get the frame rate in ms:
https://www.unitjuggler.com/convert-...-to-ms(p).html

Is this how your frame rate values in the comparision table you have is created? In that case I'm realy confused because you have stated a lower(better) framerate on the Radiolink than the GT3B when the hz is higher in the GT3B when I tested. Also the radios that have around 1ms frame latency must have very high hz.

I will soon have my hands on Futaba 4PK and 4PX... will also compare FAAST to S-FHSS on 4PX.

I think many people are interested in how cheap Chinese knock-offs perform in the tecnical parts. I cant wait to see how bad(or suprising) they are compared to "real" things. The fact that an old analog 27mhz system looks like it can beat some digital systems was suprising and I guess the low cost systems from top brands might have hard time to beat the max delay the analog radio performed.

Also please don't use the word latency when you messure time between signals this way, it is update rate you messure and it is very constant. Latency is lag time in some system components and this is not that. If this is how all data in your comparision images is created please change it all to update rate in hz, i have always thought this was something you have measured in the radio delay between radio and rx. I might have your data confused with someone else that did lots of test of the GT3B hacked firmwares.

EDIT: It was forum user derelicte that did those test, I thought your comparision table used hes values or test reults and that all other radios on the list was tested the way he did with osciloscope and measuring time from radio input to actual output from rx. My Bad

The popular air radio Taranis X9D added to results...

If a manufacturer posted their frame rates, then I simply transposed them, of the radios that I personally owned, and if the frame rate was not published, then I hooked up my PPM to get readings to put in the chart. I feel confident that my method of calculating the frame rates was very accurate.

This is a site that has latency test results since 2005.
Goto rc runryder and look for latency test.
Rctech won't let me post the link.

You can check you test method against his test method.

I found his test and results after i created my program when i looked for results on the Taranis radio when i ran it in my test. Exactly how he test i don't know but he test from stick input to servo signal and that is exactly what i do also. He haven't published exact data on the Taranis so i can't compare more than the comment he said that the radio is a bit random, and it was for me also. I averaged a lot of tests more than on any other radio so far. I thought it was because the battery was low and that the alarms interfered so i recharged battery and ran again. And looking at his data it is clear we have the same vision of what need to be tested and presented in results.
But to brag a bit I think my method of running over 100 tests in just a few seconds and getting results quicker might be a bit less work than he have put into it if he uses oscilloscope or logic analyzers.

First High End radio tested. First up is the Futaba 4PK. Having a super fast update rate of 300hz to the servo it stand out compared to the cheap lineup. The avg and max delays are as expected very good compared to the others.
Avg 10.29
min 6.25
max 18.86

But looking at what happens and how fast it does things it is clear that update rate is not everything, from the time you move the steering until the correct signal is at the servo it have already sent 2-5 updates that are wrong until it have the latest signal. So Futaba have alot of room for improvement here, and other radio manufactures might do things quicker.

Also it updates all servo at the same time instead of one after another, something i expected you must do if you want to get the maximum update rate. But it is the first time I have seen it in the logical analyzer. If you don't go parallel you can never get a 4 channel radio to update faster than about 80 hz.

The friend that let me test his radio also had 2 different receivers and the older FASST-C1 version R604FS was about 1ms slower on everything.

Using your method to show servo frame rate the Futaba 4PK has 3.30ms if you want to add to your list. But in all my test the GT3B have 16.0ms but it might be because there are several versions of the RX. The Radiolink RX I have tested is R4EH-H and it have a loop time of 18ms and 18.2ms listed in your sheet might be the same because when i look at a recording of the signal some have 18.1ms and 18.2ms but the majority is 18.0ms. No RX I have tested is 100% consistent with their times some send 5 signals correct then 1 with .2ms extra. But you should really change the description to servo frame rate. Because as you can see reading these values and the actual transmit delays they are both values around 5-20ms and people get confused easy. And a radio with lower frame rate can have faster latency than one with higher frame rate as my test shows.

The problem is that some on your list have 1ms and 1.5ms. This is impossible because the maximum signal of 2ms that the servo need for maximum output in one direction can't be sent in 1ms time. It looks like Sanwa might have some proprietary protocol for communicating with Sanwa branded servos that might have a different communication but unless the speed on those are verified the values are just impossible.
The Ko propo have on their website listed neutral pulse 1.5ms and this might be the value you have found and put in your list, this is not the update rate this is just stating the obvious that a servo have a 1.5ms pulse as it's center position. If it is the time between pulses the real value should be 1.5ms + 2ms for the pulse it self. I have found no information of Ko propo having some other sservo communication protocol making a frame rate time of 1.5ms impossible.

EDIT: It might also be important to actually show that the radio can handle another protocol for the servo signals, but the protocols don't really have the standard set or named. ESC for quads have started using other protocols such as oneshot because they need to update the esc faster than the original 2ms pulse allows. But they have taken the road with an open standard and it is very clear what they do. RC radio manufactures have taken the bad road down the closed street trying to sell servos that only works with their stuff so it will be a sad and confusing future for us it they continue with this approach. But hopefully the big brand servo manufactures will set a standard that they just have to accept.

EDIT2: Futaba frame rates from sellers infopages, all systems have a fast and slow mode for analog servo compatibility:
Servo Frame Rates:
• T-FHSS: 3.3/15ms
• S-FHSS: 6.8/13.6ms

Let me know if you want histograms for all data I collect in the future.

http://www.rctech.net/forum/attachme...1&d=1499256173

Edit: I will record 20k+ samples from all radios i test in the future. I have been implementing a little compare function to the python program that makes the histograms. I hope to get a little gui for simple compare between models in the future.
http://www.rctech.net/forum/attachme...1&d=1499277936