Platform
Cross-Platform
Description
Right now, the Meshtastic algorithm gives devices with worse antennas the priority in rebroadcasting since rebroadcasting delay is RSSI based. This is the opposite of what is desired. Their should be a slot in the setting for gain of the antenna. Each devices firmware can come with a different preset value set. For devices where you can connect your own antenna, a estimated value is made in the preset but it can be changed by the user.
This preset will have two affects.
-
It will change the delays in rebroadcasting based on gain so that the delay is antenna agnostic. Thus a T1000E will no longer have a massive rebroadcast advantage over a node with a 12 DB antenna. It calculates what the gain difference will do to the signal and uses the modified signal value for calculating rebroadcast time. For example a 1 DB antenna will reduce the rebroadcast time by X amount. A 12 DB antenna will decrease the delay by Y amount. Y is much greater then X.
-
Since we want larger gain antennas to be broadcast messages, we can further give an timing advantage to higher gain antennas. Thus we can create the opposite situation where higher gain antennas will rebroadcast sooner then a timing agnostic model would normally have them broadcast.
There will need to be a cap on how much time can be cut off so that these Client nodes do not move into the Router timing block.
edit:
Ideas that seam to be accepted.
a) It will change the delays in rebroadcasting based on gain so that the delay is antenna agnostic. Thus a T1000E will no longer have a massive rebroadcast advantage over a node with a 12 DB antenna. It calculates what the gain difference will do to the signal and uses the modified signal value for calculating rebroadcast time. For example a 1 DB antenna will reduce the rebroadcast time by X amount. A 12 DB antenna will decrease the delay by Y amount. Y is much greater then X.
b) We could allow the user to flag a device as well placed. Maybe accomplish this with the already existing Client_Base role. Right now, its purpose is to act like a router for whitelisted devices and a Client for devices that are not whitelisted. We could add the following.
For non whitelisted devices, it gets a slight timing advantage. It still operates in the Client Window (as opposed to the Router Window). It would simply get a flat amount subtracted from its SNR calculated rebroadcast delay. Of course if that subtraction would cause it to enter the router window then it would simply get the smallest allowed delay for a client.
This assumes that people would only use Client_Base on well placed nodes, and we would prefer communication to be done with well placed nodes as a way to lower bandwidth usage and improve coverage. Is that a good assumption?
Platform
Cross-Platform
Description
Right now, the Meshtastic algorithm gives devices with worse antennas the priority in rebroadcasting since rebroadcasting delay is RSSI based. This is the opposite of what is desired. Their should be a slot in the setting for gain of the antenna. Each devices firmware can come with a different preset value set. For devices where you can connect your own antenna, a estimated value is made in the preset but it can be changed by the user.
This preset will have two affects.
It will change the delays in rebroadcasting based on gain so that the delay is antenna agnostic. Thus a T1000E will no longer have a massive rebroadcast advantage over a node with a 12 DB antenna. It calculates what the gain difference will do to the signal and uses the modified signal value for calculating rebroadcast time. For example a 1 DB antenna will reduce the rebroadcast time by X amount. A 12 DB antenna will decrease the delay by Y amount. Y is much greater then X.
Since we want larger gain antennas to be broadcast messages, we can further give an timing advantage to higher gain antennas. Thus we can create the opposite situation where higher gain antennas will rebroadcast sooner then a timing agnostic model would normally have them broadcast.
There will need to be a cap on how much time can be cut off so that these Client nodes do not move into the Router timing block.
edit:
Ideas that seam to be accepted.
a) It will change the delays in rebroadcasting based on gain so that the delay is antenna agnostic. Thus a T1000E will no longer have a massive rebroadcast advantage over a node with a 12 DB antenna. It calculates what the gain difference will do to the signal and uses the modified signal value for calculating rebroadcast time. For example a 1 DB antenna will reduce the rebroadcast time by X amount. A 12 DB antenna will decrease the delay by Y amount. Y is much greater then X.
b) We could allow the user to flag a device as well placed. Maybe accomplish this with the already existing Client_Base role. Right now, its purpose is to act like a router for whitelisted devices and a Client for devices that are not whitelisted. We could add the following.
For non whitelisted devices, it gets a slight timing advantage. It still operates in the Client Window (as opposed to the Router Window). It would simply get a flat amount subtracted from its SNR calculated rebroadcast delay. Of course if that subtraction would cause it to enter the router window then it would simply get the smallest allowed delay for a client.
This assumes that people would only use Client_Base on well placed nodes, and we would prefer communication to be done with well placed nodes as a way to lower bandwidth usage and improve coverage. Is that a good assumption?