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?
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:
- Prepare to transfer another byte of data: the transmitter set SDA, and the master pulses SCL high..
- Send a "Stop": Set SDA low, let SCL go high, then let SDA go high. This releases the I²C bus.
- 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: |
|
|
| Adverb: |
|
|
| Synonyms: |
adjective. former - quondam - sometime - late
adverb. formerly - erst - once - before - heretofore - previously
|
