Simultaneous operation of internal and external XJT faulty with OTx 2.2.x

[franz4949]

I made several tests with my Txs (X9d, X9d+, QX7 and X10S) for simultaneous operation and I posted my findings in RCG, which you may find several posts with detailed test boundary conditions from me (FJH) on the page here => https://www.rcgroups.com/forums/showthread.php?2827965-FrSky-%28Horus%29-dual-RF-%28IXJT-and-XJT%29-issue-thread-%28feedback-needed%29/page2

My latest finding with my X9d+ showed very clear a different behaviour, depending on what OTx version was installed. With either OTx 2.0.17 and 2.1.9 a flawless operation was/is possible while with OTx 2.2.1 it is not. With OTx 2.2.1 on my X9d+ it even leads to loss of control within short distance.

This test experience leads me to the presumption that something must have been changed from OTx version 2.1.x to 2.2.x which causes the faulty behaviour. While I am aware of the known FrSky hardware design disadvantage, which does not allow simultaneous active telemetry of internal and external module, this is a different matter.

As I also wrote in my above linked posts, I was surprisingly also able to perform some flawless test flights with my X10S with simultaneous operation of internal iXJT and external XJT module. Majority of test flights however showed disturbed telemetry lost/recovered alarms, nevertheless no loss of control. Whether flawless or disturbed operation was a random matter, obviously on powering up the X10S.

[3djc]

Could you help us a little. Digging into very long RCGroup posts to try to find out what you are trying to report is not very helpfull.

You are aware that you cannot have two module with telem enabled so anything related to sensor/telem lost is clearly non relevant, as this is to be expected.

So could you sum up for us your finding excluding all expected telem issues ?

[franz4949]

Well the short summary is what I have written above. The link therein is referring to a single page with 4 posts from me (FJH), thus no long and endless thread. Please have only a short look at that page and my last two posts from today and yesterday. And if you want more information or help from me, I will ofcourse do my best to support you. But please have a short view at my two latest post on the linked RCG page. Thank you.

[franz4949]

And for avoiding any misunderstanding regarding telemetry, in all test cases the external XJT module was operated in telemetry-off-mode by having the two dip switches on the back of the module in ON position. And additionally the Rx bound to the external XJT was configured by jumper for binding with telemetry off too (as also was the selection for binding with telemetry off in OTx 2.2.1)

[3djc]

OK, still trying to get to the core of the issue, and get to a situation where the issue can be replicated. So really all that matter is post #29 where you suggest that on very same HW setup; Otx version does have an impact on range (unfortunately, I understand those test where not conducted on same day, which leave a door open for external influence).

So we will need a backup of your 2.1.9 bixler and one of your 2.2.1

Could you also confirm those setup elements during that specific x9d+ test:

• external XJT module with both dip switches set to "ON" position
• two RX8R receivers, one bound to internal XJT in telemetry mode, one bound to external XJT
• all module running latest non Eu firmware,, same for receivers

[franz4949]

I also lost control with my X9d running OTx 2.2.1 in my first test flight and unfortunately I did not rangetest before flight, because I only expected to have telemetry disturbation as worst case. Range testing I did after the crash.

Now X9d+ test confirmation:

• external XJT module with both dip switches set to "ON" position
• RX8R bound to internal XJT in telemetry mode, X8R bound to external XJT in non-telemetry mode (jumper set to channel 3+4)
• RX8R with FCC170208
• X8R with FCC170210
• internal XJT with FCC150128
• external XJT not sure about it, most probably with FCC as delivered in 2015 or 2016 (can't remember)

You mean eepe-file of 2.1.9 and 2.2.1 model for X9d+??

[franz4949]

Here are the model files from the X9d+ tests. For upload I have added file ending .gif, please delete gif-ending for both files.

[kilrah]

Did you rebind the receiver after setting the DIPs on? That is required, otherwise telemetry isn't being disabled.

Apart from that potential disturbance by one module of the other will be random and change at each power up, and will depend on antenna placement. Ideally antennas should be put far apart and cross polarized, if not even use an extension on the external module to put it further away.

There is no reason OpenTX would have anything to do with it.

[3djc]

The only thing we can check I guess is if timing for sending data to both modules has changed between 2.1 and 2.2

[franz4949]

Yes I did new binding before testing also after flashing other OTx version. My external XJT has all the time the dip switches both set to ON position since my very first testing one year ago.

My two antennas of my X9d are both horizontally arranged, one to the left the other to the right.

[franz4949]

I intend to repeat the tests with my X9d today with 2.1.9 as well as with 2.2.1.

[3djc]

Please try to remove all variables, by placing radio and model in similar static places and report rssi values for example (you said they where very different)

[franz4949]

I will report my test results hopefully this evening.

[kilrah]

Timing of pulses shouldn't change anything since the module is the one deciding when it sends out stuff anyway.

There could be a difference with the moment at which power is turned on to both modules.

[franz4949]

The momentum of power on is obviously also the variable which determines whether my X10S will operate flawless with both HF modules or if telemetry lost/recovered alarms will come continuously.

[franz4949]

Here my report for yesterday tests with X9d+. I tested as follows: The Bixler was put on a wooden desk and I walked away up to a distance of about 120m while X9d was put in range test mode and data were logged. When reached end of flying field I switched data logging off. This i did 3/2 times and after that I did a short flight with both modules active, so you will see 4/3 data sessions with:

• 1. session only internal XJT active, external XJT switched off and X8R power off
• 2. session internal and external XJT active and both receivers power on
• 3. session repeat of 1. session (only with OTx 2.1.9)
• 4. session test flight with both modules and receivers active From file name you can take which OTx version was running, either 2.1.9 or 2.2.1

Again with OTx 2.1.9 running I did not notice any impact neither on telemetry nor on control or signal. With OTx 2.2.1 running I noticed a curious RSSI behaviour in range test mode as you may also see in the attached graph (2. session). Obviously the RSSI was somewhat better with both XJT modules and receivers active that with only internal XJT active and X8R not powered. Therefore I also dared to make a flight with both modules and receivers active (3. session), the RSSI was not bad but more fluctuating although flight distanced was maintained quite low (maybe 10-15m) and within the flying field area, What I however had during flight were repeated telemetry alarms for lost and recovered.

After these tests I believe that my control lost issue, which I had two days ago with the X9d running OTx 2.2.1 is not a basic OTx version issue but must have been caused by a mistake which I have most probably made, maybe I did not correctly bind the X8R without telemetry (forgotten jumper??). I will do further testing the next days (not today, not tomorrow).

[franz4949]

okay first graph is with OTx 2.1.9 running, second graph is with OTx 2.2.1 running

[3djc]

I had a long chat with FrSky about it this morning. There are telemetry issues that exist, even if the telemetry is disabled on second module. Those do not affect flight control, but are obviously not ideal either. Also they clearly confirmed there is nothing that can be done on our side to improve things, as those are timing related, and there is no mechanism to synchronize those. One session might be very different from another.

If dual module are used for safety, then it is currently advised to use a R9M with module telemetry disabled as external module rather then a second XJT.

Since FrSky have confirmed there is nothing wrong with OpenTx, I'm closing this as an open bug

[franz4949]

To be honest, I do not understand your decision to close this issue, saying nothing is wrong with OTx. It is very clear that with OTx 2.2.1 you will have continueing telemetry alarms (lost/recovered) while with OTx 2.1.9 you don't have such alarms and you can fly without any irritation and restriction. Why don't you perform a simple test fllght yourself (you need to fly, no bench test)? Try and you will experience yourself that it is definitely the OTx version which makes that difference and therefore ofcourse this malfunction can be rectified by according OTx 2.2.x code modification. Please reconsider your closing decision of this issue. A proper behaviour/operation of two XJT modules is the basis to allow control for 32 channels.

[3djc]

Those telemetry alarms did not exist in 2.1.9, so yes, the issue where here, you just did not know about it. There is (or will be in 2.2.2 I cannot recall) a setting to disable those if you prefer not knowing

[franz4949]

But why you plan to just suppress the alarms instead of looking after the code part that causes this different behaviour? That's for me like a doctor giving me medicine suppressing the pain I have instead of investigating for what causes the pain.

[3djc]

I was probably not clear enough.

In 2.1, you did not get any telemetry alarms NOT because there is not reason too, BUT simply because there was not alarm bell installed. If I take your medical analogy, you did not need painkiller in 2.1 because there was no nerves to let you know that there could be pain.

Telemetry data is damaged by dual module operations in 2.1 as much as in 2.2, there is just no way for you to know that because OpenTX was not monitoring individual sensors in 2.1

Frsky is aware of that and is giving the advice to use R9M as a second module instead of XJT, and is working on another solution that I'm not at liberty to disclose.

[franz4949]

Okay, this I understand. So we have to wait and see what solution FrSky may come up with in future.

Thank you for constructive discussion.