Skip to content

Conversation

@ta3pks
Copy link

@ta3pks ta3pks commented May 31, 2023

In my usecase aprs messages gets filtered by the data type however once parsed this information was gone in aprs_parser.
Before this pr only way to get this information was to manually reparsing package

@scd31
Copy link
Collaborator

scd31 commented Oct 14, 2023

Hi!

First off, thanks for the PR and sorry it took me so long to get to it. I didn't have notifications turned on (a problem which has since been fixed) and didn't see it until a few days ago.

Just wondering, what's the use-case for this?

One potential issue is that when creating a new AprsPacket, the user will have to fill in these new fields. This may be confusing to someone not familiar with the standard, plus the value specified doesn't have any effect on encoding

@ta3pks
Copy link
Author

ta3pks commented Oct 14, 2023

hi thanks for the response.
here you can see this makes filtering a lot easier. I could achieve this by using another function but the problem with that is that this information is already there at the time of parsing and just goes to waste then we need to do some other operation to get it again back.

Ps. the link i shared belongs to the program i wrote named aprs-agent which can cross reference multiple networks such as aprs > email or aprs > twitter etc

@scd31
Copy link
Collaborator

scd31 commented Oct 20, 2023

Is there a reason you want to treat 0x1c and the backtick differently, for example? Or are you just intending to use this as a proxy between the different APRS packet types? The latter is preferable imo, since it could be implemented via a method on AprsData that doesn't require a new field.

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

Successfully merging this pull request may close these issues.

2 participants