Sending CWOP Packets via Ham Radio TNC on Serial Port

[BradMc]

Hi,

I recently bought a Davis Vantage Vue to replace an old WMR968 that I was using with wx200d on linux, and I’ve really been loving weewx.  There’s just one thing left I’m trying to accomplish...

I’m a ham radio operator, and in addition to submitting CWOP packets to APRS-IS via Internet, I also send the same packet out on the APRS frequency via a radio and TNC connected to a serial port on the same server as the weather station software.  With wx200d, you could query the daemon via command line to get the latest APRS (CWOP) formatted packet, which was then easy to just send to the serial port that the radio is connected to using your own script.

But I’m trying to figure out a decent way to do this using weewx. Since I’m a 15 year perl programmer my first attempt was to just query the latest record in the weewx.sdb archive table, format the packet, and then use the same old script I used with wx200d. While trying to figure out where the ‘rain24’ and 'dailyrain’ fields are coming from in the getTNCPacket method, I figured I might abandon that for a while, and try what I think would be the better way, for many reasons.

I figure the better way to do it is within weewx by creating a class that inherits from the CWOP class and then overrides the _send method, or some such.  But while python is something that’s on my list to learn, and the weewx docs are _very_ good, I still have no experience with python, so I’m flailing.

This routine would be mostly like the CWOP class, except the sending interval would be different and there would be no authentication needed. It would basically just take the same packet generated in the getTNCPacket method in the CWOP class, but without the preamble, and send it to a serial port on the server.

Is this something that could be done in a few lines?  Similar to the mygenerator.py example where you just inherit the class, override a method or two, stick it into the bin/user dir and tell skin.conf about it?  Or does this sound more complicated than that? It's easy enough to google how to deal with the serial port in python, etc, but getting this all working within weewx is another story.

I’ll figure my way through it eventually, most likely using the first idea above - but I thought I might see if I could get a bit of a head start here first, and maybe even end up with some re-usable code.

Thanks for any info!

Brad

[Thomas Keffer]

Welcome, Brad!

You've basically got the right idea. Your job is to define a new protocol class, call it "Brad", much like the two existing protocol classes "Ambient" and "CWOP", then tell the Restful thread to run it. At the end of an archive interval, its method "postData()" will be called with the archive and the time stamp as arguments. How you implement postData() is up to you.

As I look at the code right now, the postData() method of CWOP entangles the packet formatting with the packet destination, so it might be a bit simpler to inherit directly from CWOP's base class "REST", and define the postData() method afresh, copying code where convenient.

To get the Restful thread to run your new protocol, add it to the [Restful] section of weewx.conf. So, that section will look something like this:

[Restful]

  [[Wunderground]]

    (wunderground options)

  [[PWSweather]]

    (PWS options)

  [[CWOP]]

    (CWOP options)

  [[Brad]]

    port = /dev/ttyUSB0

   (any other options)

Any options you define in the "[[Brad]]" subsection, such as port in the example above, will be passed on to the initializer __init__ for the class. In addition, the station latitude, longitude, and hardware will also be passed on.

Now, there is one glitch: where to put your code. As written, the engine assumes that all RESTful protocol code is in the file weewx/restful.py. I can see now that was a stupid assumption on my part. For the moment, put your new code in there, but that will require you to cut and paste it with every upgrade. I'll come up with a better way in the next release.

Hope that gets you started!

-tk

--
You received this message because you are subscribed to the Google Groups "Weewx Weather Station Discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msg/weewx-user/-/hrEDwWOjVxAJ.
To post to this group, send email to weewx...@googlegroups.com.
To unsubscribe from this group, send email to weewx-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/weewx-user?hl=en.

--
Thomas Keffer

kef...@threefools.org
+1 541-386-8891 (h)
+1 541-490-9507 (c)

Skype: tkeffer

[Joseph Miller]

Dear fellow Weewx users-

 

I am also a ham, but without 15 years of perl experience.  I'm afraid I'm of the K&R C timeframe.  I can't help with the scripting, but I can help any of you who are interested in getting a ham radio license or suggesting hardware so that you can do this. 

 

The Ham Radio solution is wonderful for remote locations where power goes down and you lose DSL.  Solar Power is sufficient to keep reporting.  There is also a telemetry reporting capability so  you can monitor the status of interior temperature, battery voltage level. 

 

 

Joe KI7WV

 

---

From: weewx...@googlegroups.com [weewx...@googlegroups.com] on behalf of BradMc [bra...@gmail.com]
Sent: Wednesday, April 04, 2012 4:31 AM
To: weewx...@googlegroups.com
Subject: [weewx-user] Sending CWOP Packets via Ham Radio TNC on Serial Port

[BradMc]

Hi Tom,

Now that I found some time to get back to this, it worked out even better than I'd hoped. I copied the CWOP class to a new class and named it APRS. Then I just kept and rewrote the three methods needed -- __init__, postData, and getTNCPacket.

It only took about 3-4 hours to figure my way through it, which is a testament to how well you've built this system.  I know the concepts, but I've never coded in Python before.

This APRS method is kind of hacky, but if anybody else needs such a thing, or if you want to see it for any reason, I'd be happy to pass it along. I'd just post it here, but I'm not sure if people normally throw semi-lengthy bits of code here.

Anyway, many thanks for the head start, it really did help. I'm not sure I would've figured out how to hook it in otherwise.

Brad

--
Brad McConahay
Cincinnati, Ohio
http://BradMc.com

To unsubscribe from this group, send email to weewx-user+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/weewx-user?hl=en.

--
Thomas Keffer

kef...@threefools.org
+1 541-386-8891 (h)
+1 541-490-9507 (c)

Skype: tkeffer

To unsubscribe from this group, send email to weewx-user+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/weewx-user?hl=en.

--
Thomas Keffer

kef...@threefools.org
+1 541-386-8891 (h)
+1 541-490-9507 (c)

Skype: tkeffer

To unsubscribe from this group, send email to weewx-user+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/weewx-user?hl=en.

--
Thomas Keffer

kef...@threefools.org
+1 541-386-8891 (h)
+1 541-490-9507 (c)

Skype: tkeffer

To unsubscribe from this group, send email to weewx-user+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/weewx-user?hl=en.

--
Thomas Keffer

kef...@threefools.org
+1 541-386-8891 (h)
+1 541-490-9507 (c)

Skype: tkeffer

To unsubscribe from this group, send email to weewx-user+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/weewx-user?hl=en.

[BradMc]

Hi Joe,

Glad to see another ham here!  I bet there are at least a few others.

Sending weather packets out over the air on APRS is good just about anywhere really. There are still many stations on APRS who don't use the Internet part of it. The only way they see it at all is via RF on the local APRS network on 144.39 MHz. Even though APRS-IS and CWOP are fun and useful to the NWS, I still like to make sure I'm on RF where it all started, and where it still works without conventional power and wires.

Brad N8QQ - n8qq.com

To unsubscribe from this group, send email to weewx-user+unsubscribe@googlegroups.com.

[John Canfield]

John - wb5tht here. I was really into RTTY and packet several years
ago and had an Internet to packet gateway running for a while (until
the ISP shut down.) I've been somewhat interested in getting back
into packet vis-a-vis APRS and CWOP.

-73-

On Apr 8, 4:41 am, BradMc <bra...@gmail.com> wrote:
> Hi Joe,
>
> Glad to see another ham here!  I bet there are at least a few others.
>
> Sending weather packets out over the air on APRS is good just about
> anywhere really. There are still many stations on APRS who don't use the
> Internet part of it. The only way they see it at all is via RF on the local
> APRS network on 144.39 MHz. Even though APRS-IS and CWOP are fun and useful
> to the NWS, I still like to make sure I'm on RF where it all started, and
> where it still works without conventional power and wires.
>
> Brad N8QQ - n8qq.com
>
>
>
>
>
>
>
> On Wednesday, April 4, 2012 12:10:30 PM UTC-4, Joe KI7WV wrote:
>
> >  Dear fellow Weewx users-
>
> > I am also a ham, but without 15 years of perl experience.  I'm afraid I'm
> > of the K&R C timeframe.  I can't help with the scripting, but I can help
> > any of you who are interested in getting a ham radio license or suggesting
> > hardware so that you can do this.
>
> > The Ham Radio solution is wonderful for remote locations where power goes
> > down and you lose DSL.  Solar Power is sufficient to keep reporting.  There
> > is also a telemetry reporting capability so  you can monitor the status of
> > interior temperature, battery voltage level.
>
> >  Joe KI7WV
>

> >   ------------------------------
> > *From:* weewx...@googlegroups.com [weewx...@googlegroups.com] on
> > behalf of BradMc [bra...@gmail.com]
> > *Sent:* Wednesday, April 04, 2012 4:31 AM
> > *To:* weewx...@googlegroups.com
> > *Subject:* [weewx-user] Sending CWOP Packets via Ham Radio TNC on Serial

> > weewx-user+...@googlegroups.com.

[Thomas Keffer]

That's great, Brad!

I have it on my "to do" list for the next release to make it a little easier to add new RESTful protocols. Your experience helped me see what hooks would be needed.

Cheer

-tk (aka KD7KOQ)

To view this discussion on the web visit https://groups.google.com/d/msg/weewx-user/-/P_V_FNRuM_MJ.

To post to this group, send email to weewx...@googlegroups.com.

To unsubscribe from this group, send email to weewx-user+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/weewx-user?hl=en.

[BradMc]

Fwiw, I packaged up the code a little bit and threw it up on github...

https://github.com/bradmc/weewx_aprs_addon

Thanks again,

Brad N8QQ
http://bradmc.com

[Joseph Miller]

thanks everyone!  I would like to gate the APRS to the radio and look forward to the enhancement.

Gotta Learn some Python!

Joe Miller

KI7WV

www.pocomas.net 

---

From: weewx...@googlegroups.com [weewx...@googlegroups.com] on behalf of Thomas Keffer [tke...@gmail.com]
Sent: Sunday, April 08, 2012 8:05 AM
To: weewx...@googlegroups.com
Subject: Re: [weewx-user] Sending CWOP Packets via Ham Radio TNC on Serial Port

[G7LTT]

Hi Brad,

Thanks for your code offering.

I've been looking though it and I'm wondering if it couldn't be changed slightly. It would be useful to have both KISS and converse (sometimes called connected) mode available rather than just converse.

If I read your code correctly (I'm not good at code) the end result is an ASCII string that gets thrown out the serial port. The TNC then TX's this string when it see's the trailing CRLF character (assuming the TNC is already in converse mode). Whilst this is a great start I feel that there needs to be a way in which we can put the TNC into the chosen mode at application startup by sending the relevant config strings such as  "KISS ON" , "RESTART", "C" etc and in turn send the resetting commands when the app shuts down. I feel that we need to be mindful of the state of the connected radio. the last thing we need is for the app to crap out and leave the radio keyed up.

I think that your code could well be easily modified to produce a D-STAR text message too. This should also be a trivial parsing exercise. A simple time/temp/wind message of 20 characters. The repeater would transmit an LMESG or BMESG to either the local RF users or all connected stations - could be good for RACES WX events etc.

Speaking to Tom's thoughts on better ways to add "plugin" modules; how about a directory where one stores all the plugins one wants? These plugins are then "included" in the weewx.conf file as well as their relevant peculiar .conf files.

Just a few thoughts. I hope they are useful.

Mark

[Thomas Keffer]

Responding to the comment about plugins: I've been thinking of this strategy for version 2. It would be similar to System V's "rc.init", or Eclipse's plugins (but, without the manifests). The weewx engine would look in a plugin directory and load whatever it finds there. The load order would be determined by the collation order. 

The present method of supplying a "service list" is getting out of hand as the number of services grows.

-tk

--
You received this message because you are subscribed to the Google Groups "Weewx Weather Station Discussion" group.

To view this discussion on the web visit https://groups.google.com/d/msg/weewx-user/-/KV26kU160H0J.

To post to this group, send email to weewx...@googlegroups.com.
To unsubscribe from this group, send email to weewx-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/weewx-user?hl=en.

--

Tom Keffer

[george hofmann]

I folded this code into my 2.5.0 system as Brad described and got it to work after a couple of changes.

 

1. The snippet of weewx.conf that Brad has on github needs to have this line added:

         

          driver = weewx.restful.APRS

 

2. In restful.py, in the new APRS class, the line:

 

          for obs_type in ('rain', 'rain24', 'dailyrain'):

 

    must be changed to:

 

          for obs_type in ('hourRain', 'rain24', 'dayRain'):

     This makes it match the CWOP class after which the APRS class is patterned. The CWOP class must have changed since Brad wrote his code.

 

 

There is an issue with the wind speed and gust data that is written. It contains a hyphen as the first character of the three digits, like '-05', where it should be '005'. With the hyphen the packet is discarded by findu.com as illegal. This may be a function of my using simulator data here. Can someone verify that?

 

Other than that it works great. See results on findu.com for station KU7U.

 

George Hofmann KU7U

Edgewood, WA

 

[Thomas Keffer]

Hi, George

Thanks for your comments on getting APRS working!

 

I folded this code into my 2.5.0 system as Brad described and got it to work after a couple of changes.

 

1. The snippet of weewx.conf that Brad has on github needs to have this line added:

         

          driver = weewx.restful.APRS

 

2. In restful.py, in the new APRS class, the line:

 

          for obs_type in ('rain', 'rain24', 'dailyrain'):

 

    must be changed to:

 

          for obs_type in ('hourRain', 'rain24', 'dayRain'):

     This makes it match the CWOP class after which the APRS class is patterned. The CWOP class must have changed since Brad wrote his code.

It has indeed changed. 

 

 

There is an issue with the wind speed and gust data that is written. It contains a hyphen as the first character of the three digits, like '-05', where it should be '005'. With the hyphen the packet is discarded by findu.com as illegal. This may be a function of my using simulator data here. Can someone verify that?

There is an underscore before the first three digits. That's specified as the leading character for wind direction by the CWOP spec. Is this what you mean? 

Unfortunately, the RESTful API is due for an overhaul, so the APRS interface is likely to change in V2.6. 

-tk

[george hofmann]

The underscore before the wind direction (first three digits) is correct. It is the speed and gust data that have a hyphen as the first character.

See http://www.findu.com/cgi-bin/raw.cgi?call=KU7U for my raw packet data that shows this. The packets at the top have the problem. As I worked through issues, the packets get 'better' toward the bottom of this list. I hard coded values for speed and gust data to make it work. Note that the date on my test machine is wrong and that is why the date in these packets is one day ahead of what it should be.

 

I'm just needing to know whether the hyphen is an artifact of using simulator data rather than a real weather station here. I don't have my Davis system available to test it. 

 

Thanks Tom

[Thomas Keffer]

I suspect you're right. The simulator emits windspeeds with an average of 5, and a magnitude of 10, so it should never get below zero, but I won't swear to it.

In any case, my CWOP posts do not show the hyphens: http://www.findu.com/cgi-bin/raw.cgi?call=dw3693

-tk

--
You received this message because you are subscribed to the Google Groups "Weewx user's group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[W7JBG]

I'm about to venture into using Weewx when I get the Ambient Weather WS-1400-IP weather station next week. I'm also a ham radio operator, and about to set up a Digipeater / iGate using an ICOM 2100H radio and most likely a TinyTrak4 TNC.

My main question would be does APRS via RF still work with WeeWx? The last post here was 2 years ago.
And a subquestion that I'm not sure if it'd belong here or elsewhere. With a Raspberry Pi Model B, would I run both WeeWx and software for doing an iGate (bidirectional would be amazing) / Digipeater?