This thread is being closed as the feedback and information contained here are now covered by the firmware upgrade tools. Please check the downloads section of our website to get the last versions of the tools.
For further support on the tools please feel free to open a new thread.
Hi @Roberto I tried to modify your code because I need to send a payload that contains the current time with a header containing mac address of the node and the length of the payload. Everything went well on the node side but rated nano gateway I have an Index Error: bytes index out of rang. it is because the adresse mac ? knowing that lora.mac() give : b'p\xb3\xd5I\x95kA\xf3' with length=8 but i don't understand what does mean the : b'p......' and how the length is 8 !!
@bmarkus Yes that is correct. Only a LoRa Nano-Gateway is possible. This is not compliant with LoRaWAN. But for development and without a full compliant gateway this is ok. So you can develop LoRa Nodes which connects to your own Nano-Gateway.
It is OK, but the original subject of the topic is "LoPy as LoraWAN Basestation?" Using LoRa radio layer you can make great things with other protocols, see http://www.waziup.eu/ as an example building network with SX127x devices and gateways only. But not LoraWAN.
A small patch has just been released under v1.0.2. It contains some fixes that will help pytrack/pysense users, for example when the board goes into sleep. The serial will now handle a loss and recovery of the serial port when the board goes to sleep.
Added timeout and reconnect logic on serial connection (useful for pysense/pytrack sleep)
Pysense/pytrack serialport detection
Bugfix related to project settings not refreshing (issue #23)
Ignoring hidden and empty subfolders during synchronize
Thanks for your help the other evening - I'm up and running now, though I'm no closer to being able to update the firmware myself.
For linux users I have a (useful?) bash script that beings up a console window and then waits up to 15s for me to plugin the device (that way I see any boot messages). I don't know if this will work on OSX as I don't have a Mac.
I need to update my blog post as I've recently modified the script to allows me to select the which serial device to connect to and baud rate to use.
Hi and thanks for taking the time.
Yes and no. WDT on the same silicon is a-maybe but I prefer an external WDT. Same for Brown Out Detection (BOD). I think WDT has only just now become available. Not sure on BOD.
Silicon latchup is something I had to deal with on older CPUs and we tackled that by down powering and indeed it was the only way. Typically this happened at about the 0.6 volt VCC level - despite a 90 day run time on batteries, users let the product go flat - but they were an old CPU without BOD or a good POR etc.
I am still of the opinion it would be nice to know what caused a crash. A queue of function calls that can be unraveled and then used to get an idea of where a crash happened. We do this in a legacy product and store it in I2C for later. We'll probably implement that for our application at least during debugging.
Thank you for your attention - Richard