It's Not The Heat...

Last time around, I wrote up how rain information is sent from the Davis Weather Station Integrated Sensor Suite (ISS) to the console sitting on my kitchen counter.  That left me with one more piece of weather data to figure out: humidity.  Evil humidity.

I had been puzzling over humidity for weeks before I decided to switch to rain.  The data seemed to make sense for a while and then I would get a datapoint that made no sense at all.  I was pretty certain that humidity was sent in message 0xa0 from the station, and I was also pretty certain that the data would be contained in just one byte.  Sounded reasonable because humidity is displayed on the console to the nearest percent.

Humidity was stumping me until I got serious last weekend and wrote a Python script to collect STRMON data continuously while my DIY datalogger dutifully captured the console's interpretation of the data.  Then I could make some plots and figure out what was going on.  Like this:

Click To Embiggen

It was quickly apparent in looking at this data that two bytes were involved in encoding humidity.  You can see as the humidity drops, Byte 3 cycles through a couple times while there are some discrete steps in Byte 4.  The weird thing was that Byte 4 isn't flat as in a high byte, low byte kind of thing.  There is jitter on it that I didn't expect.

Puzzled, I thought some fresh eyes on the subject might help.  So I posted this plot and a link to the data I collected on this wxforum post.  It was user Kurgan for figured it out for me within eight hours of my post.  He da man!  As he wrote in his post:

If you take byte 4 and convert it to binary, you will see that the values is has assumed in the test, which are 24,25,26,27 then 40,41,42,43 and then 56,57,58, 59 are made of two parts: the first four bits are fixed (the big steps), and the last four are variable (the jitter).

So:

 24 25 26 and 27 have the first four bits set at 0001
 40 41 42 and 43 have the first four bits set at 0010
 56 57 58 and 59 have the first four bits set at 0011

So, you have to add the first four bits of bit 4 to byte 3 to get a 12-bit number. Try to plot this 12-bit number and compare it to the hum graph.

The last four bits of byte 4 are something else, or are random noise. I don't know.

I thought he had it wrong the first time I wrote up this post but forgot that the values in Byte 4 as written above had been converted to decimal.  Convert them back to hex for his explanation to make sense.  Next step: make a pretty plot.

Now That's Pretty

That is bang on.  The calculated value works out to the humidity displayed on the console * 10, so a calculation of 750 = 75% RH.  The lines don't sync perfectly because the timing is a bit off and the logger logs in intervals of 1 minute vs irregular intervals on STRMON.

As I wrote in a post that followed, there are other mysteries are buried in the data.  For example, here is data from message 0x90 (144 decimal). 

39.2    144   16   1   47
90.5    144   16   1   63
141.7   144   16   1   79
193     144   16   0   95
244.2   144   16   1   111
295.5   144   16   0   127
346.7   144   16   2   143
398     144   16   3   159
449.2   144   13   3   18
500.5   144   13   3   34

The columns are elapsed time in seconds, message number, byte3, byte4, and byte 5.  I deleted the wind and crc data.  The numbers in byte 5 jump up and down mostly in step sizes of 16 before resetting and then starting over again at some different value.  Looks like a counter of some kind.  And why is byte 4 in this same message just bouncing between 0 and 3?  Byte 4 in the rain message (0xe0, 224 decimal) does this too.  I'm also told that the ISS sends a reading of its battery voltage to the console  That is also hidden away somewhere in all this data I've collected as well.  And then of course there is data from the sensors I don't have: solar, leaf wetness, and soil moisture.

But I don't care too much.  I'm getting all the weather related data my ISS can send me.  Figuring out other stuff down the road would just be a bonus.  Now it should be a relatively straightforward matter of writing some code for the Alternative Davis Weather Station Receiver and having its values exactly match the values displayed by the console.  Cool.

If only I had more time to actually do this...