Lost messages while testing

I think I had noticed this on verry long rande but slow, with GPS broadcast seconds set to 60, and multiple TBeams. I think I was saturating the channel. I droped down to a faster channel, and it got better, but it could have been a coincidence.


PR for testing messages sent is here. I still see messages lost/unacked. I set broadcast_position to 30s and ls_sleep to 15 sec

1 Like

Ok cool beans. I’ll also change my test to use those settings.

How fast can i go with the position_broadcast_sec? Just 30s or even below? Will the broadcasting send the position every “30s” automatical? I noticed that the position only update if i have the meshtastic app open and screen on. The fastest way was to update the position to turn off and on the mobile GPS.

You can specify any period, but that may cause issues… And this is supposed to be automatic, no need to have the app opened. Have you restarted the device after updating the setting?

Above discussion brings another point. @geeksville does it make sense to limit in the phone app how low user can set position_broadcast_sec? I’m thinking something around 1% of duty cycle, as required by some regulations and probably common sense.
If yes, does it make sense to port RadioInterface::getPacketTime to android (to compute broadcast time for the given channel settings) or this would be an overkill?

re: a lower bound on position_broadcast_sec

oh yes - I think for now we should just do the easy lazy thing of setting the minimum at 15 seconds.

re: regulatory compliance
I think this is a good idea also (though lower priority and we can do it later and a fair amount of work)

yeah - That’s part of why I’d like to eventually hide these options in some sort of ‘advanced’ tab because I’m kinda fearful of new users thinking “faster is better” without also considering that (best case) at the longest range setting a position packet takes four seconds to send.

I would hide these options, but for some use cases (e.g., paragliding) the default value does not make sense and needs to be changed, probably at the very first use of the app.
Wow, did not realize it takes 4 seconds… Then it needs to be 400 secs, which is well above the desired 40-60 seconds interval (for paragliding). From the top of your head, do you know how long does it take at fastest channel settings? (I can dig it out, if you don’t have it)

1 Like

I don’t have it handy. Fur paragliding LOS should be great so some of the faster channel settings should still give amazing range.

Also the 1% duty cycle limit does not apply in all regions (I think it isn’t in the US)

If you would be able to provide a structure in the protobufs to populate the airtime calculations, that could be a start.

Step 1 I could then populate that with what we have. At the least, it could give visibility on the current airtime usage.

Step 2 would then be to update the region settings to include any airtime limits.

Step 3 would then be to suggest the if we’re over the limit.

Step 4 would then to enforce the limit.

I can help with step 1 and step 3

1 Like

Here are the values outputted by getPacketTime for different channel settings for messages of size 40-44 bytes:
very long: 3743 ms (bw=125, sf=12, cr=4/8) packet symLen=32 ms, payloadSize=44, time 3743 ms
long: 2379 ms (bw=31, sf=9, cr=4/8) packet symLen=16 ms, payloadSize=43, time 2379 ms
medium: 26 ms (bw=500, sf=7, cr=4/5) packet symLen=0 ms, payloadSize=40, time 26 ms
short: 111 ms (bw=125, sf=7, cr=4/5) packet symLen=1 ms, payloadSize=43, time 111 ms

@geeksville Do these make sense? The huge jump in tx time between the long and medium and reversal of trend between medium and short look strange… Maybe they are named incorrectly in the UI?

@mc-hamster, I’m not sure strict real-time enforcement of duty cycle makes sense. What if user needs to send a message right now? I would more think along the lines of providing guidance and educating during setup. So for example when the user makes the device continuously broadcast at more than 1% duty cycle - we can warn with explanation (and still allow if user insists).

Ok i set broadcasting position to 30s.
On my tbeam i set Bluetooth sleeping to 28800s.
But after a few minutes the connection disconnects. Only when i plug in a powerbank than the display show up all the time and also the Bluetooth stays connect.
I also restart the device after changing any settings.

I think at the app / web interface level it is a best practice to not allow a configuration that easily allows devices to just sit there and be at or significantly over the duty cycle limits. To me that means all the auto magic stuff (node info, ack packets, location updates, etc) is at least within the duty cycle (or close to it).

If user generated messages (in addition to the auto magic stuff) exceed the duty cycle for relatively brief periods of time it’s not ideal but I doubt it will become a major source of interference or concern in meat space (arm chair discussions are another matter).

This is an open source project, for good or bad people can change any of these settings and recompile. Or use the python interface. Giving people an easy button to abuse the shared spectrum just don’t seem like a good idea to me.

I think it is too easy and common for people without RF experience to not know or understand we are not the only project and users of theses frequencies.

Systems for monitoring and collecting highway tolls in the U.S. use the 915-MHz band as do home weather stations, automated meter reading, industrial monitoring and home security. RFID tag technology for monitoring and recording the movements of pharmaceuticals in the distribution chain also uses the 915-MHz band.

1 Like

@Spor7biker I take your message as a vote to prohibit in the phone UI setting the broadcast position to more often than 1% duty cycle? I was thinking of just warning, but could be convinced in prohibiting. I agree this is different from enforcing limits on user-generated messages.

Yes. Instead of a warning maybe we could have a message with a link to a wiki page that explains the issues and points determined people to the python interface. At least that way they can do it, but have to educate themselves and put in a bit of work. I think way too many people will think ‘more often is better, don’t care about the rest’ even if isn’t really needed.

Yup. I’m proposing we do that as a last step. There’s a lot we can learn in the interim.

I mean, no matter what happens, someone can just as easily reset the radio and the radio will lose the memory of what was previously sent.

Looks like indeed the channel names are swapped on the phone, the fix is in PR. @geeksville, do you mind merging it when you have a chance? Moreover, the doc here also has them wrong.

1 Like

So I implemented the broadcast limit in this PR. Also per prior request moved broadcast_period and ls_sleep into a new “Advanced settings” screen. @geeksville whenever you get a chance, maybe you can take a look?

1 Like

cool beans - I’ll do it tonight.