Default smartbeaconing parameters seem too agressive

[F4FXL]

Hi,

The default Smart Beaconing parameters are way to agressive and tend to generate excessive packet rates on mobile stations, saturating the network.

Smartbeaconing was meant to send packet outs when there is a sever change in direction which other station need to know about.

Here some comments on default parameters

			"smart_beacon": {
				"active": true,
				"slowRate": 120, //Fixed station are reocmmended to beacon every 10 minutes, standing mobiles do not need to beacon every 2 minutes
				"slowSpeed": 10,
				"fastRate": 60,
				"fastSpeed": 70,
				"minTxDist": 100, //if this distance is in meters, this can cause a mobile traveling at 80km/h to beacon every ~5s
				"minDeltaBeacon": 12, //this will mitigate the minTxDist Parameter, yet is too high. 
				"turnMinDeg": 10, //this is too low, a small turn on the road will trigger a packet
				"turnSlope": 80 //this is too low, and will also trigger packets on small insignificant turns
			}

Here is a proposal for more conservative parameters for mobile, which is actually more or less default on most APRS devices.

			"smart_beacon": {
				"active": true,
				"slowRate": 600, //300 woudl still be acceptable but I would not go below 
				"slowSpeed": 5,
				"fastRate": 60,
				"fastSpeed": 80,//assuming MPH
				"minTxDist": 100, //this was actually not part of original Smartbeaconing spec. not sure why it is needed as this shall be handled by the Smart Beaconing formula between 
				"minDeltaBeacon": 15, //or even 30
				"turnMinDeg": 30, //we want only sharp turns to trigger a packet
				"turnSlope": 255
			}

As a side note, APRS is not about having "a-good-track-on-aprs.fi" it is about situational/tactical awareness. transmitting your position when changing course on an intersection is what matters, not every turn on a winding road...

[richonguzman]

Hi @F4FXL

I will try to explain the decisions made to have the current values (which are not fixed and can be changed if my calculations were wrong):

slowRate": 120, //Fixed station are reocmmended to beacon every 10 minutes, standing mobiles do not need to beacon every 2 minutes

the tracker won't send any beacon unless it gets away of the "minTxDist" from the last gpsPoint which he transmited. So if he is standing still it will Tx only once at 15 min (See standingUpdate variable)

"slowSpeed": 10,
"fastRate": 60,
"fastSpeed": 70,
"minTxDist": 100, //if this distance is in meters, this can cause a mobile traveling at 80km/h to beacon every ~5s

the "minTxDist" value is not used when going the same direction without changing course, its only used to Tx when changing course. So if running at 100km/hr on a straight line it will only beacon once 60segs

"minDeltaBeacon": 12, //this will mitigate the minTxDist Parameter, yet is too high.

this is the minimal value time to send a beacon when changing course enough degrees depending on the velocity (turnslope calculations)

"turnMinDeg": 10, //this is too low, a small turn on the road will trigger a packet
"turnSlope": 80 //this is too low, and will also trigger packets on small insignificant turns

this two values change depending on the speed the car turns/change course, the faster the car goes the less degrees it has to turn to send a gps beacon. When going slower it needs a bigger change in course to send

[F4FXL]

Thanks for your reply. You added many more parameters compared to the original implementation https://web.archive.org/web/20190122090508/http://www.hamhud.net/
It seems that yet the parameters are off and generate too many packets.
If you look at this track https://aprs.fi/#!z=11&ts=1716163200&te=1716249600&call=a%2FF4EGG-9 it has way too many packets, on every turn of this curvy road.
I have been in touch with the guy and he said he is using nothing but default parameters for -9. At SF12 this is roughly a 50% channel occupancy just for one station. If each packet is digipeated at least once it will take one station to cloak the whole channel.

[richonguzman]

the problem there is that F1ZXL-10 is adding "[RSSI:-111 SNR:5.25 @ F1ZXL-10] " text into packet

he should not modify the packets he Rx, by doing so he is uploading original packet modified and also the packet F1ZDF-10 repeated as a new Rx packet. Those packets are the same original packet and when not modified the second one should be rejected as it has been processed already.

This will clearly avoid so many packets and repetitions

[F4FXL]

good catch! I did not pay attention to this! just reported the issue with some explanation to the F1ZXL sysop.
Yet, if you ignore the duplicates caused by the insertion of the RSSI you end up with approx 1 packet every 30 seconds on a winding road, which, i think is too agressive. IMHO parameters should be similar to what is found in Yaesu/Kenwood radios.....

[richonguzman]

Do you have a link to check this values specifically??

[F4FXL]

i can provide you the values from my radios

[F4FXL]

For Cars, The Yaesu radio defaults to:

LOW SPEED: 5km/h
HIGH SPEED: 70km/h
SLOW RATE: 30min
FAST RATE: 90sec
TURN ANGLE: 28°
TURN SLOPE: 26
TURN TIME: 30sec

For Bicycle it is defined as follow:

LOW SPEED: 3km/h
HIGH SPEED: 30km/h
SLOW RATE: 30min
FAST RATE: 120sec
TURN ANGLE: 28°
TURN SLOPE: 11
TURN TIME: 30sec

For pedestrian:

LOW SPEED: 2km/h
HIGH SPEED: 12km/h
SLOW RATE: 30min
FAST RATE: 120sec
TURN ANGLE: 28°
TURN SLOPE: 7
TURN TIME: 30sec

[iw2ejh]

if it can help, there is a nice smartbeaconing map simulator in the web from hb9eyz : https://www.hb9eyz.ch/g_aprs_sm_simulation.php

[richonguzman]

doing some calculations the main "sensible" variable here is the "TURN TIME: 30sec" which in my firmware would be the "minDeltaBeacon"

changing all other values are "almost" the same, but clearly sending faster data has more potential to flood the map easier.

can anyone help with getting other brands values? like Kenwood and Motorola?

[richonguzman]

also saw this:

https://thewakesileave.wordpress.com/2017/06/14/rediscovering-the-smartbeaconing-parameters/

[F4FXL]

doing some calculations the main "sensible" variable here is the "TURN TIME: 30sec" which in my firmware would be the "minDeltaBeacon"

changing all other values are "almost" the same, but clearly sending faster data has more potential to flood the map easier.

can anyone help with getting other brands values? like Kenwood and Motorola?

I have Kenwood values, but I am not sure these are style default ones though...
You values differ mainly from the Turnslope and slowrate.
Keep in mind that Turn slop is by 10° increments.