LoRaWAN low level debug messages

[woodpecker]

I’m trying to debug LoRaWAN join / send operations to a commercial provider but don’t have any feedback on what’s happening. I was able to join the network exactly once (as reported by the server) but not repeat this.

Is there any way to turn on low-level debug messages to see when join attempts are made, raw received packets / errors, etc? Not sure how to proceed without feedback.

Thanks,
Adam

[mk]

I second this!

I've just spent all day trying to connect to a commercial LoraWAN in New Zealand, apparently the join is successful (lora.has_joined() is True), but the lora.stats() almost all seem to be zero

rx_timestamp=0, rssi=0, snr=0.0, sfrx=0, sftx=0, tx_trials=0, tx_power=0, tx_time_on_air=1647, tx_counter=0, tx_frequency=0

I've gone through post after post looking for a way to scan for available LoraWAN's and see their signal strength (is this not possible? I've found nothing) or any other way to confirm what is actually happening.

[mfalkvidd]

@mk there is no way to scan for available LoRaWANs. LoRaWAN gateways do not broadcast anything, so there is nothing to scan for.

[woodpecker]

@mfalkvidd
What about logging or status of my own LoPy4’s behavior, such as join attempts, raw tx packets, tx parameters (channel, dr), and raw / partial rx packets?

When I was testing in LoRa raw mode, I saw frames that weren’t mine so I know there is traffic “out there”.

I’m basically trying to understand if there is way to query low level status or if I would need to try to add debug messages (e.g., to modules such as https://github.com/pycom/pycom-micropython-sigfox/blob/master/esp32/mods/modlora.c)

Thanks,
Adam

[jcaron]

@woodpecker it’s been a while, but IIRC I ended up adding my own log messages in the source to get the info I wanted.

Be careful not to add them in parts of the code that are called in interrupt handlers, though, that ends up pretty badly (there may be safe calls for that, though, but definitely not a regular printf).

[mfalkvidd]

@woodpecker sorry, I don’t know

[mk]

@woodpecker after getting past my first problem (poor coverage in my area for the LoraWAN network, solved by simply taking the device to a new location - not actually diagnosed from code), I was seeing the same thing as you - one packet received, others not working properly.

I got this reply from the LoraWAN provider (which I haven't yet figured out what I need to do about it) but it might be the same thing that's happening for you:

Your device is not incrementing uplink sequence numbers for every data transmission. The network has got data but each time the transmission had the same sequence number, 0. So it acknowledges it (which is what you see in the web page with downlink sequence numbers increasing) but doesn't show anything as it treats it as a repeated, old transmission. If you fix that, should work OK.

[jcaron]

@mk are you using deep sleep? If you do, do you correctly save and restore LoRa state?

[mk]

@jcaron no, not using deep sleep yet. Just have a fairly basic main.py, sending one packet as per the examples, and I either run it by uploading it to the LoPy and just keep pressing the reset button, or I've been using the "Run" command provided by the Pymakr extension in VS Code. I've been getting some weird results though and I'm starting to wonder if I shouldn't just be re-running the whole main.py every time I want to re-test.

Sorry, didn't mean to hijack this thread.

[jcaron]

@mk IIRC a reset will have the same effect as deep sleep, resetting LoRaWAN counters and other state. Unless you join every time you reset, you need to save and restore state.