Thread Tools
This thread is privately moderated by JimDrew, who may elect to delete unwanted replies.
Mar 28, 2018, 12:54 PM
Registered User
Quote:
Originally Posted by joshet89
Yes the auto match completes. Attached is a picture of my setup, hopefully that sheds a little light on the issue.
Nice plane! I just finished mine up a few weeks ago.
Sign up now
to remove ads between posts
Mar 29, 2018, 09:07 PM
Registered User
The jeti receivers output either serial udi12ch - 12 channel or serial udi16ch 16 channel outputs. Will one or both work?

We are also using a Jeti r3 rx as a soft switch for our cb200. Any idea if that might work with the xps 24?

Thanks
Last edited by WR_Rider; Mar 29, 2018 at 09:12 PM.
Mar 29, 2018, 10:19 PM
You need to use UDI12. The switch might work if the switch is an actual isolated switch (not a switch that just provides power or ground), but remember the receiver would require power full time. To do that and not have power go back into the X24 you would need to remove the center (+) wire between the receiver and the X24.
Mar 30, 2018, 09:45 AM
Registered User
Might not work then since the receiver used as a switch would need to still be powered up from the x24.
Mar 30, 2018, 11:55 AM
It apparently works. I got an email from someone who does this with their JETI and X24. The RX3 is always powered on, which makes sense as there would be no way to control electronics without power.

I have a local guy that has three X24's in his planes and flies JETI. I will have to let him know.
Mar 30, 2018, 01:52 PM
Registered User
it would be great if we could confirm this. I really like no having to cut into the fuse sides to install on / off switches.

Thx
Last edited by WR_Rider; Mar 30, 2018 at 02:10 PM.
Mar 30, 2018, 01:59 PM
Registered User
Quote:
Originally Posted by WR_Rider
it would be great if we could confirm this. I really like no having to cut into the fuse sides to install on / off switches.

Thx
Didnít Jim just confirm it by posting what he did ???
Mar 30, 2018, 03:41 PM
Registered User
Quote:
Originally Posted by JuanRodriguez
Didn’t Jim just confirm it by posting what he did ???
I didn't take it that way so thanks a million for clearing that up for me...
Mar 30, 2018, 07:47 PM
I have not seen it with my own eyes, but apparently by using the 'switch' option of the RX3 you can in fact control the power on/off of the X24 remotely.

I looked into a few JETI things today. I still don't have one to play with. I tried to buy a DS-6 but they are apparently back ordered forever. I don't want to buy a $1000 transmitter that I will use for 30 minutes and never use it again. I literally have a closet full of brand new transmitters. I hate to borrow one because anything can happen during transit. I will add support for UDI16. UDI12 is already supported. "ex bus" is just the protocol used by UDI12, UDI16, and the telemetry sensors. I am looking at adding some support for virtual telemetry sensors (data supplied by the X24). It's all free stuff because the X24 has a huge amount of free resources. I am using 7% of the code space and about 10% of the CPU time currently.
Apr 26, 2018, 08:28 PM
Registered User
Edgar Perez's Avatar

Loss Frame counter incorrect?


Hi
I have what seems to me odd or erroneous behavior of the lost frame counter in the XPS 24
Here is the setup: XPS24 with two (2) Jeti REX receivers in Ports 1 and 2. Configured dual path and UDI with 14ms period. Tx = DS-24

Turn on the plane. Move servos to test. All good. Jeti reports both Rx at 100% quality.
Switch the XPS to the Frame Counter view. It reports that Port 2 is having lost frames. This is where my secondary Rx is connected. However if I turn off transmission to the Primary, it stops reporting lost frames in Port 2, and now reports them in Port 1. I can still can moves my servos, so its receiving data from Port 2. I don't quite think that it was really losing frames from my secondary Rx.
I keep testing by turning on and off each transmission module. In all cases I maintained ability to move servos, so the XPS was picking the data correctly. However it was always reporting lost frames from port 2 whenever it was not using that Port data (even if Jeti was reporting all good on the secondary receiver)

I did a video in YouTube that shows the problem (
April 26, 2018 (4 min 2 sec)
)

Any idea was is going on?

Thanks
Apr 27, 2018, 09:09 AM
Registered User
Does it do the same thing if you swap both Rex's at the xps?

I also don't believe the way the net reports / calculates quality is the same.

It actually looks right to me. The xps is only using port one till it looses frames.... So it's ignoring all the frames from port 2, so its counting all the frames... Once rx 1 isn't receiving anymore the xps swaps over to port 2 and for every good frame it gets it is not getting the same amount of frames frames on port 2 so it's counting them as missed frames because it's expecting them to be there.

My take on it.
Last edited by WR_Rider; Apr 27, 2018 at 09:22 AM.
Apr 27, 2018, 12:17 PM
There is nothing wrong with the X24! The problem appears to be with your JETI setup. When ANY receiver does not receive a valid packet, that loss is shown on the counter. So, it seems that only one receiver is actually receiving data, not both. Did you bind each receiver to a different transmitter or something? With true receiver redundancy, ALL receivers should be bound to the same transmitter.

Watching your video I would say that you have each transmitter (primary and secondary) bound to a different receiver, and only one transmitter is actually transmitting until you switch to the other transmitter. You can verify this easily by using the primary transmitter and just unplugging the receiver from Port 1. If the 2nd other transmitter is actually working, then the receiver on port 2 would still allow servo movement. If you do still have control, then it would mean that secondary transmitter is sending data a LOT later than the first transmitter. The X24 expects all receivers to have provided the data within 500us of each other. Since the over-air transmission is received by all receivers at the exact same time, that window is to allow for slight differences in CPU speeds of the receivers. I don't have a 2nd receiver for my JETI system, so I can't test this. But, I will get a 2nd receiver for testing this. I have a many people running JETI systems with the X24 and multiple receivers, including a local guy who does not experience what you are showing in your video. However, I am not sure how his receivers are bound. I will find out.
Last edited by JimDrew; Apr 27, 2018 at 12:27 PM.
Apr 27, 2018, 01:43 PM
Registered User
Edgar Perez's Avatar
Jim
Thanks for the detailed response. I only have one radio Tx (DS-24) that have three (3) transmitters modules inside. Two of them are 2.4Gh and the other is 900 MHz.
I donít have a 900 MHz Rx, so only using the two 2.4 ghz ones.
Iím no Jeti expert. I did bind them using the dual path procedure for Jeti.
I will do the test you mention and report.
I do like the XPS24, so hoping to clarify the situation.
Thanks
Apr 27, 2018, 04:03 PM
Registered User
Maybe you should also try cloning the second rx and see what happens as well.
Apr 27, 2018, 04:59 PM
Registered User
Quote:
Originally Posted by JimDrew
... The X24 expects all receivers to have provided the data within 500us of each other. Since the over-air transmission is received by all receivers at the exact same time, that window is to allow for slight differences in CPU speeds of the receivers. I don't have a 2nd receiver for my JETI system, so I can't test this. But, I will get a 2nd receiver for testing this. I have a many people running JETI systems with the X24 and multiple receivers, including a local guy who does not experience what you are showing in your video. However, I am not sure how his receivers are bound. I will find out.
The two 2.4 tx modules in a jeti tx are not exactly in sync. They can run out of sync by much more than 500u for sustain periods of operation. The phase can change over time. Primary can lead the secondary for awhile and it can slowly change to the opposite.
The main reason for this is likely the LBT feature in the RF modules. This is a requirement in the EU certification. LBT is "Look Before Talk". In a quiet low background environment the phase can be nearly constant for long periods. But in a noisy RF local or field with lots of radios, the LBT, will have collisions and it will skip the channel and hop for a clear one. The phase will much more random in a noise local. The phase is limited, meaning they won't go completely out of sync. I would have to go look at some of my recordings, but lags of 1ms is not uncommon, And I am thinking 2ms would be long. EXBUS frames are 3ms or 3.8ms long, and the never get there is always overlap in the 10ms cycle.

When the plane is turned on, the primary usually binds first, and there can be significant delay before the secondary. There can be a sustained lag the remains nearly constant for seconds or minutes, until something cause the phase to shift, ie a second tx, etc.

If you look at some of my EXBUS traces for the cb200 failover behaviour, you will see what I mean.


Quick Reply
Message:

Thread Tools