manuals/protocol.txt

   1 This is the protocol used by the Davis Weather wiressless Integrated Sensor
   2 Suite (ISS) to communicate its readings back to the console.
   3
   4 Packets are sent from the ISS every 2.5 seconds for an ISS set to a transmit
   5 ID of zero.  The rate gets slower as the transmit ID increases by 1/16 of a
   6 second for every station ID number e.g. ID 1 transmits at an interval of
   7 2.5625 seconds (ref: Davis Serial Protocol document).  The data rate is 19.2
   8 kbps and is transmitted from the ISS with least significant bit first.  More
   9 here:
  10
  11 http://madscientistlabs.blogspot.ca/2012/03/first-you-get-sugar.html
  12
  13 The starting point for reverse engineering the protocol is the output from the
  14 STRMON command when connected to the console with an LVTTL serial connection.
  15 This connection is discussed in detail in:
  16
  17 http://madscientistlabs.blogspot.ca/2011/01/davis-weatherlink-software-not-required.html
  18
  19 Let's use the following STRMON snippet as an example.
  20
  21 0 = 60
  22 1 = 6
  23 2 = d3
  24 3 = ff
  25 4 = c0
  26 5 = 0
  27 6 = 78
  28 7 = 75
  29
  30 The eight bytes come from the ISS in this order.  However, each byte comes in
  31 from the ISS with least significant bit first.  The bit order has to be
  32 flipped before we can work with it.  All values in the example above are in
  33 hex.
  34
  35 Byte 0: This is a header.  The upper nibble is the sensor the data is from, as
  36 follows.
  37
  38   4 = UV Index
  39   5 = ?
  40   6 = solar radiation
  41   8 = temperature
  42   9 = ?
  43   a = humidity
  44   e = rain
  45
  46 The lowest three bits in the low order nibble is the transmitter ID, set via dipswitches
  47 inside the unit.
  48
  49 Ref: http://www.wxforum.net/index.php?topic=10531.msg101520#msg101520
  50
  51 Bit 3 in the low order nibble of byte 0 indicates if the transmitter battery
  52 is low. The bit is set to zero if the battery is OK, but is apparently only
  53 set if the transmitter needs to run off the battery and not the solar-charged
  54 supercap.
  55
  56 Reference: http://www.wxforum.net/index.php?topic=15273.msg149673#msg149673
  57
  58 Byte 1: Wind speed in mph.  Wind speed is updated every transmission.  Simple.
  59
  60 Byte 2: Wind direction from 1 to 360 degrees.  Wind direction is updated every
  61 transmission.  The wind reading is contained in a single byte that limits the
  62 maximum value to 255.  It is converted to a range of 1 to 360 degrees by
  63 scaling the byte value by 360 / 255.  A wind speed reading of 0xd3 = 211
  64 (decimal) * 360 / 255 = 297.
  65
  66 Davis says that 0 indicates it can't get a reading, so you'd never see wind
  67 straight out of the North unless your wind vane is broken.
  68
  69 Reference: http://www.wxforum.net/index.php?topic=10531.msg101523#msg101523
  70
  71 Byte 6: High byte of the 16 bit CRC (0x78 in our example above)
  72 Byte 7: Low byte of the 16 bit CRC (0x75 in our example above)
  73
  74 The CRC is the same as that on the serial interface and is documented in the
  75 Davis "VantageSerialProtocolDocs_v230.pdf" document.  The first six bytes can
  76 be run through the calcuation and checked against the seventh and eight bytes.
  77 Alternatively, all eight bytes can be run through the calculation and the
  78 result will be zero if the CRC is valid.  Pocketwx uses the CRC algorithm from
  79 http://www.menie.org/georges/embedded
  80
  81 Bytes 3 - 5: Depend on the sensor being read at the time.  Need to work
  82 through these.  This is what is known now.
  83
  84 Message 4:
  85
  86 Bytes 3 and 4 are for UV Index.  The first byte is MSB and the second LSB.
  87 The lower nibble of the 4th byte is always 5, so they only use the first
  88 three nibbles.  A value of FF in the third byte indicates that no sensor is
  89 present.
  90
  91 The UV index is calcuated as follows.
  92
  93   UV Index = (byte3 << 8 + byte4) >> 6) / 50.0
  94
  95 Reference: http://www.wxforum.net/index.php?topic=18489.msg178506#msg178506
  96 Reference: http://www.wxforum.net/index.php?topic=18489.msg190548#msg190548
  97
  98 Message 6:
  99
 100 Bytes 3 and 4 are solar radiation.  The first byte is MSB and the second LSB.
 101 The lower nibble of the 4th byte is again always 5, so they only use the first
 102 three nibbles.  A value of FF in the third byte indicates that no sensor is
 103 present.
 104
 105   Solar radiation = (byte3 << 8 + byte4) >> 6) * 1.757936
 106
 107 Reference: http://www.wxforum.net/index.php?topic=18489.msg178506#msg178506
 108 Reference: http://www.wxforum.net/index.php?topic=18489.msg190548#msg190548
 109
 110 Message 8:
 111
 112 Byte 3 and 4 are temperature.  The first byte is MSB and the second LSB.  The
 113 value is signed with 0x0000 representing 0F.  This reading in the old version
 114 of the ISS was taked from an analog sensor and measured by an A/D.  The newer
 115 ISS uses a digital sensor but still represents the data in the same way.  160
 116 counts (0xa0) represents 1 degree F.  A message of
 117
 118 80 04 70 0f 99 00 91 11
 119
 120 represents temperature as 0x0f99, or 3993 decimal.  Divide 3993 by 160 to get
 121 the console reading of 25.0F
 122
 123 Message a:
 124
 125 Humidity is represented as two bytes in Byte 3 and Byte 4 as a ten bit value.
 126 Bits 5 and 4 in Byte 4 are the two most significant bits.  Byte 3 is the
 127 low order byte. The ten bit value is then 10x the humidity value displayed on
 128 the console.  The function of the four low order bits in Byte 3 that cause the
 129 apparent jitter are not known.  Here is an example.
 130
 131 a0 06 52 83 38 00 5a c8
 132
 133 ((0x38 >> 4) << 8) + 0x83 = 131 + 768 = 899 = 89.9% Relative Humidity
 134
 135 The displayed humidity at the time was 90%.  The console rounds the value.
 136
 137 Reference: http://madscientistlabs.blogspot.ca/2012/05/its-not-heat.html
 138
 139 Message e:
 140
 141 Rain is in Byte 3.  It is a running total of bucket tips that wraps back
 142 around to 0 eventually from the ISS.  It is up to the console to keep track of
 143 changes in this byte.  The example below is bound to confuse: the leading
 144 value is the elapsed time since data collection started (in seconds), all
 145 bytes have been converted to decimal, and the last two CRC bytes have been
 146 stripped off.  A tip of the rain bucket causes the value the ISS is sending
 147 from a steady value of 40 to a new value of 41.
 148
 149 2426.3,224,16,33,40,1,0
 150 2436.6,224,11,36,40,1,0
 151 2446.8,224,9,29,41,2,0
 152 2457.1,224,10,29,41,3,0
 153
 154
 155 To summarize:
 156 - Byte 0 is a header.
 157 - Byte 1 always represents wind speed
 158 - Byte 2 always represents the wind direction
 159 - Bytes 3-5 will carry other data according to the header in Byte 0
 160 - Bytes 6 and 7 always represents the checksum with high byte first
 161
 162 -------------
 163
 164 From my notes to help work the rest of this out:
 165
 166 Signed values from the weather station console are two's complement, least
 167 significant byte first.  Note that pressure is measured by the console and not
 168 the ISS, so don't expect it to appear in the STRMON output.
 169
 170 Update rates below are from Davis' specs and manuals.  Data sizes and signing
 171 are as per the loop command and are what one might expect out of STRMON but
 172 not always.  I noted above that wind direction via STRMON is actually one byte
 173 unsigned.  There may be other exceptions.
 174 - Outside temp: 10 seconds in 10th of a degree F, two bytes signed (message e
 175   in STRMON, bytes 3 and 4).
 176 - Winds speed: 2.5 seconds, one byte unsigned  (Byte 1 in STRMON, always)
 177 - Wind direction: 2.5 seconds, two bytes unsigned from 1 to 360  (one byte
 178   via STRMON, Byte 2 always)
 179 - Outside humidity: 50 seconds in percent, one byte unsigned (message a in
 180   STRMON, bytes 3 and 4)
 181 - Rain: 10 seconds.  This is in counts of 0.01 inches.
 182 - Pressure: in Hg/1000, two bytes unsigned  (Rate????)
 183 - Leaf Wetness: 40 seconds
 184 - Soil Moisture: 40 seconds
 185 - Solar radiation: 50 seconds
 186 - UV: 50 seconds
 187 - Soil Moisture: 62.5 seconds
 188
 189 I think all other outdoor related values are calculated in the console.
 190
 191 The only headers (ie Byte 0) I see from my wireless VP2 with no additional
 192 sensors connected are:
 193
 194 40 50 60 80 90 a0 e0
 195
 196 The rates they show up at are:
 197 -40 shows either every 47.5 or 50 seconds
 198 -50 shows every 10 seconds
 199 -60 shows every 50 seconds
 200 -80 shows every 10 seconds
 201 -90 shows either 45, 47.5, or 50 seconds
 202 -a0 shows alternately every 40 seconds and 10 seconds (interesting!)
 203 -e0 shows every 10 seconds
 204
 205 These rates along with the rates given in the Davis manual should make
 206 correlating the data a lot easier.
 207
 208 Copyright DeKay @ madscientistlabs.blogspot.com under the Creative Commons
 209 Attribution-ShareAlike License 3.0