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|
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).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.
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.
|Now That's Pretty|
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 47The 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.
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
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...