Well, yes, but only because that’s how the concentrator works anyway.
Good side step of the other question about payload size, makes it hard to offer ideas!
I’ll add another, can you update the devices firmware?
1 Like
Maybe we should make consultancy a payed option on the forum unless at least people do provide all relevant information needed…
1 Like
Or a refundable deposit with a standard deduction per missing answer (which can be “I don’t know” or “I’m not allowed to say”).
We’ll make millions!
1 Like
It has been hard since TTN stopped funding the necessary maintenance on our crystal balls.
2 Likes
Theoretically 1000 nodes sending one 50 byte DR5 packet perfectly time-synchronized over 8 channels. Takes 12.5 seconds.
1000 nodes sending each assigned one 3.6 sec tx window can tx in one hour.
Reduce by factor of 8 using sync’d psuedo random channel assignment to 7.5 minutes using same 3.6sec window. Rotate through channel list with assigned starting position.
Reduce 3.6sec window to 1 second for completion in 2 minutes.
However this will near 100% utilization and not be friendly to others wanting to use the ISM band.
But 1000 nodes sending blindly into the ether for 2 hours appears to present room to compromise.
Local regulation may prohibit transmitter cooperation and LoRaWAN is traditionally an ALOHA protocol.
See page 25, FDMA and TDMA
Nice outline, but without @dovov giving us the payload size and, to try to factor in SF/DR, a rough geographical spread, it is indeed theoretically.
If half the nodes need to run at DR4 and 100 of them run at DR3, the calculations get stupid messy.
I’ve no doubt I could come up with a scheme for some scenarios, trouble is I can’t think of one that has 1,000 nodes on mains power that only runs for 2 hours so it’s not just theoretical, for me it’s academic.
I have this picture in my head of someone running round a site plugging in 1,000 nodes, using the big on switch on the site power, recovering and then 2 hours later running round retrieving the nodes!
Nice ‘theroretical’ back of envelope paper analysis but sadly nothing like what happens in a realworld deployment! 
A few spanners in the works off top of head:
In a class A node deployment its never going to happen - clock drift from the nodes (assuming ABP to limit loss of capacity from GW due to join process, MAC commands etc.) means they will gradually drift away from each other over time in the field and discipline will be lost and conflicts will start to happen
A class B deployment (using GW beacons to correct/reset timing) might help discipline, but improbably deployment and few TTN deployed GWs can support class B, some support class C. As nodes appear to be mains powered that might be an option?
-
Most probably nodes will be distributed over varying distances away from GW and so 1 fixed DR not realistic, and even if theoretically at suitable distances real world issues - reflections, absorbers, building clutter, walking sacks of salt-water, moving vehicles, topology, etc. will purturb RF propogation and actual useable reception at both ends of the link
-
One of the characteristics of LoRa (and LoRaWAN) is that overall spectrum and GW capacity is best utilised when running with an idealised model of distributions of channels and particularly DR’s for a given GW (think of area around a GW as like an archery target or dart board with GW at the bullseye- and that idealised model will vary by node configuration and external factors out of your control (*such as). GW’s never run with idealised capacity
4*) Other nodes in range of your GW will also be transmitting, potentially cause uncontrolled conflicts/collisions, even with the resiliance of LoRa modulation
5*) Other nodes in the area may be initiating or recipients of GW downlinks - Join processes, ADR updates, MAC command, esp for mis-behaving nodes outside your control, commanded downlinks, etc. all of which will turn the GW deaf to your nice scheduled TX’s and wiping out timeslots.
6*) Given enough other nodes in the area and even allowing for you limiting the need for DL’s for your own use, there is a severe risk that in higher traffic areas the GW may max out its duty cycle - whether for RX1 responses on same channel & DR as TX nodes (generally 1% limit where applicable) or even the higher duty cycle RX2 window (10% on TTN where applicable)
7*) Rogue/badly behaved nodes can really bugger things up in line with above!
8*) Even if network appears to settle into a reasonable near steady state (though less performant than your ideal by definition), it can still be further purturbed and upset by transitory nodes passing through your area for a period from which the system will then have to recover back to prior steady stable state - think cold chain/logistics/asset tracking type nodes passing by your GW - especially if they are hving to do a rejoin due to a link loss and all rejoin close to your GW forcing it to send downlinks. See that regularly with trains/rolling stock and cargo coming through some areas. Also a common sight with road freight truck rolls.
9*) How resiliant is system/application to packet loss? Across my GW and node estate - atleast what I have bothered to monitor at various times - I see typicall 0.1 - 1.5% loss, though some deployemnts can peak out at 2-3%, TTI suggest you should actually model for up to 10% packet loss! (due to some of the issues flagged above, but also due to external RF phenomenen and interferers, plus what about packets received ok by GW but then subsequently lost over backhaul/the internet on route to the LNS back end!) How do the numbers look if you start to model for such losses?
Of course none of this reflects some mode of operation where 1000 devices come on together and then run for just 1-2hrs…per my original post I know from experience that there will be some nodes (possibly many!) that will never get to send a received useful payload during the operating window - even if able to join! (they may send but GW and hence back end may never see…). Densifying the network with many more GW’s is the only hope for this…
There are some legitimate use cases that might fall in scope but unlikely to use this model and more likely will stay live for much longer, and which likely will retain state and then not have to rejoin once they have joined - I’m thinking e.g. wide area street lighting deployments after 1st switch on etc…but they use lots of GW’s and ‘bring up’ by the dozen or a couple of hundred at most if they want quick reliable 1st start up - they have learnt the hard way not to do it by the 1,000 off! Some years back I saw a potential application using hundreds, and potentially thousands, but again with several GW’s to monitor a very wide area - for microclimate monitoring and path evaluation and personnel/asset tracking & monitoring in forest fire management - you need as many sensors as poss as quickly as poss…but they used other mechanisms to manage start up vs a big bang.
I am still curious, even despite the total lack of information.
If you were planning for a situation where suddenly you want 1000 nodes to connect, and presumably pass on some information (another guess), shirly you would design the system so that exactly this did not happen in the first place ?
The challenge being that if using ABP they need to use a lower DR / higher SF for the initial connection to be sure, depending on their location to get a message through - which means the first few uplinks will be largely lost.
In the long term, no.
But the OP described a situation where power is restored to a bunch of nodes all at the same time.
Without intentional randomization, with such a common trigger they’re all going to transmit a the same time, too, assuming they’re all running the same firmware - divergeance would only happen over time, and with LoRaWAN packet durations could take a while to naturally de-conflict. And probably with the same spreading factor. So the only diversity is <=8 channels to hopefully randomly pick from - assuming that even that spec required randomness actually works.
Normally, channel activity detection could help some, but when things are as synchronous as they could readily be for the first transmission after a common trigger without any intentional randomness, it won’t - channel activity only works if one party started using a channel enough advance that another can notice that, before also trying to use that channel - it fails in the case of actually simultaneous start as you’d have with the same firmware on multiple copies of the same hardware triggered by the same power restoration.
Needless to say, in addition to some random holdoff uniquely needed by this particular application, the base fact remains that all LoRaWAN nodes subject to frequent power failure must remember session details and continue forward from their past history, without trying to do a new OTAA join or illicit reset of ABP counters each time they get power again.
Given that lack of information, the activity in this thread is surprisingly high.
Hello guys,
Thanks for your replies, I am sorry that I didn’t give all information needed to suggest best.
Here is application:
In a village, I am doing some sensor measurement and power monitoring for about 1000 farms. Here In village, farms get 2 hours electricity in a day at same time.
Payload Length: 37 bytes.
Upload Interval : 1 Min. (No dutycycle limit for IN865).
ADR Enabled.
And use ABP.
Thank You
Thanks for the information.
1000 farms, suggests a big area.
What are the distances between Gateway and farms ?
I will arrange gateway and node in such a way that distance between any node and any Gateway would be max 4km. So will use 5- 10 gateway. Total area of 1000 farms would be around 20KM radius area.
What is the topology like…will you have good LOS for all nodes/GW’s?
This is exactly the sort of situation where you need to both make sure that your nodes are properly maintaining all LoRAWAN state across power loss, and to modify their firmware with a random delay before the first transmission after it is restored.
However, have you considered battery power? Most LoRaWAN nodes are entirely battery powered, yours would only need a battery that could retain state and make infrequent monitoring transmissions for 22 hours and then be recharged in 2 - compared to most LoRaWAN nodes that must run for months to years on battery.
Though having the nodes operating may not help much if the gateway is not - battery / solar gateways are harder but not impossible, especially with a couple of hours of mains power to top things off each day. Gateways that appear and disappear regularly should really only be deployed on private networks though, as they deeply confuse the TTN servers’ attempt to apply ADR to other people’s nodes.
1 Like
What is you end goal?
Meter reading?
Switching the power on / off?
Verifying if the power were turned on for 2 hours?
1 Like
If you use a pseudo random delay as opposed to a random delay it is easier to debug other issues. You can achieve this randomization pretty easily. 1000 nodes means you need 10 bits (1024) discrete points. if you are using a CPU, such as a SAMD21, you can use its serial number as part of the key. If it has a LoRa radio which has an EUI then this gives you another source.
I’d build in some updatable parameters so that I can adjust timings as the results come in.
The algorithm would be based partly on which gateway(s) it is in range of and its typical SF that it uses.
But most of all I’d do as suggested above, have a backup battery in place that can run devices for a decent number of weeks, charge from the the mains when it is on and because it is charging, it knows it is time to send information.
This would have the added bonus of being able to collect data all the time and aggregate it so you can get a spread of readings from outside normal hours.
@dovov, if it can go 22 hours off, what needs sending every minute for these two hours?
And what is the format of the 37 bytes, can it optimised?
all as mentioned have some control over billing paid using power on/off by relay and contactor.
sending logs of device each minute for monitoring critical parameter of system, system also have some sensors, actuators, etc.
battery backup can’t be done as device require nearly 800mA to operate. which also add cost too.
for timekeeping it have rtc, so battery backup not needed.
32 byte is most I can optimize, further seems not to be possible.