Model matching

[geofrancis]

At the moment there is no way to select what receiver you are connecting to so you cannot have more than one receiver powered on with the same bind code.

I suggest a way of using the opentx receiver number as part of the bind code. while its true that it doesnt work for other settings like update rate, you cant change that on the r9m modules im using anyway I dont see that as a big deal.

crossfire frsky and elrs all use the receiver number in opentx as far as i know .

matching it to the model would be better than the receiver ID but i dont think there is a way of doing that without changing the radio firmware.

[olliw42]

MANY thx!

I fully agree that such a capability is missing, and that it is needed!

I am not so sure if the model id is the best approach, but it is a possible, and also relatively easy to implement, option. So, you may be right that the benefits may outweight the disadvantages. I would like to suggest however that we first kind of go through a period of brain storming, to possibly have alternative ideas in our basket to compare to.

I myself found the modei id thing very confusing at first (until I understood it on the detailed technical level), but my opinion is admitedly not very authorative. However, a while back I saw a video from JB on exactly this matter of model match in ELRS ... and - that's at least what sticked in my brain - the conclusion was, "so, you know now that it's there, what it tries to solve, and how it works ... but it's too complicated and so I just don't use it...". You see where the argument goes :)

Nit-picky as I am, I'd like to correct that it will never be possible to connect to more than one receiver with the same bind code. (in the strict sense of connecting with a bi-directional data flow, it of course will be possible to "connect" another receiver with identical bind phrase if that receiver does not send anything back to the tx module, i.e. is just listening). That's exactly the purpose of the bind phrase to establish a unique 1to1 relation ship between tx and rx. So, the "effective" bind phrase, however it is composed, will have to be the same on the receiver and tx module. The point of the discussion here is to "only" have a way to more easily change the "effictive" bind phrase from within the radio, without having to invoke the tx parameters directly (through CLI, lua, etc).

[olliw42]

I think this is the video I was refereeing to: https://youtu.be/3S6eUWCqvUY

[geofrancis]

The problem is im effectively locked out of using it with other vehicles at the moment without switching the first one off. having it remember other settings would be nice but not essential to fixing the fundamental problem. JB is never going to fly more than one vehicle at a time so thats why he has no real need for it.

[olliw42]

pl be assured that i fully understand your issue, and i was by no means trying to negate it. i however think we could spend some thoughts on how to possibly else do it and not just rush into the first thing. the model match ala elrs is not the most user friendly. i think we may come up with something better 👻

[olliw42]

what about this, quite straightforward, but different (as compared to the above) interpretation of the "receiver number" in OpenTx/EdgeTx:

the tx module can store a list of let's say 10 different configurations, where each configuration is comprised of the common and the tx paramters (the rx parameters are stored in the receiver). The "receiver number" is simply the number into this list. This "receiver number" can only be changed from within the radio, but not the CLI, Lua script or OLED display. This implies that whatever c and tx parameters are shown in the CLI, Lua, or OLED are those corresponding to the currently active list.

Implementation-wise this is not totally easy to do, since mLRS can't reconfigure itself without restarting itself. There is also the quirk (which is general for any approach using the radio's receiver number) that what happens if one and the same tx module is used one time in the radio (so it gets a receiver number from the radio) or standalone without the radio (so it doesn't), which may lead to states confusing the user, but for which I don't see a solution.

we would need a good word for the different entries in the list. "Receiver number" is obviously misleading since it's the configuration of the tx module, it's also not "model match". "Model number" is also misleading as there are already models in the radio which is a different thing than what we have herer. It could be "Configuration number" but "configuration" is so generic that it's easily confusing with all the other configurations out there. ??

I'm still curious how this is done in e.g. TBS crossfire ... crossfire is so renowned for easy to use, and they must have a method for this too.

[jlpoltrack]

I'm still curious how this is done in e.g. TBS crossfire ... crossfire is so renowned for easy to use, and they must have a method for this too.

If I recall correctly, you specify your receiver number (per model) in OpenTx/EdgeTx before binding and that provides a unique ID for each model which can be used as part of the bind phrase.

[olliw42]

so just read the tbs manual, and it seems to me it has two bind modes, normal and mutibind. However, as much as I can see it has no such thing as a bind phrase which is user selectable. In the case of multibind you get a cryptic number to be used. (I'm always not trusting my understanding which I get from only reading such manuals - it made me missunderstand things before)

Having both, a bind phrase and a receiver number, in ELRS is - in my understanding - only because the radio only offers the receiver number mechanism. The disadvantage concerning the user side of that approach is however well exposed in jb's video. If there were a method to set the bindphrase in the radio, all the mayhay would be gone and a receiver number would be obsolete.

[geofrancis]

I'm still curious how this is done in e.g. TBS crossfire ... crossfire is so renowned for easy to use, and they must have a method for this too.

If I recall correctly, you specify your receiver number (per model) in OpenTx/EdgeTx before binding and that provides a unique ID for each model which can be used as part of the bind phrase.

thats essentially how all the frsky stuff works both x and r9,

from what I can tell Elrs is doing the same as the rest of the systems by using the Receiver number thats set before binding in opentx but they also use that receiver number to load different profiles on the module. so its not so much that they are doing it different, just that they are attaching some more parameters to the receiver number than just the bind code..

[olliw42]

from what I can tell Elrs is doing the same as the rest of the systems by using the Receiver number thats set before binding in opentx but they also use that receiver number to load different profiles on the module. so its not so much that they are doing it different, just that they are doing some extra steps.

based on the procedure shown in jb video, I disagree here. A key difference is that you also have to configure the receiver correctly for this to work! That's not what you need to do for all the others systeems. And it's what makes me refrain. I don't want mLRS users to have to go through such a process as in the video.

if the TBS & FrSky like approach is ok, it should be most easy to implement. IMHO it will come with some inconvennience further down the road, but these woud then have to be accepted.

[geofrancis]

I didnt realize its not enabled by default in Elrs. I wonder what their reasoning is as it must be the only modern system that doesnt use it out the box. Even the multiprotocal module works the same way with compatible protocols.

what other parameters would you need to attach to the receivers profile saved in the tx other than bind code update rate and power level?

[olliw42]

what other parameters would you need to attach to the receiver other than bind code and update rate?

it are the common parameters (that's so to say the definition of them), currently bindphrase, mode, and frequency range.

however, it's no problem implementation wise to then also make the the tx parameters dependable on the receiver number, via the afore mentioned list and as also ELRS is doing it, which I think should be very disarable (and IMHO just a question of time that someone also wants then this).

[olliw42]

@geofrancis @jlpoltrack

I have pushed a branch dev-configid with code and firmwares for supporting the receiverId in the OpenTx/EdgeTx radios when CRSF (or mbridge) is selected: https://github.com/olliw42/mLRS/tree/dev-configid

@geofrancis, it would be great if you could give it some testing.

It was way harder to do than I would have thought, as there are some gotchas, which relate to the very different setups mLRS can be used for, i.e., that it is not just a regular rc Tx module. But I hope to have sorted them out now.

The concept is centered around a variable "ConfigId", and works as follows: In the Tx module is stored a table which hosts 10 versions of the Common and Tx parameters (the Rx parameters are stored in the receiver). ConfigId thus can range from 0 - 9 and selects which table is used. When the ConfigId is changed, the Tx module is restarted and the respective table is used.

The ConfigId can ONLY be changed from the radio by changing the receiverId. Then the receiverId is larger than 9, it is simply ignored by the Tx module. When the receiverId is changed it takes 0.75 secs for the Tx module to actually do the change (this is needed since then the wheel is scrolled there is a huge number of changes in a short time, which the module can't handle, so it may get out of sync). The CLI, Lua, and OLED now display the current ConfigId. All parameter changes, be it done via CLI, Lua, or OLED, always ONLY affect the parameter values in the currently selected table.

There is one exception, the TxChSource parameter:

• when it is set to NONE or SBUS, when the ConfigId mechanism is not available, i.e., always the table for ConfigId = 0 is selected (which is also the default table after a fresh firmware upload).
• when it is set ot CRSF (or MBRIDGE), then this setting is made to be equal across all tables.

you need to flash both the Tx module and the receiver, as well as update the lua if it is used. Note: the bw lua is not updated, it shoudl work but won't show the ConfigId.

Curious to hear how you get along with this.

[jlpoltrack]

Just to confirm my understanding, bind phrase now is bind phrase + configid https://github.com/olliw42/mLRS/commit/24f5caa678d68c9a916dfef53f20ba03c0c08137#diff-fec75109f7bfa15bed9ec9aa82c31c55feb22dcdfeed0ed9f76e49b0f2e09056R208 ?

Was wondering if these would impact the 2.4 exclusion logic but figured you had accounted for this.

[olliw42]

Just to confirm my understanding, bind phrase now is bind phrase + configid ?

no, totally not ...

the bindphrase is the bindphrase you have configured for the particular table

it is really just like 10 pages, where on each page you can fill in different values for the common and tx parameters. It's not anything like model match or whatever. While I don't know nothing, IMHO it's closer to what you find in Ghost, Flysky, etc.. It's just a table of different configurations.

so, to use it, you simple chose a receiverId, you wait few seconds for the Tx module to have restarted, then you set the parameters as you usually would do, and store them, and bind your receiver. Et voila. If you want another configuration, you chose a different receiverId, wait few seconds for the Tx module restart, set the parameters as you usually would do, store them, and bind your receiver. Et voila. ... ... ...

it's super simple - IMHO - if one can just erase everything from brain one might have heard before

[jlpoltrack]

Okay this makes sense. I am thinking that you will likely still want a different bind phrase for each receiver ID but now these are remembered using the 10 slots so switching between models is easier.

[olliw42]

you can configure different bindphrases for each table, so that's possible and achieves "model match"

ecept of TxChSource you can configure any parameter at will, so it's way more flexible than "model match"

[olliw42]

your comment made me realize that I should improve the code in that the default bind phrase is different for each ConfigId. With that change, if a user isn't interested in dealing with the bind phrase, she/he can simply set a receiverId, bind the receiver, and will have them each bound to different bind phrases and hence have them working independently. I guess that's a good improvement. LOL.

[olliw42]

updated the https://github.com/olliw42/mLRS/tree/dev-configid branch ... does now aso do different bindphrases per default, giving "model match" capability out of the box

@geofrancis did you had a chance to test this branch?

[olliw42]

merged to main. closing.

[geofrancis]

I havent had a chance to load it yet , vehicle is still outside for testing.

[olliw42]

thx for considering it though :) it's now in main anyway, so we will see how it goes :)