this is all greek to me but are you talking about the DS 24? when you say x24?

Xtreme power systems x24 is a power distribution device that can support multiple rx's. This thread is mostly how it is working with the jeti radio system and protocal (hopefully that is a decent explanation)

What happens then if the fail safe is turned off?

I for one is really interested on how the 10ms, 14ms and auto works in general. I've been trying to find more general info online but...

Well... I got the full SPI port hooked up for both modules. The primary RF module is the one closest to the top of the transmitter. The secondary module is the one closest to the center of the transmitter.

So, the primary module is transmitting every single packet at roughly 10ms. There is some variation, but that is to be expected from 802.15.4 protocol which uses a back-off exponent to randomize the start of each transmission to add some time diversity.

It seems that the secondary module is communicating about every 20ms or so. I am not sure if this is a transmission or reception (I need to look at the SPI commands to determine that). One thing for sure is that whatever is going on with the secondary module, it is the main cause of the receiver not getting data, resulting in lost packets. See the screen shots. Green shows the secondary module packets that are skipped for some reason. Red shows the packets that were sent, but not received.

You can download the full capture of the primary module here: http://www.xtremepowersystems.net/do...6_R3_SPI_1.zip
You can download the full capture of the secondary module here: http://www.xtremepowersystems.net/do...6_R3_SPI_2.zip

These captures were done in the DEFAULT (not DUAL PATH) mode with a single R3 receiver.

The IRQ can toggle for other states besides the receive interrupt, but you can clearly see when the IRQ does not occur that the receive buffer is not transferred. I didn't capture the IRQ on the DS-16 because I am only concerned with transmissions.

I am only using Failsafe disabled in my testing, however, enabling it made no difference.

So, I guess what I need to determine now is if the secondary module is receiving telemetry data coming back from the receiver or sending something else to the receiver. This could be something a simple as one RF module interfering with the other. I know that our DivBee module can have this problem and I have noted in our FCC documentation that co-located transmitter antennas must be separated at least 20cm apart to prevent this.

A couple of people asked to see the wiring I am using. So, I took a picture of that.

Originally Posted by WR_Rider

What happens then if the fail safe is turned off?

I for one is really interested on how the 10ms, 14ms and auto works in general. I've been trying to find more general info online but...

You can see udi get into failsafe and timing in my thread in Jeti USA forum.
https://www.rcgroups.com/forums/show...3-18-Receivers

Those test were done with REX FW1.10.
The last REX update 1.12 fix a lot of bugs in exbus and timing issues.

i set failsafe to 30s with period 10ms on a rex, 2 nights ago, and after the tx was turned off, and the exbus disappeared, the REX repeated the last udi frame 4 times, then the udi output stopped. The pwm continued at 10ms, until i turned the tx back on (before the failsafe.

I got my R5 connected again and added a IRQ wire to the setup.

I have 3 interrupts per cycle (when things are normal).
RX_start, TRX_end(for receive), and TRX_end(for transmit of telem)


Here is trace with one missing EXBUS packet. But it seems to be a RF loss.


I have two interrupts during the cycle with the missing exbus frame.


Here is the first interrupt. After the first interrupt, the rx reads the interrupt status register 0x8F , and gets back a value of 0x04, which is start of rf frame.


Here is the second interrupt. Again, the rx reads the interrupt status register 0x8F , and gets back a value of 0x04, which is start of rf frame.

My interpretation is there was RF, or enough to start the reception process but it was rejected (didn't pass crc check), there was a resend, and it too was rejected.

I set a trigger to find the EBXUS holes fast without lots of normal data.
I did a bunch of short captures.

I also see EXBUS losses where there are no interrupts.
Either nothing was sent, or the frame didn't pass the basic filters to qualify for starting reception (preamble/SHR/PHR were bad)



When this happens, the only part of the normal cycle that remains (yellow)
are the commands to switch to the next channel in the hopping sequence and the power level to use on the new channel.

Yep, what you have posted is exactly what I have captured as well. I think the problem has to do with the secondary RF module (using DEFAULT mode, not DUAL PATH) being interfered with or interfering with the primary RF module. I did a quick check in DUAL PATH mode and see that the same issue occurs, but the packets are completely different from DEFAULT mode and both RF modules are outputting/receiving data and losing packets. I think the issue is either a setup issue (not checking PLL lock after changing the channel - and prior to doing some other command) or interference between modules. I ran into both of these issues myself when developing our RFU. I might disable the power from the secondary module and see if the system starts complaining about no signal and look at the receiver loss.

I ended up putting connectors on the SPI port connections so I can have the SPI ports available in the future if needed.

After doing about 100 quick captures, i would estimate that 10-20% of the events have a interrupt, and some form of reception started, but failed. And 80-90% were events that had terrible headers or were completely missing RF frames.

Makes me wonder what would happen in "teacher" mode where one tx module is connected to the RX and one is connected to another tx.

Originally Posted by JimDrew

...
A couple of people asked to see the wiring I am using. So, I took a picture of that.

while you have the tx module open, will you tell me what RF front end chip is in it?
it looks a little rectangular in your pic.

ACK! I soldered the shield back on already! I figured it was a TI chip because that is what they used in all of their receivers. I will see if I have better pictures where I can read a part number. It is very rectangular, not a typical square chip.

::edit:: It has a SE2431L on the part.

http://www.skyworksinc.com/Product/933/SE2431L

Our DivBee module uses the RFX2401 (not to be confused with RFX2401C, there is a huge difference!). The 2401C is a power hog, has horrible harmonics, etc. I am not sure why they still produce that part. The RFX2401 (NMOS version) is only available through special order. I happen to have reels of them inventory.

JIm,

Just a note that may or may not be of interest. Gene and I have been working with his X24 and have come across something odd.

My X24 is set up with two R3/RSW receivers in UDI @your recommended settings. Both receivers are solid and no (or few) lost frames showing.

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.

I sent you two REX and two R3s with my X10 and X24. While you have them, can you try the REX receivers hooked up the X24 (One in normal and one in clone) with TX in default and see what results you get and your interpretation?

I appreciate the work you are doing. Hopefully we can get something that works here in the hell hole of Las Vegas or I am going to have to move away from here.....

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.

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.