Thread Tools
This thread is privately moderated by JimDrew, who may elect to delete unwanted replies.
Dec 03, 2018, 10:56 PM
Thread OP
Quote:
Originally Posted by cravenjw
This is not correct
Actually, this is correct. The internal frame work is base on 14ms. This is the rate that the PWM output occurs to the servos.


Quote:
Originally Posted by cravenjw
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).
Correct. The Tx always sends packets at either 100Hz or 50Hz. The output rate to the servos is always at 14ms, and the output rate of the UDI/PPM is programmable by the user.


Quote:
Originally Posted by cravenjw
EXBUS frames are output from the RX, immediately following RF frame reception. No RF frame, no EXBUS frame.
That remains to be seen, but I am doubting that the receiver is actually missing the reception due to RF reasons (or JETI would have a real problem with their receivers). Since UDI mode works perfectly (as far as I can tell so far) It is more likely that the transmitter is not actually sending the frame OR that for some reason (like system overhead) the receiver is not outputting the ExBus packet when the receiver gets the frame. The reason why i believe the receiver is not missing the frame is because JR DMSS and XPS also use the exact same over-air RF protocol (802.15.4) and neither of those systems ever have a problem with a receiver getting packets. In all of my testing, I had ZERO packet loss with JR DMSS, XPS, Graupner HoTT, Hitec, Spektrum (DX5, DX6i, DX7, DX9), FrSky (Taranis and Horus), and Futaba systems. Only the JETI system in ExBus mode showed any packet loss in the controlled test environment.


Quote:
Originally Posted by cravenjw
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.

As I stated, the JETI system works internally at 14ms. That is the servo output rate. When you have packets arriving faster or later than 14ms, the latency increases dramatically and things can get out of sync quickly. This is easy enough to prove by simply looking at the LOGIC dumps and looking at when the PWM pulse occurs in reference to the incoming packet. It's pretty clear that if you have a PWM pulse occurring in the middle of a packet reception, that PWM pulse's position data would have had to have come from the previous packet. The testing that John Kos did (see the runryder info in this thread), shows that the latency can be as much as 23.4ms, and it varies constantly.
Last edited by JimDrew; Dec 03, 2018 at 11:11 PM.
Sign up now
to remove ads between posts
Dec 03, 2018, 10:59 PM
Registered User
Quote:
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?
In my testing, there is always about 0.5% loss, no matter the RF environment and range.
In my basement, with 2 wifi waps in house, with 5-10 waps visible in survey, TX and RX 3m apart, typically about 1% loss.
During my tests, i don't kill the wifi, but i also don't generate any device traffic.
These stats are based on lots of long term 6-24hr tests.
Dec 03, 2018, 11:07 PM
Thread OP
I can set the JETI receiver on top of my TP-Link router, run a WiFi speed test with www.speedtest.net and have ZERO packet loss while in UDI mode. I don't see any difference with ExBus mode... I still get random packet loss. Like I said before, I am using a completely controlled environment and I get absolutely no packet loss with any system, including the JETI when using UDI mode. In ExBus mode, I get constant random packet loss. It's pretty black and white.

I should have the wiring done to the RF chips tomorrow and I can monitor the interrupt pins on the RF chips and check the data rate to see if interrupts are being missed on either side while in ExBus mode.
Dec 03, 2018, 11:48 PM
Registered User
Quote:
Originally Posted by JimDrew
Actually, this is correct. The internal frame work is base on 14ms. This is the rate that the PWM output occurs to the servos.
...
As I stated, the JETI system works internally at 14ms. That is the servo output rate. When you have packets arriving faster or later than 14ms, the latency increases dramatically and things can get out of sync quickly. This is easy enough to prove by simply looking at the LOGIC dumps and looking at when the PWM pulse occurs in reference to the incoming packet. It's pretty clear that if you have a PWM pulse occurring in the middle of a packet reception, that PWM pulse's position data would have had to have come from the previous packet. The testing that John Kos did (see the runryder info in this thread), shows that the latency can be as much as 23.4ms, and it varies constantly.
I hope you measured before pulling 14ms out of that latency study!

Simple test (which i have done, and you should probably should repeat for yourself).
Setup a sequencer that is cyclic/asymmetric.
2 point sequence, 0.0sec=-100% and 1.0sec=+100%
Assign the sequencer as input of a function.
Assign function to a servo.
Make sure servo travel is the defaults (-100,+100%)
Set TX at 100Hz.
Set RX at auto period.

Hookup your LOGIC on that channel, grab a couple seconds.

When you do that, you will see every PWM period is different, 1000us,1010, 1020....1990, 2000us, repeat.

The TX is sends 100 unique values per second, the RX receives them at 100Hz, and the PWM is updated at 100Hz (10ms), ie each pulse is unique.

If you set the RX period to 10ms, each PWM will be unique
If you set the RX period to 5ms, each PWM will output twice (1000,1000,1010,1010...1990,1990,2000,2000,repeat)

I can post my test trace for this, but it sounds like you are already setup, and it should take you about 5mins to prove that TX, RX, PWM/UDI/EXBUS/PPM are updated at 100Hz(10ms).
Last edited by cravenjw; Dec 04, 2018 at 12:04 AM.
Dec 04, 2018, 12:24 AM
Thread OP
The PWM frame rate for each channel output on JETI receivers is 14ms. Take a look at the dumps I made. The PWM frame rate is every 14ms, with a 100Hz rate enabled.

The screen shot shows Rx1-Channel 2 and Rx2-Channel 2. You can see that the frame rate is 14ms, just like ALL of the channels. The output protocol type does not affect the PWM output rate.
Last edited by JimDrew; Dec 04, 2018 at 12:34 AM.
Dec 04, 2018, 12:56 AM
Registered User
Quote:
Originally Posted by JimDrew
I can set the JETI receiver on top of my TP-Link router, run a WiFi speed test with www.speedtest.net and have ZERO packet loss while in UDI mode. I don't see any difference with ExBus mode... I still get random packet loss. Like I said before, I am using a completely controlled environment and I get absolutely no packet loss with any system, including the JETI when using UDI mode. In ExBus mode, I get constant random packet loss. It's pretty black and white.

I should have the wiring done to the RF chips tomorrow and I can monitor the interrupt pins on the RF chips and check the data rate to see if interrupts are being missed on either side while in ExBus mode.
Your not using auto period.
If you loss RF, you lose the exbus frame, and you loss udi and pwm/ppm, with auto period.
If your using 5-30ms period (not auto), you always get udi/pwm/ppm, but the udi frames are repeats of the last buffered RF frame values.

I can post the traces, if you want.
Dec 04, 2018, 01:14 AM
Thread OP
It doesn't matter what I set the frame rate to when ExBus mode is being used, I get the same results. Only UDI mode is affected by the frame rate setting, and only for the actual protocol - not the servo PWM outputs.

Keep in mind that the only time I see the random lost frames is in ExBUs mode, and the frame rate setting has no affect on this. I am using 24 channel output mode. I can try 16 channel output mode.

The issue to resolve here is the constant random frame loss that occurs only in ExBus mode.
Dec 04, 2018, 12:51 PM
Registered User
Thank you for doing this guys. I know myself and a few others find this interesting and useful.

so Jim, you say to use 14ms frame rate. does the udi still work if you set it to auto frame rate?
Thx
Dec 04, 2018, 04:35 PM
Thread OP
No, not with the X24. The UDI12/16 support requires that the frame rate be set to 14ms (it's hard coded for that).

Since the JETI receivers use the same RF chipset as our RFU and Nano receivers, I know this chipset very well and I am able to look at how the chip is setup, the hopping sequence , etc. XtremeLink, JR DMSS, and JETI all use the same over-air system and could actually be compatible with each other if we all wanted that.

So, I did do a dump of the JETI R3 receiver today. I found out that it is not always getting packets from the transmitter. This is why they are missing in the ExBus mode. UDI mode appears to be substituting the last good packet for the lost packet. I am not sure why they didn't do that with ExBus. Next, I have to figure out the SPI pinout for JETI's RF modules they use in their transmitters. Once I do, I can dump the communications to the RF chip and determine if the transmitter is actually transmitting all of the packets. This will really determine which side is at fault.
Dec 04, 2018, 05:08 PM
Registered User
First post with JETI UDI traces. There are more coming.

Conditions:

DC-16 FW4.28
REX7 FW1.12
TX set to 100Hz
one function, engine, assignment to servos 1,2,3
input to engine function is sequencer Q1
Q1 creates sawtooth signal, -100 to +100%, each 1sec
servos all have -100%,+100% travel
so each 1s, pwm or serial channel values go from 1000us to 2000us, by 10us steps

REX bound with wireless mode default
REX pins all set to GroupA
E1 set to udi16
E2 set to EXBUS

Each logic capture is 3s.

Captures done to show REX output periods: auto, 10ms, 5ms


Period:Auto (Full Trace)
Name: REX7-UDI-EXB-auto-1.png
Views: 18
Size: 102.8 KB
Description:
The trace clearly shows that when there is no EXBUS, there is no UDI, and there is no PWM.
I didnt show it, but if your using PPM, it would be missing too.
When a RF frame is lost, there is no EXBUS, or any other outputs (PWM/PPM/UDI).
Its black and white.


Period:Auto (Zoomed into RF loss)
Name: REX7-UDI-EXB-auto-1z.png
Views: 22
Size: 84.6 KB
Description:
There are actually two lost frames back to back in this zoom view.
Exbus, UDI, and PWM(Group A) are basically sync'd.
All signals see the same jitter of the incoming RF.
The jitter in the RF.
Jitter is intentional, ATMEL radio chip has features to induce jitter and the Jeti algorithm includes jitter.


Next post will show REX with 10ms output period.
What is also will show, is using fixed period, there is still rf loss, and UDI and PWM outputs are just repeated using the last received values.

Updated: The raw capture data has been attached.
Last edited by cravenjw; Dec 04, 2018 at 09:58 PM.
Dec 04, 2018, 05:59 PM
Thread OP
I agree with your findings. and as I stated I was able to confirm at the hardware level that the receiver itself is NOT getting the packet from the transmitter and that is causing the frame loss. See attached dump. The green circle is the missing IRQ line that should go high when the chip receives a packet and it is in the buffer and ready to be retrieved. You can see with the red circle that the ExBus output is missing this packet because it never arrived.

So, it could be either the transmitter is not actually sending the packet, or the receiver is in a state where the RF chip is either not setup yet (PLL not locked on the frequency change to the next channel in the hopping sequence) or the receiver has not switched from transmit mode back to receive mode.

Considering that every single system I have tested has absolutely no packet loss (zero packet loss over many minutes of test duration), I do not think this is an RF related issue. There is just way too much packet loss occurring, especially in a controlled environment - not to mention no other systems have any loss. Until I check the transmitter I won't know which side (Tx or Rx) is responsible.

The dumps I have done showing /SEL, IRQ, MOSI, MISO, and SCLK are via the SPI interface between the Atmel CPU and RF chip. I did a dump of the REX12 and original Duplex R5 (from 8 years ago) with the exact same results. The R5 doesn't have a protocol output (ExBus or UDI) capability, but you can also see the missing packet circled in green.
Last edited by JimDrew; Dec 04, 2018 at 06:40 PM.
Dec 04, 2018, 06:28 PM
Registered User
Sorry for the side note.
Are you both using this little saleae Logic Pro logic analyzer for all this stuff? It seems like a pretty cool device...
Dec 04, 2018, 06:38 PM
Thread OP
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.
Dec 04, 2018, 07:29 PM
Registered User
Quote:
Originally Posted by JimDrew
I agree with your findings. and as I stated I was able to confirm at the hardware level that the receiver itself is NOT getting the packet from the transmitter and that is causing the frame loss. See attached dump. The green circle is the missing IRQ line that should go high when the chip receives a packet and it is in the buffer and ready to be retrieved. You can see with the red circle that the ExBus output is missing this packet because it never arrived.

So, it could be either the transmitter is not actually sending the packet, or the receiver is in a state where the RF chip is either not setup yet (PLL not locked on the frequency change to the next channel in the hopping sequence) or the receiver has not switched from transmit mode back to receive mode.

Considering that every single system I have tested has absolutely no packet loss (zero packet loss over many minutes of test duration), I do not think this is an RF related issue. There is just way too much packet loss occurring, especially in a controlled environment - not to mention no other systems have any loss. Until I check the transmitter I won't know which side (Tx or Rx) is responsible.

The dumps I have done showing /SEL, IRQ, MOSI, MISO, and SCLK are via the SPI interface between the Atmel CPU and RF chip. I did a dump of the REX12 and original Duplex R5 (from 8 years ago) with the exact same results. The R5 doesn't have a protocol output (ExBus or UDI) capability, but you can also see the missing packet circled in green.
I did the same breakout of spi bus on an R6 last year and did recording with the LOGIC.
I exported the decoded SPI data.
I wrote an excel workbook and macros that imported it, and the macros convert it into easy to read atmel chip commands, like set channel, set power, do clear channel assessment, write tx buffer, read rx buffer, etc
I had it to the point that most if not all of the transactions that jeti uses were decoded.

I was willing to do this on a cheap RX.
I didn't have the guts to go soldering leads on the RF modules in my tx during flying season! Lol

So, given you statement above, I assume contrary to some of your early statements, you now agree, there is no more data available with udi than with exbus, RF loss impacts both equally.
Dec 04, 2018, 07:36 PM
Registered User
Quote:
Originally Posted by WR_Rider
Sorry for the side note.
Are you both using this little saleae Logic Pro logic analyzer for all this stuff? It seems like a pretty cool device...
I have the original logic16. It is an excellent tool!
The newer models are faster, have more mem, and have one or more analog channels in addition to the logic channels.


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