Davis Weather Wizard - Hacking the Serial Port - III

I am always telling folks at work to read and understand the specs. Before you start anything... well, ahem, I need to listen to my own advice from time-to-time.  I sat down this weekend and really looked through the Davis documentation.  Not a usual thing to do on an abnormally sunny day, (It was a record 85F high, 19F above normal BTW)  but I did it over a couple cups of morning coffee.

From which I learned that the Wizard is definitely *not* compatible with the Vantage...

http://www.davisnet.com/support/weather/downloads/

The first of the downloaded documents of interest for the Wiz was:

WeatherLink Serial Communications Reference V3.3  1/22/1999

An amazing bucket of information they released, in fact contains almost everything a programmer could ask for, short of the source code.  I am actually a little embarrassed by some of my earlier speculative posts, all the info I should need is contained in this single document  ...with ONE glaring exception (more on this later)

But for now anyway, it looks you will still need the Davis Link Interface / Data Logger (dongle) to communicate with the Wizard!

0D 0D 0D OD 00 0D 0D 0D OD 00 0D 0D 0D OD 00 0D 0D 0D OD 00...

THIS IS THE CLOSEST THING I GOT TO RESPONSE WITH TTL LEVEL SERIAL DATA...FOR EVERY 4 CHARACTERS INPUT, THE RX LINE DROPS TO LOW LEVEL, SOUNDS A LOT LIKE AN ACK/NAK RESPONSE.... IT DOES NOT SEEM TO MATTER WHAT THE CHAR IS OR EVEN THE DATA RATE, IT IS JUST APPEARS TO BE LOOKING AT THE TRANSITIONS...

After poking around with the device a bit more this weekend, I have finally come to the conclusion that the protocol between the little weather link module and the Wizard III, with about 99.975% certainty, it is the two wire interface: I2C. 

A simple RS232 -> 5V TTL converter won't communicate with the wizard.  All is not lost!  We in all probability wake this thing up eventually, but we will need a serial to I2C converter...sound familiar?

http://www.sparkfun.com/products/9544

The order went to those sparky guys in Boulder, CO for one today...  I am thinking that this $30 device can also be the interface substitute for the Davis Dongle as well?

BACK TO THE PROTOCOL:  There are only a few responses that Weather link provides:

"...If a command is understood, an ASCII 6 (0x06) (ACK) is returned (before any returned data).  If the command was not understood, an ASCII 33 (0x21) (!) is returned...."

So in order to verify the link is talking, we should get a "!"  (0x21) in response to a corrupted or otherwise unrecognized command:

xxxx0D 21

View from the $40 Digital 'Scope View - I gotta get one!  Had a little trouble triggering it, but it did the job.  You can also save waveforms but I did not attempt to this weekend All-in-all a nifty portable scope!

This view is the 0x0D input to the pins which produced dismal results.  I now suspect that one pin is SDA and the other is the SCL line of a two wire interface, most likely I2C,  I have a strong suspicion as well the serial data won't come out of the wizard until the Master/Slave relationship or some other digital courtships occurs!  Then and only then the happy little 3rd beep will emit and all the good info can be put to use...

! ! !

The major interface to the Wizard is only a few commands:

"...The commands "RRD" and "RWR" operate on the link processor memory. These commands execute faster than the "WRD" and "WWR" commands which operate on the station processor memory..."

They operate on two banks in nibbles and must be followed by a CR (0x0D):

"...Commands must be in upper case and terminated with a carriage return (0dh). Do not insert spaces between binary data arguments. If an argument description uses the character '|' then one byte of data is to be formed from the 4 bit values on either side. For example: "bank | n-1" becomes the single byte "0x13" where bank = 1 and n = 4"

Finally, the major command we need to get real time data for APRS modem is the vaunted "LOOP" command:

MULTI LOOPS (65536 –n) so for 1 loop:   
4C 4F 4F 50 FF FF 0D...

     start of block                     1 byte

     inside temperature                 2 bytes

     outside temperature                2 bytes

     wind speed                         1 byte

     wind direction                     2 bytes

     barometer                          2 bytes

     inside humidity                    1 byte

     outside humidity                   1 byte

     total rain                         2 bytes

     not used                           2 bytes

     CRC checksum                       2 bytes

                                       --------

                                       18 bytes

MULTI LOOPS (65536 –n) so for 5 loops:                      

4C 4F 4F 50 FB FF 0D….

I am not sure what use this can be...maybe if you hjave l0ts of link err0rs...or doing some averaging??

There is a lot of good info about the check sum and the data formats:

"...Some commands return a data stream and a CRC check sum.  The generator polynomial for the check sum is x^16 + x^12 + x^5 + 1 (CRC-CCITT backward)...

"...All binary data is transferred in "Intel" format: least significant byte first. In addition, multi-nibble data values on the station are stored least significant nibble first. This does not make a difference when you look at byte sized pieces of memory, since the Link will correctly align the nibbles when sending byte data. "

In a nutshell; this tells us pretty much how these bytes and bits go in and out.  Here are some examples of the actual hex bytes needed to implement some of these commands, and even some expected responses:

INSIDE TEMP (@ LOCATION 0x30 = 0x2D8 => 728  => 72.8F):

57 52 44 44 30 0D 06 D8 02

BAD COMMAND (NAK = 0x21 "!") :

...0D 21

I would think a 0x0d without any proceeding data would not get recognised and produce a " ! " as well.

! ! !

...AND with the upcoming DST time change it got me thinking that these commands hopefully will work as well:

GET TIME (06:37:02)

57 52 44 64 BE 0D 06 06 37 02  

SET TIME (04:25:00)

57 57 52 63 BE 04 25 00 0D 06  

GET DATE (9/20)

57 52 44 44 C8 0D 06 20 09

SET DATE (to today's date 03/04)

57 57 52 43 C8 04 03 0D 06

SET DATE (12/31)

57 57 52 43 C8 31 0C 0D 06

                   

Note: From the appendix , the time and day are in BCD,  but the month is only 4-bits, so the last day of the year 12/31 is shown as above.

0064     SpdHTime:   DS  4      ; BCD hour and minutes of hi.

0068     SpdHDate:   DS  3      ; BCD day of month + 1 nibble for month

So if you have the data logger dongle and want to be free of using a PC to generate your APRS info into your packet modem from the Wizard itself...you are in luck! Stay tuned here and I will soon modify my existing APRS modem code to accomplish this via the serial link which should show you the gorey details of formatting the data into a proper DVS weather packet. 

If you don't have a Weather Link / Data Logger module all is not lost!  I will follow this shortly with the results using a 2-Wire interface (soon as I sort out the details, hopefully, with the help of the Buss Pirate)

As for that glaring omission?  While these documents and code snippets are a wealth of info for the RS232 side of the interface, there are no specs on the dongle to Wizard side.

The assumption is, of course, that the command structure is the same for both interfaces and simply passes these along as the Vantage does. 

I have reached some of the technical details with the aid of that handy little gadget, the pocket O'scope, which I only borrowed to do some more snooping on those two pins this weekend:

"...Once SCL is high, and the master waits a minimum time (4 μs for standard speed I²C) to ensure the receiver has seen the bit, then pulls it low again. This completes transmission of one bit.

After every 8 data bits in one direction, an "acknowledge" bit is transmitted in the other. The transmitter and receiver switch roles for one bit and the erstwhile receiver transmits a single 0 bit (ACK) back. If the transmitter sees a 1 bit (NACK) instead, it learns that:

• (If master transmitting to slave) The slave is unable to accept the data. No such slave, command not understood, or unable to accept any more data.
• (If slave transmitting to master) The master wishes the transfer to stop after this data byte.

After the acknowledge bit, the master may do one of three things:

1. Prepare to transfer another byte of data: the transmitter set SDA, and the master pulses SCL high..
2. Send a "Stop": Set SDA low, let SCL go high, then let SDA go high. This releases the I²C bus.
3. Send a "Repeated start": Set SDA high, let SCL go high, and pull SDA low again. This starts a new I²C bus transaction without releasing the bus.

- Wikipedia


Wow! this looks a lot like what I was seeing stimulating these inputs... even more interesing; They actually used the word "erstwhile" in this definition?  ...Really?  

erst·while/ˈərstˌ(h)wīl/

Adjective:	Former.
Adverb:	Formerly.
Synonyms:	adjective.  former - quondam - sometime - late adverb.  formerly - erst - once - before - heretofore - previously

~ ~ ~

  

Davis Weather Wizard - Hacking the Serial Port - Pt.2.5

Hummm... This is getting interesting.  I got curious why when I measured these signals sometimes P2 would be +5V others it would toggle to 0V ( or darn near)   I have now stumbled onto a pattern:

Weather Link connector {Wire colors match w/ signals 3/12}




 

So here is the deal....When I cycle P2 ( GREEN wire)  4x  then P1( YELLOW wire) toggles to voltage level 0V ( could be logic "1" I don't know yet) on the fifth cycle it returns to +5 V.  The pattern is very repeatable, I still don't know what this means yet or if it is even significant.  ...Just sayin'

UPDATE: The signals now match the wire colors to avoid confusion 3/12/12

Davis Weather Wizard - Hacking the Serial Port - Pt.2

Wizard still sleeps!  I have not devoted too much time to this,  but since the last post,  there has been some new info found! 

While it is still not spewing serial data my little modem can digest and convert int WX packets,  I have done more measurements, on TWO separate devices and the results are very similar.

First, I want to say that the signals I measured with my DVM were not entirely correct. I am not sure if I had a loose connection or what happened but here are the latest measurements:

WW3 Weatherlink Signals -- Updated

These hold true on two units!  The second is a $10 eBay find, I wanted one for my lab anyway and now I don't have to keep moving and resetting the existing unit in the family room.

So we can see P1 and P2 are TTL signals and P2 seems to be toggling, at least once after power up. It comes up near 0 V and toggles to +5V. I tried to tie each signal to GND and then to  a +5V source thru a resistor and finally a loop back as well (shorted the two signals) cycling the unit's power between each setup...

But, I never heard the happy "THIRD" beep that says you have a valid dongle attached.  I was hoping this would be the first breakthrough! But until now, only two beeps. Rats.

Stay Tuned!

~ ~ ~

Davis Weather Wizard - Hacking the Serial Port



<><><><><><><><><><><><>

<>~PART ONE~ <>

NO USER SERVICEABLE PARTS INSIDE





Oh my,  it seems we are out of warranty!

*VOID* Hey now ~ look where they put the screw!

 If the truth be told - this is not the first time I was inside this unit. When I bought it the original unit none of the keys worked, so I returned it to the store to exchange it for this last remaining unit they had on the shelf.  But, when I got it home and found some of the keys were stuck I knew it would be fruitless to drive the 40mi. round trip to Fry's to return this second one. 

So, I did the logical thing - opened it up.  All it needed to fix it was that ribbon cable on the lower left corner of the unit had to get re-seated. (this is really why the label was so wrinkled in the first photo)

Late 20th century technology?

 Yeah, this reminds me of a device I designed in the late '90s.  Hybrid surface mount and through hole technologies.  I  had to smile when I opened this thing, I remember that device used the Intel 80C188 processor which only came as a Quad flat pack surface mount part. At that time, my bosses were terrified we could not work with such fine pitched parts. That part lead spacing looks gigantic compared to the stuff I work with now! 

The big square multi pin surface mount IC  is the microprocessor.  (Hummm... is it the old '188?   It is from the same era, but it's doubtfull as this one looks like it is a flash ROM part...I am pretty sure that one needed an external ROM part.....any clues?)


The first interesting thing is the parts that are missing.  It appears that this "NEW UNIVERSAL BOARD"  could also contain a barometric pressure and humidity sensors for the unit that Davis marketed as the "Perception II Model 7400".   As far as I know, they never had a "combo unit" that did all three parameters with  Wind, Barometer and Humidity.  Also, there are spots for for LEDs for back lighting the LCD display. I would love to have the schematic for this thing but it is not needed for this exercise!  The problem is to figure out which of the pins on  the weatherlink connector ( J3 Below)


The second thing we notice is there are no components which would like +/- 12V of a standard RS232 serial port.  It is all CMOS and LS - TTL 5V compatible hardware.   Most of the other components appear to be for analog switching and signal amplifiers.

Davis Wizard's Connectors

One other interesting thing to note is the layout.  The connectors sit right on top of the LCD display, making the circuits very difficult to trace, although I suspect that they simply go to ports on the processor so tracing will not lead us to the conclusion which goes to TxD or RxD.

DigiKey A9091-ND  CONN MOD 4-4 FLAT

The first task was to build a cable.  I found that the 4P/ 4C-connectors are not very common.  If you look carefully at most telecom connectors which were used for wired telephone extension cords they are actually 6 -position with 4-circuits,  the little 4p/4c connector cables you find typically have only the center two positions wired for handset plugs. 

The cable was a little more challanging to crimp as all I had were 6P crimper but the 4C 6P seeemed to do the job.

I used an unsoldered RJ9 connector on the 6P end to probe the wires.

Snooping with a DVM shows a few bits of possibly useful info.  Actually, the colors are a bit arbitrary, just happen the way I built this cable, but some of these readings may be the tell we need to get stuff out of the Wizard!  So for the 4 (P)ositions; we can see two have some (C)ircuit voltage values, P3 is most likely the ground connection, it traces back to the  (-) on the 9V battery and all the large tin plate on the circuit board, which is what I was really searching for, but I measured the other s as well.  P2 is connected to a  positive voltage 7.8V to be exact, and seems to be coming from the voltage regulated output (VR1 on the circuit board)  

Ah, So...  P2 may either be a driven line (output?) or the power source for an attached module.  The other positions P1 and P4  have a fractional voltage associated with them ~0.7 V  which can either be inputs or outputs, too early to determine at this stage, but they seem to be connected to something.  The other possibilities for example are; there needs to be a loop back combination of some of these signals ( i.e. one grounded or +) to signal the data logger is attached or a pull up resistor for an open collector output driver... Even a simple 4-wire hack can get complicated!

☺☺☺

Looking again at the serial protocol documents from Davis leads me to believe that the Wizard default seems to use a 2400 8/n/1 serial protocol.  It is easy to test multiple serial rates but this will be my starting point.

   if ( strcmp (argv [1], "1200") == 0 )
      initialize_serial_port (0x83);
   else
/*
  2400 baud, 8 data bits, no parity, one stop bit...
*/

Also, it is not clear that the Vantage's TEST<LF> instruction is even included in the earlier models.  What is for sure, that this is a very primitive communications protocol and even one bit difference in the serial data will most likely yield no response, a quiet protocol with no other prompts to indicate a bad command...sneaky. 

The only sequence I see that may let us know for sure we are in if we send a LF  (0x0A) we expect a LF CR (0x0A 0x0D) response. I checked all my serial program's settings (Procomm and TeraTerm - which I happen to have on my laptop)  there is no way to produce this single hex digit 0x0A sequence



It gets worse... the example programs don't even allude that that is included in the earlier models!  We do see an interesting commented out code snippet though... maybe hex 44 will produce an interesting output?:

//    put_serial_charnw (0x44);
    
//    printf ("'%c'\n", get_serial_charnw ());

So we may need to build a more complex command such as LOOP to see if it is alive!

      else if ( strncmp (line, "loop", 4) == 0 )
          {
          put_serial_string ("LOOP");
          a =  5;                           // Default 5 times.
          sscanf (line, "%s %u", command, &a);
          send_unsigned ((unsigned) (65536 - a));
          put_serial_char (0x0d);
          printf ("%x\n", get_serial_char ());

Which looks something like: "LOOP<0xFFFB><0x0D>"

...but I found a gem of a serial program which allows even sending these types of more complex commands:

http://sourceforge.net/projects/realterm/

SO the next tool I will need is a RS232 to 5 volt converter and trial and error on these found circuits to see if we can wake up the sleeping Wizard!

~Stay tuned~

New Rain Gauge for Davis Weather Wizard



Works!



Here is the first recorded rain event.  This modified unit works even better than I expected from the earlier post. The 0.09" was the exact amount reported from the official total taken less than 2 miles from this location, not the 0.02" per tip as the Acurite documentation stated which would have meant this would have been the indicated count for 0.18"   So this means the bucket volumes are compatible!

The patient arrives on the workbench! The tipping buckets attach through an interesting bit of injection molding genius.  The theory is similar to the water tight doors on the Titanic.   There is a high wall of plastic  water dam surrounding the electronics and tipping bucket assembly;  with no gasket of any kind!  The whole thing clamps to the bottom of the unit which is open to the wet world to let the water drain out from the buckets. 

   I guess if the water level tops the watertight doors, you are sunk anyway.

 Two small screws hold the electronics to the battery enclosure, the gap is where the water dam goes.  The spring is the antenna and the reed switch ( the part we need) is the little glass tube in the center of the board.

Transmitter

The plan was to ditch the electronics and just wire to the switch.  I changed the approach slightly when I saw the mounting for the reed switch was in fact part of the circuit board.  I guess I could have proceeded by removing the reed switch and hot gluing it to the top of the assembly, but in the interest of time and to keep the original alignment, and not introducing any axial rotation, to the switch, opted to leave the circuit board in place.   Passing the cable simply requires a small hole located where there is no interference to clamping the assembly together... It was a little hard to drill this right angle hole so I ended up chipping the plastic a bit, no harm though.

 Passing the cable through the assembly took a little thought so as to minimally compromise the water rejection scheme.

The wiring looks straightforward, I attached the grounded wired (RED / BLACK ) to the (-) side of the battery terminal ~ which worked OK

The "hot" side was originally wired as shown here, which in fact will NOT work as shown without a slight modification to the circuit board. 

If the "top" end of the reed switch remains connected to the rest of the transmitter circuit there is a low impedance path to ground, low enough anyway, that the counts will Not get detected by the Wizard! This is why we test! 

The battery was low on the camera so I did not get a pic of the modification but you can simply cut the lead as it enters the circuit board and attach the wires to the free end of the lead.  A dab of hot melt will hold the assembly together as the upper lead will no longer be connected to the board.  Alternatively, you can figure out which trace on the circuit board needs to be cut to keep the leads on the bottom side of  the board ~ it is up to you depending on how much circuit board re-work you are comfortable with.  Either way, should be fine.

The cable passes through the outer shell into the battery compartment and into the electronics compartment. With a reasonable service loop of wire; hot melt does the sealing for a water tight cable entry.