We’ve set the gps update to be a little on the slow side because it can rather quickly fill up the available bandwidth if updated too often but one of the more frequent questions around here is “How can I send the update of my gps position out to my mesh more frequently?”.
There’s a new option to enable:
position_broadcast_smart
If you set that to true and your device has moved at least 150 meters, a new position will be broadcast – up to once every 60 seconds based on the last time a position was sent out.
At an average walking speed of 5.5kph / 3.5mph, that’s an update about once every 90 seconds.
If you’re running / jogging / biking / driving that will update about once a minute but will then throttle down once you slow down.
Please still remember that updating the mesh this frequently does incur a cost at the long range settings, you’re better doing this sparingly and with the faster / shorter range settings.
Once you stop moving, the other settings will take effect and you will update the mesh with your position every 15 minutes (the existing default).
You’ll need at least Meshtastic Python 1.2.44 and Meshtastic Device 1.2.48!
This is a great idea - thanks a lot for implementing it so quickly in these regular updates.
As usual as soon as something new is out I wish for an additional setting! Maybe it’s already doable but I would like to lower the distance moved before a new position is broadcast. Maybe 50m? I always stick to the default channel LongSlow but I could change if needed as my rak4631 is not too demanding on my battery. Thanks again.
Long term I think the user and community friendly thing to do is adjust some of these parameters min / max settings based on the channel settings and perhaps more importantly have an internal counter that represents network congestion that can override frequent updates.
A lot of this stuff is great as is for small networks. If things start getting a bit more main stream users will start encountering issues and there may not be a central person that understands what is causing them and how to resolve.
Then there is the often overlooked duty cycle issues. I personally don’t think it is an issue right now but as the use of ISM bands increase the utility of those bands can be threated by too many bad actors…
Speaking of congestion, I’ve been trialing this new option and today my node has been sending position updates every 5 seconds, which I’m guessing is pretty much just maxing out the channel (ShortFast). I’m trying to work out the issue but thought I’d mention it
I do have positionBroadcastSecs set to 900, so it shouldn’t be that
One thing I did try was PositionPlugin.cpp:172. That number timeTravel is treated as milliseconds in the comparison. But changing it to 60 000 didn’t seem to help
Cool thanks. Sitting at my desk it isn’t spamming position messages now. I’ll take it out while I’m mowing the lawn in an hour or two and see how it goes. I’ll leave it running on my desk until then to keep an eye on it
Something we discussed in chat was to change the minimum interval for transmitting a packet based on the data rate of the network. That’ll come in a future update.
All good, thanks for helping out! Sitting on my desk with positionBroadcastSecs set to 900, I’m still getting a position packet every 60 seconds. an example:
05:42:14 122 [PositionPlugin] Sending smart pos@61ac5133:6 to mesh (wantReplies=0) (distance=7723096.500000) (time since last=60040)
I changed the debug msg call to
DEBUG_MSG("Sending smart pos@%x:6 to mesh (wantReplies=%d) (distance=%f) (time since last=%d)\n", node->position.pos_timestamp, requestReplies, distance, (now - lastGpsSend));
So it looks like its a problem with the distance calculation. My latI from the GPS is negative, lonI is positive.
This repeats every minute. I am plotting these reports in Traccar and while there is a little bit of spread (the node is inside, but with a big 25mmx25mm gps antenna), it’s not 150 metres, more like 50.
Hmm … the distance calculation method is used in two other areas of the device. Smart Position was working for two testers prior to release, but it sounds like this deserves some time on the bench.
We’re in different parts of the globe. Hmmm… Maybe that’s it.
Right after that latLongToMeter() call, I added this:
DEBUG_MSG("Calculated distance %f from: last lat %f last lon %f current lat %f current lon %f\n", distance, lastGpsLatitude*1e-7, lastGpsLongitude*1e-7, node->position.latitude_i*1e-7, node->position.longitude_i*1e-7);
Which produces this (decimal figures removed after the fact) :
07:05:28 92 [PositionPlugin] Calculated distance 7723092.000000 from: last lat 390.000000 last lon 175.000000 current lat -38.000000 current lon 175.000000
If I DEBUG_MSG without the *1e-7 factors, they come out correctly.
Found the problem:
PositionPlugin.h lines 17 and 18. Those lastGps*itude need to be int32_t to handle the negative. I’m getting reasonable distance figures now.
