End device behavior with airtime

Hello,
we may have a problem with the duty cycle or with the fair use policy.
Our devices keep blocking and don’t send any messages. We found out that we get the status CHANNEL_BLOCKED 0x0A from the module.

Is it correct that this is controlled by the provider, in our case by TTN? So TTN is blocking the end device?

It’s just the behavior of the devices that is incomprehensible.

We have registered three identical devices with the same FW with TTN. Two devices send a standard message every hour (consumed_airtime 0.071936s) and a few messages in between (max 10 in 24h, consumed_airtime=0.046336s) for events.

All messages are confirmed.

One device only sends the standard message every 24h and the events exactly like the other two (all devices are connected in parallel). This device blocks for hours due to the duty cycle, the other two continue to run. That is not logical. We do not believe that we have exceeded the airtime at all, especially not with the device that sends fewer messages.

We have also checked that our “host controller” is not sending any more messages in the background to the LoRa module.

Do you have any advice for us on how we can find out the reason for this blocking behavior or how we can make it deterministic?

Thank you very much

Channel blocked is not usually a duty cycle - it’s a misconfiguration of the channel setup for the region.

What is the device - without knowing this we have no way of knowing what the likely firmware is based on!

If you are sending confirmed uplinks (why do they have to be confirmed) every hour, then you are in breach of the FUP.

Suspending thread pending confirmation of adherence to FUP.

Hello,
Thank you for the quick reply.
The devices are our own development. We use the LoRaWAn module iM881A-XL from IMST GmbH with the firmware ProLink_V3.0_BC207.

Is the behavior due to the set regional parameters?

We are only sending so often for test purposes. These are alarm messages that only occur very rarely later.
The devices that send hourly are not blocked, only the device that sends once every 24 hours.
Thank you very much

grafik

Before getting into the weeds of your particular set up and problem please note:

Please confirm you will now follow FUP (Max 10 downlinks per day - and note we recommend - for the benefit of all community users - that this should really be thought of as 10 per week or per month or…!

Not an excuse. if every user sent heavily (and with confirmations) ‘as a test’ the network and spectrum would soon become unusable for all. Please send only when neccessary vs hammering the system - it will not respond well or get any better just 'cause you repeat (like banging head on a wall :slight_smile: ) A push to send button will work just as well…and in this case if it does work will help point to a set up problem and repetition issues?!

Please provide links to originating materials and sources vs expecting volunteers & contributors to go playing search games - its faster, more accurate and less frustrating for all…

Awaiting your FUP staus update…

OK, got it. We changed the messages to unconfirmed and ended the test.

Nope, a device behaves autonomously - it does receive a channel plan on join of the channels it can use and it doesn’t send a list and then say some are blocked.

As “CHANNEL_BLOCKED” doesn’t appear in the LoRaMAC-node source code you will be best served asking IMST for advice.

If you have any more questions, can you be a bit more expansive on things like “host controller”, what the application is and if you have any off the shelf devices that can verify your local gateway is behaving as expected.