Is there a way to fully disable sleep so the board is always awake, listening, and broadcasting every 5 seconds? Or what’s the limit on that for each channel, and why?
And is there a way to modify how often the GPS coordinates are sent out to each node and also make sure that every node is constantly listening?
I saw something in another thread stating that LoRa radio is always listening and acts as an interrupt and then wakes up the device if it receives anything.
I’m still trying to wrap my head around the bandwidth/channels/etc. From what I’m seeing it may not be possible to transmit that frequently because of the available bandwidth on the LongSlow channel?
Someone correct me if I’m wrong and if you can provide a little more explanation on that.
If necessary, I’m not afraid to dig into the code. I have some experience in that, just need to be pointed in the right direction.
What exactly are you trying to do? The Lora radio is always listening and will wake up the sleeping CPU on a device if a packet comes in. The LongSlow channel can maybe handle a message every 30 seconds, 60 is recommended. You can try it out yourself with the range test plugin Range test plugin | Meshtastic.
As Garth mentioned, the network is constantly updating in the background, but hitting it too frequently with additional broadcasts will create a backlog when using LongSlow. If you’re expecting to stay within close-ish proximity to each other (and take into account hilly terrain), you may want to experiment with some of the intermediate radio settings to get a faster throughput.
You can use the meshtastic command line interface to set a few of the position related timings. These are the ones I always adjust for our very hilly environment and poor gps antennas:
gps_update_interval (how often the gps position will be refreshed, in secs)
gps_attempt_time (how long to wait to get a gps fix. if you have a device that battles to get a gps fix, consider pushing this up to around 600 secs)
position_broadcast_secs (how often to send out the background position broadcast message, with your gps location, in secs. Consider the impact on the mesh if using LongSlow)
wait_bluetooth_secs (keeps bluetooth alive after a position broadcast, to give phone app time to update gps positions, in secs)
So, for example, I usually set mine up with the following command:
Avron has given a good answer, but there are so many variables in the network, no of devices, range, channels, LoRa bandwidth that you will need to do some trial and error. However I would say that almost everything is configurable, and you don’t need to dive into the code.
Meshtastic is designed and built around two major constraints, LoRa (range, bandwidth) and battery life, and assumes that the main applications of Meshtastic are in situations where you cannot use a faster network (3G, 4G).
In your case, devices in vehicles usually have power, so you may be able to use ShortFast and the above settings, and then see what constraints you hit. We don’t have great tools today that let you see what is happening on the mesh network, but make use of the Debug Panel in the app to get an idea.
That parameter gps_attempt_time just makes the unit more forgiving for how long it wait for a gps update (gps fix) to take before giving up, every time it does a gps update (gps_update_interval). If you have the standard little ceramic gps antennas, you may have found some of those sometimes take a long tome to get any gps sats, so this will buy them more time to get that fix.
So, the unit will look to update its gps location data, every gps_update_interval seconds. The
gps updates will be sent out every position_broadcast_secs, with either the actual gps location, or an empty location if no gps fix was achieved. To make achieving the gps fix a bit more forgiving, you can allow the gps a longer attempt time before giving up, using gps_attempt_time.