[aprssig] aprssig Digest, Vol 105, Issue 13
kf4lvz at yahoo.com
Mon Mar 18 17:10:05 CDT 2013
I may sit down and run some checksum calculations but I'm willing to bet the checksum can be fooled and result in a callsign passing the checksum test even though the parser failed to capture all the data.
At the very least using a zero as the initiator symbol for a number results in a callsign parser that expects an even number of symbols...even moreso because you have four fixed symbols in the format. If the parser found an odd number of symbols then it could toss the whole thing instantly without needing to compute the checksum because there was a symbol lost somewhere. If two are lost, the likelihood of the checksum passing is diminished.
On the other hand if the parser completes the scan and finds all the symbols, then the length of the received datagram is double the length of the callsign plus four so the length of the callsign is now known before fully decoding.
(Technically, it should also make the parsing code simpler because it looks for the flag and then the following character instead of having to handle an awkward special case).
----- Original Message -----
> From: Robert Bruninga <bruninga at usna.edu>
> To: Alex Carver <kf4lvz at yahoo.com>; TAPR APRS Mailing List <aprssig at tapr.org>
> Sent: Monday, March 18, 2013 2:43 PM
> Subject: RE: [aprssig] aprssig Digest, Vol 105, Issue 13
> You raise a good point. However, the use of a checksum makes the added
> digit unnecessary. If any digit is lost, not just the specific one of
> your concern, then the callsign fails.
> Bob, WB4aPR
> -----Original Message-----
> From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
> Of Alex Carver
> Sent: Monday, March 18, 2013 4:23 PM
> To: aprssig at tapr.org
> Subject: Re: [aprssig] aprssig Digest, Vol 105, Issue 13
>> Message: 3
>> Date: Sun, 17 Mar 2013 14:15:24 -0400
>> From: Robert Bruninga <bruninga at usna.edu>
>> To: aprssig at tapr.org
>> Subject: [aprssig] APRStt works!
>> Message-ID: <a4dfdc828440c3c490b13ea5bc2172a1 at mail.gmail.com>
>> Content-Type: text/plain; charset="windows-1252"
>> We used APRStt successfully yesterday to allow anyone with any HT to
>> report their positions along our Marathon by entering only the DTMF code
>> followed by their callsign from DTMF memory. The MM number was
>> converted by a lookup table to the exact position of the mile mark.
>> Further, anyone could report themselves anywere in the 10 mile grid to
>> the nearest 600? or so using the DTMF format ?B2XXYY*?
>> We think that has great potential to expand the use of APRS at events,
>> since everyone in the club could input data, not just the 10% that had
>> APRS capability.
>> See the web page:
>> More to come when Byonics eventually decides to make these DTMF
>> adapters available. Right now, only 3 of us have alpha models for
>> But be thiking of how you can use EVERYONE in your club at your next
>> event to enter data. For example, how we report Boy Scout troop
>> scores at our
>> camporees: http://aprs.org/aprsevent.html
>> Our local Repeater owner also said he would be happy to put an APRStt
>> decoder on the repeater input so that non-APRS mobiles in the area
>> could easily be seen on APRS too?
> Bob, I see a bug in your callsign encoding. You use a single number key
> to encode a number but you use a number and then a letter to encode the
> letters. The problem comes when you perhaps lose one of the letter keys
> (interference, bad key, etc.) which is then interpreted as a straight
> number. Perhaps you should amend your format such that numbers are
> prefixed with 0. This keeps the 2-symbol-per-character encoding
> consistent and also provides a flag for signalling a numeric.
> I know that uses up a little bit of airtime but it isn't much when
> talking about the callsign and adds a bit of error checking.
> aprssig mailing list
> aprssig at tapr.org
More information about the aprssig