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.