[Xastir] How to get CWOP weather on APRS network

km5vy Tom Russo russo at bogodyn.org
Thu Jan 20 11:29:20 PST 2022


On Thu, Jan 20, 2022 at 11:13:52AM -0800, we recorded a bogon-computron collision of the <curt.we7u at gmail.com> flavor, containing:
> Commented-out lines: Seems to be a common complaint of yours these
> days. 

As someone who's day job involves maintaining an enormous legacy software
package written by some dozen different authors over 20+ years, code 
readability and code rot is a major concern, and I'll bring it up often until
I retire from that job *and* start using a pencil instead of a computer in
day to day operation.

Commented out code in version-controlled software, especially commented out
code that was inserted once 18 years ago and then promptly commented out,
has been the bane of my existence because of its impact on readability.  
Worse, code inside those comments is often rotted out so that uncommenting it 
would be disastrous.  

My position is that if it was commented out in 2005, the code in there is 
no longer helping anyone and just serves to make it that much harder to 
read and maintain.

"git log -p" on a file will show all the changes made to that file since
it was created, and one can always just use the pager's search function to
look for specific old code that was removed.

> 
> Anyway... I was just mentioning the Xastir adoption of packets as a
> side-effect in case you wanted to add a blurb about that to the
> man-page as well.

I don't have the opportunity to scope out when and how Xastir adopts packets
inserted this way right now, though I believe I have made use of the fact in 
my old (no longer functional) DFing code --- inserting OBJECTS via TCP or UDP 
into Xastir's ports does seem to let Xastir adopt them if you use the same
call.  But it's been so long since I've done that I'm uncomfortable adding it
to the documentation without actually testing it out first.

I think that's because objects created by xastir get handled by looping them  
through the input processing, and then inserted into Xastir's own-object list 
when they're recognized, at which point they get transmitted and added to
the "retransmit this periodically" process.  Both objects created by Xastir 
and those that come in through an interface get treated the same way.  But I'd 
actually have to revisit all the code to make sure this is true.

And I'm pretty sure that non-object/item packets don't get the same treatment.

> On Thu, Jan 20, 2022 at 11:07 AM km5vy Tom Russo <russo at bogodyn.org> wrote:
> >
> > The code is pretty hard to read and is peppered with blocks of commented-out
> > code that have been that way since 2005.  There used to be some attempt to
> > treat the injected stuff as third-party only if its callsign was different
> > from Xastir's, but all that is commented out and stuff injected by
> > xastir_udp_client is *always* treated as third-party.
> >
> > Whether it gets inserted into xastir's "own" packets and adopted for
> > retransmission is another question, but I don't think it does.
> >
> > When I tested this all out by hand, I didn't use the same SSID for the
> > injected packet, so I could tell the difference when I looked at aprs.fi
> > for whether it had been gated properly.  Xastir retransmitted it fine, but
> > did not adopt it.
> >
> > Since it's not an object or item, I don't think Xastir would have retransmitted
> > it anyway --- WeeWx's aprs extension creates a "weather station" packet payload,
> > not a "weather object" payload.
> >
> > On Thu, Jan 20, 2022 at 11:00:57AM -0800, we recorded a bogon-computron collision of the <curt.we7u at gmail.com> flavor, containing:
> > > It's fuzzy in my memory now, but I believe there may be a side-effect
> > > in Xastir as well (which can be taken advantage of in some cases)
> > > where if the call and SSID are the same as the Xastir instance when
> > > injecting packets in via xastir_udp_client, Xastir can take up
> > > re-transmitting those packets at intervals. Like I said it's a bit
> > > fuzzy now as I haven't messed with that piece for some time.
> > >
> > > Where it can be and advantage is if you're trying to inject
> > > objects/items into Xastir from some other interface, using
> > > xastir_udp_client to do this injection.
> > >
> > > Of course the side-effect is if you don't desire Xastir to pick up the
> > > transmission as it's own and retransmit it. I believe this can be
> > > solved by using a different SSID and/or callsign for the injection.
> > >
> > > On Thu, Jan 20, 2022 at 10:50 AM Tom Russo <russo at bogodyn.org> wrote:
> > > >
> > > > Resurrecting an ancient thread, because Dj opened an issue on GitHub about it
> > > > this week, and I tracked down what is happening here.  I'm following up to
> > > > the original thread to clear up the misunderstanding and get the answer into
> > > > the mailing list archive where it could presumably be found in web searches.
> > > >
> > > > Dj had Xastir and WeeWx's APRS extension working, but only by modifying
> > > > main.c.
> > > >
> > > > The reason for the suggested mods of main.c in the message I'm replying to
> > > > is to work around some mistaken usage of xastir_udp_client, which I think
> > > > may have been the result of some incomplete  (or perhaps overly vague)
> > > > documentation.
> > > >
> > > > xastir_udp_client does NOT insert the packet header "FROMCALL>TOCALL:" into
> > > > the data passed to it on the command line, it does a straight insersion of
> > > > the data passed to it directly into Xastir's incoming packet stream.  And so
> > > > one MUST include "FROMCALL>TOCALL:" at the beginning of the packet oneself.
> > > > Some other APRS tools for injecting packets do this for you, but
> > > > xastir_udp_client does not.
> > > >
> > > > Once injected, Xastir creates a third-party packet out of the data.  Third
> > > > party packets look like "xastircall>APX219,PATH1,PATH2...:}tpcall>tocall:..."
> > > > where "xastircall" is the call sign of the Xastir instance and "tpcall" is the
> > > > call sign of the third party station (which may be the same as Xastir's).
> > > > When properly formatted, these packets show up in APRS clients (including web
> > > > based ones like aprs.fi) as being from tpcall.
> > > >
> > > > The main.c changes Dj mentions here basically break the third-party insertion
> > > > and mask the fact that he's left out the packet header in what he's passed to
> > > > xastir_udp_client.  The fact that he was leaving out "tpcall>tocall:" was
> > > > why his packets were being flagged as invalid without those
> > > > modifications (the stuff after the "}" was incomplete).
> > > >
> > > > Once that usage error is corrected, Xastir should be able to take WeeWx's data
> > > > just fine.  So the script to do the insertion would be:
> > > >
> > > >  #!/bin/bash
> > > >  #
> > > >  weatherpacket=`cat /dev/shm/aprs.pkt`
> > > >  /usr/local/xastir/bin/xastir_udp_client localhost 2023 YOURCALL XXXX -to_rf
> > > >  "YOURCALL>APX219:$weatherpacket"
> > > >
> > > >
> > > > with the obvious modification to make it correct for your call sign.  This
> > > > will work with Xastir unmodified, and is as xastir_udp_client was meant
> > > > to be invoked.
> > > >
> > > > I have examined the xastir_udp_client man page and found it to leave too much
> > > > to interpretation.  I edited it and added more notes about how it really works
> > > > so that perhaps it will be easier for others to grok in the future.  If anyone
> > > > still finds it confusing, I can modify it further.
> > > >
> > > > On Sat, Oct 31, 2020 at 08:30:18PM -0400, we recorded a bogon-computron collision of the <xastir at deej.net> flavor, containing:
> > > > > On 10/30/2020 1:07 AM, Steven Morrison wrote:
> > > > > > I can configure the WeeWx program to generate a report and send it to the
> > > > > xastir Pi, but how can i receive that report and transmit it in xastir?
> > > > >
> > > > >
> > > > > I'm doing it as follows in Linux (Raspberry Pi) with both WeeWx and Xastir
> > > > > running on the same RPi, but you could easily rsync the /dev/shm/aprs.kpt
> > > > > file to a different computer if needed.
> > > > >
> > > > > I have the APRS extension loaded into WeeWx
> > > > > (https://github.com/cavedon/weewx-aprs).
> > > > >
> > > > > In /etc/weewx/weewx.conf I have:
> > > > >
> > > > > # Options for extension 'aprs'
> > > > > [APRS]
> > > > >     comment = "RaspberryPi-Xastir-Wx-Topsham,ME"
> > > > >     include_position = 1
> > > > >     symbol_code = _
> > > > >     symbol_table = /
> > > > >     output_filename = /dev/shm/aprs.pkt
> > > > >
> > > > >
> > > > > Then I have a crontab entry that does:
> > > > >
> > > > > 01,11,21,31,41,51 * * * * /home/xastir/scripts/send-weather-rf.sh >
> > > > > /dev/null
> > > > >
> > > > >
> > > > > and the send-weather-rf.sh script looks like (XXXX is my 4 digit APRS code):
> > > > >
> > > > > #!/bin/bash
> > > > > #
> > > > > weatherpacket=`cat /dev/shm/aprs.pkt`
> > > > > /usr/local/xastir/bin/xastir_udp_client localhost 2023 N1JOV XXXX -to_rf
> > > > > $weatherpacket
> > > > >
> > > > >
> > > > > I am using an older version of Xastar (2.1.1) compiled from source code, and
> > > > > had to make the following change in main.c to make the xastir_udp_client
> > > > > command work for the above.  I do not know if this still needs to be done in
> > > > > later versions.
> > > > >
> > > > > main.c is my custom version, main.c.orig is the original.
> > > > >
> > > > > $ diff main.c main.c.orig
> > > > > 12180,12183c12180,12183
> > > > > < //                            char path[100+1];
> > > > > < //                            char info[100+1];
> > > > > < //                            char *path0 = NULL;
> > > > > < //                            char *info0 = NULL;
> > > > > ---
> > > > > >                             char path[100+1];
> > > > > >                             char info[100+1];
> > > > > >                             char *path0 = NULL;
> > > > > >                             char *info0 = NULL;
> > > > > 12187,12188c12187,12188
> > > > > < //                            path0 = strtok(line,":");   // Pointer to
> > > > > start of path
> > > > > < //                            info0 = strtok(NULL,"");    // Pointer to
> > > > > information field
> > > > > ---
> > > > > >                             path0 = strtok(line,":");   // Pointer to
> > > > > start of path
> > > > > >                             info0 = strtok(NULL,"");    // Pointer to
> > > > > information field
> > > > > 12190,12197c12190,12196
> > > > > < //                            xastir_snprintf(path, sizeof(path), "%s",
> > > > > path0);
> > > > > < //                            xastir_snprintf(info, sizeof(info), "%s",
> > > > > info0);
> > > > > < //                            //fprintf(stderr, "path: %s\n", path);
> > > > > < //                            //fprintf(stderr, "info: %s\n", info);
> > > > > < //                            //fprintf(stderr, "line: %s\n", line);
> > > > > < //                            xastir_snprintf(line, sizeof(line),
> > > > > "%s%s%s", path, ",NOGATE:", info);
> > > > > < //                            xastir_snprintf(line, sizeof(line),
> > > > > "%s%s%s", path);
> > > > > < //                            //fprintf(stderr, "line: %s\n", line);
> > > > > ---
> > > > > >                             xastir_snprintf(path, sizeof(path), "%s",
> > > > > path0);
> > > > > >                             xastir_snprintf(info, sizeof(info), "%s",
> > > > > info0);
> > > > > >                             //fprintf(stderr, "path: %s\n", path);
> > > > > >                             //fprintf(stderr, "info: %s\n", info);
> > > > > >                             //fprintf(stderr, "line: %s\n", line);
> > > > > >                             xastir_snprintf(line, sizeof(line), "%s%s%s",
> > > > > path, ",NOGATE:", info);
> > > > > >                             //fprintf(stderr, "line: %s\n", line);
> > > > > 12239c12238
> > > > > < // *(line + line_offset - 1) = '}';
> > > > > ---
> > > > > > *(line + line_offset - 1) = '}';
> > > > > 12242,12243c12241
> > > > > < //                                (char *)(line + line_offset - 1),  //
> > > > > Raw data line
> > > > > <                                 (char *)(line + line_offset), // Raw data
> > > > > line
> > > > > ---
> > > > > >                                 (char *)(line + line_offset - 1),  // Raw
> > > > > data line
> > > > >
> > > > >
> > > > > -Dj
> > > > >
> > > > >
> > > > > --
> > > > > Dj Merrill - N1JOV - EAA Chapter 87
> > > > > Currently Flying: Glastar
> > > > > Previously: Cessna 150 - Glasair 1 FT - Grumman AA1B
> > > > >
> > > > > _______________________________________________
> > > > > Xastir mailing list
> > > > > Xastir at lists.xastir.org
> > > > > http://xastir.org/mailman/listinfo/xastir
> > > >
> > > > --
> > > > Tom Russo    KM5VY
> > > > Tijeras, NM
> > > >
> > > >  echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]
> > > >
> > > > _______________________________________________
> > > > Xastir mailing list
> > > > Xastir at lists.xastir.org
> > > > http://xastir.org/mailman/listinfo/xastir
> > >
> > >
> > >
> > > --
> > > Curt, WE7U        http://xastir.org        http://www.sarguydigital.com
> >
> > --
> > Tom Russo    KM5VY
> > Tijeras, NM
> >
> >  echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]
> >
> 
> 
> -- 
> Curt, WE7U        http://xastir.org        http://www.sarguydigital.com

-- 
Tom Russo    KM5VY
Tijeras, NM  

 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]



More information about the Xastir mailing list