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

Disabling of awaiting an ack APRS message #387

Open
ioef opened this issue Oct 22, 2024 · 5 comments
Open

Disabling of awaiting an ack APRS message #387

ioef opened this issue Oct 22, 2024 · 5 comments

Comments

@ioef
Copy link

ioef commented Oct 22, 2024

Hello all.

I would like to ask if there is a way to disable acknowledgement when sending a message. In order words if there is a menu that can configure the message options and disable the awaiting of ack APRS messages.

Thank you!

@na7q
Copy link
Contributor

na7q commented Oct 22, 2024

I believe it could be done. I'd ask why though?

@ioef
Copy link
Author

ioef commented Oct 22, 2024

Because i am encountering a case where I use HG-UV98 with APRSDroid and PicoAPRS in order to exchange test messages among them and i experience a lot of retransmissions. Possibly due to APRSDroid awaiting an ack, which is receiving, but not in a consistent way... Sometimes APRSDroid marks with green the messages, whether other times it marks it with light green and eventually re-transmits the message. And the distance of the handhelds is not longer than 5 meters.

@na7q
Copy link
Contributor

na7q commented Oct 22, 2024

So it sounds like they may be too close. In some cases signals can experience a buzz causing it not to decode in close proximity. Happens all the time to me.

I would check with more distance and just generally see if it's just not decoding. I have a version of APRSDroid with some added features that you can adjust the retry limit and time between.

@na7q
Copy link
Contributor

na7q commented Oct 31, 2024

I have intentions to create a setting to disable the ack, and create a duplicate suppression of repeated acks based on X set time.

My reason for this is on HF APRS networks that use VARA. Since VARA is very slow, and each beacon takes up to nearly 18 seconds (even more sometimes), but on average 12.
So where a user can receive a message from multiple igates (~3-4) within 60 seconds for example, sometimes more. This means a backlog of acks are waiting to make it to RF, and it would cause a 1 minute or more transmission. So reducing to 1 duplicate ack per minute instead of duplicating it, it would resolve this congestion problem.

@na7q
Copy link
Contributor

na7q commented Oct 31, 2024

Initial commit. I'll be re-working the menus for all the new features. So it's subject to change. But it worked great during the inital tests. Needs some cleaning up.

na7q@983fd91

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