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

APRX not gate courtesy position to RF after message #66

Open
F4FXL opened this issue Dec 4, 2021 · 5 comments
Open

APRX not gate courtesy position to RF after message #66

F4FXL opened this issue Dec 4, 2021 · 5 comments

Comments

@F4FXL
Copy link

F4FXL commented Dec 4, 2021

APRX does not pass posit packet when gating a message to RF.
IGate rules state that along messages a courtesy posit shall also be agted to RF.
When no t/pm source filters are specified, only message is gated to RF and the posit is dropped.

F4FXL added a commit to F4FXL/aprx that referenced this issue Dec 4, 2021
@PhirePhly
Copy link
Owner

Please provide a citation for the relevant RF-gate rule requiring this behavior and background on the amount of testing you've performed on this patch.

@F4FXL
Copy link
Author

F4FXL commented Dec 5, 2021

Hi,

As per http://www.aprs-is.net/IGateDetails.aspx a posit shall be gated to RF along the message.

Testing so far :

  • On the bench (not on ragular APRS frequency) a posit gets transmitted along the message
  • Issue : if a nearby igate already sent the posit to RF the posit is not set. this might be an issue when the igate is the only one serving the message recipient. But I guess the is wanted behavior complying to rule 4 of above link...

@PhirePhly
Copy link
Owner

I'm not thrilled with this patch, because if I'm reading it right, it will keep RF-gating position packets until the message drops out of the history db, so one message could trigger dozens of position packets, where I think the original intention is to gate only the next position packet.

I'm also dubious of how much value the position packet has for a message conversation, but I don't have a strong opinion against it.

@F4FXL
Copy link
Author

F4FXL commented Dec 6, 2021

Actually further testing has shown exactly the behavior you describe..... You are right about the original intention, only gate the next packet after the message.
Ideally this shall be handled as some sort of state machine : whenever there is an outgoing message wait for a posit for a short amount of time (5 or 10 minutes) on the posit is sent, clear the message from the history. This all regardless of any source filtering.

@F4FXL
Copy link
Author

F4FXL commented Dec 7, 2021

Ok nevermind my previous comment, only one posit gets sent after the message... I had some test code locally creating the above behavior...
However as soon as a filter is used (eg we use -p/F0 to block novice which are not allowed for APRS) the message posit no longer gets sent.... I think the logic shall move outside the the check of the presence of filters

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