In my case I have gateway mounted on a vehicle which travels over specific road to collect data from nodes. My problem is how to choose a proper algorithm that the nodes to be able to speed as much as possible to save battery and in the same to be able to send their data when the while is in reach.
Any suggestion for effective way of doing this ?
( if I leave the nodes in just listening and send a “beam” signal from the gateway periodically to invite the nodes tos edn data - the energy consumption is still big - eg. the node cannot last 2 years with 2 x AAA batteries… need A LOT MORE)
Sounds like a distorted use case for a LoRaWAN deployment and that you perhaps need to read up on ‘normal’ use cases and specifically around node behaviour and class A, B, & C operation. Without something to trigger the nodes they wont know to send and will either be sending on an alarm/predetermined condition or on a pre-programmed timeschedule (which may or may not match with the time of your passing vehicle). In class A the node will only listen for a trigger (your beam signal) in the RX1 or RX2 window after their own TX, which is a chicken and egg problem based on above. Also a given node may or may not be received depending on the range and any clutter intervening between the node and GW and that in turn will be dependent on the TX conditions of the node (power & SF) - higher on either count and you will start to run down battery, lower on either count and you compromise GW ability to hear the node. A static node is usually ‘optimised’ by using ADR - which will train to other GW’s (fixed!) in the area if available, and may evolve to run too short SF and too low TX power if another GW close by (out of your control immediately or at some point in the future as mode GW’s are deployed) and much closer than your mobie vehicle GW so may never get heard. The brief interaction with your mobile GW as it passes will unlikely be enough to cause the node to step up its ADR settings. If you dont use ADR and ‘fix’ on a SF then you move away from LoRaWAN compliance, esp if also fixing channels etc. Class B and Class C offer different operating modes including ability to listen when not in Tx mode, listen on a beaconed timescale etc…but that is not battery friendly and usually associated with powered nodes or nodes where there is regular power top-up (e.g. solar powered/backed up).
What you are describing is more commony associated with e.g. drive by utility meter reading and the players in that market have to adapt and adopt alternate mechanisms to allow use of LoRaWAN. Mobile GW’s are a thing, though some forumites protest or object or claim they are not possible/practical, (on ships and railway truck/carriage convoys etc), but usually to support monitoring of fellow traveller nodes (e.g ship cargo or equipment or nodes on the train rolling stock etc.), not monitoring passed fixed locations. LoRa point to point or point to multipoint and using proprietary implementations may be more suited to what you want to do but that will require you to do you own development or license a solution in and is outside scope of TTN (as TTN is LoRaWAN based) & this forum.
Any suggestion for what to read regarding algorithm " LoRa point to point or point to multipoint and using proprietary implementations" that can solve my problem ? e/g/ any example how “drive by utility meter reading” works ?
Ask much as I can understand the ADR will lower energy use in the LoRa but still will consume a lot of energy compare to full sleeping mode cannot and get the node work for years. Also ADR si designed for static gateways and nodes e.g. with moving gateway the chance of missing a report with ADR will be extremally high
It seems that if you could narrow the window the nodes will “listen”, and operate as Class C during that time, you might be able to make it work. (What is power draw for class C operation for 1 or 2 hours per day? or 2 hours 3 days a week?). Any chance of a few square inches of solar on the nodes?
Class B would be useful to you, but not the complete solution. The “moving gateway” problem is a whole other level of complexity given that LoRaWAN is an ALOHA network.
Why not do it properly and install gateways where they’re needed?
It seems that if you could narrow the window the nodes will “listen”
If the node for instance only listens for 1 second in every minute, it means that the ‘Gateway’ would need to be sending out perhaps 120 wake ups every minute. That does not sound very TTN friendly.
And the nodes battery, even though it is only one for about 1 second in every 60, would still only last 6 months or so.
Any chance of a few square inches of solar on the nodes?
Why not go the whole hog and have a solar panel that is big enough to keep the node in RX mode all the time ?