CLASS-C behaves exactly like CLASS-A

Hello.
When I send a Downlink to a Device in Class-C instead of sending the downlink immediately to my device, it is queued and only goes to the device in the downlink window similar to Class-A.
Am I doing something wrong or is there a problem with Class-C’s routines?
Has anyone ever experienced something like this?

You may be experiencing this:

It has been merged but not yet part of a release.

bcomway, thank you very much for your prompt response.
Is there any prediction on which release this will be implemented in?

Since it’s already merged, it should be in the next one. I have no idea on the time frame for that, only @brocaar would know.

You could run the master branch in the short term, if this is a showstopper for you.

Yes i’ll
Once again, thank you very much for your help.
It really helped me a lot

There is one more item that I’m working on (Store device-sessions in database to simplify backups and disaster-recovery · Issue #74 · chirpstack/chirpstack · GitHub), before I will create a new release :slight_smile: I don’t expect it will take very long before a first test-release will be available.

2 Likes

I thank you, brocaeer, because I really need this correction and unfortunately I was unable to compile the new code on my machine.
Thanks for your attention

Is this happening in recent ChirpStack version?

In my ChirpStack v4, I only need to wait for the Class C node to send a first uplink, then after that, downlinks will be sent down to the Class C node instantly.

Om seeing rhe same thing - but I’m a bit confused by this comment in the fix - I see the issue for devices that have been through a join.

“This happens if the device was activated without going through the join procedure, whereby join.js sets the device mode for LoRaWAN 1.0 devices”