While they were only able to induce a lock out at very low Q, at this point the factory considers the lock out issue with dual serial I/O fixed

Can you run three R3's ... two through the Cortex Pro and one direct into RX2 on the CB200?

JS

No there aren't enough connections to the central box.. perhaps in the future if Jeti releases updated central box firmware to support 2 2.4ghz rxs plus a 900mhz backup..

I guess you could run 2 RX into the Cortex, and only have RX1 connected from the gyro to the CB, and then a 3rd RX direct into the CB RX2 port.

That way, you could build time on the Cortex and look for any further signal switching lockout issues, and still have an independent RX direct into the CB to protect against a lockout.

I assume you'd have to run them all in clone mode, but I have never tried it.

Paul

The TX doesn't support 3 RX yet.....

Hello All,

Can someone explain clearly the issue or what may happen, I'm not sure I completely understand the (possible) issue. Is it only in Jeti CB setup or also apply to other setup like X24 or powerbox ? I'm planning to buy a Cortex Pro on my very soon project and I would like to know more about this (I will use dual futaba SBus receivers to Cortex Pro and to an expander (probably a PowerBox)).

Thanks

I ran my second rx REX 7 directly to the CB200 and bypassed the CP, my question is why you are hooking the telemetry up from CB200 EXT to the expander plugged into REX7? i left my expander plugged into EXT port on CB200 with my telemetry plugged into it and nothing into the rx2 and all telemetry seems fine?

Thanks

Bypassing the CB doesnt solve the problem, only takes away a RX when the CP fails. It masks the problem, not fix it. That is why I took mine totally out. The CP quits and fails to send the signals to the CB.

Tom,

Maybe I am thinking about it wrong, but: If the CP blocks RX1 and RX2 is active to the CB, wouldn't you get an alarm and be able to land the plane? And if Demon is right and they have fixed it with the update, then RX2 should not ever take over under normal circumstances?

You are correct with the idea that Rx2 will supply signal to CB with the CO bypassed...but the CP is still faulting. I have heard of issues after the 1.4 update. For me its not worth the risk to have a device with major issues in my jet.

Thank you.

We have no reported lockout issues since v1.4 has been released. If you know of this first hand please post it or have the person who has had a lockout with v1.4 post here or contact us.

..

I stand corrected. I re-read the post and see the 1.4 update was done after the lockout. I have still removed the CP from my jet until I am 100% sure the problem is fixed.

what you did works fine.. Had this set up this way before we got 1.2 enabling the bi directional telemetry, so just left it that way because the Secondary receiver handles the datalink, and the primary just handles the signals. It will pass data faster in a low q environment this way.

Make sure you all upgrade to 3.24 according to Jeti there could be a issue with internal data overload.
losing sync all the double path setups could be affected.
especially if you use lots of sensors and telemtric.

make sure you get the latest Firmware for the cortex AND Jeti..

Don't think you would get an alarm based on Rx1 since the transmitter maintains communication with both receivers. When the problem occurred the Cortex simply wasn't passing the EX Bus data from the receivers to the central box.
Connecting Rx2 directly to the Central box will prevent any loss of control but I don't think you would ever know that the problem occurred..I think telemetry and everything else from the central box would simply go through Rx2 and unless you could tell that you no longer had stabilization you would never know it happened...Probably the most likely way you would know something happened is that since most use much less expo when the Cortex is on vs off your airplane would simply seem more sensitive if the problem occurred..

you can set it to alarm you at the loss of signal 1. but remember the PRO will switch at a low Q. and its normal to use both receivers in a low Q.

I wish Jeti had a way of telling us which receiver port is the driver port at any given point, but it doesn't.

Goose, how does the CP recognizes a low Q ??
As it has been explained several times, Q is a value computed at the Transmitter. Receivers don't know or care about Q.


Jack

Do you mean 4.23?

It sounds like you guys are flying around with the pin pulled from a hand grenade , why would you want to put a grenade in your plane. outsider looking in.

The Cortex Pro knows nothing about Q values and in high level terms works basically the same as the CB200 in deciding which receivers data to use. When the receivers are set to Auto as suggested when used with a Central Box, if they receive a valid frame they send it as an EX Bus packet, it they don't receive valid data, they send nothing during that interval.. If the Cortex Pro (or CB200) receives a valid packet from Rx1, it uses it, if not, it looks for one from Rx2 and if RX2 has valid data is uses that. If it doesn't get valid data from either, the Cortex Pro should send nothing to the CB200. If the CB200 sees no data within it's failsafe window, it goes into failsafe..

In general if a receiver is having trouble receiving data for any amount of time it will show up as a low Q value but I'm pretty sure that the CB200 decides whether to use Rx1 or Rx2 on a frame by frame basis so it should be possible for Rx2s data to be used if RX1 simply dropped a couple of frames but still has a Q value of 98%..

While it's possible to alarm on loss of Rx1 when I had the Cortex Pro lock up before the latest firmware update I never got an alarm because the link between both receivers and the transmitter was perfect, there was simply no data passed between the Cortex Pro and the CB200. I lost telemetry from the CB200 which I didn't have any alarms set for at the time so I had no indication that anything bad had happened until the CB200 went into failsafe. If someone connects Rx2 directly to the CB200 I don't think they will even lose CB200 telemetry so I don't think they would necessarily notice anything was wrong if the Cortex Pro stopped sending EX Bus data from Rx1 to the CB200. That is the only reason I'm not a fan of the Rx2 direct to the CB200 configuration. While it should protect your model, which is a very good thing it seems it also masks this issue to the point where you may never know if a problem still exists..Based on the information available I'm actually pretty confident that the latest firmware will resolve this issue, I still have another issue that I need to get to the bottom off before flying again but I think as soon as I'm sure that's been taken care of I'm going to simply connect both receivers directly to the Cortex Pro.

Wayne,

Are you suggesting that the CP merges the RX1 & RX2 data and re-broadcasts the 'best' signal along with gyro inputs onto both RX1 & RX2 outputs to the CB. If that were to happen, the CB would never see a single RX drop-out as the CP would 'fill-in' on its output.

I would have expected that the CP would keep the 2 RX streams completely separate and pass them through with added gyro commands, letting the CB determine which RX to use.

On your point about bypassing the CP with RX2, I have flown my Ultra Flash with the gyro inadvertently set to 0% gain (remember the DS-16 s/w error earlier this year). It flew very differently and it was immediately apparent that something had changed. I'm sure for those cases where the CB switched to a non-gyro stabilized RX that I would notice a difference.

Paul

No that's not what I'm saying. What I'm saying is that the system has no concept of "best signal" since data is either received correctly or it isn't. If a receiver fails to receive a frame correctly it sends nothing on Ex Bus (no servo information anyways). The Cortex Pro or central box can always listen to Rx1 and Rx2 but if Rx1 is valid, Rx2 can simply be ignored for that frame...If it doesn't receive valid data from RX1 it doesn't sit around waiting for Q values (which it has no knowledge of) to be updated it simply looks at the Rx2 input and if Rx2 sent it data it uses that. If it doesn't receive anything from either Rx1 or Rx2 then the Cortex Pro shouldn't send anything so the CB200 will update it's failsafe timer. If the condition persists where no data is received from either receiver for long enough for the CB200s failsafe timer to expire then it goes into failsafe. The bottom line is if Rx1 has no valid data but Rx2 does it would be extremely inefficient to not use Rx2's data to update the servos immediately. Frames get dropped all the time due to other systems hopping onto to your frequency, etc.

As for whether the Cortex Pro processes both streams separately I don;t know but if I had to guess I suspect data from both receivers is simply sitting in queues and if Rx1's data is valid it gets stabilized, if not then they try Rx2 but they may well have the processing horsepower to be constantly stabilizing both even though Rx2's data will be discarded if Rx1 is valid.