@mxklt said in Firmware Release v1.20.2.r2:
I get an error when i try to use machine.pygate_reset() -> LORAPF_ERROR:pygate_reset failed to reset
Pycom MicroPython 1.20.2.r2 [v1.11-3a7776d] on 2020-11-23; GPy with ESP32
Please update the Pygate FW and try again: https://docs.pycom.io/updatefirmware/expansionboard/
I've created a simple project : I want to measure my water consumption. The water meter provides me with a pulse output, so it's easy to integrate with an MCU (a LOPY board, in my case).
As the water meter is out of reach of my wifi network, I wrote a small micropython script that counts the pulses and sends the total to another LOPY board using node to node raw Lora (based on this example : https://docs.pycom.io/tutorials/networks/lora/module-module/).
This 2nd Lopy forwards the message on MQTT via Wifi. The data is then processed by Home-assistant.
This prototype works as expected. I'm in the process on improving the proto (waterproof enclosure, battery, sleep mode,...).
My question here is about the Lora communication. For now, the sensor board just sends the number of pulses using raw lora (no protocole, formatting, encryption,...) and the receiver board just listens to lora and parses the messages it receives.
Is there a better way to do this? An existing protocole I could implement? Let's say I would like to send more data (temperature, uptime, battery level) and add more nodes, should I just improve my node 2 node protocole, or should I use a Lora Gateway? Join a Lora network like TTN?
What's the state of the art for a small network of Lora sensors?
@Miguel-Toscano-G All you have to do is start LTE and connect to the network. Once you have done that, you can run the nanogateway code as it is. I just tried that here with NB-IoT.
For connecting to the LTE service, follow the examples.
I answers my question by myself:
Until now, I haven't recognized rshell. I can do the job by using "esptool" and "rshell" from within a python script. So I can connect to the api of the LoRaWAN server to register the devices, creating the config.json an copying all the stuff into /flash.
@geraldm As discussed in another thread, it's difficult to combine the flexibility of a high-level language like (micro)python on a device with 2 fast cores, Wi-Fi, BLE, and more with the optimisation available when programming in C (or even assembler) on a controller optimised for very low power applications. Different MCUs have different power profiles, performance, RAM/flash capabilities, sleep modes, etc.
A LoPy is probably overkill for most LoRa applications where you just get a few bits of data from a sensor or two and send them over LoRaWAN (the small PIC on the Pysense or Pytrack is probably more than enough for that!). But it enables you to quickly prototype things, and if you need to, you can do a lot more with it than you can in simpler LoRa devices.
Note that 1.01 seconds cannot be a complete cycle for a LoRaWAN-compliant device (unless it always receives a response in RX1 from the network). It is a requirement for the device to be awake during both RX1 and RX2 unless it received a downlink in RX1. And RX1 is at least 1 second after end of transmission, and RX2 is always 1 second later. RX2 is also quite a bit longer as it needs to accommodate the slower data rate of SF12.
But yes, with a carefully chosen MCU and optimised firmware, you can get down to just over 2 seconds at the fastest data rates, with most of it actually spent sleeping!