[Xastir] How to get CWOP weather on APRS network
Curt Mills
curt.we7u at gmail.com
Thu Jan 20 11:32:30 PST 2022
Yes, that description of how they get adopted fits my fuzzy
recollection of same. Perhaps others who have used that side-effect
feature can comment.
It'd be good to add a blurb to the man-page about the possibility, so
people don't get confused when things work differently than they
expect.
On Thu, Jan 20, 2022 at 11:29 AM km5vy Tom Russo <russo at bogodyn.org> wrote:
>
> 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]
>
--
Curt, WE7U http://xastir.org http://www.sarguydigital.com
More information about the Xastir
mailing list