Could someone explain what consequences it brings in the operation of the device when these errors come out?

@ahaw021 @bnjroos Thanks for the information, I really appreciate it. I'd like to give a go for option A as it seems more straightforward. :)

@bucknall I am able to corrupt the file system pretty easily. Running 1.7.6FW ATM. It seems to be when the program has a file open and an error occurs. What is the file system running on these boards? It doesn't appear to be a journaling file system. It is way too easy to corrupt the file system and have it erase the whole flash. I am developing a BT application that can update any file on the device and really need protection against this type of failure. I'm already doing a double buffer approach with the file writes so I have a good copy of the target file before deleting the original and renaming the file. The issue is resetting the board in the middle of a file write causes any manor of flash corruption. Before someone says "don't do that", I try very hard to design my system to recover from any type of errors. The cardinal rule is that there should be no way to brick a unit doing an update. To that end, I test every kind of failure during updates to make sure the device remains in a operating state.

@jmarcelino Ok, I'll try with ABP as well and let you know. If this is the reason, then if i remove and re-set the channels after the join operation, wouldn't be "fixed"? UPDATE: With ABP all seem fine. I also tried again with OTAA. I noticed that in the github code the non-default channels were actually removed after join, whereas in my code this did not happen. So, when I added this code after join OTAA did work fine as well. Another remark: how do we know if we work with 3 or 8 channels? Many thanks @jmarcelino for your help!

@Vercellotti look e.g. here https://forum.pycom.io/post/9105

Hi, it has a LoRaWAN stack implemented and certified by the Lora Alliance. It works with LORIOT server. Let me know if you need help. Regards... Béla

@RobTuDelft thx for the help.

Thank you both for your answers! Finnaly with ADC.ATTN_11DB it works!

@robert-hh Perfect, I will have a look at it, thank you.

Upgrading firmware solved the problem.

@dangerdan02 It's clear, someone invested a lot of money to develop Symphony Link. But if they license it to "large customers" without a fee, why not license it to e.g. Pycom for one dollar or two per LoPy? Think about the possibilities. And they could still sell their gateways.

Did someone successfully connect to the Things Network (TTN) with ADR working? The TTN should have ADR enabled by default with the algorithm kicking in after 20 packets, yet even after 70 packets it's still at SF12BW125. The gateway is just next door, my packets have an RSSI of about -50 and a SNR of around 5-7. SF7 would still give plenty of margin. My LoPy firmware is at 1.7.3b2.

Solved it. I used the pycom upgrader 1.1.1.b2 to downgrade to FW 1.6.0.b1. Afterwards, the upgrade to 1.7.5.b2 worked seemlessly.

@jellium This is not possible yet, please see the existing topic: https://forum.pycom.io/topic/1350/strategy-for-lorawan-with-deepsleep-2

@titi974 so last test was with sf7, we did it again with sf12 and managed to get 550 meters this time.