--- /dev/null
+This is the protocol used by the Davis Weather wiressless Integrated Sensor
+Suite (ISS) to communicate its readings back to the console.
+
+Packets are sent from the ISS every 2.5 seconds for an ISS set to a transmit
+ID of zero. The rate gets slower as the transmit ID increases by 1/16 of a
+second for every station ID number e.g. ID 1 transmits at an interval of
+2.5625 seconds (ref: Davis Serial Protocol document). The data rate is 19.2
+kbps and is transmitted from the ISS with least significant bit first. More
+here:
+
+http://madscientistlabs.blogspot.ca/2012/03/first-you-get-sugar.html
+
+The starting point for reverse engineering the protocol is the output from the
+STRMON command when connected to the console with an LVTTL serial connection.
+This connection is discussed in detail in:
+
+http://madscientistlabs.blogspot.ca/2011/01/davis-weatherlink-software-not-required.html
+
+Let's use the following STRMON snippet as an example.
+
+0 = 60
+1 = 6
+2 = d3
+3 = ff
+4 = c0
+5 = 0
+6 = 78
+7 = 75
+
+The eight bytes come from the ISS in this order. However, each byte comes in
+from the ISS with least significant bit first. The bit order has to be
+flipped before we can work with it. All values in the example above are in
+hex.
+
+Byte 0: This is a header. The upper nibble is the sensor the data is from, as
+follows.
+
+ 4 = UV Index
+ 5 = ?
+ 6 = solar radiation
+ 8 = temperature
+ 9 = ?
+ a = humidity
+ e = rain
+
+The lowest three bits in the low order nibble is the transmitter ID, set via dipswitches
+inside the unit.
+
+Ref: http://www.wxforum.net/index.php?topic=10531.msg101520#msg101520
+
+Bit 3 in the low order nibble of byte 0 indicates if the transmitter battery
+is low. The bit is set to zero if the battery is OK, but is apparently only
+set if the transmitter needs to run off the battery and not the solar-charged
+supercap.
+
+Reference: http://www.wxforum.net/index.php?topic=15273.msg149673#msg149673
+
+Byte 1: Wind speed in mph. Wind speed is updated every transmission. Simple.
+
+Byte 2: Wind direction from 1 to 360 degrees. Wind direction is updated every
+transmission. The wind reading is contained in a single byte that limits the
+maximum value to 255. It is converted to a range of 1 to 360 degrees by
+scaling the byte value by 360 / 255. A wind speed reading of 0xd3 = 211
+(decimal) * 360 / 255 = 297.
+
+Davis says that 0 indicates it can't get a reading, so you'd never see wind
+straight out of the North unless your wind vane is broken.
+
+Reference: http://www.wxforum.net/index.php?topic=10531.msg101523#msg101523
+
+Byte 6: High byte of the 16 bit CRC (0x78 in our example above)
+Byte 7: Low byte of the 16 bit CRC (0x75 in our example above)
+
+The CRC is the same as that on the serial interface and is documented in the
+Davis "VantageSerialProtocolDocs_v230.pdf" document. The first six bytes can
+be run through the calcuation and checked against the seventh and eight bytes.
+Alternatively, all eight bytes can be run through the calculation and the
+result will be zero if the CRC is valid. Pocketwx uses the CRC algorithm from
+http://www.menie.org/georges/embedded
+
+Bytes 3 - 5: Depend on the sensor being read at the time. Need to work
+through these. This is what is known now.
+
+Message 4:
+
+Bytes 3 and 4 are for UV Index. The first byte is MSB and the second LSB.
+The lower nibble of the 4th byte is always 5, so they only use the first
+three nibbles. A value of FF in the third byte indicates that no sensor is
+present.
+
+The UV index is calcuated as follows.
+
+ UV Index = (byte3 << 8 + byte4) >> 6) / 50.0
+
+Reference: http://www.wxforum.net/index.php?topic=18489.msg178506#msg178506
+Reference: http://www.wxforum.net/index.php?topic=18489.msg190548#msg190548
+
+Message 6:
+
+Bytes 3 and 4 are solar radiation. The first byte is MSB and the second LSB.
+The lower nibble of the 4th byte is again always 5, so they only use the first
+three nibbles. A value of FF in the third byte indicates that no sensor is
+present.
+
+ Solar radiation = (byte3 << 8 + byte4) >> 6) * 1.757936
+
+Reference: http://www.wxforum.net/index.php?topic=18489.msg178506#msg178506
+Reference: http://www.wxforum.net/index.php?topic=18489.msg190548#msg190548
+
+Message 8:
+
+Byte 3 and 4 are temperature. The first byte is MSB and the second LSB. The
+value is signed with 0x0000 representing 0F. This reading in the old version
+of the ISS was taked from an analog sensor and measured by an A/D. The newer
+ISS uses a digital sensor but still represents the data in the same way. 160
+counts (0xa0) represents 1 degree F. A message of
+
+80 04 70 0f 99 00 91 11
+
+represents temperature as 0x0f99, or 3993 decimal. Divide 3993 by 160 to get
+the console reading of 25.0F
+
+Message a:
+
+Humidity is represented as two bytes in Byte 3 and Byte 4 as a ten bit value.
+Bits 5 and 4 in Byte 4 are the two most significant bits. Byte 3 is the
+low order byte. The ten bit value is then 10x the humidity value displayed on
+the console. The function of the four low order bits in Byte 3 that cause the
+apparent jitter are not known. Here is an example.
+
+a0 06 52 83 38 00 5a c8
+
+((0x38 >> 4) << 8) + 0x83 = 131 + 768 = 899 = 89.9% Relative Humidity
+
+The displayed humidity at the time was 90%. The console rounds the value.
+
+Reference: http://madscientistlabs.blogspot.ca/2012/05/its-not-heat.html
+
+Message e:
+
+Rain is in Byte 3. It is a running total of bucket tips that wraps back
+around to 0 eventually from the ISS. It is up to the console to keep track of
+changes in this byte. The example below is bound to confuse: the leading
+value is the elapsed time since data collection started (in seconds), all
+bytes have been converted to decimal, and the last two CRC bytes have been
+stripped off. A tip of the rain bucket causes the value the ISS is sending
+from a steady value of 40 to a new value of 41.
+
+2426.3,224,16,33,40,1,0
+2436.6,224,11,36,40,1,0
+2446.8,224,9,29,41,2,0
+2457.1,224,10,29,41,3,0
+
+
+To summarize:
+- Byte 0 is a header.
+- Byte 1 always represents wind speed
+- Byte 2 always represents the wind direction
+- Bytes 3-5 will carry other data according to the header in Byte 0
+- Bytes 6 and 7 always represents the checksum with high byte first
+
+-------------
+
+From my notes to help work the rest of this out:
+
+Signed values from the weather station console are two's complement, least
+significant byte first. Note that pressure is measured by the console and not
+the ISS, so don't expect it to appear in the STRMON output.
+
+Update rates below are from Davis' specs and manuals. Data sizes and signing
+are as per the loop command and are what one might expect out of STRMON but
+not always. I noted above that wind direction via STRMON is actually one byte
+unsigned. There may be other exceptions.
+- Outside temp: 10 seconds in 10th of a degree F, two bytes signed (message e
+ in STRMON, bytes 3 and 4).
+- Winds speed: 2.5 seconds, one byte unsigned (Byte 1 in STRMON, always)
+- Wind direction: 2.5 seconds, two bytes unsigned from 1 to 360 (one byte
+ via STRMON, Byte 2 always)
+- Outside humidity: 50 seconds in percent, one byte unsigned (message a in
+ STRMON, bytes 3 and 4)
+- Rain: 10 seconds. This is in counts of 0.01 inches.
+- Pressure: in Hg/1000, two bytes unsigned (Rate????)
+- Leaf Wetness: 40 seconds
+- Soil Moisture: 40 seconds
+- Solar radiation: 50 seconds
+- UV: 50 seconds
+- Soil Moisture: 62.5 seconds
+
+I think all other outdoor related values are calculated in the console.
+
+The only headers (ie Byte 0) I see from my wireless VP2 with no additional
+sensors connected are:
+
+40 50 60 80 90 a0 e0
+
+The rates they show up at are:
+-40 shows either every 47.5 or 50 seconds
+-50 shows every 10 seconds
+-60 shows every 50 seconds
+-80 shows every 10 seconds
+-90 shows either 45, 47.5, or 50 seconds
+-a0 shows alternately every 40 seconds and 10 seconds (interesting!)
+-e0 shows every 10 seconds
+
+These rates along with the rates given in the Davis manual should make
+correlating the data a lot easier.
+
+Copyright DeKay @ madscientistlabs.blogspot.com under the Creative Commons
+Attribution-ShareAlike License 3.0
projects / dweather.git / blobdiff