Class C end device downlinks

Dear Sirs,

I am starting a new project that needs some centralization diagnostics, and LoraWan fits, or I think so, our needs.

We are now in the Proof Of Concept stage, with a purchased GATEWAY that has been registered in TTN Community, and a end device of class C (own design), that has been registerd also as class c.

It is based on a ASR6501 LoraWanModule.

The end devices are going to send few uplinks per day (justa few bytes indicating they are working ok).

The question is that we need to send aldo some downlinks to the end device (maybe one per month, and also a few bytes, or perhaps some splitted frames if the are bigger than say for example 50 bytes).

We have registered our gateway and our end device in TTN and all works like a charm.

The only doubt I have is that if I schedule a downlink (only for testing now), I do not receive it until the end device uplinks some message, and as far i have understood this is not the expected behaviour for a class c device, that can recevice the message in any time.

The end device has been joined and sent some uplink messages prior to schedule the downlink.

I am missing somethings, or is it a TTN limitation?

Is important for us to explore all the possibilities because if the project goes on the fleet of end devices will be for more than 8000 units.

Thanks in advance for your help.

Ouch! What firmware / LoRaWAN stack / code base are you using for this?

But has it switched over to Class C mode once it has joined? The answer to what firmware you are using will clarify a great deal.

Then TTN is most definitely not the platform for you as you will be exceeding the notional limits on devices with your testing very quickly - you should look to using a TTI Discovery instance so you can seamlessly upgrade to a full commercial supported instance with an SLA - paging @rish1

1 Like

The stack version is 1.0.2.
It has switched to C class before Joining.

Thanks for your help.

And yes we are going to test in in TTI, but at this moment we get some undefined error on the web page when registering

Stack version is not specification version. A (software) stack may support a specific specification version - possibly several. Here I think Nick is looking for the firmware version/library (source please)

The ASR6501 is running

software version V1.2.0

(Retrieved with the AT+CGMR command)

For trying to get the DOWNLINK we are using

Version of what - where did you get the code that you compiled for your device from - GitHub, vendor, Father Christmas? What is the name of the folder/directory that it came in.

Where in what code?

AFAIK, you join then switch to Class C …

“The web page” - which web page? TTS errors are very specific so not seen an undefined one …

Sorry if I have not explained me.

The software version is the version that the ASR601 Lorawan Module reports when you inquiry it with the GCGMR command.

The firmware that runs the end device is our OWN FIRMWARE and OWN HARDWARE, sending the AT COMMANDS to the ASR6501 MODULE.

The web page for registering in the things industries is giving us an error, so we are using the things community.

I will try to first JOIN and then swith to C class, but i dont see any sense on doing it.


Maybe because that’s how it works???

So you aren’t running a LoRaWAN MAC on your MCU but you are using the ASR6501 module.

So if your firmware has a name, like Zebedee, because that’s what you call it in the office, what is the name of the code that is running on the ASR6501. Or if you don’t know, where did you get the ASR6501 - like a web link, so we can see what LoRaWAN MAC you are running.

That’s a really really old version to be using for a new product. v1.0.3 is considered old but current. v1.0.4 is ‘up to date’ - we are on the cusp of using v1.1 in the next year or so …

As to the error message, contact the TTI office direct as that’s the onboarding site, not TTS.

As per definition, ASR6501 has all the STACK of LORAWAN inside.
No we are not running any LoraMAC in our CPU.
We are just running the firmware that drives the AT COMMANDS to the ASr6501.
Purchased here.

As per JOINING and then switching to class C because you say that it because it how works, I paste from the DOCUMENTATION of setting class device from ASR :
5.2.16 Set/Read Class +CCLASS
It need be set before the “Join” procedure, the default class is ClassA.

you can find it here, page 16

Also tried with v1.0.4

SAme Behaviour.

  1. JOIN.
  2. Send a first UPLINK.
  3. Schedule a DOWNLINK.
    The Class C Device only gets a downlink iwhen you send a new UPLINK.

As per your responses, nice to finally have enough information.

As per M5 Stack link, LoRaWAN version is stated to be v1.0.1

As per comments above, you’ll need to ascertain how the firmware is working.

Perhaps the vendor, M5, could supply you with the firmware that runs on the ASR6501 so you can see how the Class switch is implemented. Or even the how they go about keeping the receive window open.

But overall, using such an old version of LoRaWAN when there are other less expensive more up to date AT command modules around seems to be a dead-end.

This is not the final product, just a proof of concept.
So ASR6501 has not to be the final ChipSet we are going to use.
I will switch to TTI when the registering error disappears.
We have many others LoraWan Modules as final candidates, but if you can recommend one it will be much appreciated.

Others seen are AI_RA07, AI_RA08, Murata CMWX1ZZABZ, MURATA 1SJ, RFM6501, SEEEDUINO LoRa-E5.

AI_RA07 = Not correct frequency, you’d need the H version, older module
AI_RA08 = Ditto, has potential, is a rebadged RFM6601W
Murata CMWX1ZZABZ = the original gold standard of professional devices, now outdated
MURATA 1SJ = it’s replacement, with newer radio chipset
RFM6501 = Older version of RFM6601, ironically probably has better support
SEEEDUINO LoRa-E5. = Uses latest STM32WL chipset so well supported by ST, has it’s foibles.

There are plenty more modules around with varying levels of quality & support at various price points - both for NRE &/or unit cost. Without knowing what your application is & what risk levels for hardware you are prepared to accept, it’s a bit hard to know what to suggest.

1 Like

If the downlink is still available for a class A window, I would check that the device is registered correctly.
A class c device that has joined and sent at least one uplink would not have a packet waiting in the queue.

Gateway logs and UI traces would show when downlinks are sent to the GW.