Hello. This is my first post here. I know that other users have already posted about the same issue, but I’ve read several and still haven’t been able to solve my problem.
I’m using a Bluenrg-lp microcontroller with the SX1262 radio in the AU915 region in ABP mode, and the Semtech loramac-node stack.
I’m using ChirpStack V4, which I installed using Docker on Windows.
I’m using the Femto gateway wlrgfm-100.
I can send uplinks and receive downlinks from ChirpStack without any problem. I configured my end node as Class-C and did the same in the ChirpStack device profile.
The issue is that I only receive downlinks from ChirpStack if I send an uplink first, as if my device were Class A.
The gateway is configured to use channels 8 to 15 (AU915_1), just like the end node.
What should I do to figure out what’s happening? How can I determine if the issue is between ChirpStack and the gateway or between the gateway and the end node?
Yes. But if you’re using Class C, you should be able to send downlinks at any time. This isn’t working correctly if the LoRaWAN 1.0 device doesn’t go through a Join procedure, as Chirpstack only sets the device class (internally) for LoRaWAN 1.0 devices during the join procedure.
Thanks for your time to answer my post. I read the “Unable to enable class C in pre-activated/ABP device · Issue #291 · chirpstack/chirpstack · GitHub 1” and understand that it can be a bug. In my application I should use ABP instead of OTAA. What do you suggest me to do? Does Class C work with ABP activation n Chirpstack V3?
I do not know whether this bug was already there in Chirpstack v3.
Can you use OTAA mode instead? Unless you have a strong reason to use ABP, ABP mode does bring some disadvantages. Such as:
The session keys (NwkSKey, AppSKey) are fixed. These are normally randomly generated during the OTAA join procedure.
There were ambiguities in the LoRaWAN 1.0 specification in areas like what happens when power is removed and re-applied. Older devices may not retain the frame counter values between power-cycles, but it’s basically impossible to differentiate between a replay attack and a device booting up. If your device does this, it will be blocked from rejoining the network after a power-cycle.
Check the Gateway LoRa logs? While testing I had ChirpStack hosted on Docker through my Windows PC.
I had my LoRaWAN gateway set to ‘Private’ and the firewall would not allow the uplink to be sent to my ChirpStack. You may need to look at your firewall settings. In the end it was my local network connection on my PC being set to Public (windows 11 thing). I set the Gateway to Public and configured my PC firewall.
Also check the ChirpStack Logs to see what comms you’re getting there to see where it’s being held up?
You’re right that it should not matter, under normal circumstances.
But I believe that the code has a problem with class C devices in ABP mode, which only affect LoRaWAN 1.0. Such class C-styled downlinks just don’t work if the device doesn’t go through a join process, despite the UI indicating that you selected class C. Internally, the database still records the device as only supporting class A, which is what I tried to point out in the Github issue and eventually attempted to fix in a subsequent PR.
It is a development version between 4.6.0 and 4.7.0, with the 5x PRs that I’m trying to submit on Github.
There is an additional modification to use MQTTv3 because of my MQTT broker, but it probably should not make a difference.
You will probably have to re-activate the device, in order for the device class to be set.
I’ll try OTAA and see what happens. As I’m new in LoRaWAN and Semtech loramac-node stack, I’ll study witch changes I have do to in the end node firmware. As soon as I do this, I’ll post the results here. Thanks for yor time again.
Thanks for the reply. I’ll check the gateway and CS logs. I remember to have seen the gateway log and nothing happened when I put the downlink message in the QUEUE tab, as if the message never leave from LNS. I have checked the channels enabled in the gateway and they are the same expected by CS in AU915_1.
Before putting a downlink message in the QUEUE I’m always sending uplinks. When I send uplinks I always receive downlinks in RX1 or RX2.
In ABP activation method the is no need of a join procedure as the keys and device address are fixed in the end node. If there is a LoRaWAN gateway in range I can start sending messages any time without joininng the network.
Hi @sp193. I tried the OTAA instead ABP. The end node send the JoinRequest and receives the Join Accept. After that if I put a message into the ChirpStack QUEUE I can see it gets to my gateway (It does not happens when using ABP… maybe because of the bug you talked about). I know that the messa reached my gateway because of the logs, but the message is not getting my end node yet. Resuming: I receive the Join Accept from the Gateway but I don’t receive the messages I put in the QUEUE.
If you are certain that the gateway transmitted the frame, have you checked that you got the FPort number correct, as expected by your app? Depending on your code design, the FPort number may matter.
As for loading the Docker image, you can use:
docker load < theimage.tar.gz
It will print the image tag that the image is presently tagged with, after loading.
Re-apply docker-compose.yml. I’m not sure how you deployed it in the first place, so I cannot tell you. I normally use the command-line as Docker Desktop isn’t free for me to use, so I do:
docker-compose up -d
Please use the appropriate method to deploy the update.
