Radio Benchmark program and results.
#1
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.
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.
Last edited by condac; 07-08-2017 at 01:15 PM. Reason: spelling
#2
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.
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.
Last edited by condac; 07-03-2017 at 01:09 AM.
#3
Just for fun i digged up an old 27mhz radio that came with a team AE RTR nitro car. It outperformed the GT3B.
#5
Tech Champion
iTrader: (33)
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
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
#6
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
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
#7
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.
#8
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
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
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
#9
The popular air radio Taranis X9D added to results...
#10
Tech Champion
iTrader: (33)
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.
#11
Tech Rookie
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.
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.
#12
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.
#13
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.
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.
Last edited by condac; 07-02-2017 at 11:31 PM.
#14
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.
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
Last edited by condac; 07-03-2017 at 09:12 AM.
#15
Let me know if you want histograms for all data I collect in the future.
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.
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.
Last edited by condac; 07-05-2017 at 11:05 AM.