New bug fix Beta 2023 09 04

[kf4hzu]

You guys are sure making fast progress! Thanks for the hard work!

Wanted to report a possible bug, or this could be by design?

Position ambiguity just seems to send a less-accurate full set of coordinates. It should actually replaces end digits of the coordinates with spaces depending on the setting you select in the CPS. This allows other stations and aprs.fi to show the proper position ambiguity of a station based on the number of missing digits.

Code: Select all

2023-09-06 06:09:23 EDT: KF4HZU-7>APOG77,WIDE1-1,WIDE2-1,qAR,KC9TIK:!2752.74N/08244.54W[RT3S
2023-09-06 06:14:01 EDT: KF4HZU-7>APOG77,WIDE1-1,WIDE2-1,qAR,KC9TIK:!2752.74N/08244.52W[RT3S
2023-09-06 06:18:30 EDT: KF4HZU-7>APOG77,WIDE1-1,WIDE2-1,qAR,KC9TIK:!2752.20N/08244.40W[RT3S

The above is 0.0005, 0.001 and 0.01 - I think it should have looked like this but I may be incorrect about the number of deleted digits on the higher settings:

Code: Select all

2023-09-06 06:09:23 EDT: KF4HZU-7>APOG77,WIDE1-1,WIDE2-1,qAR,KC9TIK:!2752.7 N/08244.5 W[RT3S
2023-09-06 06:14:01 EDT: KF4HZU-7>APOG77,WIDE1-1,WIDE2-1,qAR,KC9TIK:!2752.  N/08244.  W[RT3S
2023-09-06 06:18:30 EDT: KF4HZU-7>APOG77,WIDE1-1,WIDE2-1,qAR,KC9TIK:!275 .  N/0824 .  W[RT3S

Edited based on finding this:

Screenshot 2023-09-06 064115.png (75.73 KiB) Viewed 1076 times

[VK3KYY]

You guys are sure making fast progress! Thanks for the hard work!

Wanted to report a possible bug, or this could be by design?

Position ambiguity just seems to send a less-accurate full set of coordinates. It should actually replaces end digits of the coordinates with spaces depending on the setting you select in the CPS. This allows other stations and aprs.fi to show the proper position ambiguity of a station based on the number of missing digits.

Code: Select all

2023-09-06 06:09:23 EDT: KF4HZU-7>APOG77,WIDE1-1,WIDE2-1,qAR,KC9TIK:!2752.74N/08244.54W[RT3S
2023-09-06 06:14:01 EDT: KF4HZU-7>APOG77,WIDE1-1,WIDE2-1,qAR,KC9TIK:!2752.74N/08244.52W[RT3S
2023-09-06 06:18:30 EDT: KF4HZU-7>APOG77,WIDE1-1,WIDE2-1,qAR,KC9TIK:!2752.20N/08244.40W[RT3S

The above is 0.0005, 0.001 and 0.01 - I think it should have looked like this but I may be incorrect about the number of deleted digits on the higher settings:

Code: Select all

2023-09-06 06:09:23 EDT: KF4HZU-7>APOG77,WIDE1-1,WIDE2-1,qAR,KC9TIK:!2752.7 N/08244.5 W[RT3S
2023-09-06 06:14:01 EDT: KF4HZU-7>APOG77,WIDE1-1,WIDE2-1,qAR,KC9TIK:!2752.  N/08244.  W[RT3S
2023-09-06 06:18:30 EDT: KF4HZU-7>APOG77,WIDE1-1,WIDE2-1,qAR,KC9TIK:!275    N/0824    W[RT3S

This is by design. We don't insert spaces, we modify the position.

Is there a technical specification for APRS Ambiguity?

[kf4hzu]

This is by design. We don't insert spaces, we modify the position.

Is there a technical specification for APRS Ambiguity?

Yes, sorry was editing my original post while you replied.

Here is the source link: http://www.aprs.org/doc/APRS101.PDF

PDF Page 34. Labeled as page 24.

[SA0BUX]

You guys are sure making fast progress! Thanks for the hard work!

Wanted to report a possible bug, or this could be by design?

Position ambiguity just seems to send a less-accurate full set of coordinates. It should actually replaces end digits of the coordinates with spaces depending on the setting you select in the CPS. This allows other stations and aprs.fi to show the proper position ambiguity of a station based on the number of missing digits.

Code: Select all

2023-09-06 06:09:23 EDT: KF4HZU-7>APOG77,WIDE1-1,WIDE2-1,qAR,KC9TIK:!2752.74N/08244.54W[RT3S
2023-09-06 06:14:01 EDT: KF4HZU-7>APOG77,WIDE1-1,WIDE2-1,qAR,KC9TIK:!2752.74N/08244.52W[RT3S
2023-09-06 06:18:30 EDT: KF4HZU-7>APOG77,WIDE1-1,WIDE2-1,qAR,KC9TIK:!2752.20N/08244.40W[RT3S

The above is 0.0005, 0.001 and 0.01 - I think it should have looked like this but I may be incorrect about the number of deleted digits on the higher settings:

Code: Select all

2023-09-06 06:09:23 EDT: KF4HZU-7>APOG77,WIDE1-1,WIDE2-1,qAR,KC9TIK:!2752.7 N/08244.5 W[RT3S
2023-09-06 06:14:01 EDT: KF4HZU-7>APOG77,WIDE1-1,WIDE2-1,qAR,KC9TIK:!2752.  N/08244.  W[RT3S
2023-09-06 06:18:30 EDT: KF4HZU-7>APOG77,WIDE1-1,WIDE2-1,qAR,KC9TIK:!275    N/0824    W[RT3S

This is by design. We don't insert spaces, we modify the position.

Is there a technical specification for APRS Ambiguity?

Not a formal specification but a blog on how aprs.fi as implemented it:

https://blog.aprs.fi/2011/01/position-a ... pport.html

Document Page 24 (PDF 34) in http://www.aprs.org/doc/APRS101.PDF


A bit off topic but about APRS , I found a thesis "Examining Ambiguities in the Automatic Packet Reporting System"
That seems interesting.
https://digitalcommons.calpoly.edu/cgi/ ... ext=theses

[VK3KYY]

This is by design. We don't insert spaces, we modify the position.

Is there a technical specification for APRS Ambiguity?

Yes, sorry was editing my original post while you replied.

Here is the source link: http://www.aprs.org/doc/APRS101.PDF

PDF Page 34. Labeled as page 24.

Thanks

Reading the spec

Position Ambiguity

In some instances — for example, where the exact position is not known —
the sending station may wish to reduce the number of digits of precision in
the latitude and longitude

This is for when the operator does not know their exact position.

Our function is for people who do not want to report their exact position.

i.e the exact position , from the GPS is deliberately modified to reduce its level of accuracy.

[SA0BUX]

This is by design. We don't insert spaces, we modify the position.

Is there a technical specification for APRS Ambiguity?

Yes, sorry was editing my original post while you replied.

Here is the source link: http://www.aprs.org/doc/APRS101.PDF

PDF Page 34. Labeled as page 24.

Thanks

Reading the spec

Position Ambiguity

In some instances — for example, where the exact position is not known —
the sending station may wish to reduce the number of digits of precision in
the latitude and longitude

This is for when the operator does not know their exact position.

Our function is for people who do not want to report their exact position.

i.e the exact position , from the GPS is deliberately modified to reduce its level of accuracy.

Couldn't it be used in both cases ?

[kf4hzu]

This is for when the operator does not know their exact position.

Our function is for people who do not want to report their exact position.

i.e the exact position , from the GPS is deliberately modified to reduce its level of accuracy.

I understand that is the wording, but remember it is from 23 years ago. Not long after that document was created, companies like Kenwood added the functionality to allow people to turn this on to mask their position. It is also very common in many APRS software packages, even DireWolf which isn't dedicated to APRS.

Kenwood TM-D710G manual:

Screenshot 2023-09-06 065708.png (16.77 KiB) Viewed 1059 times

DireWolf manual:

Code: Select all

AMBIGUITY
or AMBIG

Number of lower digits to omit for position
ambiguity. Range 0 to 4. Default 0.
Can’t be used with compressed format.

As SA0BUX posted, aprs.fi expects this format. Just messing up the accuracy will likely cause users confusion since people familiar with APRS expect it to work as specified in the document. If you want to stick with what you've written I'd recommend renaming it to something besides "ambiguity" as I hope you understand this term has a very specific meaning and format in APRS.

[VK3KYY]

Ok.

The name will need to be changed to something like Position masking

[kf4hzu]

Sounds like a good name to me.

I am curious why you would stick with the current method. Is it less code space (simple floating-point math) then manipulating the transmitted string for each of the possible 5 settings (1-4 digits or off)?

If it is development time I'd be happy to submit a pull request or a diff, I'd just need the relevant files.

[VK3KYY]

Sounds like a good name to me.

I am curious why you would stick with the current method. Is it less code space (simple floating-point math) then manipulating the transmitted string for each of the possible 5 settings (1-4 digits or off)?

If it is development time I'd be happy to submit a pull request or a diff, I'd just need the relevant files.

Just dropping characters is different from what the position masking does

The format of the text is dd mm.mmmm. We use dd.dddddd for these calculations