[Xastir] Weather Warnings Comment text

Wed Dec 19 14:46:37 EST 2012

I just noticed that a Winter Storm Watch has been issued for our area.  I'm glad to see Xastir has automatically sent out this object via RF and via aprs.fi.  However, the comment text appears to have been truncated.  The object was LOTWSW and the comment on the object is "Winter Storm Wa"
That causes some ambiguity between watch and warning.  Is there any way to set it so it at least says "Winter Storm Warning"?  Ideally it's say something like "Wint. Storm Warn exp 1900 THU" as indicated in the bulletin but, hey, maybe we'll get there down the road.
Just a suggestion.  thanks.
Mike, AA9VI  

--- On Thu, 10/20/11, xastir-request at lists.xastir.org <xastir-request at lists.xastir.org> wrote:

From: xastir-request at lists.xastir.org <xastir-request at lists.xastir.org>
Subject: Xastir Digest, Vol 71, Issue 17
To: xastir at lists.xastir.org
Date: Thursday, October 20, 2011, 11:00 AM

Send Xastir mailing list submissions to
    xastir at lists.xastir.org

To subscribe or unsubscribe via the World Wide Web, visit
    http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
or, via email, send a message with subject or body 'help' to
    xastir-request at lists.xastir.org

You can reach the person managing the list at
    xastir-owner at lists.xastir.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Xastir digest..."

Today's Topics:

   1. Re: corrupt packets (Tom Russo)

----------------------------------------------------------------------

Message: 1
Date: Wed, 19 Oct 2011 10:29:31 -0600
From: Tom Russo <russo at bogodyn.org>
To: Xastir - APRS client software discussion <xastir at lists.xastir.org>
Subject: Re: [Xastir] corrupt packets
Message-ID: <20111019162931.GA71636 at bogodyn.org>
Content-Type: text/plain; charset=us-ascii

On Wed, Oct 19, 2011 at 08:02:33AM -0700, we recorded a bogon-computron collision of the <aa9vi at yahoo.com> flavor, containing:
> The last couple of days I have been reading about corrupt packets getting transmitted over the air.? This sounds similar to what I had mentioned a month ago.? There was no obvious solution then.? I use a KPC3 and Xastir 2.0.0.? I could find no solution until I set permissions on the objects.log and objects-temp.log file to 555.? So, there is some over the air feedback mechanism causing bad packets to be heard over the air and then get fed back into Xastir and then overwrite the default settings. Wouldn't a simple solution be to not have that feedback algorithm?? 

The "feedback algorithm" is in fact how Xastir is intended to work, so 
removing that requires a complete rewrite of how Xastir handles its own
objects.

When Xastir generates an object, it does so by producing the text for a packet
and running it through its normal data parsing routines via a "loopback" 
interface.  Those routines enter the data into the internal database of heard 
information, and if the "FROM" callsign is its own callsign/ssid, then Xastir 
considers the object/item its own and schedules beaconing for it.

This is how we are able to use the server port to inject objects from 
external programs.  If the external program sends the object to Xastir
using a FROM callsign that is the same callsign/ssid that Xastir is using,
then as far as Xastir is concerned, it produced the object, and it begins
beaconing it.  

BUT, if some local digi is corrupting packets and digipeating them, then when
Xastir hears the packet it still claims it is FROM your own station (its from 
callsign was not corrupted), but it doesn't match an existing record (as it 
would if it were not corrupted).  So it enters the "new" data into its 
database, and because the callsign is its own, takes ownership and begins 
beaconing it just as if it had produced the data itself.  Making it not do 
this would require that the object processing mechanism be completely 
revamped, and would break the intended use of server ports to inject data.  

This is different from what Lynn just described:  if someone ELSE beacons
an object with the same name as one we are beaconing already, it will have a 
DIFFERENT "FROM" callsign than Xastir does;  Xastir will NOT adopt it, the 
object will be changed in its internal database as now being owned by some 
other station.  Since the object is no longer its own, it will stop beaconing 
that object.  

Now, the idea that your station is producing garbled objects because it is
receiving them garbled from a digipeater is just a theory, but it seems
at least plausible.  Since you say you were able to stop it from working  by
changing permissions on the objects.log files, then it is almost certain that 
the real issue is that some station other than your own is digipeating garbled 
copies of your own packets --- Xastir refuses to accept them now, because you 
have broken its ability to record its own objects in objects.log.

Your best bet for figuring out where these corrupted packets are coming from
is to start clean  --- remove (or move) objects.log, and start xastir over
with now objects beaconed.  Beacon one object and log your TNC data.
Watch the log until a garbled version of your packet shows up.  Look for the
very first instance of the garbled packet, and scan its digi path.  One of
the stations in that path is broken --- and probably because it's got PASSALL
on in its TNC.  PASSALL off prevents a TNC from sending to the attached 
computer any packets whose data do not have the same computed checksum as 
their transmitted checksums, thus ignoring corrupted packets.  With PASSALL
ON, all packets, irrespective of checksum match, are passed to the attached
machine.  PASSALL is a debugging tool, and should never be on in a TNC used
for a digipeater or IGate.

Come to think of it, it is ALSO possible that your packets are being injected
into APRS-IS by a bad IGate, and picked up again by your station through
APRS-IS rather than your own TNC.  Either way, if the from callsign is not
mangled by the broken station, Xastir will think the packet is its own and
adopt it.  Eliminate *this* possibility by turning off any internet server 
interface you have while looking for the problem on the RF side.  If you
stop receiving garbled packets, but they still show up on, say FINDU or 
aprs.fi, then your job will be to track down which IGate is first injecting 
the garbled packets.

Good luck with that.

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236        http://kevan.org/brain.cgi?DDTNM
 "One man alone can be pretty dumb sometimes, but for real bona fide
 stupidity, there ain't nothin' can beat teamwork." - Edward Abbey

------------------------------

_______________________________________________
Xastir mailing list
Xastir at lists.xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir

End of Xastir Digest, Vol 71, Issue 17
**************************************