Thread Tools
This thread is privately moderated by JimDrew, who may elect to delete unwanted replies.
Dec 06, 2018, 08:59 AM
Registered User
Quote:
Originally Posted by JimDrew
...
::edit:: It has a SE2431L on the part.
http://www.skyworksinc.com/Product/933/SE2431L
...
Thank you
Sign up now
to remove ads between posts
Dec 06, 2018, 09:01 AM
Registered User
Quote:
Originally Posted by JimDrew
Yeah, when Gene was here (as well as the AMA event) his receiver packet loss was insane. I have many customers experiencing the same thing though with REX recievers. It seems the R3 recievers fair much better than the REX receivers. I will let you know what I see with your stuff.
I hope they are using the latest 1.12 fw. The prior versions had multiple bugs, some of which impacted both EXBUS and UDI outputs.
Dec 06, 2018, 12:12 PM
Thread OP
Yes, they do!

Quote:
Originally Posted by TBeghtol
When we try his out with the newer REX receivers we get almost immediate counting of one or both receivers at a fairly rapid rate of frame loss. Have swapped out receivers, leads, and re-verified all the settings to match those in my R3s. The REX receivers have the latest 1.12 update.
Dec 06, 2018, 12:34 PM
Thread OP
Quote:
Originally Posted by Edgar Perez
Guys
Appreciate the detective work here...
Seems that more testing is needed to reconfirm best path forward. Appreciate if conclusions or options for users are restated once there is more certainty. I use planes with either XPS24 and just plain receivers.
I was about to patch my XPS24 with the latest firmware for Exbus in order to get the 24 channels, but seems I should wait before doing so.
Thanks.
You can update your firmware and tinker with the ExBus protocol, just be aware you are going to see a lot of packet loss.

Here is what we know right now:

In my RF test setup the background noise level for the entire 2.4GHz band peaks at -97dBm, and is as low as -100dBm, depending on the exact frequency. I have tested the following systems (using a direct connect to their RF chipset, like we have done here for the JETI system): XtremeLink, JR DMSS, Spektrum, Graupner HoTT, Futaba, FrSky, Hitec, Airtronics, Walkera, and a couple of Chinese toys. In all cases, there has always been zero packet loss between the transmitter and receiver. The transmitter and receiver are separated 10 feet apart to eliminate any possibility of receiver front-end saturation due to being too close to the transmitter. The JETI system is the only system where I have seen packet loss. Our customers reported the packet loss to us when the support for the ExBus protocol was added to the X24. When I tested the X24's ExBus support I did see some packet loss, but attributed that to me placing the receiver between myself and the transmitter, and moving transmitter around on a desk, all of which can randomly block the signal. It wasn't until I started getting people asking about the packet loss that I really looked into the issue.

After connecting the logic analyzer to the JETI RF modules and receiver, it's pretty clear that data is missing. JETI is using the exact same RF chipset that we use, so I know the quirks of this RF chipset and I know it's pretty easy to have interference between two modules when they have their antennas closer than 8" apart, which is the case for the JETI transmitters. My gut feeling is that one RF module is interfering with the other, but that could certainly be wrong. It's possible that there is not enough settling time after a channel change during the frequency hop before a transmit occurs, or other little issues. It's not my product, so I really don't need to figure out the issue. I just needed to identify that their system is losing data in a clean RF environment, proven by a spectrum analyzer and the fact that no other system exhibits this behavior. I am hoping that JETI will look at the dumps I (and jwcraven) have provided and can identify something. I am pretty sure that this can be resolved with a firmware update (and hopefully one that does not attempt to mask the issue, but actually resolves it). I do not think this is a hardware problem.
Last edited by JimDrew; Dec 06, 2018 at 12:47 PM.
Dec 06, 2018, 02:09 PM
Registered User
Edgar Perez's Avatar
Quote:
Originally Posted by JimDrew
You can update your firmware and tinker with the ExBus protocol, just be aware you are going to see a lot of packet loss..
May well do so, but since my setup works ok now would probably wait until more information is available (Im missing a smoke channel in my jet, but is not critical).

Ont thing that is not clear to me if this conversation about packet loss is a different issue from the frame counter losses I reported when I started using the Jeti/XPS24 combo. See post : https://www.rcgroups.com/forums/show...&postcount=175 (more startign in page 13 of that thread)

At that point your though process was that "it seems that the receivers are out of phase from each other and if a receiver's packet arrives too late it is considered "lost", but only if another receiver has a valid frame. The receiver's data is still captured if it comes late though. Whichever receiver has a valid frame closest to the 14ms frame rate will provide the data to the X24. This is why it works, but the frame rate counter may report incorrectly. The JETI system is the only system that will apparently do this."

Regards, Edgar
Dec 06, 2018, 02:40 PM
Thread OP
Yeah, that was a preliminary "guess" as to what the problem was. But it's clear that a loss of data is occurring in ALL modes - that means PWM, UDI, and ExBus. PWM and UDI modes "mask" the problem by providing the last good packet's data. ExBus simply drops the packet completely. If you are using UDI mode, you need to set the frame rate to 14ms in order to have no apparent frame loss (but loss is still occurring, it's just disguised by what JETI does with the UDI protocol).
Dec 06, 2018, 11:55 PM
Registered User
Jim,
i sent you a PM regarding the SPI CLK for both the TX and RX, in the primary rx data file you posted.
please take a look and tell me if you think what i am seeing is real or a sampling problem.
John
Dec 07, 2018, 02:31 AM
Thread OP
I will re-capture at a higher resolution and see if that changes things.
Last edited by JimDrew; Dec 07, 2018 at 02:52 AM.
Dec 08, 2018, 09:02 AM
Registered User
Edgar Perez's Avatar
Quote:
Originally Posted by JimDrew
Yeah, that was a preliminary "guess" as to what the problem was. But it's clear that a loss of data is occurring in ALL modes - that means PWM, UDI, and ExBus. PWM and UDI modes "mask" the problem by providing the last good packet's data. ExBus simply drops the packet completely. If you are using UDI mode, you need to set the frame rate to 14ms in order to have no apparent frame loss (but loss is still occurring, it's just disguised by what JETI does with the UDI protocol).
I think I follow, but just want to make sure I understand the risk implied in my options:
1 - Using ExBus receviers only : get 24 channels, packet loss are happening. Jeti does not disclose them.
2- Using XPS24 in UDI16 : Get only 16 channels, packet loss are happening, XPS shows them in the lost frame counter
3- Using XPS24 in ExBus mode (latest patch): get 24 channels, packet loss are happening, XPS shows them in the lost frame counter

Is the amount of lost packets is the same in all 3 options? If so,then will like to go to option #3. However if the packet loss are worst in ExBus, I would rather stay in #2.

Thanks
Dec 08, 2018, 02:16 PM
Thread OP
1) Correct.
2) No. All modes (except ExBus) replaces any lost packets with the last valid packet, so no loss is actually shown although it is occurring.
3) Correct.

The amount of packet loss is the same, no matter what mode you use.
Dec 12, 2018, 04:28 PM
Registered User
I have just done some testing with a SparkFun Dev Mini Board acting as a sensor receiving packages from a R7 on the ExBus.
I'm getting 100 packages a second, so no data loss.
I have also run a capture using Saleae Logic Analyzer and I can not see any package misses as you do in your captures. I also send back 100 telemetry packages per second, also showing up onicely in the capture.

I have a DS-16 with FW 4.27 and R7 has FW 3.23.
Dec 12, 2018, 09:28 PM
Thread OP
I have never tested a R7, but there are now several people who have captured their receivers - all of which have packet loss in ExBus mode (all modes actually, but it's visible when using ExBus mode).

One thing that was discovered in the captures that I did is that there is a problem with the SPI clock in the JETI hardware not always clocking out 8 bits of data. Instead, sometimes there is a single clock for the entire 8 bit period.

Can you post your Saleae capture?
Dec 13, 2018, 11:17 AM
Registered User
Sure, just need some time in front of the laptop.
Dec 13, 2018, 12:03 PM
Thread OP
Thanks. It's clear in my capture of the transmitter's SPI bus that there are definitely missing packets - the transmitter is not actually sending them.
Dec 13, 2018, 02:22 PM
Registered User
Quote:
Originally Posted by JimDrew
Thanks. It's clear in my capture of the transmitter's SPI bus that there are definitely missing packets - the transmitter is not actually sending them.
Here are two captures both captured between R7 and the Sparkfun Dev Mini board.
Capture1.logicdata is with ExBus channel packages from R7 to Sparkfun.
Capture2.logicdata is with ExBus channel packages from R7 to Sparkfun and telemetry packages from Sparkfun to R7.

Fail safe is off in the R7 by the way.


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