ST Microelectronics LoRa driver breaks EU TX regulations!


#1

For anyone using ST Microelectronics LoRa modules or boards (such as the B-L072Z-LRWAN1), watch out!

I opened a support ticket with ST back in October (2018) highlighting a bug in their driver code that adds +1 dBm to a user’s TX power request. If a 14 dBm TX power (25 mW, EU limit in most 868 LoRa bands) is set by the user through the I-CUBE-LRWAN driver API, the driver code actually sets the SemTech RF IC (SX1276) register setting for 15 dBm, which (unknown to the user) would break EU TX regulations. I received no response until December (2018) where it was simply said my bug fix had been passed-on.

I noted the new release of the I-CUBE-LRWAN (1.2.1) still did not include this fix. I opened a new support ticket again highlighting the issue (and including the file name, line number and simple code fix from the previous ticket). Unfortunately this time, whoever is at the other end of the ST support for this case is INSISTING they will do nothing unless I provide an “image of the RF signal as displayed on a calibrated Spectrum Analyzer”. I have explained multiple times their driver is writing the wrong TX power setting directly to the SemTech RF IC (SX1276) register. It is very fair for me to assume the SemTech chip will perform as it is certified to do and output the TX power it has been asked to (which it still within its own specification). The clear issue is ST’s driver is passing a HIGHER TX power level than set by the user through their API. It should NOT require an (expensive) calibrated RF analysis to request that ST Microelectronics fix a bug in their code, that is at the very least ASKING the SemTech RF IC to transmit at levels that are above EU limits against the wishes of the programmer. What a very stubborn and anti-customer line for ST Support to be taking.

I think my only option at the moment is the warn as many users as possible - reduce your TX power request by 1 dBm for ST’s driver to actually do as you ask and not risk inadvertently breaking RF regulations. For reference, my ST support case IDs were 00067813 (where I provide full code details, datasheet references and explanations) and 00072508 (current, “we don’t care unless you prove to us the actual RF output is illegal”, case).

Argh.