What’s the fuzz about PPM and UDI?
Disclaimer: I’m just a hobbyist. I’m no expert in radio- or signaling-theory. These are self-noticed issues and what I’ve read on different forums.
Test-setup
- Jeti DS-16 v.3.02
- RSat2 receiver v.3.23
- VBar blueline 5.3.4 Pro
- PPM direct positive, 20 ms, failsafe off
- UDI direct, 5ms and auto timing, failsafe off
- Jeti at 100 Hz
PPM = Pulse Position Modulation
A signal with fixed time-frame (for example 20 ms) where all channels signals are transmitted as PPM frame decoder outputs within fixed total time. Separation of signals repeating with frame separation blank time. (Great info here.)
In picture above we can see a PPM-signal in scope. First channel starts on first rise and ends when second channel rises. The -100 to +100 value for the channel is determined from the width of the pulse. Total length of transmission packet (time between times channel 1 is repeated) is 20 ms.
Above we can see channel 1 being quite narrow, transmitter is sending channel as -100. The channels are sent with lengths of 1 ms to 2 ms and neutral (zero) point being 1,5 ms just as it should be. Now, let’s see what happens to channel width when having channel 1 at +100:
What we can clearly see is that when channel is at -100 the length of channel 1 signal is clearly 1 ms and when at +100 the width is 2 ms. So far so good.
Now, let’s do some calculation with normal heli-setup. Usually we are transmitting 8 channels. That means 8 times the max channel width 2 ms, that is 16 ms in total. After the last channel is sent there needs to be a certain amount of blank detection time for the receiver to understand that next signal is again channel 1. This gives us a usable total time of 20 ms with 8 channels allthough in theory 8 times 2 ms = 16 ms would be all we need.
So in conclusion every channel is repeated quite near every 20 ms.
But. Channel signals “move” inside the 20 ms time-frame. Let’s say channels 1 -5 are all at -100 value. This means channel 6 comes in at 5 ms time from the start. Now lets put channels 1 -5 to +100 value. Now channel 6 comes in at 10 ms. (5 x 2 ms = 10 ms). This is because of “chaining” the channels, so the exact time of when channels are sent are always depending on where the previous channels are what comes to their value. This does not concern channel 1 so much, it is always the firs within the 20 ms time frame and is always between 1 ms and 2 ms in width.
Why not adjust 20 ms to shorter? Well, in theory that works. Problem is that there is a minimum. We need the 2 ms per channel and the blank detection time. So practically the 20 ms is the minimum if/when the receiving unit (gyro) is using blank detection time. If gyro uses pulse count instead the frame-time can be shortened to (in practice) 17 ms.
UDI = Universal Digital Input
UDI is Mikado’s digital communication protocol to get signal from receivers to VBar gyro. Why this is such a fuzz is apparent when we look at the UDI-signal in scope:
All 8 channels are transmitted within fixed time-frame and the total time of all channels transmitted is not depending of channel values. We can zoom in a bit.
The advantage of UDI is very apparent in the scope-picture above. All channels are always sent in a fixed time of approx 2.5 ms and since the signal is digital there is no blank detection time needed. The frequency of transmission is determined of output period-setting. Unfortunately I can’t read digital signal in byte-level so I can only see the signal not the data.
Example calculations:
PPM – All 8 channels at +100 value, if blank detection time is ~4 ms then total minimum time is 20 ms. This means that channels value is repeated every 20 ms to gyro. That is 50 times in a second.
UDI – All 8 channels are sent digitally every 5 ms (if output period is 5ms) to gyro. That is 200 times in a second. Auto defaults to approximately 10 ms with some variations. (Picture of 5 ms setting below)
The question is, what is the tightest timing VBar accept’s? In scope 5 ms is working but I have not confirmed this with VBar. If we choose auto in Jeti the timing is 10 ms.
This is of course not possible in practice since transmitter can refresh channel (stick) values in max 100 Hz frequency, that means in UDI we get the maximum value refresh-rate of 100 times per second.
The fuzz?
The fuzz is about errors in VBar when using UDI. More specific it’s VBar loosing signal synchronization and in worst case scenario dropping the heli from air.
According to forum-consensus (great link here) this has to do with a bug in Jeti-firmware regarding failsafe. These errors occur when failsafe is off in receiver and transmitter frequency is set to 50 Hz.
Also it seem’s apparent that the signal-wire from receiver to VBar is prone to disturbances. So, always make sure You use as short cable as possible, try to route the signal-wire so it’s so far away from everything else as possible. A ferrite-ring is possible a good thing also.
I did extensive tests with my setup and I did not get these errors in any way even when using 50 Hz and failsafe on. This is most likely because I’m using newer firmware compared to cbdane’s testing with older firmware. This can also be confirmed when reading forums.
Some questions:
Why would You use 50 Hz in transmitter? Today there might be some gyro- / servo-setups that don’t like 100 Hz. My advice is to do some modernization and move over to 100 Hz
Why would You use PPM, it’s slower? Well, in my opinion with current firmware there is no point in using PPM. It’s slower, it’s not synchronized ie. channel input-values are not at fixed time-points. Also UDI is digital, it is by technology more precise.
Do You notice the difference in time regarding refresh-times? Most likely not. I mean really, 50 times in a second compared to 100 times a second? How fast does a heli move? how responsive is a heli in the air?
Why would You use failsafe off isn’t this dangerous? Failsafe should be set in VBar not in the receiver. When there is no transmission it’s the VBar that should determine what to do. This is the safest way to do failsafe, do not trust the failsafe to receiver when using VBar.
Now, just go out and fly Your heli and enjoy!
"Also UDI is digital" – It is *Not* digital; clearly it is an analog amplitude modulated signal as seen from your images. This makes it prone to noise. This is precisely why Pulse modulation is used. It is the difference between AM and FM radio, and why FM is superior in terms of noise.
To make things more worse, PPM, better dPPM because it is not absolute but delta Pulse Position Modulation, is pure digital!
In good old days as the pulses and the deltas where defined over charged and discharged capacitors it was indeed analog.
But, some assumptions you do are not as strongly defined as you believe.
The pause between the pulse packets is depending of the spoken dPPM variant and as far as i can remeber only (very loose) defined as if pause is longer then 4ms there is a new packet. Ah, and btw, dPPM is low active. Normally. That comes from the hf-transmitter stage. hf is emitted the whole time but keyed of if there is a pulse.
In modern times where the dPPM is defined by discrete counter/timer steps it may be look like analog but can only do discrete steps and is by definition digital.
BTW, it would be very easy to synchronize dPPM but you will loose a little bit of time because you have to wait until the whole packet is received.
But there is another draw back of this. If i remeber correctly, in the beginning of the 2.4GHz RC, the good old times as spektrum does the first steps and there was an RC named "Aurora", there where efforts to synchronise servo outputs what leads to power problems because ALL servos started to move at the same time and some times they overload BEC or even battery which leads to disconnected receiver because of brown out and some times loss of model.
So, i would be carefull about my wishes.
You did read the disclaimer, right? :)
It could be fun to do this again, after all it’s been about 8 years :)