wb2osz
commented
1 year ago 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
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.