-
Notifications
You must be signed in to change notification settings - Fork 313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Digipeated Packets ignore transmit timing, causing collisions between Direwolf digipeaters #446
Comments
Thanks for all the great feedback from your experiences. I just followed what the inventor of APRS had to say on the topic. http://www.aprs.org/balloons.html
http://www.aprs.org/kpc3/kpc3+WIDEn.txt
You can change the digipeater code if you believe it would improve your particular situation. 73, |
Well the discussion raised some questioning on my side. Actually, this way of doing will help reduce channel congestion by artificially creating "cells" |
Works as intended. Closing. |
As per the topic started here, Transmit Timings (PERSIST and SLOTTIME are ignored.
Settings extreme values like PERSIST 1 and SLOTTIME 900ms which should cause the Direwolf to transmit the digipeated framealmost 1 second after it was received. However the frame goes out on air right away.
All Direwolf will behave the same way, goign on air as soon as the channel is free i.e. simultaneously. As a matter of fact if several Direwolf digipeaters are running in the same area, the network quality can quickly degrade.
Probable cause: Digipeated frames are fed into the high priority queue https://github.com/wb2osz/direwolf/blob/dev/src/digipeater.c#L183
In function wait_for_clear_channel the program only waits for the channel to be free. Frames fed into TQ_PRIO_0_HI queue ignore PERSIST and SLOTTIME https://github.com/wb2osz/direwolf/blob/master/src/xmit.c#L1463 and go out immediatly
Frames fed through KISS seem not to be affected.
The text was updated successfully, but these errors were encountered: