V1.3.4.0 - Null information fields in Multi type 0x01 status packet.

[sloped-soarer]

Hi.
I downloaded the V1.3.4.0 firmware from the downloads
https://downloads.multi-module.org/
Module was iRangeX
v1.3.4.0
Serial
EU(LBT)
AETR

Protocol 28 AFHDS2A appears to be unavailable. Hence the null Protocol name and sub-protocol name in the 0x01 Multi status packet.
What I didn't realise was that the module LED was flashing red every second ... short blip meaning protocol unavailable.

From this I assume AFHDS2A is not a LBT protocol ?.

However, does Multi.txt always lists all available protocols ?.

Please advise.

[pfeerick]

From this I assume AFHDS2A is not a LBT protocol ?.

Most likely not... the protocol predates the EU directive for LBT, as does Spektrum DSM2, and ASSAN.

Multi.txt is a flat text file - it simply lists all the available protocols, and does not take into account if you downloaded a Surface, Air or LBT firmware variant. The file is located here in the repo => https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/Multiprotocol/Multi.txt

I believe this is the same for the Lua Scripts... it is simply a zip file of this folder => https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/tree/master/Lua_scripts

[pascallanger]

Multi.txt is probably not needed anymore. It was used at the time by er9x and erskytx to list the protocols but I think I can remove this file since these firmwares are using what the module is sending for some time now. OpenTX and edgetx never used it.
From a lbt perspective, only 2 protocols are lbt. Others must fall under the channel usage and power tx rules but it's hard for me to know in which category they should fall so I've just selected a very small subset. I can add/remove things if needed.

[sloped-soarer]

Multi.txt is probably not needed anymore. It was used at the time by er9x and erskytx to list the protocols but I think I can remove this file since these firmwares are using what the module is sending for some time now. OpenTX and edgetx never used it. From a lbt perspective, only 2 protocols are lbt. Others must fall under the channel usage and power tx rules but it's hard for me to know in which category they should fall so I've just selected a very small subset. I can add/remove things if needed.

@pascallanger
Please do not remove the multi.txt file. I know the prehistoric OpenAVRc still uses the multi.txt file at compile time to provide a quick lookup for protocol number to protocol name. With the update time of 0.5 seconds for the 0x01 status packet, things can slow down quite considerably when stepping through the protocols.

Thanks anyway for clarifying the LBT situation.
I did wonder whether you would just reduce the power level to 10mW for the non-LBT protocols, rather than eliminating them.
I haven't read the ETSI standard recently and it's not on bedtime reading list either. But i seem to recall at below 10mW there were other rules such as channel dwell time or similar that came into play.