Hello,
I have a LoRa development board (SeeedStudio LoRa-E5 mini) running STM32WL 1.1.0 and having issues get it going with ChirpStack (v3.17). It joins Chirp Server and send two packets in predetermined intervals. After that no packets are sent from LoRa-E5 mini. However, with same firmware, LoRa-E5 works well with TTN. I am attaching here few screenshots. Not sure what’s the issue. I tried all available option in Chirp server especially under device profile, but no luck. Any suggestions would be really appreciate.
Hi Guys,
I am going to add one more screenshot here. It has more details about the downlink packets …
As I said, E5-mini stop sending after 2 packets. Here is the log from Mikrotik gateway. Device is configured as 1.0.3 revision B.
Maybe you did misconfigure the channel-plan in ChirpStack or your gateway? I can’t see what is being sent to your device, but potentially ChirpStack is setting the wrong channel-plan in the first downlink, then your device acknowledges (second uplink) and starts using the wrong channel-mask?
Hi Brocaar,
Thank you very much for getting back to me. To make sure, that there is no issue with the Chirpstack installation, I did a fresh installation on Ubuntu 18.04. However, the issue still persists. I checked the channel plan and it seems to be ok in both chirpstack-network-server.toml and under application server Gateway-profile settings (enabled_uplink_channels=[8, 9, 10, 11, 12, 13, 14, 15, 65]). However, I found a critical hint while debugging and you might be able to figure out the issue based on that. What happen is, when I debug the LoRa-E5 node using STMCubeIDE, and go step at a time during the transmission process, Chirpstack is able to receive packets properly. I feel that this is something to do with some timing issue such as acknowledgeTime, DutyCycleWaitTime, dwellingTime and so on. I can see that some of those settings can be changed in network-server.toml, but not sure which settings I have to adjust. Can you please suggest something to test further ? And FYI, I have a few LoRaWAN nodes from other Manufacturers, and they work with Chirpstack server and Mikrotik gateway flawlessly.
Thanks
It’s possible your node is being confused by MAC commands sent down, it would really help if you could expand the fOpts field from the downlinks to show the actual hex contents.
But even if it is triggered by MAC commands, it sound more like a bug in how the node’s firmware responds to them.
You may want to add some debug output to the node firmware so that you can see what it is trying to do, particular print out the frequency and spreading factor any time the node gets ready to transmit.
Hi Chris,
Thanks for getting back to me. Here I am attaching 2 screenshots containing fOpts field of downlink packet 1 and downlink packet 2. I will also try to get more info from node end, about how it processes the downlink info. Thanks for your help.
As far as I can tell, the downlink MAC commands configure the 2nd sub-band, fairly standard for US915 and similar though not clear what you are actually using.
I think you’re going to need to put some effort into debugging the internal state / logic of your problem and figure out why it isn’t transmitting (or trying to?)
Thanks Chris, Yes I am using US915 sub2. I compared the behaviour of uplink packets between TTN and ChirpStack. I noticed that with TTN, first packet sends with SF10BW125 and the rest uses SF7BW125. However, ChirpStack continuing to send on SF10BW125. Could this be due to an ADR negotiation issue ?
No, in one of those downlinks Chirpstack told it to use datarate 0 (which in US915 is SF10BW125) so it’s doing exactly what it was told.
The algorithm may want to see more uplinks before changing things, though yes, RSSI -56 and SNR 11 would justify something faster.
Thanks Chris for the input. I disabled the ADR in both ChirpStack and LoRa E5 settings. Now it works well and ChirpStack has received more than 3000 packets in last 24 hours without a single loss. So we can assume that problem is something to do with ADR negotiation between ChirpStack and STM32WL software. I know that ChirpStack can use a different ADR algorithm, using a plugin. May be I will look into that. In the meantime I have to work with disabled ADR, which may not be the best option. Thanks for your help again …
And how long did you let it run in ADR mode? Essentially, you didn’t, because it only managed two packets before the node firmware hung, so the ADR algorithm never really got a chance to do anything.
No, you’ve given absolutely no evidence of a failure in ADR “negotiation”. In fact you’ve demonstrated the opposite - the node doing exactly what it was intrstructed to do via the ADR aspects of the MAC command traffic you capture.
The question would be what sorts of ADR commands are sent long term and if there’s any failure to follow an ADR command to a higher rate, if one is actually issued.
But first you have to debug why the node firmware is hanging.
Hello Chris, I see your point. I am not blaming the ChirpStack implementation of the ADR. As you said, I have to debug the node firmware to see why it is not properly responding to the second downlink message. What I noticed that gateway doesn’t receive anything after the second downlink packet, so unable to monitor the ADR commands for long term. I am going to debug the node firmware to see whether I can figure something out. If I find something, I will post it here. Thanks for your help.