Order Tray | Contact Us | Home | SIG Lists

[aprssig] Weird characters from station VKA

Heikki Hannikainen hessu at hes.iki.fi
Mon Dec 1 16:05:51 UTC 2008


On Sun, 30 Nov 2008, Scott Miller wrote:

> While monitoring a station in Canada on the APRS-IS stream to help a
> user debug a problem there, I saw a packet come through with a report
> from VKA in Australia that had one of the Canadian packets tacked onto
> the end.
> Checking on findu, I see that there's a non-printable character at the
> end of every packet from VKA.  Presumably something out there is getting
> confused by this.  Findu itself doesn't show the concatenated packets,
> but it's there on the APRS-IS.  Perhaps it's a null character and findu
> thinks it's the end of the string, while the IS servers get confused and
> pass it along with the next line?

   Yup, it's a null (before the CRLF): http://aprs.fi/?c=raw&call=VKA

   I have seen two APRS packets on the APRS-IS without a CRLF between them. 
Several times. Didn't make any statistics or additional investigation. But 
I wouldn't guess that it's related to the null bytes.

   There are plenty of stations sending packets with lots of null bytes, 
mostly with a destination callsign of APAGW (agwtracker with UTF-16 
unicode messaging enabled). They normally put a null byte as every second 
character if the transmitted text would otherwise be plain ASCII:


This would be avoided by using UTF-8 unicode encoding instead of UTF-16. 
It'd be backwards compatible with ASCII when only ASCII characters are 

I think there's a bug in agwtracker, it seems to send packets with an 
appended null byte even when unicode messaging is disabled:


Those popped up on the top of the list when I queried my database for 
null bytes. There were 80 stations sending them within the past 60 

But these are so common, that I would be surprised if the null byte 
triggered the two-packets-with-no-crlf issue. When looking at packets with 
null bytes in the end, there are usually no packet concatenation problems 
around there.

Now, if I do a query for "%,qA%,qA%" (% is the "match all" SQL wildcard 
character, like * in normal glob matching), the top 5 list (within past 5 
hours) with concatenated packets is:

  JR6VZG-I  16
  VE7ROW    6
  VE7EHP-9  4
  VE7MMG-1  2
  VE7CHW    2

JR6VZG-I (or JR6VZG-D?) is a buggy APRS-IS client sending ,QAC, instead of 
,qAC, and getting another Q construct. The next four are all using 
VA7YLW-15 as their igate. I wonder if there's something fishy going on in 
there (at the igate or at it's upstream server). The packets look like 

Crystal Mountain APRS [Invalid uncompressed location]
Igate [Invalid telemetry packet]
Igate [Invalid telemetry packet]
monitoring 146.500 mhz, ve7ehp at racVE7RPC>BEACON/1,qAR,VA7YLW-15:Campbell 
Mtn APRS Digi VE7RPC [Rate limited (< 5 sec)]

(The query will also return plenty of mic-e packets with a ,qA in the 
encoded payload, but that's OK.)

   - Hessu, OH7LZB

More information about the aprssig mailing list