Re: [Xastir] How to get CWOP weather on APRS network
Thanks! On Thu, Jan 20, 2022 at 1:34 PM Tom Russo wrote: > > On Thu, Jan 20, 2022 at 02:07:41PM -0700, we recorded a bogon-computron > collision of the flavor, containing: > > OK, I'll modify the xastir_udp_client documentation to note that injecting > > objects or items into Xastir using the same callsign/SSID as Xastir's will > > cause Xastir to own the object and retransmit it in the same way that it > > does > > objects created via its interface. > > Done. > > Also, tested and confirmed correct --- if you actually match the callsign and > SSID, Xastir adopts, otherwise it doesn't. > > > > On Thu, Jan 20, 2022 at 01:49:09PM -0600, we recorded a bogon-computron > > collision of the flavor, containing: > > > On Thu, Jan 20, 2022 at 1:01 PM Curt Mills wrote: > > > > > > > > > > > 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. > > > > > > > > > > That works and I have made use of it during bike events to translate SPOT > > > beacon position reports into xastir objects. (Along with a few other > > > similar uses.) > > > > > > - Jason > > > > > > -- > > > "The problem with quotes on the Internet is that it is often difficult to > > > verify their authenticity." - *Abraham Lincoln* > > > ___ > > > Xastir mailing list > > > Xastir@lists.xastir.org > > > http://xastir.org/mailman/listinfo/xastir > > > > -- > > Tom RussoKM5VY > > Tijeras, NM > > > > echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] > > [n-z][a-m] > > -- > Tom RussoKM5VY > 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@lists.xastir.org > http://xastir.org/mailman/listinfo/xastir -- Curt, WE7Uhttp://xastir.orghttp://www.sarguydigital.com ___ Xastir mailing list Xastir@lists.xastir.org http://xastir.org/mailman/listinfo/xastir
Re: [Xastir] How to get CWOP weather on APRS network
On Thu, Jan 20, 2022 at 02:07:41PM -0700, we recorded a bogon-computron collision of the flavor, containing: > OK, I'll modify the xastir_udp_client documentation to note that injecting > objects or items into Xastir using the same callsign/SSID as Xastir's will > cause Xastir to own the object and retransmit it in the same way that it does > objects created via its interface. Done. Also, tested and confirmed correct --- if you actually match the callsign and SSID, Xastir adopts, otherwise it doesn't. > On Thu, Jan 20, 2022 at 01:49:09PM -0600, we recorded a bogon-computron > collision of the flavor, containing: > > On Thu, Jan 20, 2022 at 1:01 PM Curt Mills wrote: > > > > > > > > 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. > > > > > > > That works and I have made use of it during bike events to translate SPOT > > beacon position reports into xastir objects. (Along with a few other > > similar uses.) > > > > - Jason > > > > -- > > "The problem with quotes on the Internet is that it is often difficult to > > verify their authenticity." - *Abraham Lincoln* > > ___ > > Xastir mailing list > > Xastir@lists.xastir.org > > http://xastir.org/mailman/listinfo/xastir > > -- > Tom RussoKM5VY > Tijeras, NM > > echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m] -- Tom RussoKM5VY 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@lists.xastir.org http://xastir.org/mailman/listinfo/xastir
Re: [Xastir] How to get CWOP weather on APRS network
OK, I'll modify the xastir_udp_client documentation to note that injecting objects or items into Xastir using the same callsign/SSID as Xastir's will cause Xastir to own the object and retransmit it in the same way that it does objects created via its interface. On Thu, Jan 20, 2022 at 01:49:09PM -0600, we recorded a bogon-computron collision of the flavor, containing: > On Thu, Jan 20, 2022 at 1:01 PM Curt Mills wrote: > > > > > 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. > > > > That works and I have made use of it during bike events to translate SPOT > beacon position reports into xastir objects. (Along with a few other > similar uses.) > > - Jason > > -- > "The problem with quotes on the Internet is that it is often difficult to > verify their authenticity." - *Abraham Lincoln* > ___ > Xastir mailing list > Xastir@lists.xastir.org > http://xastir.org/mailman/listinfo/xastir -- Tom RussoKM5VY 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@lists.xastir.org http://xastir.org/mailman/listinfo/xastir
Re: [Xastir] How to get CWOP weather on APRS network
On Thu, Jan 20, 2022 at 1:01 PM Curt Mills wrote: > > 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. > That works and I have made use of it during bike events to translate SPOT beacon position reports into xastir objects. (Along with a few other similar uses.) - Jason -- "The problem with quotes on the Internet is that it is often difficult to verify their authenticity." - *Abraham Lincoln* ___ Xastir mailing list Xastir@lists.xastir.org http://xastir.org/mailman/listinfo/xastir
Re: [Xastir] How to get CWOP weather on APRS network
I have not played with Xastir for some time, but yes that side-effect did exist as I remember using it. I would also agree it occurred only when using the same callsign and ssid as the Xastir instance. Brett KQ9N On Thu, Jan 20, 2022 at 1:33 PM Curt Mills wrote: > 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. > ___ Xastir mailing list Xastir@lists.xastir.org http://xastir.org/mailman/listinfo/xastir
Re: [Xastir] How to get CWOP weather on APRS network
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 wrote: > > On Thu, Jan 20, 2022 at 11:13:52AM -0800, we recorded a bogon-computron > collision of the 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 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 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 wrote: > > > > > > > > > > Resurrecting an ancient thread, because Dj opened
Re: [Xastir] How to get CWOP weather on APRS network
On Thu, Jan 20, 2022 at 11:13:52AM -0800, we recorded a bogon-computron collision of the 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 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 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 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
Re: [Xastir] How to get CWOP weather on APRS network
Thinking about that another few seconds, the "Those of us who aren't as accomplished with Git" bit probably means just myself, as we have only three developers at present. On Thu, Jan 20, 2022 at 11:13 AM Curt Mills wrote: > > Commented-out lines: Seems to be a common complaint of yours these > days. Those of us who aren't as accomplished with Git, not using it > everyday, tend to keep possibly-useful code around in this form. Feel > free to get rid of such lines, at the expense of making it harder for > some of us to look up later in Git if we want to re-add or learn from > the unused bits of code. > > 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. > > On Thu, Jan 20, 2022 at 11:07 AM km5vy Tom Russo 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 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 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
Re: [Xastir] How to get CWOP weather on APRS network
Commented-out lines: Seems to be a common complaint of yours these days. Those of us who aren't as accomplished with Git, not using it everyday, tend to keep possibly-useful code around in this form. Feel free to get rid of such lines, at the expense of making it harder for some of us to look up later in Git if we want to re-add or learn from the unused bits of code. 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. On Thu, Jan 20, 2022 at 11:07 AM km5vy Tom Russo 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 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 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 > > > -to_rf > > > "YOURCALL>APX219:$weatherpacket" > > > > > > > > > with the obvious
Re: [Xastir] How to get CWOP weather on APRS network
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 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 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 -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 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
Re: [Xastir] How to get CWOP weather on APRS network
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 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 -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 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 ( is my 4 digit APRS code): > > > > #!/bin/bash > > # > > weatherpacket=`cat /dev/shm/aprs.pkt` > > /usr/local/xastir/bin/xastir_udp_client localhost 2023 N1JOV -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
Re: [Xastir] How to get CWOP weather on APRS network
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 -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 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 ( is my 4 digit APRS code): > > #!/bin/bash > # > weatherpacket=`cat /dev/shm/aprs.pkt` > /usr/local/xastir/bin/xastir_udp_client localhost 2023 N1JOV -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 >
Re: [Xastir] How to get CWOP weather on APRS network
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 ( is my 4 digit APRS code): #!/bin/bash # weatherpacket=`cat /dev/shm/aprs.pkt` /usr/local/xastir/bin/xastir_udp_client localhost 2023 N1JOV -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@lists.xastir.org http://xastir.org/mailman/listinfo/xastir
Re: [Xastir] How to get CWOP weather on APRS network
On 1/11/20 10:31 am, Liz wrote:
On Fri, 30 Oct 2020 08:26:41 -0500
Steven Morrison wrote:
Can you explain how you do this?
On 10/30/2020 4:17 AM, Liz wrote:
On Fri, 30 Oct 2020 00:07:19 -0500
Steven Morrison wrote:
Another approach would be to read the new weather entries sent
to APRS-IS for my callsign and transmit them from that report.
I'm still doing that. When I'm driving and see my weather displayed
I know that everything in the chain is working, and that includes my
internet ;)
Liz
VK2XSE
OK
I filter the incoming available data from APRS-IS for local data.
weeWx has sent out my data to APRS-IS, and I collect it along with
other items of local interest (bushfires, storm warnings) and broadcast
them all. This also collects packets from HF APRS users in the
district, or those sending data to APRS-IS through the phone system.
There is a weeWx extension which is able to produce a wxnow.txt file.
Because my weeWx and APRS are on different hardware it became too much
effort to sort out as the existing system worked most of the time.
Liz
VK2XSE
Be aware that the weewx extension cwxn-0.4 provides for three digits of
humidity while the APRS Spec calls for just two digits. It's easy enough
to change the Python script (/usr/share/weewx/users/cwxn.py at around
line 135) to change the 3 for a 2. If used without that change for APRS
the last digit for humidity is chopped off so, e.g., 020% appears on
APRS as 02%. For APRS 100% appears as 00% with the correct (for APRS)
two digit format.
if data['outHumidity'] < 0 or 100 <= data['outHumidity']:
data['outHumidity'] = 0
fields.append("h%03d" % int(data['outHumidity'])) << The 3
in this line should be replaced with a 2 as per the following line.
fields.append("h%02d" % int(data['outHumidity']))"
I use rsync to get wxnow.txt from the wx server to feed to xastir using
the xastir_udp_client. I do it that way because some data I receive is
in metric format and first needs to be massaged to meet the APRS spec.
My combination shell script and perl isn't very pretty but it works!
Ray vk2tv
___
Xastir mailing list
Xastir@lists.xastir.org
http://xastir.org/mailman/listinfo/xastir
Re: [Xastir] How to get CWOP weather on APRS network
On Fri, 30 Oct 2020 08:26:41 -0500 Steven Morrison wrote: > Can you explain how you do this? > > On 10/30/2020 4:17 AM, Liz wrote: > > On Fri, 30 Oct 2020 00:07:19 -0500 > > Steven Morrison wrote: > > > >> Another approach would be to read the new weather entries sent > >> to APRS-IS for my callsign and transmit them from that report. > > I'm still doing that. When I'm driving and see my weather displayed > > I know that everything in the chain is working, and that includes my > > internet ;) > > > > Liz > > VK2XSE OK I filter the incoming available data from APRS-IS for local data. weeWx has sent out my data to APRS-IS, and I collect it along with other items of local interest (bushfires, storm warnings) and broadcast them all. This also collects packets from HF APRS users in the district, or those sending data to APRS-IS through the phone system. There is a weeWx extension which is able to produce a wxnow.txt file. Because my weeWx and APRS are on different hardware it became too much effort to sort out as the existing system worked most of the time. Liz VK2XSE ___ Xastir mailing list Xastir@lists.xastir.org http://xastir.org/mailman/listinfo/xastir
Re: [Xastir] How to get CWOP weather on APRS network
You might take a look at: https://github.com/weewx/weewx/wiki/cwxn and https://www.wxforum.net/index.php?topic=38817.0 On Sat, Oct 31, 2020 at 12:57:31AM -0500, we recorded a bogon-computron collision of the flavor, containing: > Thanks for the info. I'll investigate it further.?? I'm running a Davis > Vantage Pro 2, with Weewx reading the weather station console and forwarding > the data to the NWS CWOP program. I should be able to create a report to > create the wxnow.txt report. > > > On 10/30/2020 3:24 PM, Tom Russo wrote: > > I can't explain what Liz is doing, but Xastir supports "wxnow.txt" format > > weather reports in a somewhat kludgy way. Does your weather station by > > any chance support such a format? > > > > The trick is to run a little perl kludge I wrote that masquerades as a > > Davis Meteo database server --- but instead of polling the Meteo database > > it reads the wxnow.txt file and serves it up to Xastir in the right format. > > > > That script's called "wxnowsrv.pl" in the Xastir scripts directory. > > > > You run this script on the machine where the wxnow.txt file is > > created, then tell Xastir to connect to it as a "Networked WX" interface. > > > > See comments at the top of the script for more detail. > > > > On Fri, Oct 30, 2020 at 08:26:41AM -0500, we recorded a bogon-computron > > collision of the flavor, containing: > > > Can you explain how you do this? > > > > > > On 10/30/2020 4:17 AM, Liz wrote: > > > > On Fri, 30 Oct 2020 00:07:19 -0500 > > > > Steven Morrison wrote: > > > > > > > > > Another approach would be to read the new weather entries sent > > > > > to APRS-IS for my callsign and transmit them from that report. > > > > I'm still doing that. When I'm driving and see my weather displayed I > > > > know that everything in the chain is working, and that includes my > > > > internet ;) > > > > > > > > Liz > > > > VK2XSE > > > > ___ > > > > Xastir mailing list > > > > Xastir@lists.xastir.org > > > > http://xastir.org/mailman/listinfo/xastir > > > ___ > > > Xastir mailing list > > > Xastir@lists.xastir.org > > > http://xastir.org/mailman/listinfo/xastir > ___ > Xastir mailing list > Xastir@lists.xastir.org > http://xastir.org/mailman/listinfo/xastir -- Tom RussoKM5VY 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@lists.xastir.org http://xastir.org/mailman/listinfo/xastir
Re: [Xastir] How to get CWOP weather on APRS network
Thanks for the info. I'll investigate it further. I'm running a Davis Vantage Pro 2, with Weewx reading the weather station console and forwarding the data to the NWS CWOP program. I should be able to create a report to create the wxnow.txt report. On 10/30/2020 3:24 PM, Tom Russo wrote: I can't explain what Liz is doing, but Xastir supports "wxnow.txt" format weather reports in a somewhat kludgy way. Does your weather station by any chance support such a format? The trick is to run a little perl kludge I wrote that masquerades as a Davis Meteo database server --- but instead of polling the Meteo database it reads the wxnow.txt file and serves it up to Xastir in the right format. That script's called "wxnowsrv.pl" in the Xastir scripts directory. You run this script on the machine where the wxnow.txt file is created, then tell Xastir to connect to it as a "Networked WX" interface. See comments at the top of the script for more detail. On Fri, Oct 30, 2020 at 08:26:41AM -0500, we recorded a bogon-computron collision of the flavor, containing: Can you explain how you do this? On 10/30/2020 4:17 AM, Liz wrote: On Fri, 30 Oct 2020 00:07:19 -0500 Steven Morrison wrote: Another approach would be to read the new weather entries sent to APRS-IS for my callsign and transmit them from that report. I'm still doing that. When I'm driving and see my weather displayed I know that everything in the chain is working, and that includes my internet ;) Liz VK2XSE ___ Xastir mailing list Xastir@lists.xastir.org http://xastir.org/mailman/listinfo/xastir ___ Xastir mailing list Xastir@lists.xastir.org http://xastir.org/mailman/listinfo/xastir ___ Xastir mailing list Xastir@lists.xastir.org http://xastir.org/mailman/listinfo/xastir
Re: [Xastir] How to get CWOP weather on APRS network
I can't explain what Liz is doing, but Xastir supports "wxnow.txt" format weather reports in a somewhat kludgy way. Does your weather station by any chance support such a format? The trick is to run a little perl kludge I wrote that masquerades as a Davis Meteo database server --- but instead of polling the Meteo database it reads the wxnow.txt file and serves it up to Xastir in the right format. That script's called "wxnowsrv.pl" in the Xastir scripts directory. You run this script on the machine where the wxnow.txt file is created, then tell Xastir to connect to it as a "Networked WX" interface. See comments at the top of the script for more detail. On Fri, Oct 30, 2020 at 08:26:41AM -0500, we recorded a bogon-computron collision of the flavor, containing: > Can you explain how you do this? > > On 10/30/2020 4:17 AM, Liz wrote: > > On Fri, 30 Oct 2020 00:07:19 -0500 > > Steven Morrison wrote: > > > > > Another approach would be to read the new weather entries sent > > > to APRS-IS for my callsign and transmit them from that report. > > I'm still doing that. When I'm driving and see my weather displayed I > > know that everything in the chain is working, and that includes my > > internet ;) > > > > Liz > > VK2XSE > > ___ > > Xastir mailing list > > Xastir@lists.xastir.org > > http://xastir.org/mailman/listinfo/xastir > ___ > Xastir mailing list > Xastir@lists.xastir.org > http://xastir.org/mailman/listinfo/xastir -- Tom RussoKM5VY 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@lists.xastir.org http://xastir.org/mailman/listinfo/xastir
Re: [Xastir] How to get CWOP weather on APRS network
Can you explain how you do this? On 10/30/2020 4:17 AM, Liz wrote: On Fri, 30 Oct 2020 00:07:19 -0500 Steven Morrison wrote: Another approach would be to read the new weather entries sent to APRS-IS for my callsign and transmit them from that report. I'm still doing that. When I'm driving and see my weather displayed I know that everything in the chain is working, and that includes my internet ;) Liz VK2XSE ___ Xastir mailing list Xastir@lists.xastir.org http://xastir.org/mailman/listinfo/xastir ___ Xastir mailing list Xastir@lists.xastir.org http://xastir.org/mailman/listinfo/xastir
Re: [Xastir] How to get CWOP weather on APRS network
On Fri, 30 Oct 2020 00:07:19 -0500 Steven Morrison wrote: > Another approach would be to read the new weather entries sent > to APRS-IS for my callsign and transmit them from that report. I'm still doing that. When I'm driving and see my weather displayed I know that everything in the chain is working, and that includes my internet ;) Liz VK2XSE ___ Xastir mailing list Xastir@lists.xastir.org http://xastir.org/mailman/listinfo/xastir
