After several weeks of testing and consulting with other developers I have concluded that there is a problem with the JETI system dropping packets (frames) while the receiver(s) are set to output the ExBus protocol. There are no problems with UDI12 or UDI16 (as far as I can tell). It is recommended that all X24 customers use only the JETI UDI setting and set your JETI receivers to UDI12 or UDI16 mode, with the frame rate set to 14ms. You can have the system rate at 100Hz or 50Hz, as that does not matter. You can use dual path or normal Tx modes with one or more receivers as long as the receivers are set to output one of the UDI modes.

In an RF controlled environment I conducted numerous (and I mean over 100) captures of the JETI system in the various output modes, and with dual path mode on and off. Every time the results were identical (or should I say random). While the receiver is set to ExBus mode, it randomly fails to output some ExBus protocol packets. With the X24 you can see the lost packets for each receiver in real time, as well as the actual total loss of packets (when both receivers did not receive a packet). Initially, there is huge loss of packets on each receiver but the total loss remains just a few because it just so happens that the no actual loss is occurring when one receiver does get a good packet. However, as time goes on the receivers start to get out of phase and you end up with as many (and then more) lost packets as good packets. With a single receiver in ExBus mode there is constant packet loss the entire time due to not having a secondary receiver. When the receiver(s) are set to output UDI12 or UDI16 mode, there was zero packet loss in all of my tests, which were all conducted in the exact same controlled environment.

Attached are images of the captures for the JETI System in dual path mode with dual REX 12 receivers set to output ExBus, and then UDI16 modes. You can see the skipped packets in ExBus mode (random gaps) and no loss that occurs in UDI16 mode. Also attached are images of the XtremeLink system with dual Nano receivers. This is using a Graupner MX16 transmitter with the XtremeLink system built-in. I did this to show the latency difference between the JETI and XPS systems. Our dual receivers output the Xtreme protocol within 1us of each other. You can also see that our receivers output the channel data at virtually the exact same time, unlike JETI which has an odd staggered pattern. This staggered output would be a real problem for heli pilots or even giant scale pilots that expect opposite surfaces to be moving at the exact same time. When using the JETI system with the X24, you get the same simultaneous servo outputs that our receivers have, so it eliminates the servo output latency.

I am also including the raw captures that are done with the LOGIC 16 PRO from Saleae so you can load them in and examine the data down to the nanosecond.

http://www.xtremepowersystems.net/do.../protocols.zip

So if I'm understanding this correctly, with the udi setting we are gaining not having any lost packets but we still end up with a shift or sync error between the two recievers. I assume that isn't good either.

The receiver shift just causes random latency.

Does it matter if there is dual receivers? Would we still be getting dropped packets even if there was only 1 receiver? I would then think that even with a CB200 or such it too would be seeing all this lost data. Also the frame rate has no effect on the exbus lost packets?

Thx

Any JETI receiver set to output ExBus protocol is dropping packets. Any device connected to a JETI receiver in ExBus mode is going to see dropped packets - X24, CB200, CB400, PowerBox, etc.

In ExBus mode, the frame rate setting is ignored. The system refresh rate (100Hz or 50Hz) doesn't matter, but you will see packet loss twice as fast in 100Hz mode.

It seems that even in "grouped" mode, the JETI servo output latency varies by 24.3ms - https://rc.runryder.com/t172571p1/

How does the frame rate of 14ms work with the UDI? Why not say 10ms?

Thx

You MUST use 14ms. Nothing else will work. The JETI system itself is 14ms internally and any other frame rate causes syncing issues, so I require the frame rate to be 14ms to match.

The screenshots doesn't really tell us anything about which packages are sent, or if any is missing at all. You will have to look at the specific pakages to conclude that.
At 100Hz you get one channel package every 10 ms, but there are other packages sent as well. These are send in between the channel packages, and those can be send at more random times depending on e.g. if the JetiBox Emulator is in use on the Tx, when telemetry is requested etc.

Did you do any analysis on the actual packages or did you "just" look at the trace pattern ?

I don't think you understand how the JETI protocol works. The over-air data rate can be either 100Hz or 50Hz, and the data stream should always produce packet data every 10ms or 20ms. UDI12 and UDI16 modes clearly work per the JETI specification. It's just the ExBus mode that has issues with dropped frames. The data that is missing is actually missing because you can set a trigger (like a switch change) and if it just so happens to coincide with a dropped frame on one receiver, it does appear on the other receiver. I am going to connect the logic analyzer directly to the RF chip on the Tx interrupt in the transmitter and Rx interrupt on a receiver to see if the Tx is not actually sending the packet or if the Rx is not actually receiving the packet . Another possibility is that the Rx is receiving the packet from the Tx, but not actually outputting the packet data via the ExBus output.

So you are saying that the frames missing is on the RF connection between the Tx and Rx and not on the ExBus data stream ?
Or is it on both sides, i.e. a frame miss on RF gives a missing packet on the ExBus ?
Did you test other Rx or just the REX 12 ?

I am not sure yet if the issue is the Tx not sending all packets, the Rx is not receiving all packets, or the Rx is not sending all packets through the ExBus port. This issue occurs with multiple different JETI receivers, using normal or dual path modes.

In response to this post:

https://www.rcgroups.com/forums/show...ostcount=35932


There are absolutely NO (other) radio control systems on the market that output a protocol that randomly drops packets as part of their "normal" operation. I have in-depth knowledge of all of the various RF and local protocols used for radio control systems because I spent a considerable amount of time reverse engineering all of them for a white paper that I wrote for a defense contractor.

I have provided the raw capture files created using one of Saleae's LOGIC 16 analyzers so that anyone can download their software and examine the data stream themselves. There are no issues with lost frames in UDI or PPM output modes, only with ExBus mode.

I am in the process of connecting the logic analyzer directly to the transmitter's RF chip and the receiver's RF chip to determine where the loss is actually occurring. I will also make those captures available.

It seems to me that knowing if its the tx or rx would be a good thing.
If the rx converts the incoming signal to exbus or udi stream and the conversion to exbus is the issue, then do you see any issues with the incoming signal sent via pwm directly to the servo's?

In the end this dropped frame issue can't be too bad since it seems to work in the end. What is the % of dropped frames then?

Originally Posted by JimDrew

.... The JETI system itself is 14ms internally and any other frame rate causes syncing issues, so I require the frame rate to be 14ms to match.

This is not correct
Jeti is 100Hz (or 50Hz but i doubt this is used much).
User may set the PWM/PPM/UDI output rate of the RX to auto or fixed period (5ms-30ms), but not the EXBUS frame rate.
TX sends at 100Hz (or 50Hz is the user chooses to lower the TX rate).

EXBUS frames are output from the RX, immediately following RF frame reception. No RF frame, no EXBUS frame.
In auto mode, the same is true for PWM/PPM/UDI. No RF frame, not PWM/PPM/UDI.

In fixed period mode, incoming RF channels are buffered in RX.
RX outputs PWM/PPM/UDI are based on the last buffered channel values.
If no RF frames are received, PWM/PPM/UDI effectively hold the last values, until the fail safe period is reached.

After failsafe starts... well you can read one of the many threads in the Jeti forum where i have documented the failover and failsafe for each output type EXBUS/PWM/PPM/UDI.

If your XPS device expects 14ms, then yes the Jeti user should follow your guidelines, and set the period to 14ms.
But would be an XPS requirement. Jeti doesnt work any better or worse given an RX period of 5-30ms.

Originally Posted by WR_Rider

It seems to me that knowing if its the tx or rx would be a good thing.
If the rx converts the incoming signal to exbus or udi stream and the conversion to exbus is the issue, then do you see any issues with the incoming signal sent via pwm directly to the servo's?

The JETI system is asynchronous in UDI/PPM modes, and synchronous in ExBus mode. In both cases, the servo outputs are buffered and output every 14ms with the protocol output at whatever rate is selected (programmable) for UDI, and either 100Hz or 50Hz for ExBus. PWM servo outputs on the receivers will output whatever the last frame is when a frame is lost.

Originally Posted by WR_Rider

In the end this dropped frame issue can't be too bad since it seems to work in the end. What is the % of dropped frames then?

With a single receiver I am seeing 10% at first and it increases from there over time. I am not sure where the maximum point is but I have seen as much as 50% when two receivers are out of phase.