REX UDI problems vs. firmware 1.01, are they gone?

Shortly, yes.

I still advice you to read on a bit, it is not that simple.

What is it about?

It’s about the inconsistency of UDI-signal from REX-series receivers to gyro’s used in heli’s. Most sensitive according different heli-forums to this issue seems to be Mikado’s VBar. There are quite a lot of write-up’s on forums about this phenomenon, one that triggered me to try to go to depths with the issue is when user “cdbane” wrecked his Velos 880 due this error, I’m using UDI in my 800 Xxtreme equipped with VBar Silverline Pro and definitely do not want to wreck it. Read the thread about cdbane’s findings here. More on the UDI-issues can be found in this long thread. (Both on Helifreak)

Let’s get cracking with this.

Equipment used

Used equipment in this article

• Jeti DS-16 with firmware 3.02 and 4.00
• REX6 with firmware 1.00 and 1.01 (UDI 12)
• REX7 with firmware 1.00 and 1.01 (UDI 12)
• R6 with firmware 3.24 Standard (UDI)
• R9 with firmware 3.24 Standard (UDI)
• RSat2 with firmware 3.24 Standard (UDI)
• Mikado VBar Silverline Pro 5.3.4
• Mikado Mini-VBar Pro 5.3.4
• Rigol DS1104Z Oscillosope

All UDI signal-settings were Direct, Failsafe disabled, TX on 100Hz.

UDI signals were examined both with gyro attached and freely with only the oscilloscope connected, no difference on signals were found.

No difference in behavior regarding transmitter firmware 3.02 and 4.00, so I can be pretty convinced this is solely a receiver-issue.

All R-series receivers including RSat2 were “clean” regardless of timing & settings applied.

Disclaimer

I’m a RC-hobbyist, not an engineer in different signal protocols and their transmission over the air. Always use source-criticism when browsing world-wide-wait. I’m interested in these things and can draw some conclusion on findings, therefore the article.

Initial findings

First impressions with fw 1.00 are actually quite worrying regarding REX-receivers. There are a few issues:

• Signal is not locked, timing is “all over the place”
• Timing adjustment on transmitter does nothing.

Here’s a short clip of both firmware 1.00 and 1.01 from REX6 to explain the situation:

I have no doubt that gyro could get into problem-situation when signal looks like this, I do believe gyro has great issues trying to lock to signal. If the gyro can’t lock to a enough amount of packet’s gyro rightfully thinks the signal is lost and goes to fail-safe, that also usually means a crash with heli.

On top of that, with REX7 initial view with fw 1.00 was even more worrying:

The signal actually floats between packets! Fortunately this receiver was not in use. (Also the timing was funny, it was even more “all over the place” than REX6. At first I was thinking about hardware-issue but after updating this unit to firmware 1.01 it was exactly the same as REX6 with fw 1.01. So there’s obviously nothing wrong with the receiver itself.

Why?

Unfortunately I do not see any other reason than error in code from Jeti’s part. It might be that UDI does not have to be time-locked but I find that hard to believe. It is pretty clear that an electronic device (gyro) has a lot easier to lock to a signal when it arrives in a timely fashion. Of course I might be way off here, I quite often am :)

All these are of course just guessing since we normal mortals do not have access to UDI protocol specification. At least I’m unable to find anything conclusive about it, I’m pretty sure Jeti had to sign an NDA (Non disclosure agreement) with Mikado about it. Too bad.

REX Firmware-release 1.01

Well, to start with, get yours from the download-page or with direct link to Jeti’s file.

Release notes are promising on the “Modified”-section:

• Increased minimal gap between UDI and ExBus data packets
• UDI packets period is also controlled by “Output period” value (like servo outputs)

So, here we go!

What is UDI?

UDI is a summary-signal from receiver to gyro. That was in short. So is also PPM. The differences are covered in my previous article about UDI vs. PPM here.

Let’s have a look on UDI with 8 channels:

Above is one frame of UDI summary signal. This is 2.35ms long (With UDI 16 channel the signal-packet is 3.00ms), the size does not change when using channels since the data is digital and not based on signal width like PPM , that means it’s a “fixed time-frame signal”. The problem with fw 1.01 lies in the issue with timing. Let’s take look on the timing:

UDI packets are spaced 10 ms apart when output period is set to 10ms (or “Auto“in Device explorer -> REX6 -> General Settings -> Output period.

Now, here’s an important note! (If you do not read whole article, read this!)

If “Auto” is used instead of fixed time (10ms) the packets are obviously trying to lock to something but cannot do that and they fluctuate quite a lot! The Auto timing defaults to 10ms but it is not stable. After seeing this behavior it is my conclusion one should always use the fixed time! My suggestion is to use 10ms. (You do remember that PPM is 20ms apart, right? So UDI is faster even in fixed time-frame) This happens with both firmware’s 1.00 and 1.01!

Just for the heck of it, when we are using a 2.35 ms signal packet, let’s see how it behaves when timing is set to 5 ms in firmware 1.01:

Looks like that would work, signal is stable with firmware 1.01. We can see that the UDI-packets are now only 5ms apart. This means we are controlling gyro with four times faster than we would with 8 channel PPM-signal. (We remember that 8 channel PPM needs to be 20ms apart.)

Why should we not use 5ms timing, I wanna control my heli with up-most precision!?

Honestly, I’m not sure. There is a reason that Jeti’s “Auto”-settings defaults to 10ms, we just do not know the reason. The issue here is pretty clear and simple: We do not know the UDI specification. We do not know how UDI works, what timing is specified by Mikado and what timing VBar really would be most comfortable with.

And frankly, that sucks. I do understand the will to keep the protocol itself under NDA, but the signaling specifications could be made public without harming anyone or giving the secrets out. As I see it, it also the safety issue when we, the users. have a possibility to use “wrong” signaling options.

I did test 5ms setting with both Silverline and mini-VBar, both were totally comfortable with 5ms setting. No matter what I did I could not generate any “out of sync”-errors. Would I still use it? Not at this time, I’d like to get some signal-timing information from Jeti or Mikado.

EDIT: I cannot believe I did not see this: Transmitter has a 100hz setting, that means the transmitter sends updated info every 10ms. Even if we make the receiver send out data-packets every 5ms the actual updated channel-info is only on every other packet, that is every 10ms. Thanks to jmackey on Helifreak for reminding me!

Is it fixed in firmware 1.01?

Yes, it is. The signal is now the same as what it is in R-series receivers. That means it’s solid and behaves (in my eyes) exactly as it should. Also, now the output period-adjustment actually does something as seen in previous picture. In fw 1.00 the 5ms setting is not possible, actually the timing seems to be in “Auto” regardless what we choose.

Am I confident to fly my 3000€+ heli with REX6 with UDI?

With firmware 1.01 on REX, yes. Simple as that.

Where to from here?

I have asked both Jeti and Mikado to comment this, I have asked about the timing and other comments they might possibly have.

Let’s to be seen if they answer, hopefully they do. Most likely they will kill all my findings and yell at me but we’ll see :)

Now, go out to field, fly something and have fun, after all it’s that it’s all about! :)