Fix odd binding behaviour

[pkendall64]

There is a weird bind behaviour on the TX backpack.

Problem

The TX backpack on receiving a bind message from the TX module, stores the UID and forwards the bind message, via ESPnow, to any listening VRx backpacks. The problem is that if the TX backpack is flashed with a passphrase it will always use the flashed UID as the ESPnow group address. So the upshot is that the VRx has bound to the TX address, not the TX backpack address.

Solution

When sending a bind from the TX backpack, if the backpack was flashed with a passphrase, overwrite the address in the message with the flashed address.

EDIT:
After discussions, we now check the flashed UID against the passed in binding UID. If they are different then drop the bind, and print an error message. If there is no flashed UID, store the passed in binding UID as the UID for the TX backpack and forward it on to continue the binding process.

The downside to this is that the TX backpack will not bind if it flashed with a different bind-phrase to the TX module. Which is probably better than binding and not working.

[wvarty]

I actually think the "issue" you described is what we want (i.e. working as expected).
The same bind phrase is supposed to be used across the ELRS ecosystem in order to bind, so there should not be a case where the TX bind is different to the TX backpack bind, and if it is different, then it should not communicate.

[pkendall64]

Yeah, I know what you're saying, so it would be better to have the main firmware tell the TX backpack what the bind UID is rather than configure it at build time. That way it's always correct.

[wvarty]

Yeah, I know what you're saying, so it would be better to have the main firmware tell the TX backpack what the bind UID is rather than configure it at build time. That way it's always correct.

We could do that I suppose.
It makes things a little confusing, since it would be the one firmware that you DON'T need to supply your binding phrase on build, which might catch people out a little, but it solves the problem.

[wvarty]

An easier approach is to prevent the TX-backpack from sending any messages if it has a different UID to the TX

[pkendall64]

An easier approach is to prevent the TX-backpack from sending any messages if it has a different UID to the TX

I don't like the idea that it just silently doesn't work. Users will/have been confused as to why they can bind but it doesn't seem to work. With the code that returns the version number we could send back the UID in the backpack and then in the LUA it could say "UID mismatch"

[wvarty]

An easier approach is to prevent the TX-backpack from sending any messages if it has a different UID to the TX

I don't like the idea that it just silently doesn't work. Users will/have been confused as to why they can bind but it doesn't seem to work. With the code that returns the version number we could send back the UID in the backpack and then in the LUA it could say "UID mismatch"

Doesn't it "silently fail" right now if you flash a TX and RX with different phrases?
In saying that, I'm fine with either of the approaches you've suggested. Moar work is all.

[pkendall64]

An easier approach is to prevent the TX-backpack from sending any messages if it has a different UID to the TX

I don't like the idea that it just silently doesn't work. Users will/have been confused as to why they can bind but it doesn't seem to work. With the code that returns the version number we could send back the UID in the backpack and then in the LUA it could say "UID mismatch"

Doesn't it "silently fail" right now if you flash a TX and RX with different phrases? In saying that, I'm fine with either of the approaches you've suggested. Moar work is all.

TX and RX won't connect, but backpack to backpack it will bind using the bind-phrase from the TX module (passed in the bind command) but then it tries to talk with the UID on the backpack.

I noticed it when I added bind in the goggles and I put a success on the display when it gets a bind message. Then it didn;t get any messages because I fat-fingered the passphrase on my TX module so it was different to the TX backpack. Took me all day to figure out what had gone wrong!

[wvarty]

An easier approach is to prevent the TX-backpack from sending any messages if it has a different UID to the TX

I don't like the idea that it just silently doesn't work. Users will/have been confused as to why they can bind but it doesn't seem to work. With the code that returns the version number we could send back the UID in the backpack and then in the LUA it could say "UID mismatch"

Doesn't it "silently fail" right now if you flash a TX and RX with different phrases? In saying that, I'm fine with either of the approaches you've suggested. Moar work is all.

TX and RX won't connect, but backpack to backpack it will bind using the bind-phrase from the TX module (passed in the bind command) but then it tries to talk with the UID on the backpack.

I noticed it when I added bind in the goggles and I put a success on the display when it gets a bind message. Then it didn;t get any messages because I fat-fingered the passphrase on my TX module so it was different to the TX backpack. Took me all day to figure out what had gone wrong!

Nah my suggestion was to prevent ANY comms if the passphrases dont match. Even the bind message.

[pkendall64]

Nah my suggestion was to prevent ANY comms if the passphrases dont match. Even the bind message.

I'm cool with that. We will have to make people aware that if it doesn't bind then mismatching UIDs could be the reason.