In my testing with two android phones and two devices, I see about 30% of either messages lost (not reaching the receiver) or messages received, but not ack’ed on the sender. This is with the 1.1.44 app and 1.1.42 device. Both devices are in the same room on the “Very long range” channel. To reproduce it better, I even added a simple code to the app to send pings every 30 seconds, here is the screenshot showing unacked messages and skipped messages.
Am I pushing the system too hard? I also changed the ls_sleep=15 and position_broadcast_sec=30.
I noticed this also. I think there has been a recent regression (in my case I saw error -7 when reading). I’ll look into this tomorrow.
1 Like
(I’ll put more notes in the bug - but I just reran the stress test. at a radio protocol level it is fine. now adding a stress test at the api consumer level - where I think the problem lies?)
hmm - alas, I saw this as well, but now I can not reproduce it.
I’ve also updated the “meshtastic --test” python stress test to work automatically use two radios connected to USB. I tried four radios and various combinations show no dropped packets (even with retries turned off)
would it be possible for you to send in a PR that adds your android based stress test to the “debug menu” and then I can use that to figure out what is happening.
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.
2 Likes
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.