Hi,
I would like to send frames from loraserver.io to my device (via API) as soon as possible. So I have changed default configuration:
deduplication_delay=“1ms”
get_downlink_data_delay=“1ms”
scheduler_interval=“1ms”
downlink_lock_duration=“1ms”
My program sends first frame and waits to ACK. Next checks post response “fCnt” with “fCnt” from ACK. If it maches then I send immediatly next frame. My problem is I can’t see on my device all frames I’m sending. Of course when I back to default config everything is correct, but sending for example 100 frames takes too many time. Do you have any solution or tip?
Hi,
I think it NECESSARY follow the specs for LoRaWAN, so the delays between one packet and another should be consistent with the specs.
In my case I have a similar problem, but for solve it I figure it out making several measurements from the sensor and then send it to the gateway. In the other way around you should use ADR to configure the frequency plan as good as possible and when you make a downlink probably you can make it with ACK or without it.
Probably if you make an unconfirmed downlink when the node receives, it can change something in the payload, like a flag or a state, then you can know in the GW side if the downlink has been delivered or don’t.
Check the LoRaWAN Regional Parameters to see the parameters you need.
Hope it can help to you. Good luck.
That’s not really consistent with the design of LoRaWan, at least not for class A devices.
The basic idea is that the network transmits to the node only in response to the node’s transmission, and only at a specific time called a receive window, which in most situations is one second after the end up the node’s uplink transmission.
If you try to send more downlink packets, they’ll just be dropped, because there’s no other agreed upon time when the node would be listening to receive them.
In theory there is a pending bit in the downlink frame which can request the node to send another uplink in reply to which more downlink data could be sent, you can see if that is effectively implemented all the way through.
Typically LoRaWan networks move more data in the uplink direction than the downlink direction. Exceptions tend to be special cases operating in modes other than class A, or multicast things like firmware updates.