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.
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
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)
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 ā¦
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.
JOIN.
Send a first UPLINK.
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.
Thanks.
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.
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.
