Fixed_id queries

I assume these truths to be self evident:
1. If a RxA binds to a modelX.ini file with a fixed-id coded in TxA, the Rx is "stamped" with that fixed-id associated with TxA.
2. A modelY.ini in TxA will fail to bind to RxA if it presents a different fixed-id.
3. A modelY.ini in TxB will fail to bind to RxA even if it presents the same fixed_id.
4. As a corollary: every model.ini file should be specified with a different id to avoid binding a model.ini file to the wrong aircraft.
How deluded am I?

1, & 4 are true. 2 is true if you're meaning reestablishing the link. Actually re-binding will clear out any old fixed ID and set a new one and in that case ANY model.ini in ANY transmitter WILL BIND to RxA because that's what the bind process is (but again I assume you mean reestablishing the link after a power cycle)


3 is true in stock DeviationTx FW however any number of Devo transmitters can be forced to ID themselves (called TXID) the same therefore allowing the situation in your scenario 3 to be false.

See here for an explanation on that:
www.deviationtx.com/forum/how-to/6358-ho...eral-tx-to-one-model

Thanks, Cereal_Killer. All possible usages of the parameter are therefore documented.

Spektrum ModelMatch.

For DSMx protocol I do not use FixedIDs in DeviationTX model configs so far....I thought I was OK with ModelMatch automatically.
Would have to re-test 1-3 models to make sure....

Actually you do NOT want to fly a 450 3D flybar heli with a glider / warbird model config, neither you would want to fly the StrykerQ as delta/elevon wing with your 450 flybar settings. You really want ModelMatch

If you want to share 1-3 model configs, well then you would have to share the same Fixed modelID, which is not possible on Spektrum transmitters and this requires a re-bind to the #2, #3 model.

Thomas, deviation DSM binding with no fixed id means all the receivers will have the same bind info. The receivers will connect to the tx with any DSM model file with fixed id of none, which is probably not what you want. Each model should be given a different fixed id. I guess Spektrum transmitters assign different id values automatically?

There's a request in this thread to change DSM protocols to auto-bind if fixed id is set to none (like Devo and Flysky) and I've made a test build. If this is adopted it will (partly) break your model files (they'll still work but deviation will go into bind mode every time if the fixed id is set to none. You'll have to exit bind mode and then the receivers will connect.)

I do think the auto-bind change is a good idea. It probably should be that way for all protocols capable of a true bind just to encourage users to set some fixed id value before binding. But I'm hesitant to make any changes that would break existing model files.

Maybe we should put a random fixed id in the default model files instead of them all having the same value...

hexfet wrote: Maybe we should put a random fixed id in the default model files instead of them all having the same value...

I think this is a great idea, I always ALWAYS set a fixed ID but sometimes worry (because I'm crazy) that I've already used that number (I have a tendency to come up with the same repeating number sequences subconsciously when attempting to make up random numbers in my head). For the last ~6 months now if I'm setting up a new model i just pull up a random number generator on my phone just so I can trust I'm entering a truly random number, stupid pattern loving human brain...

Is there an easy way to get STM32 to deliver a random number? I've played with randomization on 8bit PIC and AVR and it's not simple to do (in either of those 8bit architectures, especially not AVR)...

On AVR it's nearly impossible, on PIC I can setup a randomization table then feed it I crazy (but solvable) algorithm to come up with X, Y coordinates on the table for which random solution to use that time

To satisfy one user's request for auto-bind you are willing to (partly) break everybody else's model files that have fixed id set to none?
All of my ~40 model files have fixed id set to none...
Can you not make this an option?

Don't panic. That's why it's under discussion. No change would be merged without some consensus. A config option is one possibility.

But I think those model files are broken already, at least as far as the fixed id functionality. Any of those 40 DSM receivers will respond when the tx is powered on with any of the 40 models. The purpose of fixed id is to prevent that from happening by having a different fixed id for each model.

Seems like it would be better for deviation to manage fixed id automatically to enforce this safety aspect. Remove it from the GUI. Use a separate option for auto-bind. If for some reason it was desired to have two models share a fixed id the model.ini file could be edited. But managing fixed id automatically seems non-trivial - supporting trading/copying of model.ini files, changing fixed id on model Copy, etc. Needs more thought - comments invited.

How about adding a warning in the tx settings? Something like "Warning the fixed ID is already in use would you like to continue?"
That way the user could choose to change or if they wanted to use the same ID proceed with the bind process..

I like the idea of removing the default fixed id. The rest is essentially what happens today except fixed id is zero instead of random. But the bind info is still made unique by the transmitter id so there's no chance of two deviation radios interfering with each other.

I can't think of any way to make auto-bind backward compatible without a configuration option, and that seems awkward. Looking at the code it seems the way auto-bind works for Devo and Flysky is the intended design, but DSM (and Frsky) didn't follow the intention. However a breaking fix is not likely to be merged by anyone but PB.

Are there any reasons to have multiple models with the same fixed id other than when moving a receiver from aircraft to aircraft?

Current thought is to remove the default fixed id from model.ini. If no fixed id is set when the bind button is pressed, then generate and store a random id (as cereal_killer suggested). The fixed id stays in the GUI for cases where a user wants to force a particular value. This doesn't solve the auto-bind issue but would help prevent users from inadvertently binding multiple models with the same fixed id.