I made some tests yesterday and sent a packet with only one ":". The
result was an error message [Unsupported packet format] from aprs.fi.
If you do not trust me, you should trust aprs.fi here.
Here is the error:
2014-02-07 23:53:27 CET:
Erlang,RXcount/10m,TXcount/10m,none1,STxxxxxx,logic [Unsupported packet
and here the messages normally generated by SvxLink (no error):
2014-02-07 23:40:04 CET:
You can check this here:
As you can see, there are no errors with this messages.
SvxLink is sending more than just this two kind of messages:
A state when an EL stations is connecting/disconnecting, the position of
the object and the statistics we're discussing about
> Hmmm.. good point on the BEACON_INTERVAL but I wonder what the usual
> ageout time is for an icon on say aprs.fi, openaprs, etc. to disappear?
> Looking a bit deeper, it seems Bob Bruninga recommends 30 minutes for
> fixed stations gating into RF: http://www.aprs.org/aprs12/IS-to-RF-b.txt
It is not so extremly important for messages sent over the internet,
good values are between 20 minutes and 1 hour. Normally you have much
more bandwith as on Rf. The clients (e.g. xastir) can be configured by
the user different (in xastir vom 30seconds to 180minutes), so you can't
say 40minutes is the best value.
If you send the positions over Rf it's important to set the interval not
to high to reduce the traffic on Rf.
> Back to the point, if I don't want to send statistics at all, wouldn't
> it be better to have the Svxlink code support "STATISTICS_INTERVAL=0"?
> Asking another way, is sending Erlang data into APRS-IS "required" or
> "optional"? I would think it would be optional but it seems that both
> Svxlink and APRX makes it mandatory!
Hm, maybe we can change it but again, the problem occurs when sending
over Rf, not fundamentally.
> It's interesting, I'm not seeing the following lines in the APRS.FI
> output so I wonder if they filter these packets out in their display.
> I'll go ask for an update from that remote HAM to see if he's still
> seeing these packets:
This is the result of forwarding the packets to Rf:
WA6TS-1 is sending the previously over the internet received data out as
an own object (Third-party traffic) over Rf:
The :<UI> is unclear for me, maybe a configuration problem? Normally it
should have this structure:
W3XYZ is the source
APRS,DIGI* the destination
WA4ABC>APRS,WIDE,... until <CR> is the third-party payload
> Ok but I ultimately don't understand why the two different packets are
> formatted differently. I would think the two packets coming from
> Svxlink would both use the identical formatting (:T vs ::). Maybe even
> using :> instead for "status":
Because _we have_ two different types of messages. The first is the
header containing a description, the following line contains the data
(analogue values, digital values).
See it as an Excel|csv-file, the first line is the header, the second
1: Name, ZIP, city, phone, ...
2: Adi, 06231, Halle, 123456, ...
You have two distinct messages (header and data) and it is not
guaranteed that you receive the header line at first, so you have to
classify the type by a single character (here ":") because depending on
the data structure it can not necessarily be detected automatically what
type data is.
I havn't done development of aprs, you should ask the people deeper
involved in it. Maybe is my poor English too that I'm unable to explain
the situation here, sri.
vy 73's de Adi, DL1HRC