You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a bad idea because modem transmissions can take longer than 20 seconds on the SX1262. We need to calculate the airtime and then wait 2x that airtime, or similar, so that our timeout value scales with the airtime.
The text was updated successfully, but these errors were encountered:
I forget if it's actually stored or just computed on the fly, but considering an MDU of 500 byes, would it make sense to do timeout = (500*8) / Baud + PreambleTime + FudgeFactor?
Basically compute the maximum transmission time and add, oh, 10 - 20%? I can't imagine it's too critical to be close if there's currently a flat 20 second timeout.
A 1.1 or 1.2x timeout may also work, yes. Detailed testing needs to be
done to figure out the usual drift between the calculated airtime and
the actual airtime.
On 24/10/14 09:05am, faragher wrote:
I forget if it's actually stored or just computed on the fly, but considering an MDU of 500 byes, would it make sense to do `timeout = (500*8) / Baud + PreambleTime + FudgeFactor`?
Basically compute the maximum transmission time and add, oh, 10 - 20%? I can't imagine it's too critical to be close if there's currently a flat 20 second timeout.
--
Reply to this email directly or view it on GitHub:
#91 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
This is a bad idea because modem transmissions can take longer than 20 seconds on the SX1262. We need to calculate the airtime and then wait 2x that airtime, or similar, so that our timeout value scales with the airtime.
The text was updated successfully, but these errors were encountered: