Skip to content

Ignoring SLOTTIME and PERSIST setting #263

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

Closed
kandev opened this issue Apr 5, 2020 · 3 comments
Closed

Ignoring SLOTTIME and PERSIST setting #263

kandev opened this issue Apr 5, 2020 · 3 comments

Comments

@kandev
Copy link

kandev commented Apr 5, 2020

I'm using Direwolf 1.5 on Raspberry PI 3 with Ubuntu 18.04
All seems to be working fine, except that I can't insert any delay between receiving and digipeating packets. Basically digipeating start immediately after packet is recieved.
Currently I have this in my configuration:

PTT GPIO 25
DWAIT 0
SLOTTIME 100
PERSIST 5
TXDELAY 30
TXTAIL 10

This should give very little chance to transmit at earliest, 1 second after the packet is received. But in reality PTT/digipeating is triggered immediately after packet enters.
Am I missing something or what could be wrong?! Any ideas?

@kandev kandev changed the title Ignoric SLOTTIME and PERSIST setting Ignoring SLOTTIME and PERSIST setting Apr 5, 2020
@dranch
Copy link
Collaborator

dranch commented Apr 5, 2020

None of those values are intended to delay the digipeating function. They are for just interfacing with your specific radio's key up characteristics. The digipeater section has the "DEDUP" feature which can minimize duplication and there is also the "satgate" feature offers a delay as well but I don't think that's appropriate here. Please read the UserGuide for more details on these items as well as the "“viscous” discussion which is supported by APRX but not Direwolf.

@kandev
Copy link
Author

kandev commented Apr 5, 2020

Thanks for clearing this out! I guess I have missed it if it's written somewhere in the manual.

@wb2osz
Copy link
Owner

wb2osz commented Apr 5, 2020

As David stated, APRS digipeaters are supposed to retransmit immediately, after the channel is clear, rather than waiting the usual random time. This is intentional.

@wb2osz wb2osz closed this as completed Apr 5, 2020
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

3 participants