|
|
Thread OP
|
Alert
X24 customers please read!
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 ImagesView all Images in thread
|
Last edited by JimDrew; Dec 04, 2018 at 07:38 PM.
|
|
|
|
|
|
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 |
|
|
|
|
Thread OP
|
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/ |
Last edited by JimDrew; Nov 30, 2018 at 04:02 PM.
|
|
|
|
|
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 ? |
|
|
|
|
Thread OP
|
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.
|
|
|
Thread OP
|
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? |
|
|
|
||
|
Quote:
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. |
|
|
Last edited by cravenjw; Dec 03, 2018 at 10:43 PM.
|
|
|
||
Thread OP
|
Quote:
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. |
|
Last edited by JimDrew; Dec 03, 2018 at 11:33 PM.
|
||
Thread Tools | |
Similar Threads | |||||
Category | Thread | Thread Starter | Forum | Replies | Last Post |
Alert | Customers outside North/South America PLEASE READ | Xpress.. | Hitec/Multiplex USA | 0 | May 17, 2018 01:08 PM |
Discussion | A plea to the community. | Joexer | Model Aircraft & Drone Advocacy | 1 | Dec 23, 2015 08:37 PM |
Discussion | Plea To DJI for better Inspire Customer Service | jfro | Multirotor Drone Talk | 5 | Apr 13, 2015 10:11 PM |
Discussion | Need some info about radios-Pleas read | mrhodes | Radios | 2 | Feb 12, 2014 12:55 PM |
Discussion | From Customization to Custom Builds: Addictions and Community (READ POST #1) | ChristianGeek | Multirotor Drone Talk | 184 | Jan 08, 2014 08:25 PM |