[Xastir] Oregon Scientific wmr200
Tom Russo
russo at bogodyn.org
Sun Oct 29 09:47:37 PDT 2017
Oh, yeah, and looking over Joe's use case, where the wxnow.txt file is
generated on one Pi and consumed by a different pi in a different part of the
house, the network daemon approach is ideal --- the daemon would run on
the machine where wxnow.txt is created, and Xastir on any machine anywhere
in the house, connecting to that daemon on the other machine for its weather
data. No need for samba (ugh) or other file sharing techniques.
So again, my first option described below should be low-hanging fruit for
anyone who already knows how to write quickie Python network server scripts.
Or an interesting project for someone who *wants* to know how to do that and
who has the spare cycles to do the learning.
On Sun, Oct 29, 2017 at 10:19:19AM -0600, we recorded a bogon-computron collision of the <russo at bogodyn.org> flavor, containing:
> Gang:
>
> I've been following this thread a little. I have no ATUs to spend on coding
> any solution right now.
>
> Unfortunately, Xastir has no code for periodic polling of any files at all --
> it assumes all input regarding position, weather, or RF data comes from
> some sort of input device -- either a serial port or a network daemon to which
> it will have to connect.
>
> Back in 2009, I added code to Xastir to support the "Davis APRS Data Logger,"
> which was a dongle you could stick between a Davis wired weather station and
> a serial port, and which would reformat all the weather data into an APRS
> "complete weather report" packet, which could be transmitted exactly as is
> without need for any software. There is now code in wx.c that takes this
> packet, strips out just the weather data, and stores it in Xastir's internal
> weather datastructures for later transmission.
>
> The format of Wxnow.txt is *exactly* the weather data portion of a
> "complete weather report" APRS packet as describe in the 1.0.1 spec
> on page 65. So the code to *parse* that data is already in Xastir as part of
> parsing the APRS Data Logger device. It could be used as the basis for a
> new interface type for parsing Wxnow.txt data.
>
> There is also already code in Xastir to support the Davis and LaCrosse
> weather stations by a network interface --- there are two helper programs (in
> the Davis and LaCrosse directories of the Xastir source) that handle these.
>
> In both of these cases, a *third* program is actually communicating with the
> weather station and putting data into a MySQL database, and the helper programs
> are just daemons that pull that data out, reformat it into the weather payload
> of a "positionless weather report", and then periodically send it to all the
> clients who are connected to the daemon.
>
> One particularly kludgy aspect of this is that the code was originally written
> for the Davis, and later extended for LaCrosse and so it uses the "xDvs"
> identifier at the end of the data to recognize what decode path
> it needs to go through --- and therefore when the LaCrosse daemon was written,
> it has to lie about what weather station it is by saying it's "xDvs." (see
> code in wx.c's "wx_decode" function for where this string is used to figure
> out which interface type we have).
>
> So I see two approaches to a quick-and-dirty hack that would get Xastir to
> support Wxnow.txt. Each would have to work within the constraints of
> how Xastir already processes weather (i.e. via serial or network data).
> Neither is without its issues, and neither is a perfect solution.
>
> 1) A real quickie would be to hack up a really simple Python or Perl daemon
> that accepts connections just like the Davis and LaCrosse codes do,
> but instead of reading weather data from a database, it reads it from
> the Wxnow.txt, parses it, reformats into a positionless data format, and
> throws it back at the client periodically.
>
> BTW, "parsing" and "reformatting" is a bit of an overstatement. The
> Wxnow data is of the form:
> CSE/SPDg...t...r...p...P...h..b.....
> and the networked wx code is just expecting:
> cCSEsSPDg...t...r...p...P...h..b.....xDvs
>
> That is, course and speed need c and s prefixes and no slash. About the
> most trivial reformatting imaginable. I would imagine that a daemon
> that could do this work in python would be a few lines long, almost
> all of it managing accepting client connections and handling any
> multithreading issues one has to manage.
>
> One could even just copy the db2APRS or open2300db2APRS
> programs in the Davis or LaCrosse directories, and just use
> the parts of these programs that handle the network daemon. The
> guts would just read Wxnow.txt and make that minor reformatting before
> regurgitating it to the client.
>
> The advantage of this approach is that *all* of the work would be in
> writing the external daemon, and no changes would be necessary to Xastir.
>
> As with the LaCrosse daemon, this thing would have to lie about being
> a Davis (by tacking "xDvs" to the end of the data it sends) in order
> for Xastir to understand it. Either that, or Xastir would have to
> be modified slightly to stop using "xDvs" as the signal to run though
> that particular decode path, and to recognize additional strings for
> networked weather stations that go through the same processing.
>
> 2) Alternatively, one could hack on wx.c and create a new interface type,
> "Networked WXnow" that would be similar to the code for the
> serial-port "Davis APRS Weather Logger" code, but with slightly simpler
> parsing (that code had to strip off non-weather data from the input
> stream, and this code wouldn't need to do it)
>
> Then one could write a *trivial* server that simply reads the wxnow.txt
> file every so often, and simply sends the exact second line back to
> the clients each time it changes.
>
> There are other bits of code one would have to hack on to create a new
> interface type like this, but there are plenty of examples in the code
> to crib from.
>
> There would certainly be subtleties about this approach that I haven't
> thought of.
>
> It seems to me that neither of these approaches is ideal, but neither are
> they extremely deep changes to Xastir. The first would work just by faking
> out an existing mechanism already in Xastir. The second is a little harder,
> but doesn't require adding a new way for Xastir to get weather data --- it's
> still just working within Xastir's existing "weather stations are either
> serial or networked data" approach.
>
> The "ideal" approach would be just to poll the wxnow.txt file directly, but
> that would be a new and different "interface" type for which there are no
> examples to copy from. It might not be easy, or pretty.
>
> As I said, I have no round tuits to play with this, but perhaps some
> others with the right skill set are hanging around. The approach of option
> 1 above should be really simple if one already knows how to write python or
> perl daemons.
>
> On Sat, Oct 28, 2017 at 06:33:28PM -0400, we recorded a bogon-computron collision of the <joe at laferla.ca> flavor, containing:
> > This is the format of the wxnow.txt file
> >
> > wiki.sandaysoft.com/a/Wxnow.txt
> >
> > This file is generated by CumulusMX on my pi on the second floor of my house (better reception from sensors) and using samba is shared with pi in basement connected to tnc software (YAAC in my case at the moment).
> >
> > Joe VA3JLF
> >
> >
> >
> > Sent from Mail for Windows 10
> >
> > From: davidf4
> > Sent: Saturday, October 28, 2017 6:19 PM
> > To: 'Joseph LaFerla'
> > Cc: 'Xastir - APRS client software discussion'
> > Subject: RE: Oregon Scientific wmr200
> >
> > Joe,
> >
> > It may be possible that one of the primary Xastir programmers (I couldn???t code my way out of a wet paper bag unless it???s a DOS script) has an ATU or two to take a look and see if a reoccurring import of a file is possible.?? I can???t guarantee it but things have happened in the past???
> >
> > Is there a short definition of the file or, if it???s only a few lines, can you copy/paste those lines into a reply all with a short explanation of the fields?
> >
> > Dave
> > KD7MYC
> >
> >
> > From: Joseph LaFerla [mailto:joe at laferla.ca]
> > Sent: Saturday, October 28, 2017 2:33 PM
> > To: davidf4 at mindspring.com
> > Subject: Oregon Scientific wmr200
> >
> > Hi David
> >
> > Thanks for your reply to my xastir post and I apologize for a direct reply but I couldn???t figure out how to reply to the message, since I did not receive a message to my email address.??
> >
> > I currently use cumulusMX to upload to weather underground and aprs/cwop but I want to connect the weather station to my tnc using xastir so that I can gate the weather on local rf.?? Other software (like YAAC< which I am now using)allows for creation of a port?? to capture a wxnow.txt file which (in my case) provides the weather info to YAAC which is then sent by radio to the local rf.???? Xastir does have an option for a networked weather station which would receive weather data through a port but without additional software to read the weather data and upload it to the port, it is not usable. ??If a solution presents itself I may switch to xastir because it has some nice features.
> >
> > Joe VA3JLF
> >
> >
> > Sent from Mail for Windows 10
> >
> >
> > _______________________________________________
> > Xastir mailing list
> > Xastir at lists.xastir.org
> > http://xastir.org/mailman/listinfo/xastir
>
> --
> Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/
> Tijeras, NM QRPL#1592 K2#398 SOC#236 http://kevan.org/brain.cgi?DDTNM
> 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
--
Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/
Tijeras, NM QRPL#1592 K2#398 SOC#236 http://kevan.org/brain.cgi?DDTNM
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