Thread Tools
This thread is privately moderated by JimDrew, who may elect to delete unwanted replies.
Dec 04, 2018, 07:40 PM
Thread OP
Yes, based on the SPI data and watching the IRQ line, It is clear that the RF loss impacts both protocols equally. However, the UDI data stream "appears" as an uninterrupted stream, unlike the ExBus data stream which just drops the frames that are lost, leaving gaps. JETI should probably figure out why there is so much packet loss, and at very least change the ExBus output to be like UDI where you don't actually know how much loss is occurring.

I don't mind if I kill my JETI transmitter by accident. It is going to take a bit of experimenting to figure out the module pin out.

I re-captured the R3 SPI and ExBus/UDI again with a higher data rate so you can actually decode the stream correctly with something like your excel macro. I captured it originally at just 4MHz to keep the file size small enough so I could attach them to RCGroups, but that goofed up the SCLK and thus MOSI/MISO. The first post now has a link to the protocols.zip file that can be downloaded and read/decoded.
Last edited by JimDrew; Dec 04, 2018 at 07:50 PM.
Sign up now
to remove ads between posts
Dec 04, 2018, 07:40 PM
Registered User
Quote:
Originally Posted by JimDrew
Yes. I have been beta testing/using Saleae products since their first LOGIC device was released. I literally have one of everything they have made. The latest version is the LOGIC PRO 16 which can capture analog signals. It's amazing stuff. You can download their software from their website (www.saleae.com) and use it in demo mode to look at the dumps I have made. John and I have shared dumps while looking over this stuff.
I was going to say the same thing. You can download the software and look at recorded traces.
When I test, I always save the raw data, then take the screenshots to post.
I will post the raw traces I did for this thread.
Dec 04, 2018, 07:43 PM
Registered User
Quote:
Originally Posted by JimDrew
It is clear that the RF loss impacts both equally, however, the UDI data stream "appears" as an uninterrupted stream, unlike the ExBus data stream which clearly just drops the frames that are lost.
I agree it does appear that there are no udi "holes" in fixed period mode, but udi frames are just being repeated on a hold last basis, when RF/exbus frames are lost/missing.
Dec 04, 2018, 07:51 PM
Thread OP
Yep... so the question now remains - which side is responsible for this packet loss. My DC16 is opened up and wires hanging out.
Dec 04, 2018, 09:27 PM
Registered User
Quote:
Originally Posted by cravenjw
I was going to say the same thing. You can download the software and look at recorded traces.
When I test, I always save the raw data, then take the screenshots to post.
I will post the raw traces I did for this thread.
That would be cool and very interesting to say the least.

So to sum up am I correct in saying this issue seems to be tx related and not rx?

Udi is supplying the missing data with what it thinks is the last good data?

Exbus is just leaving blank data or dropping data where there isn't any good data?
Dec 04, 2018, 09:55 PM
Registered User
Quote:
Originally Posted by WR_Rider
...
So to sum up am I correct in saying this issue seems to be tx related and not rx?
...
I have only looked at the RX side, via logic traces from RX output and the RX spi bus (this was limited).
I also used a ATMEL Zigbit USB stick as a 802.15.4 packet sniffer and piped that into wireshark.
I could only listen to one channel, not all 16. In limited testing the sniffer suggested (but not conclusively) that it might be issue at TX.
I mean the sniffer often missing frames and the same time as jeti. But not always. This anecdotal. I hate not being able to data/traces my statements.
I wanted to do what Jim is proposing on the TX side. But i like to fly, more than i like to test jeti. I didn't risk my tx.

My issue saying it is at the tx, I do not have a clean RF shop or testing space.
Most of my testing in the presence of some wifi.
I have done tests to see how wifi causes RF loss with jeti.
It does cause interference and Jeti packet loss.

I have basically worked under the hypothesis that the 0.5-1.0% packet loss even at close range testing, has been most caused by wifi.

Quote:
Originally Posted by WR_Rider
...
Udi is supplying the missing data with what it thinks is the last good data?

Exbus is just leaving blank data or dropping data where there isn't any good data?
If a valid RF frame is received, the channels are put in a buffer.
An exbus frame is generated immediately using those channel values.

If the RX has period auto:
PWM/PPM/UDI are also output immediately using the channel values.

If the RX has period 5-30ms:
The PWM/PPM/UDI run in a different loop.
Each cycle, when they go to do their output, the grab the current value in the channel buffer.
If the buffer has not been update, they output the pulse/frames repeated, ie they hold last.

One last little tidbit. I am not going to go into details, because i documented it in a thread in the Jeti USA forum on failover/failback.

If RF is total lost, the PWM is keep repeating until the failsafes kick in.
But, UDI and PPM, will actually repeat for 40-45ms, and then stop outputting.
Dec 04, 2018, 10:00 PM
Registered User
Saleae Logic software downloads

I have attached the raw capture data to my first post and will attach them to future posts.
Dec 04, 2018, 11:10 PM
Registered User
Here is a 10ms output period trace.

I am also going to show the RX is not updating internally at 14ms,
10ms/100Hz data generated by the sequencer is getting thru (except in the RF holes!)


Period:10ms (Full Trace)
Name: REX7-UDI-EXB-10ms-1-i.png
Views: 13
Size: 123.9 KB
Description:
I have marked area with 2 frame and a 1 frame gaps.
This will help show the udi and pwm behavior with periods other than auto.
Note, there are no UDI holes, But i am going to show you that in the rf/exbus holes the pwm/udi frames a repeating, not unique.


Period:10ms (Zoomed into to show the RF gaps at 0.86s and 0.91s)
Name: REX7-UDI-EXB-10ms-1z-i.png
Views: 14
Size: 128.2 KB
Description:
If you look at the ch1 pulse widths i labelled in left rf loss, you can see the pwm widths are;
1.13ms, 1.14ms, 1.14ms(repeat), 1.14ms(repeat), 1.17ms
there 2 repeat 1.14ms pulses during the 2 frame rf loss
when the rf returns the width jumps to 1.17ms, as expected
with no RF loss, i expected, 1.13ms, 1.14ms, 1.15ms, 1.16ms, 1.17ms

The next single rf loss, we a have 1.19, 1.20, 1.20(repeat), 1.22
instead of 1.19, 1.20, 1.21, 1.22

I went thru the circled groups, and confirmed that it udi frames also, hold/repeat in the same way.

its pretty black and white.
Last edited by cravenjw; Dec 04, 2018 at 11:16 PM.
Dec 04, 2018, 11:41 PM
Registered User
Last one trace, 5ms output period

Period:5ms
Name: REX7-UDI-EXB-5ms-1z-i.png
Views: 17
Size: 129.9 KB
Description:
I have zoomed into a nice 3 frame RF loss.
I have labelled the pwm widths.
I have gone thru and checked the bytes on the udi frames and labelled them and the pwm pulses with there rf/exbus frame providing the data.
We running at 5ms, with 10ms data for tx, we expected two pulses with same width and two udi frames with same bytes.
This is nice, concept, but remember our periodic outputs are being supplied with RF with considerable jitter (intentional).
Look at the variation in timing of the exbus (jitter) with the matching periodic udi frames.
Only in auto, do you see exbus and udi/pwm closely sync.
Last edited by cravenjw; Dec 04, 2018 at 11:50 PM.
Dec 05, 2018, 12:10 AM
Thread OP
Quote:
Originally Posted by WR_Rider
So to sum up am I correct in saying this issue seems to be tx related and not rx?
I don't know yet. It could be the RF chip is not being reset to receive mode fast enough after a channel hop.. or it could be the transmitter is not sending a packet because it is simply too busy trying to process data (CPU is bogged down), or there is a bug somewhere in the logic. Until I capture the transmitter, it's all speculation.


Quote:
Originally Posted by WR_Rider
Udi is supplying the missing data with what it thinks is the last good data?

Exbus is just leaving blank data or dropping data where there isn't any good data?

Yes, this much has been proven to be true.
Last edited by JimDrew; Dec 05, 2018 at 11:57 AM.
Dec 05, 2018, 11:39 AM
Registered User
Jim,
I wish I had to time to dig in an find the answer(s) to the always present <1% RF losses we see with Jeti.
I admire your search for the truth.

But i can't figure out why you would dwell on this, and are focusing on this issue, and not turning our efforts to making your XPS work with the jittery 100Hz (on paper, > 99Hz in practice) EXBUS signals.

The <1% has been there forever. Its not significant issue in the world of Jeti.
Most Jeti users came to your XPS products when i documented the less than ideal utilization of a second RX connected to the CB200. The majority of CB200 users probably were never impacted in a critical way. The average CB200 user lost at most couple of percent of control frames that could have been sent to the servos from a secondary RX.

But currently, if i am reading right, you seem to asking Jeti users to only use UDI at 14ms. This means that those users are instantly throwing away, 29% of their 100Hz control data. The statistical losses using a CB200 and it poor RX2 utilization were far less!

My point, is why are you obsessing over this 1% RF issue in another brand, saying because its not right, Jeti users must give up 29% more!
You should be working on a Exbus XPS that handles all RX frame by frame, using EXBUS in all its jittery and imperfect glory, and gives the couple percent back to former CB200 users!

If you do, i think you win (more sales) and the Jeti user wins.

That's my 2cents!

I will continue to follow your threads. Ill try to stay out, unless i see any info posted about Jeti that isn't not correct.
Dec 05, 2018, 12:34 PM
Thread OP
The reason I "dwell" on this is that there are JETI users (IMAC and jet pilots) that are having severe loss of control of their aircraft, and until they got the X24 they had no idea why. Several of them got the X24 thinking that their problem was with the CB200 (perhaps after your in depth review of its problems).

The packet loss is far greater than 1% in my testing here. In fact, up to greater than 10% is quite common with several different systems (DC-16, DC-24, DS-24) that I have had here for testing (just to rule out one specific transmitter). However, customers are reporting thousands of lost frames during a flight in ExBus mode. What customers are reporting is real-world experience during flying, and that needs to be noted.

The reality is that there should be 0% packet loss in a controlled. short range, test. As in absolutely NONE. This is what I experience from ALL other radio systems that are tested, even the cheap Chinese radios. To say that even 1% packet loss is acceptable is simply ridiculous. If the test was conducted with a mile of separation between the transmitter and receiver, and you were getting 1% packet loss that would be certainly acceptable. I conducted tests with MaxStream (now Digi) of our original system 12 years ago, and we had better than 90% packet success at over 5 miles away!

Most JETI users came to our X24 because it has far more features, more channels, substantially better servo outputs (nearly simultaneous which means dramatically reduced latency), better power handling, lifetime warranty, and it's less expensive.

Quote:
Originally Posted by cravejw
You should be working on a Exbus XPS that handles all RX frame by frame, using EXBUS in all its jittery and imperfect glory, and gives the couple percent back to former CB200 users!
Ah... perhaps you don't realize that the X24 already supports ExBus perfectly - jittery and all. The issue is that when an ExBus frame is dropped the X24 reports it! This is how the problem with how severe the dropped frames are was discovered in the first place. You can sit and watch the loss frame counter for a receiver increment like gas pump meter! The control appears to be perfect, but there is data constantly being lost. In UDI mode, you don't see the loss because that has now been proven to be "smoothed over". 14ms is about the fastest frame rate that operates analog servos without burning them up, and that is the frame rate of Futaba SBUS systems. It's a reliable frame rate for ESCs, gyros, etc. If JETI can fix the frame loss (and not by just smoothing it over), then I could recommend ExBus mode be used again. At this point, people need to be aware that there is a lot of frame loss occurring, as both you and I have proved.
Last edited by JimDrew; Dec 05, 2018 at 01:00 PM.
Dec 05, 2018, 12:53 PM
Registered User
Quote:
Originally Posted by JimDrew
...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.
Sorry i thought the point of this thread was a warning to Jeti users to only use UDI, and not EXBUS.

I have demonstrated that in terms of RF reception, there is nothing that will keep a plane in the air, and get more data to the servos, using UDI rather that EXBUS. However, running, UDI at 14ms, rather than EXBUS auto, instantly discards 29% of the possible data. You stack the same RF losses on top of that for UDI as you get with EXBUS.

I know some of the guys who have extreme Jeti issues. Even some who are using your products. Its great they have had any issues, but its not because the have any less RF losses, or anymore unique control data going to the servos.
Last edited by cravenjw; Dec 05, 2018 at 01:00 PM.
Dec 05, 2018, 03:31 PM
Thread OP
That warning was prior to discovering that the JETI system just masks the packet losses in UDI mode.

I think you are missing one important point here - the JETI system ALWAYS sends RF data at either 100Hz or 50Hz, depending on your SYSTEM/CONFIGURATION setting. It is ONLY the output rate for the UDI protocol that can be varied. You are NOT losing 29% of the RF data by changing the frame rate. You are simply updating the servos 29% slower, using 100% of the available RF data. If the RF data rate was slowed by 29% then I would agree with you - but it's not. It's the protocol update rate that is being slowed. There are frequent cases where two RF frames (the end of one and all of another) appear before the 14ms update occurs. So you are getting two RF frames which could be different with the 2nd RF frame's data being used for the protocol output. This is why the latency constantly shifts.

I did discover something interesting today while looking at the dumps. I do see lost packets (RF wise), but the ExBus failsafe just happens to take over in the nick of time so it looks like there was no loss of that packet - when clearly there was. If you look at the IRQ line for the AT86RF23x chips, it goes high on a valid packet reception. You can see in the dumps where this does not occur and that results in what appears to be some confusion in the receiver? The SPI commands to the receiver are sort of goofy until the next RF frame occurs and then it's back in sync again.

I removed the RF shield from one of the JETI transmitter modules and made a pinout diagram. I wired up ground and SLP_TR (on both RF modules), which is the recommended (but not required) method to start a transmission after your start filling the transmit buffer. JETI doesn't seem to use SLP_TR at all. Argh! So, I am going to wire up just the SCLK. I should see an exact repeating pattern with no gaps. I would wire up the complete SPI port, but I am not sure which RF module is the primary, and which is the secondary. I hate to have to wire up two full sets of wires.. it's quite a rats nest already.

If you get brave enough to wire up the SPI yourself, here is the pinout. I should probably wire up the complete set and capture the range test, binding, and standard modes and offer compatible receivers to JETI users.
Last edited by JimDrew; Dec 05, 2018 at 04:15 PM.
Dec 05, 2018, 04:28 PM
Registered User
Quote:
Originally Posted by JimDrew
...
I did discover something interesting today while looking at the dumps. I do see lost packets (RF wise), but the ExBus failsafe just happens to take over in the nick of time so it looks like there was no loss of that packet - when clearly there was. If you look at the IRQ line for the AT86RF23x chips, it goes high on a valid packet reception. You can see in the dumps where this does not occur and that results in what appears to be some confusion in the receiver? The SPI commands to the receiver are sort of goofy until the next RF frame occurs and then it's back in sync again.
....
Just to clarify, you see this on the RX side?
i have an R4 or R5 with SPI wires.
I do understand the interrupts on reception and tx buffer empty, and other for other features.
Jeti only uses the interrupt of reception? not Clear channel assessment or tx or others?

If the only the interrupt enabled on the RX side is for incoming RF, then i agree, this is a super simple way to determine if the RF arrives but is mishandled and not output. Its also a super simple way to collect long term RF receptions stats. However, its a lot of work, if the interrupt is enabled for more than just RF reception.

I will figure where to add a interrupt wire, and be ready to measure some stats and confirm what you see.


Quick Reply
Message:

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