fix(mpm): some protocols excluded

[3djc]

Pascal called me because he could not select MouldKg protocol on his TX16S.

This fixes it

[pfeerick]

Probably need to check with @mha1 about this... as they are prevented from access per the note on that function, (not sent by MPM protocol scan) ... remember what that was about?

[3djc]

Probably need to check with @mha1 about this... as they are prevented from access per the note on that function, (not sent by MPM protocol scan) ... remember what that was about?

Checked with Pascal, and basically he said 'nonsense' (well that the politically correct version of what he said)

[mha1]

well, tell him to stop being a dick and have him communicate changes so they can be properly reflected. The reason is EdgeTX holds a shadow definition of the MPM's capabilites for offline use (MultiProtoDefs.h, MultiSubtypeDefes.h), i.e. doing setups in CPN or on the radio without an MPM present.

Multi.txt is a superset of protocols. Not all of them are in a scan (see MPM/_Config.h). To have a proper offline representation isMultiProtocolSelectable() excludes the ones that are not in a scan. Of course this is MPM fw version dependent and needs to be updated with MPM changes.

He enabled MOULDKG 4 and CFLIE month ago with commit 72da3c5. Up to this point it was excluded in the scan (not defined in _Config.h). If you want to have a proper offline MPM database in EdgeTX just take out those two from isMultiProtocolSelectable().

[3djc]

Thats not what it does, it also exclude those from the scan

[mha1]

The point is the offline database and scan results need to be inline to not confuse e.g. CPN users. isMultiProtocolSelectable() does that. If MPM makes changes to available protocols and subprotocols the offline database and isMultiProtocolSelectable() needs to be changed accordingly. Then everything stays identical.

[3djc]

Thats cannot happen anymore, since firmware have been spitted in air and surface. Also, offline use should not prevent protocols in the module to be read, since the very purpose of getting the list from the module is to not have to do catchup with MPM...

[mha1]

I'm out. God bless

[pfeerick]

Yeah, the split between Air/Surface has resulted in somewhat of a support mess... people start complaining that X protocol is missing, so you have to ask "have you tried the other firmware"... Really needed some videos / more documentation to highlight the differences between them ready before that happened, and would have been nice to know that was coming. i.e. if the MPM indicates what list of protocols is in use - i.e. AIR/SFC/EU, we could perhaps use that to adjust the lists (as well as it being user selectable filter if offline) - and if the MPM firmware doesn't... ask why ... not? That, or perhaps the MPM needs its own cloudbuild solution... so you can pick the protocols you actually want/use, until the firmware is full ;)

Anyway, yeah, something isn't quite right with isMultiProtocolSelectable(), as it is is filtering the rfProto list in scanReply, thus dropping that those protocols that if they are present, rather than just filtering the offline list. Really all that should have been dropped was the Config protocol as that isn't mean to be user selectable. So will go with this for now, but this is not the end of this problem... but a bandaid, methinks...