[aprssig] Weird characters from station VKA
Pete Loveall AE5PL Lists
hamlists at ametx.com
Mon Dec 1 10:53:00 CST 2008
> -----Original Message-----
> From: Heikki Hannikainen
> Sent: Monday, December 01, 2008 10:06 AM
> JR6VZG-I (or JR6VZG-D?) is a buggy APRS-IS client sending ,QAC, instead
> ,qAC, and getting another Q construct. The next four are all using
Actually, JR6VZG improperly put TCPIP*,QAC,JR6VZG-D as his path for transmission over D-STAR. For general APRS use: TCPIP, TCPXX, and any q construct are -never- to appear on RF. APRS clients should never append any q construct except qAR (means "Received and gated to APRS-IS by"). APRS-IS servers create all other q constructs for APRS-IS use -only- per the specification at http://www.aprs-is.net/q.aspx
> VA7YLW-15 as their igate. I wonder if there's something fishy going on
> there (at the igate or at it's upstream server). The packets look like
I have seen concatenation occurring with APRS+SA IGates (not sure of the TNC configuration) and I have seen certain versions of aprsD also have issues with null and other non-printable characters due to the use of C string functions instead of memory functions. I looked for VA7YLW-15 originated packets and only found some gated to APRS-IS by another IGate. Unfortunately, the destination "call" is APRS so there is no information on the software used.
I saw the same issue with the null character being appended to each AGWTracker transmission. Something for George to look into.
javAPRSSrvr (primary APRS-IS server software) makes no modifications to "packet" payloads (nulls, etc. are left intact). It does replace any end-of-line indicator with a cr/lf sequence upon retransmission to ensure a single, proper cr/lf sequence is received at the client per line transmitted.
Hope this helps.
Pete Loveall AE5PL
pete at ae5pl dot net
More information about the aprssig