search

rossengeorgiev / aprs-python

📡 Python module for working with APRS
http://aprs-python.readthedocs.io/en/latest/
GNU General Public License v2.0
114 stars 37 forks source link

Update common.py #64

Closed TheCranston closed 2 years ago

TheCranston commented 2 years ago

This comprehends the PHGR custom message that MUST be terminated by "/" and the standard PHG message of 4 chars.

TheCranston commented 2 years ago

@rossengeorgiev Greetings sir. Can you please take a look at this PR. Thank you for your support.

rossengeorgiev commented 2 years ago

This looks like precursor to some of the code changes in #60. Spawned by #62

Look ok on first look, but lacks tests and comments with samples of the data being parsed.

TheCranston commented 2 years ago

According to http://www.aprs.org/aprs12/probes.txt

By adding it to PHG, it is 100% backwards compatible to existing
parsing of PHG data...  To give it a name, instead of "PROBES" we simply
call it the "PHGR" data...  Here is the FORMAL SPEC for PHGR:

  PHG is (and remains)  "PHGabcd........"

  PHGR is  "PHGabcdr/......

  Where a,b,c,d are as defined in the APRS spec.
  Where r is the integer rate of PHGR packets XMTD in packets per hour
          expressed as a single byte 1-9 and A-Z (A is 10 for example).

And we add a specific "/" separator between the PHGR and any following
text to help flag this as the new PHGR format.  All existing software on
receive should still receive the "PHGabcd" with no impact, since no
following character was ever specified..   And since the only field that
follows a PHG is a variable length free-text comment field (except DF),
the addition of the "/" on the front of that field does not disrupt
understanding of the comment field.

So to process a PHGR message it the code needs to look for a "/". If its not there then its a PHG message and only the following 4 chars are part of that message. Currently the regex being used takes in 5 chars from the input stream with no regard to the "/" character and the first char of any remaining messages end up in the PHG string in error.

an example would be from my local i-gate

N8QYG-1>APDW17,WIDE1-1,WIDE2-1,qAR,N8HKU-5:!4218.96N/08329.13W-PHG7260Travis in Canton, MI - tbully@gmail.com

currently the code pulls in the "T" from the first character in the comment into the PHG message in error. There is no "/" in the 6th character after the PHG so this is not a PHGR. Currently the parser will show a PHGR of "7240T" which is incorrect.

My PR addresses that case. Thanks.

TheCranston commented 2 years ago

@rossengeorgiev I've updated the PR with the change to the unit test processing the "/".

Please let me know if there is anything more I can provide for this PR to meet your requirements. Thanks and have a great day.