Skip to content
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

Closed
F4FXL opened this issue Feb 3, 2023 · 3 comments

Comments

@F4FXL
Copy link

F4FXL commented Feb 3, 2023

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.

@wb2osz
Copy link
Owner

wb2osz commented Feb 4, 2023

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

APRS NETWORK FRATRICIDE: Generally, all APRS digipeaters are supposed to transmit immediately and all at the same time. They should NOT wait long enough for each one to QRM the channel with the same copy of each packet. NO, APRS digipeaters are all supposed to STEP ON EACH OTHER with every packet. This makes sure that everyone in range of a digi will hear one and only one copy of each packet. and that the packet will digipeat OUTWARD and not backward. The goal is that a digipeated packet is cleared out of the local area in ONE packet time and not N packet times for every N digipeaters that heard the packet. This means no PERSIST times, no DWAIT times and no UIDWAIT times. Notice, this is contrary to other packet systems that might want to guarantee delivery (but at the expense of throughput). APRS wants to clear the channel quickly to maximize throughput.

http://www.aprs.org/kpc3/kpc3+WIDEn.txt

THIRD: Eliminate the settings that are detrimental to the network.

  • UIDWAIT should be OFF. (the default). With it on, your digi is not doing the fundamental APRS fratricide that is the primary mechanism for minimizing channel loading. All digis that hear the same packet are supposed to DIGI it at the SAME time so that all those copies only take up one additional time slot. (but outward located digs will hear it without collision (and continue outward propagation)

You can change the digipeater code if you believe it would improve your particular situation.

73,
John WB2OSZ

@F4FXL
Copy link
Author

F4FXL commented Feb 5, 2023

Well the discussion raised some questioning on my side. Actually, this way of doing will help reduce channel congestion by artificially creating "cells"

@wb2osz
Copy link
Owner

wb2osz commented Apr 10, 2023

Works as intended. Closing.

@wb2osz wb2osz closed this as completed Apr 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants