2A ver.20 firmware doesn't work with my 2A ver2.0..!

[fxbisto]

Thanks for your work on these firmwares, it's brilliant! I don't understand how you managed to reverse engineer the binary but I like it a lot :)

Anyway, back on topic... I have a flashed 3x iA6B, 2x X6B, and 2x 2A ver2.0. Obviously I was most excited for the 2A but it doesn't play nicely on either of the 2 I have. Interestingly 1 is form Banggood and 1 is from ebay but they both have identical firmware and behave the same on the mod'd f/w. All other receivers work fine.

When I flash either of your ch8 or ch14 2A binarys to my 2As they just blink in groups of 4 or 5 flashes with a gap inbetween them, but don't connect to my Tx or give an ibus signal. It works if I inject the byte at 10FC from my binary into yours then flash, but then I lose telemetry on the Tx. Previously it would send back Rx voltage. I've attached my original f/w from the 2A's, would you please be able to take a peek for me when you have the time?

I would have tried to use the script to modify my firmware but it's unclear to me what dependencies the code and compiler have, or how we use it. I'm guessing it's a case of replacing the 8A_orig.bin with mine and then issuing some command?

Thanks again Original flysky 8A binary.zip

[Cleric-K]

I suppose that by 2A you meant 8A ?

Anyway, if that's the case - the problem should be solved, but it seems I have forgotten to upload the fixed version =O Thank you for reminding me!

It turned out that 8A has some checksum that is dependent on the unique id of the stm mcu. Instead of trying to generate the correct checksum I simply disabled the checking.

Please try downloading again 8A from the build directory and say how it goes.

[fxbisto]

Yes quite right, 8A indeed.

Awesome. I did manage to work out that I needed gcc-arm-none-eabi so used your code on my binary which spat out a different binary but it functions exactly the same.

I'm out at the moment but I will be home to try the latest commit and report back in a few hours

Cheers

On Sat, 1 Jun 2019, 20:49 Cleric-K, notifications@github.com wrote:

I suppose that by 2A you meant 8A ?

Anyway, if that's the case - the problem should be solved, but it seems I have forgotten to upload the fixed version =O Thank you for reminding me!

It turned out that 8A has some checksum that is dependent on the unique id of the stm mcu. Instead of trying to generate the correct checksum I simply disabled the checking.

Please try downloading again 8A from the build directory and say how it goes.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Cleric-K/FlySkyRxFirmwareRssiMod/issues/4?email_source=notifications&email_token=ACN732PWFST32OO3LXIVGWDPYLHDLA5CNFSM4HSBAON2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWXHMPA#issuecomment-497972796, or mute the thread https://github.com/notifications/unsubscribe-auth/ACN732OO2OEWTGLWNMSS3ZLPYLHDLANCNFSM4HSBAONQ .

[fxbisto]

Okay so I've just flashed the updated binary and it now acts the same as the other firmwares I managed to get to work, led acts as it should, binding works as normal and RSSI output seems correct but still no Rx V available in sensors list.

[fxbisto]

Also as a side note, the RSSI doesn't go to 0 during a failsafe event, it just holds wherever it was previously. I'm not sure if this is the intended behaviour or not and I guess in the long run it doesn't make much odds as the RSSI should drop before you lose signal?

[Cleric-K]

Great news for the 8a!

About the rssi not going to 0: that's normal. It's actually effect of betaflight itself.

8a/a8s rxes simply stop dumping frames when they lose tx signal. BF decides it is a failsafe condition by the fact that it has no ibus frames for more than x ms. The problem is that it also never gets the chance to receive a frame that carries 0 on ch14. That's why it keeps the last known value.

ia6b, x6b and others have failsafe support and continue to send failsafe ibus frames (as configured in the tx). If properly configured (by sending invalid value channel, below or above the 1000-2000us range) it activates BF failsafe but BF also ignores the remaining channels (even though ch14 now carried 0).

The solution in both cases is just to simply configure in BF failsafe value for ch14/aux10 Set 0. This will cause the rssi indicator to go 0 when failsafe condition is detected.

[fxbisto]

Yes, I checked with the 'scope and it's the 8A physically stopping packets when the Tx is lost. Your workaround seems to work just fine! Closing this issue I've another interesting one just happened. Thanks