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, [email protected] <[email protected]> wrote: From: [email protected] <[email protected]> Subject: Xastir Digest, Vol 71, Issue 17 To: [email protected] Date: Thursday, October 20, 2011, 11:00 AM Send Xastir mailing list submissions to [email protected] 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 [email protected] You can reach the person managing the list at [email protected] 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 <[email protected]> To: Xastir - APRS client software discussion <[email protected]> Subject: Re: [Xastir] corrupt packets Message-ID: <[email protected]> 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 <[email protected]> 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 [email protected] http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir End of Xastir Digest, Vol 71, Issue 17 ************************************** _______________________________________________ Xastir mailing list [email protected] http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
