what's lowest latency for Spekrum (new orangeRX w/ bus vs spectrum sat?)

[AdamV]

I'm sure i'm not alone in admitting my interest in learning about the hobby has far outpaced my ability. I fly a spektrum DX6 but have found myself itching to jump on the taranis train - for many reasons, but most recently as a way to use SBUS w/ multirotors for lower latency. OrangeRX recently came out with a new receiver with SBUS and telemetry which has me very interested - seems like it could scratch the itch and save me (for now) from buying a new transmitter.

http://www.hobbyking.com/hobbyking/store/__90605__OrangeRx_R620X_V2_6Ch_2_4GHz_DSM2_DSMX_Comp_Full_Range_Rx_w_Sat_Div_Ant_F_Safe_SBUS.html

Alternatively,
At a higher price, i could go with the spectrum AR7700 and utilize the serial connection SXRL: https://www.spektrumrc.com/Products/Default.aspx?ProdID=SPMAR7700
Or use a lemon satellite, but that doesn't seem to use a serial connection (unsure)

Here is a summary of my knowledge (please correct if wrong!):
1. PWM & PPM have latency of ~20ms
2. Cleanflight averages 3 PPM/PWM signals to calculate the signal - so actual latency is 60-80ms
2. SBUS latency is 10-20ms
3. Spektrum satellites utilize a serial connection (like SBUS) called SRXL.. (latency is ~ 15ms?)
4. FPV cameras (could be bottleneck) also have latency; i.e. ~ PZ0420 has ~30ms, but newer cameras claiming < 1 ms: http://team-blacksheep.com/products/prod:tbs_zerozero
5. I don't know if transmitter and receiver latency is additive (ex: 22ms for DSMX + 15ms for SRXL on satellite)
6. Spectrum advertises 11/22ms frame rate (same as latency?), with 11ms only useable with digital servos. Presumably you could use 11ms with quads as there are no servos?

It really has been as easy as i had hoped to research this online? Anyone have any knowledge to share?

 

[Craftydan]

The Frame Rate expresses how often the Radio sends a frame -- a full packet of data, namely all the current positions of the mapped channels. Actual latency between when you change and when it gets the packet may be less (depending on which ms you started your change) but it will be no worse than the frame rate plus some processing from serial to output format (that's typically ridiculously fast).

The current PWM systems run between 11-22(ish) ms/frame, which is where you get most of your latency measurements above. These bounds are pretty standard to all modern radio gear because that's the PWM period most servos will respond to -- too much shorter than 11ms, and pulses get rejected, too much longer than 22ms, and the servos controllers start to give up. The actual TX's frame rate will depend on how it was designed, and it's RX's will be designed to match.

The digital signals like S.Bus and Spektrum Satellite should follow the frame rate of the TX -- if it's 11ms, every 11ms they will output a new packet. if the TX is bound at 22ms, new data pops out every 22ms. Since they are digital data already rather than an analog time measurement (pulse width), the 3-point low-pass filter isn't as critical for cleaning out bus noise . . . not sure if it's being done anyways, though.

Keep in mind, a running low-pass filter will still respond instantly, just in a muted fashion -- for a 3-point average, 1/3 of your input shows up instantly, 2/3 shows up on the next read, and the full change is in place by the third.

That being said . . . you do realize you're working in 1/100's of a second? I hate perceived latency in FPV with a passion -- it takes the fun out of it -- but in practical application, at these response rates, "you can't react that fast" comes into play. Even "noticeable" becomes extremely difficult. IMO, set the framerate to 11ms, and work on reducing your video link below perception . . . which isn't that hard if you've picked the right video gear.

 

[AdamV]

Thanks Dan! I think i understood half of that... lol. I do realize it's 1/100th's of a second, it's just fun for me to think about.

This is a quote from Oscar Liang's blog, "Lets say if your quad is going at 100Km/hr (about 62 MPH) which is 27.8m/s, in 50ms of delay, your quad can travel 1.39 meters which is about 4.5 feet!"

I'm nowhere near being able to do proximity at 62 MPH

 

[Craftydan]

Yup . . . but in the same respect, 50ms delay is 1/20th of a second. I'm not the twitchiest of pilots, but few could muster any sort of response in that time frame, and fewer still won't over/underreact. For most people, under 100ms is hard to even see -- it's more felt than seen, which means mostly it's muscle memory, not deliberate reaction.

. . . and watching the better pilots thread the needle at high speed re-enforces this. If you watch, they all get up to speed from a distance, set a line and stay on it. So long as they make their corrections smoothly to stay on that line, through the needle they go. They seldom make strong corrections on a line (and that usually ends up slowing, stopping, changing lines entirely or smashing into something from overcorrection). Get on the line, and gently control to keep it on the line. Effectively, at high speed their deliberate piloting choices are made flying ahead of the airframe.

Will limiting latency reduce how far ahead they need to fly? Absolutely. That's why most pilots use board-cams instead of flying through a Mobius/GoPro. The 10-ish ms added on in your control feedback does add on to the total, but discounting any muddy gears between our ears, the video link is more often the overall time hog in that feedback loop. Swapping out radio gear for this reason alone doesn't get you much bang for your buck, since at most you get back ~10ms, or possibly as little as 1ms.

There are plenty of good reasons to trade in a radio, many of them well worth the cost. If your radio is able to do 11-ish ms frames, however, this isn't one of them.

 

[GhstWlf]

A bit of topic but part of the latency discussion.
Some avid video gamers say that minimum Frames Per Second (FPS) is 60Hz, that is a round trip of about 17 ms from input to picture.
I don't know if FPV need that low latency but lower is better I guess.

 

[Craftydan]

GhstWlf,

true, not quite the same, but still, you have a valid point.

The 100ms is from work I've done in soft-control panels -- a 10hz refresh rate is typically "smooth enough" for pushbutton controls, so it's usually a goal. In reality, anything much below 4 Hz and the lag between a button press and response becomes noticeable and annoying to users. In full motion vid, gaming or FPV, you're right, that's not quite the same thing.

Agreed, lower is better, and above single digit refresh it may not be plainly visible, to some degree you can still feel it in the controls -- I've comfortably played FPSs at 30FPS (which analog TV runs at, BTW), but 15-20? barely can see the stutter, but un-fun enough to justify a nicer video card.

In FPV, I started with a Mobius on a quad and hated it -- could not keep ahead of the throttle and found myself chasing a pilot induced oscillation. Switched to a board cam and it became fun (all at 22ms frame rate -- I'm flying 11ms now, but more because the RX can do it, rather than it "felt better"). I've since flown a Mobius on a more sedate platform and it wasn't bad . . . but that airframe was doing all the hard work.

Lag is Lag and is to be hated, I suppose. Low-hanging-fruit is always best to hit first, but if it's still too long and the money is there to upgrade for that next little bit of improvement, who am I to say it's not worth it to the buyer?

 

[finnen]

Craftydan, not sure if you are aware of this, but there is actually difference in latency of about 50ms when comparing cppm and sbus/spektrum serial. The cppm pulse train is about 20 ms, but most control boards takes a 3 point average, which means it takes about 60ms for the control board to react.

The reason for this is that cppm is an analog signal, so there is no fault checking. sbus and spektrum satellites are digital, with built in fault checking, so no need to wait for the next value before using the current one.

Sure, 50ms isn't a lot, but it will be noticeable for people doing really fast proximity flying. If you are a newbie, I wouldn't care.

Adamw, in your case I would use whatever you have at hand. If you need to order something, the new orangerx receivers look really nice, I would go for that. Orangerx or lemon satellites will work to, they use a digital protocol, so performance should be comparable to SBUS.

 

[Craftydan]

As I mentioned earlier, even 3-point filters respond instantly . . . they just respond in thirds -- 1/3 this frame, 2/3 the next frame, and finally to full on the third. It's a smoothing feature in the FCB not particularly "lag" . . . which for those who tend to over-control a bit, that's not a bad thing

. . . that and CPPM outputs at the frame rate. If it's bound at 22ms, you get a new one every 22ms. Bind it at 11ms, you get it every 11ms (assuming the RX can support 11ms frame rates, but most newer RX's can).

 

[pressalltheknobs]

To answer the original question a bit more fully mostly for my own entertainment... Spektrum Satellite (SpekSat) or Orange SBUS for the least latency? I don't have either and I don't have the equipment to examine them closely in any case, so from what I can find from other people's investigations into SpekSat and SBUS...if you have a Spektrum radio, then SpekSat is the better bet but there's not going to be much in it.

It seems that SpekSat is essentially the binary DSM/DSM2/DSMX transmission from the transmitter, the data sent by the TX. So if this is sent directly to the FC you will get it as it happens subject to the latency of the TX communication which is the "frame rate" plus some negligible processing time.

Spektrum DSM* apparently uses two 16 bytes packets sent 11ms apart (or 22ms apart in older systems). Each packet contains space for 7 channels at full resolution (2048). Given this, the latency for a particular channel will be 22ms since the channel value is sent every other packet. If 22ms frame rate is used this means it could be as much as 44ms. The protocol allows for optimizations but it is unclear if or when this is done. There is some indication that DSM2 repeats channels in the second packet.

Note: I think the DX18 must pack the upper 8 channels somehow since there is only room for 14 channels and it only claims 2048 bit resolution on the first 10 channels.

Note 2: It seems newer Spektrum transmitters transmit at 11ms frame rate regardless of whether the RX is configured to put out PWM pulses at 11ms or 22ms so if your TX claims 11ms that's probably the latency you will see on SpekSat subject to the channel value potentially being sent every other packet

The Orange DSMX receivers with SBUS have to convert the Spektrum signal to an SBUS signal. It depends a bit how they do this. Futaba SBUS sends one 25 byte packet containing 16 channels (and 2 "digital" channels) every 7ms (fast) or 14ms (normal). Frsky SBUS is 9ms (fast) and 18ms (normal). These packet rates don't match the Spektrum rates so the mismatch will cause delays and thus have more latency than SpekSat.

It's possible that Orange just sends the SBUS packets at the Spektrum rate of 22ms - or possibly 11ms if there is optimization - which would make it essentially the same latency as SpekSat. I'm not sure how much leeway there is in the SBUS spec on packet rate so if Orange do this, it maybe you will get poor results using the Orange implementation of SBUS with other SBUS devices. That is entirely speculation though.

SBUS and SpekSat both run at around 100,000 bits per second so these packets take a couple of ms to deliver (25*8=200 bits; 100000/200=500; 1/500 = 2ms). It's mostly the time between the packets that gives the latency. Processing delays should be minimal except if there is conversions to different signalling.

I suspect the difference between 7, 9, 11, 14, 18, and 22ms is undetectable.

So that answers that. But what of this SBUS low latency vs CPPM reputation I hear you cry.

CPPM is a totally different animal. It's a pulse train of 1 to 2ms pulses for each channel so a 8 channel CPPM signal takes 16ms + gaps + one >2ms pulse to mark the frame. You can fit an 8ch frame in 22ms but it takes nearly the whole 22ms to send the 8 channel pulses. Actually one of the most commonly used racing quad receivers, the FrSky D4R-II has a 27ms CPPM frame. This odd time is due to the underlying 9ms FrSky SBUS packet spacing and that 8chs CPPM doesn't fit in 18ms (they tried and it caused some consternation) so they had to make it 27ms.

What this means is there is a extra delay of up to an entire frame before the FC has all the data from the 8 channels and can make its calculation as to what values to send to the motor controllers next.

So now add to this the effect of the 3 frame averaging which is apparently used - I haven't looked at the "***Flight" source codes to confirm it is - more on this below. As Dan points out, this does still act immediately so it's not a 3 frame lag as has been claimed but it is still a lag. It's difficult to quantify since it varies but the lag will increase the faster a channel values vary. So let's say, for the sake of argument, it contributes an average of 1 frame of latency.

So now we are up to possibly 3 frames of 27ms or 81ms. Now since the FrSky SBUS works at 9ms latency, it seems possible that someone who was really tuned in to flying it could tell the difference between something working at 9ms vs working at 81ms particularly if they flew them back to back. Not me obviously but some kind of drone-elete might.

An interesting observation though is that if you use parallel PWM, 1 frame of this CPPM latency might just go away. If the parallel pulses are all send as soon as the SBUS packet reaches the receiver then the FC will have read them 2ms later giving a potential latency of 56ms or maybe even 29ms if averaging is not necessary in the parallel PWM case. But I have never heard anyone claiming parallel PWM is faster/less laggy than CPPM.

On the 3 frame averaging, I'm a bit perplexed as to why it should be necessary. In modern RC systems, as I understand it, CPPM is generated by the receiver from the underlying digital packet, and as used by a FC, has to travel maybe 10cm between the RX and the FC. There is no reason I can see that such a signal would degrade to the point of requiring averaging. Before the advent of 2.4Ghz and digital signalling when CPPM was maybe the TX to RX signalling method I could see a point since presumably distorted pulses might occur due to interference on RF link and averaging might smooth this out for an analog servo. If this averaging is being done in the FC software today, I wonder if it is really necessary or just something put in for reasons that are now obsolete and misunderstood. Some further poking around is called for.

In case you are interested here are some of the links I found on which I based the above:

DSM* Satellite...
http://www.desertrc.com/spektrum_protocol.htm
http://blog.kwarf.com/2013/08/a-look-at-the-spektrum-satellite-protocol/
https://pixhawk.org/_media/dev/dsm2_dsm_x_protocol.pdf
http://wiki.paparazziuav.org/wiki/DSM
https://bitbucket.org/PhracturedBlu...M.txt?at=default&fileviewer=file-view-default

SBUS...
http://forum.arduino.cc/index.php/topic,99708.0.html
https://developer.mbed.org/users/Digixx/notebook/futaba-s-bus-controlled-by-mbed/

 

[AdamV]

wow, thanks for typing all of that out! i'm going to have to read it a few times to understand it all. And, a *ton* of thanks for the links

 

[pressalltheknobs]

Since I saw this thread referenced from elsewhere, it seems like a good idea to update it with some additional information.

It seems that Spektrum 11ms mode does optimize the channels in 11ms mode and sends 4 channels (2,3,4,6 I think) but not Throttle in every 11ms packet. This allows for fast refresh, 11ms, on those 4 channels. Throttle and other full res channels refresh at 22ms (every other packet). This allows for up to 10 full resolution channels over two packets (2,3,4,6 + 1,5,7) (2,3,4,6 + 8,9,10).

For some reason Spektrum don't document this anywhere in their manuals although apparently it is "not a secret" since their representative can share it on forums. Seems a bit misleading to me. It is a perfectly reasonable optimization but evidently the Horizon marketing department think just touting 11ms and 22ms is all we need to know.

I'm unclear how the DX18 full res channels 11 and 12 are sent or the low res X-plus channels...but these are only available in 22ms mode where no optimization of the 4 channels is performed. There is some overlay and the channels are staggered over a number of packets with up to 88ms refresh delay according to the DX18 and DX20 manuals.