Closed mikedsp closed 2 years ago
That is an interesting finding, but what exactly does it have to do with this library?
My bad - this comment has nothing to do with this library. I put it in the wrong repo. I apologize. I don't know how to delete the issue, or else i would have. Please feel free to delete it.
No problem, happened to me before as well. I will just close it.
Last week I joined a Browan MerryIoT CO2 sensor to the Helium network and noticed that a significantportion of the uplink messages were not being picked up by the network. I have 2 hotspots in my house and several around me and the rest of my sensors typically have an uplink connection rate of 95+%. Upon further investigation I noticed that the datarate being used for the MerryIoT was SF8BW500. All my other 20+ sensors use BW125, so the BW500 was a surprise.
I reached out to the Browan application engineer and his response was as follows: "I'm sorry to tell you that there is a known issue if node is using BW500K for joining to Helium. However, this issue comes from Helium LNS (LinkADR MAC command) instead of our nodes, it will cause the uplink hit rate issue. We've reminded and discussed with the Helium team, they are going to fix this issue and will keep us updated. On the other hand, according to standard LoRaWAN US915 join procedure, the join request messages on random 125k and 500k, so in case of join successfully at 500k, it is probabilistic instead of our design.
The workaround is relaunching the OTAA join by holding the test button for over 5 seconds to see if it can just join the Helium on 125k."
I followed the recommended work around and the device joined with BW125 and since then the uplink hit rate has been fine. I have attached a Log of messages received from the device. In the log you can see that when BW=500, there are are gaps in the frame count, but that once the device was rejoined with BW125, the gaps in the frame count go away.
20220303_Log_MerryIot_CO2.xlsx