Unable to bind XM+ with ACCST X2 LBT #543

prikrylm · 2021-03-13T17:15:39Z

I'm unable to bind FrSky XM+ receiver with XM+_ACCST_2.1.2_LBT firmware.
I was trying to bind this RX with TX16S and iRangeX with the latest FW (1.3.2.58).

Original trasmitters bind this RX with no issue.

Cloned original TX is able to communicate with the XM+ RX.

pascallanger · 2021-03-13T17:23:39Z

You need to bind use the protocol FrSkyX2 LBT(EU). And if not enough try different values of RF freq: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/docs/Frequency_Tuning.md

prikrylm · 2021-03-13T18:18:46Z

Of course I try to bind whith the FrSkyX2 LBT protocol. But it also fails to bind when tuning the frequency.

I made some experiments and there is no problem to bind with older XM+ firmware. (v2.1.0 LBT) - so problem is with newer v2.1.2 and no matter if it is FCC or LBT.

pascallanger · 2021-03-13T18:28:41Z

So they have released a new version... They must have added a bind protection... Do you know if the TX needs to be updated as well?

prikrylm · 2021-03-13T19:20:46Z

They wrote
"2020-10-28 -- ACCST D16 v2.1.2 -- 1. Fix the issue that servo direction would be reversed at full stick when channel range set on radio end exceed 100%.
2. Add the firmware file for the 8th channel to output RSSI."

FrSky TX module has still the same firmware.

I can cause a problem with servo reversal only with the original FrSky transmitter module and only if the signal exceeds ~ 2250 us (near 150%). There is no problem with the external module even on FrSky transmitter.

So, if the XM+ won't be used with the original FrSky module, the problem is solved by using older firmware.

MRC3742 · 2021-03-13T19:25:05Z

Possible duplicate of earlier issues #502 and #511 ?
Seems the XM+ has issues with version2 ACCST (even on FrSky TX Radios).

Rich

prikrylm · 2021-03-13T20:12:44Z

Yes it looks similar. But I have no issue on FrSky TX modules.

pascallanger · 2021-03-13T21:02:58Z

Since the bind fails it means that they've added more verification on the protection they implemented when transitionning to v2. I could do a test build with a different bind packet type to see if the RX would take it. But they could have added far more things. I have only one FrSky RX and the fw for it is still v2.1.0 so I can't do any testing myself...

MRC3742 · 2021-03-13T21:13:18Z

Yes it looks similar. But I have no issue on FrSky TX modules.

Have you tried to clone your original FrSky TX running on V2 LBT Firmware to the MPM under "FrskyRX", "CloneTX"

Then after you bind the XM+ to the original FrSky TX it should just work without bind on the MPM using "FrskyX2", "Cloned" setup with the same receiver number as the original TX bind.

Rich

MRC3742 · 2021-03-13T21:22:19Z

Since the bind fails it means that they've added more verification on the protection they implemented when transitionning to v2. I could do a test build with a different bind packet type to see if the RX would take it. But they could have added far more things. I have only one FrSky RX and the fw for it is still v2.1.0 so I can't do any testing myself...

I have an XM+ running on 2.1.2 and its green LED flashes intermittently if i get within 5 meters of it even using the internal XJT.
It did the same with 2.1.0 and is a problem receiver running on any X2 version I have tried even after RF tuning.
It seems a little better after I Cloned the ID from the X9D+ but its still seems to have swamping and range issues.
This RX seems to be happier on the version X1 ( 170313 ) firmware.

https://github.com/FrSkyRC/Firmware-Test/issues/41
https://github.com/FrSkyRC/Firmware-Test/issues/56

Rich

prikrylm · 2021-03-16T13:24:37Z

Have you tried to clone your original FrSky TX running on V2 LBT Firmware to the MPM under "FrskyRX", "CloneTX"

Then after you bind the XM+ to the original FrSky TX it should just work without bind on the MPM using "FrskyX2", "Cloned" setup with the same receiver number as the original TX bind.

Rich

Yes. I am able to control XM+ v2.1.2 with cloned FrSky TX. (bound on orig FrSky)

pascallanger · 2021-03-17T18:48:06Z

Yes. I am able to control XM+ v2.1.2 with cloned FrSky TX. (bound on orig FrSky)

Seems to indicate that they are checking their protections a little more closely.
Can you compile the code by yourself? if yes I can indicate a couple of changes you could try.

prikrylm · 2021-03-17T19:42:09Z

I cloned project, set Arduino IDE, compile the project, flashed to internal TX16S module and be able to pair some receivers. I'm not very familiar with this project, but I'm able to make some small changes, compile the binary and try it in the transmitter.

MJ666 · 2021-03-24T17:51:09Z

Have also done some test with new XM+ firmware (v2.1.2) and it also does not bind with my MPM's. The R-XSR (v2.1.1) is still able to bind. With Deviation latest nightly and the Devo10 the XM+ is still able to bind. I have only tested the LBT V2 mode.

pascallanger · 2021-03-24T17:56:17Z

@MJ666 are you saying that the XM+ v2.1.2 binds with deviation but not MPM?

MJ666 · 2021-03-24T18:23:13Z

@MJ666 are you saying that the XM+ v2.1.2 binds with deviation but not MPM?

Yes.

pascallanger · 2021-03-24T18:42:57Z

Amazing knowing that deviation has been updated based on my code on MPM...

MJ666 · 2021-03-24T18:55:58Z

The XM+ is reacting to the bind process with the MPM. The green LED goes off when the TX stops binding. Till this point it behaves like normal bind. After repower the XM+ it is not connected and the red LED is blinking with some unevenly pattern. Same as if you power the XM+ without an TX switched on. If connection is lost after an successful connect the pattern is a steady blinking.

pascallanger · 2021-03-24T19:02:13Z

Ah so the bind seems to work then. Have you tried to tune the frequency after the power up just to see?

MJ666 · 2021-03-24T19:05:42Z

Deviation is still using an fixed third ID byte (0x02) for index 11 (V1) and 5 (V2) in the bind package. This is a difference which comes into my mind.

I have not done tuning since it works with the offset with 2 R-XSR. I also tested with two XM+ and have the same behavior for both of them.

Update: Have tried to tune after unsuccessful bind but there is no reception.

pascallanger · 2021-03-24T19:09:56Z

Deviation is still using an fixed third ID byte (0x02) for index 11 (V1) and 5 (V2) in the bind package. This is a difference which comes into my mind.

Same value is used for Multi if not in clone mode...

MJ666 · 2021-03-24T19:14:48Z

Deviation is still using an fixed third ID byte (0x02) for index 11 (V1) and 5 (V2) in the bind package. This is a difference which comes into my mind.

Same value is used for Multi if not in clone mode...

Just have seen it when i was digging deeper into the code. Mhhh, quite strange. In my view the bind package should be really the same between MPM and Deviation. May be some timing issue?

pascallanger · 2021-03-24T19:15:33Z

The RXNUM in deviation is forced to 16. Can you try to put 16 for MPM as well?

MJ666 · 2021-03-24T19:24:41Z

Usually i use RXNUM 0 but also 16 does not change anything. Also binding with different offset (40, -40) will not help with binding. But the green LED goes off more early with offset of 40?

pascallanger · 2021-03-24T19:27:30Z

Just have seen it when i was digging deeper into the code. Mhhh, quite strange. In my view the bind package should be really the same between MPM and Deviation. May be some timing issue?

A post above is stating that clone mode works. Meaning that if the RX is bound with a FrSky TX, then the ID copied to MPM, the RX works with MPM which tells me that the timing and packets are fine in normal mode which tends to show an issue in bind instead.

Can you clone the ID of the devo? and then use this on the RX to control (with RXNum=16) and confirm that it works? then try a bind?

MJ666 · 2021-03-24T19:39:37Z

Works in cloned mode for both XM+. XM+ are very sensitive to swamping. nedd to move them >1.5m eway from TX to stopp flickering of the green LED.

pascallanger · 2021-03-24T19:44:39Z

Works in cloned mode for both XM+. XM+ are very sensitive to swamping. nedd to move them >1.5m eway from TX to stopp flickering of the green LED.

What works? Control and bind?

MJ666 · 2021-03-24T19:53:30Z

Both, control of an prebound XM+ and new binding.

pascallanger · 2021-03-24T20:32:19Z

Both, control of an prebound XM+ and new binding.

Can you explain exactly what you've tested?
Like new binding, have you used RXnum set to 16 or you have used a couple of different values all working?

MJ666 · 2021-03-24T21:14:41Z

Cloned the ID of my Deco10 (FrSkyRX, CloneTX). Used the XM+ (FrSkyX2, Cloned, RXNum 16) which was bound to the Devo10 before. The XM+ was connecting and working as expected.

I initiated the bind sequence with the settings used above and the bind process looks like successful and XM+ was connected again. Looks to be the problem here is that bind is not successful and it only keeps the former bind information. Binding with a new RX number will show the same problems as before.

Looks to be the bind process will always fail.

pascallanger · 2021-03-24T21:24:41Z

I initiated the bind sequence with the settings used above and the bind process looks like successful and XM+ was connected again. Looks to be the problem here is that bind is not successful and it keeps the former bind information. Binding with a new RX number will show the same problems as before.

Ok we are narrowing the issue down. Now when you tried to bind with a different rx number, the RX looked like it successfully accepted it from the blinking pattern, correct?(that's what you said before). But after the reboot it was still using a RX number of 16?

MJ666 · 2021-03-24T21:41:31Z

This is correct. As soon as i change the RX back to RXNUM 16 it will connect again.

pascallanger · 2021-03-24T21:50:31Z

Another question, can you describe exactly how you bind?
Example:

Put RX in bind mode
Launch a bind on the TX
When I see that the RX is bound from the led pattern, i stop the bind process on the TX
I unplug the RX
I replug the RX and it doesn't work

If you do the step 3, can you try without it? But instead move 3 to 4a?

MJ666 · 2021-03-24T22:01:08Z

The process is like you describe above except step 3. For step 3 i always wait for the TX to finish the bind sequence (beeping will stop by itself). The change in the RX LED pattern (green LED goes off) will usually happen at this point also. I have seen it ones when the green LED was going off before the TX stopped beeping.

pascallanger · 2021-03-25T07:02:41Z

Can you shutdown the TX or select another model or select a different protocol, whatever you want to not let the bind to finish? well before it stops beeping.
I'm wondering if the issue is in the switch from bind to normal.
What about also if you unplug the RX well before the TX stops beeping?
I need to check but I think on a FrSky XJT module you need to power off the TX to stop bind.

FYI, In v2 the RX only needs to get 1 packet to have all the bind information.

I've pushed a new version .64 of the FrSkyX code which I don't think is going to change anything since it's mainly cosmetics but may be you can try it: https://downloads.multi-module.org/latest-test/

MJ666 · 2021-03-25T15:25:50Z

OK, shutting down TX or RX during bind or interrupting does not change anything. During proper bind the red LED is flashing and the green stays on. This stays like tis till the XM+ is powered off. During the unsuccessful bind the red LED is solid and the green goes off when the bind process stopped.

The MPM will stop binding after a few seconds but the external XJT module need to be stopped by pushing a button (OpenTX radio). The XM+ will always react on end of the bind procedure. The green LED will go off o but with MPM it will never bind. The XM+ maintains the former bind information in this case and can connect with the TX which was bound before. I tested .58. 61 and .64 of MPM. In general .63 looks to be still working.

I also found some very strange behavior after I bound the XM+ with the XJT I’m also not able to bind them with the Devo10 anymore. The behavior is now the same as with the MPM before. This was tested with two XM+.

Flashing XM+ with v2.1.0 firmware will allow binding in any combinations (MPM, XJT, Devo10).

The XM+ and also the R-XSR will not bind in FrSky Clone mode but can be used when bound with the original TX.

MJ666 · 2021-03-25T20:06:22Z

XM+ will bind to Devo10 with v2.1.2 again after flashed with latest V1 firmware and bound to a different RX. Interestingly the bind information survives the update from V1 to V2 and you still be bound to the TX after all settings are adjusted. The procedure does not work with an downgrade to v2.1.0. The XM+ still stays in bind mode after the green LED goes off during an unsuccessful bind as long you keep it powered. If you start the bind process on a non MPM TX the red LED starts flashing and the green one is turning on again. The bind will be successful in this case. This is working with the XJT and the Devo10 as long the XM+ was not bound to an XJT before. Than it flails like the binding with the MPM. The MPM never binds with V2.1.2 firmware.

MJ666 · 2021-03-31T18:25:02Z

XM+ v2.1.2 is binding properly also with X9 Lite S and ISRM 1.1.1/2.1.6 EU. Also after bound in this combination is will not bind to the Devo10 again and also not to the MPM. Also the downgrade procedure fro the XM+ described above looks not working reliably and binding with Devo10 will work only a few times and than fails again. For now it looks to be for the XM+ to stay with V2.1.0 and be sure to avoid situation wich cause the servo direction reversal.

MJ666 · 2021-04-01T04:18:28Z

I will now get my BetaFlight development and debug environment ready again to capture the decoded bind frames for the MPM, XJT and ISRM and compare. Likely there is a difference in the fixed part (unknown bytes) of the bind frame which is now analyzed/used by the new XM+ firmware. Same thing could happen with upcomming FrSky RX firmware updates in the future. Any other ideas or feedback how the problem can be solved are welcome.

MJ666 · 2021-04-06T04:52:29Z

Here is what i got from capturing. Till now i only took a single sample from each module but it shows the "unknown bytes" section is always different and likely the root cause of the bind problem. May be the new XM+ firmware is doing some more testing in this area.

          | TX18S MPM | X9LiteS ISRM | T16 XJT | MPM | BetaFlight
packet[0]  | 0x1d | 0x1d | 0x1d |   |  
packet[1]  | 0x3  | 0x3  | 0x3  |   |  
packet[2]  | 0x1  | 0x1  | 0x1  |   |  
packet[3]  | 0x77 | 0x99 | 0x5c | rx_tx_addr[3] | bindTxId[0]
packet[4]  | 0x28 | 0xb0 | 0x55 | rx_tx_addr[2] | bindTxId[1]
packet[5]  | 0x2  | 0xc  | 0x9  | rx_tx_addr[1] | bindTxId[2]
packet[6]  | 0x0  | 0x0  | 0x0  | RX_num | rxNum
packet[7]  | 0x0  | 0x27 | 0x27 | Telem+ Chanels |  
packet[8]  | 0x32 | 0x6  | 0xfd | … UnknownBytes |  
packet[9]  | 0xb  | 0x9  | 0xd  |   |  
packet[10] | 0x0  | 0x5d | 0x0  |   |  
packet[11] | 0x0  | 0x14 | 0x0  |   |  
packet[12] | 0xa8 | 0x15 | 0xa4 |   |  
packet[13] | 0x26 | 0xb3 | 0x8  |   |  
packet[14] | 0x28 | 0xee | 0x72 |   |  
packet[15] | 0x1  | 0x0  | 0x1  |   |  
packet[16] | 0xa1 | 0x47 | 0xd4 |   |  
packet[17] | 0x0  | 0x40 | 0x9  |   |  
packet[18] | 0x0  | 0x2c | 0x0  |   |  
packet[19] | 0x0  | 0x39 | 0x0  |   |  
packet[20] | 0x47 | 0x4f | 0x19 | 0x0E ^ rx_tx_addr[3] |  
packet[21] | 0xc2 | 0x1a | 0xb6 | 0x1C ^ rx_tx_addr[2] |  
packet[22] | 0x87 | 0xa5 | 0x8c |   |  
packet[23] | 0xc7 | 0xfe | 0xc7 | … UnknownBytes |  
packet[24] | 0xa7 | 0xa7 | 0xa7 |   |  
packet[25] | 0xa7 | 0xa7 | 0xa7 |   |  
packet[26] | 0xa7 | 0xa7 | 0xa7 |   |  
packet[27] | 0xa7 | 0xa7 | 0xa7 |   |  
packet[28] | 0x1a | 0x95 | 0xea |   |  
packet[29] | 0x54 | 0xdb | 0x4c |   |  
packet[30] | 0x31 | 0x42 | 0x1e | crc |  
packet[31] | 0x97 | 0xff | 0x90 | crc | 
```

pascallanger · 2021-04-06T07:39:03Z

I'm not sure what you are looking for by doing this... The 16 unknown bytes starting at packet[8] are the result of a pseudo random generator so yes they are always different. By the way CRC is in packet[28] and [29] not 30 and 31.
What I still can't get is why deviation with the same code is working and not multi. But it looks like that deviation does not work very well either from your tests...
We can easily change the unknown bytes being used in the multi code to something else and see if the RX will like it better. But again if deviation is somewhat working then it points to somewhere else.
Not having the RX in my hands to try things makes it really difficult...

prikrylm · 2021-04-06T08:09:39Z

Not having the RX in my hands to try things makes it really difficult...

Ok, where should I send the receiver or the money to buy? :)

pascallanger · 2021-04-06T08:26:54Z

Ok, where should I send the receiver or the money to buy? :)

Thanks for the offer, you can PM me on RCGroups, username hpnuts.

I've pushed v1.3.2.70 available here: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/suites/2428270863/artifacts/51851187
@prikrylm @MJ666 Can you test it?
I haven't tested it on any RXs, just modified the code to use 2 different random frames and toggle between them.

prikrylm · 2021-04-06T08:38:21Z

I will try this build, but not before tonight (I'm at work).
PM sent (I hope - there is 0 sent messages in the list :-/ ) .

MJ666 · 2021-04-06T09:34:52Z

First the good news v1.3.2.70 is binding with my 2 XM+ receivers immediately with the first try. All looks good at the bench test.

My intension with the testing was to understand what is different in the bind package between the TX modules. From the code I was not aware the unknow bytes are kind of random. They also could contain some kind of sequence number or other criteria which could be use by the new FrSky firmware to detect a third party TX module and refuse binding. My next planed test was to capture multiple bind frames in sequence. For now the problem looks to be solved.

Deviation binding was not working after first bind with an original FrSky TX. I got it to bind a few times after a firmware downgrade as described above but this was not an reliable procedure. This was also strange since the code was basically the same as in the MPM.

prikrylm · 2021-04-06T15:53:53Z

I also report that v1.3.2.70 is binding well with XM+(2.1.1). And also looks like v2.1.1 XM+ FW solved better signal handling in short distances between RX and TX.

pascallanger · 2021-04-06T16:13:19Z

Great news so I'm closing this issue ;-)

prikrylm · 2021-04-06T16:15:30Z

Nice work! :)

pascallanger added the help wanted label Mar 13, 2021

pascallanger closed this as completed Apr 6, 2021

MJ666 mentioned this issue Jun 11, 2021

Fix bind problem for FrSky XM+ v2.1.2 firmware DeviationTX/deviation#1011

Merged

Unable to bind XM+ with ACCST X2 LBT #543

Unable to bind XM+ with ACCST X2 LBT #543

Comments

prikrylm commented Mar 13, 2021

pascallanger commented Mar 13, 2021

prikrylm commented Mar 13, 2021

pascallanger commented Mar 13, 2021

prikrylm commented Mar 13, 2021 • edited

MRC3742 commented Mar 13, 2021 • edited

prikrylm commented Mar 13, 2021

pascallanger commented Mar 13, 2021

MRC3742 commented Mar 13, 2021

MRC3742 commented Mar 13, 2021 • edited

prikrylm commented Mar 16, 2021 • edited

pascallanger commented Mar 17, 2021

prikrylm commented Mar 17, 2021 • edited

MJ666 commented Mar 24, 2021

pascallanger commented Mar 24, 2021 • edited

MJ666 commented Mar 24, 2021

pascallanger commented Mar 24, 2021

MJ666 commented Mar 24, 2021 • edited

pascallanger commented Mar 24, 2021

MJ666 commented Mar 24, 2021 • edited

pascallanger commented Mar 24, 2021

MJ666 commented Mar 24, 2021 • edited

pascallanger commented Mar 24, 2021

MJ666 commented Mar 24, 2021 • edited

pascallanger commented Mar 24, 2021

MJ666 commented Mar 24, 2021 • edited

pascallanger commented Mar 24, 2021

MJ666 commented Mar 24, 2021

pascallanger commented Mar 24, 2021

MJ666 commented Mar 24, 2021 • edited

pascallanger commented Mar 24, 2021 • edited

MJ666 commented Mar 24, 2021

pascallanger commented Mar 24, 2021 • edited

MJ666 commented Mar 24, 2021 • edited

pascallanger commented Mar 25, 2021 • edited

MJ666 commented Mar 25, 2021 • edited

MJ666 commented Mar 25, 2021

MJ666 commented Mar 31, 2021

MJ666 commented Apr 1, 2021 • edited

MJ666 commented Apr 6, 2021 • edited

pascallanger commented Apr 6, 2021

prikrylm commented Apr 6, 2021 • edited

pascallanger commented Apr 6, 2021 • edited

prikrylm commented Apr 6, 2021 • edited

MJ666 commented Apr 6, 2021 • edited

prikrylm commented Apr 6, 2021

pascallanger commented Apr 6, 2021

prikrylm commented Apr 6, 2021

prikrylm commented Mar 13, 2021 •

edited

MRC3742 commented Mar 13, 2021 •

edited

MRC3742 commented Mar 13, 2021 •

edited

prikrylm commented Mar 16, 2021 •

edited

prikrylm commented Mar 17, 2021 •

edited

pascallanger commented Mar 24, 2021 •

edited

MJ666 commented Mar 24, 2021 •

edited

MJ666 commented Mar 24, 2021 •

edited

MJ666 commented Mar 24, 2021 •

edited

MJ666 commented Mar 24, 2021 •

edited

MJ666 commented Mar 24, 2021 •

edited

MJ666 commented Mar 24, 2021 •

edited

pascallanger commented Mar 24, 2021 •

edited

pascallanger commented Mar 24, 2021 •

edited

MJ666 commented Mar 24, 2021 •

edited

pascallanger commented Mar 25, 2021 •

edited

MJ666 commented Mar 25, 2021 •

edited

MJ666 commented Apr 1, 2021 •

edited

MJ666 commented Apr 6, 2021 •

edited

prikrylm commented Apr 6, 2021 •

edited

pascallanger commented Apr 6, 2021 •

edited

prikrylm commented Apr 6, 2021 •

edited

MJ666 commented Apr 6, 2021 •

edited