J.F.Drew © 2000-2017

Mobile menus

VK5DJ

Weather APRS

A data converter for the Tandy WM918 weather station

The WM918 weather station is a popular system for home weather measurements.

The South East Radio Group has established a weather station network across the south east of South Australia. Stations at Port MacDonnell, Kongorong, Millicent, Kingston and Bordertown (not in network currently).

 The concept is to have an interconnected system that provides amateurs with a regularly updated weather reporting system for personal interest.

The data coming out of the WM918 weather station is not structured for weather data over packet radio. To create the format required by programs such as UI-View, an interface such as this or a computer running an interface program is required.  

This project describes an interface to interpret the data from a WM918 station and make this available as a string that can be delivered to a Packet TNC for transmission as either a beacon or as a connected packet. For information on the data structure of the WM918 a summary is available from http://wx200.planetfall.com/wx200.txt

The software in the BAS file is completely original within the context of the APRS format for weather but I received valuable pointers by looking at a solution published on Andrew VK5EX’s website.

(http://www.qsl.net/vk5ex/wx-stn/wm.htm)

Thanks Andrew. I am not sufficiently competent to reverse engineer the solution provided by Andrew. It was easier to start again. Why re-invent the wheel is a good question? Because I like a challenge and once I understand how to do it, the concept can be extended with additional features, which is what I have done here.

Andrew’s solution has the capacity to change delays in the beacons and an option to place the TNC in converse mode. It produces positionless packets only and therefore requires a separate beacon from the TNC to provide position detail.

My solution has the following additional features:

1. Switch between position and positionless packet
2. A choice between connected and beacon modes
3. A choice between Imperial and Metric data output

 The beauty of the connected mode is that it will be possible to dispense with random beacons and provide a more controlled system for grabbing data from a range of sites with reduced collisions.

A view of the interface board installed in a second hand diecast box that happened to have to one 5 pin and one 8 DIN connectors already installed.

The outside view with leads going off to the TNC and the WM918

The WM918 outputs data in a frame that is quite different from that required by programs such as UI-View.  The circuit is included as a separate file but utilises a 16F628 PIC and a handful of resistors, capacitors and switches. The PIC runs at 10MHz.

The following options are provided:

1. Connected or beacon mode
2. UI-View mode or standard TNC mode (puts TNC in converse mode first)
3. Positionless weather data or complete weather data including position
4. Send Metric or Imperial measurements
5. Beacon period from 50 secs-35 minutes

The drill pattern for Vero Board. Left is switch end.

Left: The main circuit

Left: Connections to interface

Notes re table to left:

Each input (apart from serial in) is held high with a 10-22 K resistor. Input ports are in red.

Table to left:

The codes that preface data in the positionless format.

Table to left:

EEDATA memory locations

The “u” following the 5 digit barometric information signifies UI-view is the software commonly used for receiving this packet (it could be anything really but I’m not sure what happens if you duplicate one of the above codes.)

The DJWS stands for DJW(eather)(S)tation software.

This is followed by a text string describing the location of the system.

Note: the information string at the end of the EEDATA can be as long as you want within the limit of the 119 bytes of EEDATA. It must have a zero as the last byte indicates to the sending routine that it has reached the end of the string.

You are advised not to try to edit anything other than the lat/long starting after the “z” and finishing at the “E” (locations 3 to 1C) and the information string starting at the “M” (address 35) of Millicent and going to wherever you please within the memory limits and leaving room for a “0” end of string marker.

Most programmers have facility to edit the EEDATA area. Remember that the value of the letter entered is the ascii value in hex. But the zeroes after each string MUST be real zeroes and are entered as 00. This equates to zero hex and is tested as such. Look at the sample hex file to get the system.

Table left:

All three switches closed (on) = 0 volts on port

Beacon mode

Beacon mode may be either positionless or complete weather modes.

Positionless beacons begin with a “_” and have identifiers for wind direction and speed. There is no position information and the date/time is mm/dd/hh/mm

All weather information after the time is prefixed by an identifier eg “c”, “s”, “g” etc.

Complete weather beacons begin with a “@” and have a date/time of dd/hh/mm  (no month) followed by “z” to indicate Zulu time, then lat/long, an underline character to indicate weather then wind direction and speed separated by a “/” with no prefixes (i.e. no “c” or “s”).

The rest of the weather information follows with the appropriate prefixes.

 Connected mode

Connected mode (SW4 off, TNC DCD line connected to PortB.6, SW3 on for uidigi mode)

Connected packet may be either positionless weather (SW6 on) or complete weather with lat/long (SW6 off).

Connected mode is intended for a weather system consisting of a number of stations whose beacons could easily cause hidden transmitter problems. As the stations gradually drift in their timing it could mean that data is corrupted for days or weeks. The solution is to use the connected mode.

 In this mode the outlying station is connected to by a central station. Once a connection is identified by the remote station the PIC sends one packet to the TNC with the most recent data. At most this packet may need up to 10 secs to arrive. On receipt of the packet the central station (running the SEweather program) disconnects and the remote station returns to a dormant state awaiting the next query. The central station then either beacons the first remote station’s information over the network or alternately holds the information until all remotes are queried and beacon the lot in one packet. The first alternative results in shorter packets and would be the preferred mode.

The main aim of this process is to reduce traffic at what could be a busy time. In addition the central unit can control the frequency at which data is gathered and from which station.

Comment on standards

The option of sending metric measurements is included in the PIC program as the preferred mode of operation for SEweather will be metric. It is a pity that some programs choose to use the non standard imperial for input – metric has been accepted by the scientific community for 100 years. Rightly the WM918 outputs metric as a scientific instrument should. What a program outputs for a user is another matter and must meet user needs – in cubits if need be!

 Here is the hex file for loading into a 16F628A (download Hex)

Here is the source code written in Proton + - a Crownhill Basic Compiler Product

The latitude and longitude for a site is stored in EEDATA in the PIC. This is accessed when a complete weather packet is required. It avoids the need to have a separate beacon radiated from the station to establish a position on a UIView screen and assists with the reduction of beacon clutter, especially in this arrangement where 5 weather stations share the same network. Obviously this mode is turned off when used in a mobile situation.

The software was written to emulate and build on the software provided on Andrew’s website and I have used the same connections to enable plug in capability for this project. The 16F628 is pin compatible with a 16F84 but is a more modern device and cheaper. To access the extra features of this solution, additional switches are required. I do not use an “in circuit” programmer but this facility is still available for those who require it. I have made use of one of the ports dedicated to this, providing that switch SW6 is off, then in circuit programming in still available.

Some samples

This first packet example is a complete weather packet with lat/long and includes Imperial measurements as expected by UIview. Note that the WM918 weather station outputs in metric units. At the time there was no wind or rain in my shack – but there was a rain total of 78 points from my experiment with artificial rain two days earlier.

@301902z3735.30S/14021.18E_092/000g000t063r000p0000P0078h60b10150uDJWS Millicent weather

This second packet is similar data 2 minutes later in positionless weather data format.

_09301904c092s000g000t063r000p0000P0078h60b10150uDJWS Millicent weather

The next packet is in metric mode – positionless format (17 minutes later)

_09301921c092s000g000t178r000p0000P0020h60b10150uDJWS Millicent weather

Note that the temperature in Celsius is showing 17.8 degrees while in the previous packet the temperature was showing 63 degrees F due to slight change in temp over the 17 minutes (17.8C=64 deg F). In any case you will find a small discrepancy will appear due to the use of integer arithmetic in the PIC.

The difference in packets between UIdigi mode and dumb TNC mode is the addition of a control C to put the TNC into command mode and then sending a “conv” to put it in guaranteed converse mode, other than that they are identical. Andrew talks about this on his web site and you will find it useful to read his information too.

The latitude and longitude are stored in EEDATA and can readily be changed at programming time. You’ll have to do some arithmetic in changing the ascii value of a letter/numeral to hex – still it’s good for the soul and few people change QTH that often. I’ve provided a table of values later in this document.

Jumper wiring