The problem is when LMIC is used in the arduino way. Here the timing is made by busy waits, which is consuming power. LMIC is using the functions hal_checkTimer() to setup a timer for the next wakeup and hal_sleep() to put the CPU to low power mode when nothing needs to be done. This can be used to hook in some low power implementation (timer+cpu sleep).
Hmm, Helium (the largest lorawan network) managed to use 1second as default RX1_DELAY.
Have you ever met “GSM Latency”?
Guess the difference is Helium doesnt expect to use GSM…not with GW’s apparently consuming 40-60GB/Mo! 
@mrx23dot V2 used 1sec, and you can set in V3 if you must (some legacy devices had to use that as a fall bac if they could not be reprogrammed (in the field) during V2-V3 migration) - but you need to have regard for backhaul latency as Johan calls out - this was evidenced many time over during the life of V2…just dont complain if your node misses messages as processing loads are increasing over time and ‘the standard’ or perhaps better the ‘default’ per L-A and as used by many other LRaWAN networks is 5sec. Guess when you are running a full ledger you have to assume a decent bband/fibre connection for most of the route to GW, which allows you to assume a lower latency per Helium, which is LoRaWAN with a twist as you might say…
1 Like
From my part of the world I have seen often 800 up ms from the network the gateway is on to the NS.
So if you think that Mr H is going to handle this with real hotspots, good luck.
Do they care? Most hotspot^H^H^H^H^H^H^miner owners seem only interested in earning rewards, not lpwan, so as long as the mechanism that gets them paid works, it may not matter that the network fails to meet downlink windows.
Maybe by gateway count, from other evidence not even close by actual useful traffic.
And your point is?
Have you looked at Packet Broker and the very considerable benefits that brings?
Or the option to change it to suit your use case in the console?
1 Like