Class-C end node not working

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?

Thanks in advance

For Chirpstack v4, I believe that there is presently a bug when it comes to LoRaWAN 1.0 Class C nodes in ABP mode: Unable to enable class C in pre-activated/ABP device · Issue #291 · chirpstack/chirpstack · GitHub

I attempted to solve that with this, but my testing is very limited: Fix device activation not setting the device class for LoRaWAN 1.0 by sp193 · Pull Request #344 · chirpstack/chirpstack · GitHub

In class A, a node will only receive downlink right after an uplink.
This is LoRaWAN specs.

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?

Yes, you’re rigth and I know that. My device is not a Class A. It is Class C and Chirpstack is treating it as it is a Class A.

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.
1 Like

Have you checked the logs?

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?

Hope this helps.

In my opinion, OTAA or ABP should not be relevant. They are ways to join the network only.
OTAA should be preferred over ABP.

For current implemetation of Chirpstack, I believe we need to send one uplink in Class C.
Then after that, you can send any downlinks anytime.

I remember there was a fix to push uplink before sending a first uplink in ChirpStack.

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.

@Hillermann_Lima This is a Docker image of what I’ve been working on. So if you would like to help me confirm/deny whether the patch helps, do try this version out and let us know: Download chirpstack_460-1231.tar.gz from - send big files the easy way

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.

1 Like

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.

Thanks. I’ll download and test it tomorrow. Hope it works.

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.

Sorry about my english.

I could not test this. I don’t know how to install this in my PC running windows. Sorry about that.

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.

Done. And now? What should I do? Sorry about my lack of knowledge.

This is the main screen of my docker

How to make sure I’m running with your modifications?

Hi. I’m guessing that you used the docker-compose file from chirpstack-docker?

Edit docker-compose.yml, changing this part:

    image: chirpstack/chirpstack:4

…to look like this:

    image: chirpstack/chirpstack:4.6.0-20231231

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.