Issue:
script performs and parse lorawan Data received by MQTT Integration, and do downlink if require. As Device is in Class A, need to send downlink command to chirpstack as soon as get uplink,
But issue is when script fetch data to downlink from a remote sql Server it takes some times, and then script perform send downlink by MQTT to chirpstack, but downlink doesn’t performed due to delay in sending downlink message, and so it will remains in queue of chirpstack, and will be send on next uplink. there is nothing can be done in script side to send downlink faster to chirpstack for now.
Downlink is needed to reached to device when request made, not in next uplink.
So, I though use device in class C when doing uplink and and wait for command for 6 seconds and switch back to class A, for power saving.
TTN does not allow you to switch a device to a different node at runtime. It requires you specify the device class when adding it to the stack. So even if it would be legal, it is not an option in TTN.
Apart from the “wrong forum” issue, you are trying to fix the problem by breaking something else rather than fixing the actual issue of the slow database / processing script.
Although with a good understanding of LoRaWAN protocols, there is an obvious solution for users on TTN …
Sorry for wrong forum mistake. I mean to find solution asap. I am testing TTN and Chirpstack both, to find compare both. nd this issue is also related to TTN.
I mean that Set Device in Class C in TTN, and on device side use Class C for 6 seconds when uplink done.
Testing two LNS’s to step around the compliance to resolve an entirely different problem is only likely to make the situation worse.
And you’ve been told there is no mechanism to change the class of a device on demand - it’s set when you create it. So there is no solution in this regard
Why can’t you resolve the slow database / script issue?
Is this the 1,000 nodes transmitting at the same time with the really poor SNR from the only antenna you’ve tried project?
Testing two LNS’s is to make best choice, to perform all functionality needed in product.
database side can be made faster, but want to make solution for worst case scenario.
Yes 1000 node with poor SNR is my current status of project.
Functionality of your product does not depend on LNS. All LoRaWAN compliant LNSes have the same limitations when talking to nodes. The major difference between offerings is how your application connects to the LNS but that is a minor part of the chain.
Your node firmware and your backend application determine functionality of the product.
Your hardware and deployment determine the RF quality. If not good enough for certain nodes, assuming the nodes have descend antennas and RF circuit, you need to either move a gateway or add one.
Consequently you are adding extra work & variables in to the mix when, as there is a blindly obvious solution, there is more of the basics for you to get to.
And you are evaluating two stacks to see how they can be bent to make your solution work when the actual problem is with your database script. Plus the concurrent tx challenge and the pitiful SNR.
You’ve been told clearly that there is no functionality to switch class of device on the fly, so this thread is getting a bit pointless.
If you are going to evaluate things, I’d evaluate antenna’s to sort out the SNR, I’d look at my database script and I’d scroll to the top to hit up the Learn menu item and really get to know the LoRaWAN transmission cycle.