Sunday, May 6, 2012

Here Comes The Rain

Today's weather at Mad Scientist Labs: Cloudy and Cold.  Wet and Miserable.  Rain, rain, and more rain.  In a word: perfect.
 This Takes Me Back...
As a (hopefully) interesting aside, The Cult used to go by the name of the Death Cult, and before that the Southern Death Cult.  I guess there is something to be said for brevity.  There's also something to be said for picking a name palatable to all those moms who buy music for their kids.  Music was on "records" or "LPs" back in those days.  And I walked to school uphill both ways.

With weather this lousy, going outside and taking care of various chores out there just isn't going to happen.  This gives me a perfect excuse to take it easy after a very busy week and do some stuff I enjoy doing.  What might this be, you ask?

Well, moments ago I pulled a good looking loaf of Jim Lahey's "Pane all’Olive" out of the oven.  This is a fancy way of saying No Knead Olive Bread.  How'd it turn out?
Damn Good, That's How.  And I Don't Like Olives.
I've been a big fan of his No Knead technique lately, since the taste to effort ratio is astronomically high.  Here is a link for this bread and two others that you might want to try.

I've also spent some time today reverse-engineering the STRMON data spit out from my weather station.  I had all of the weather-related parameters sorted out now with the exception of rain and humidity.  It was raining this morning, so that gave me the chance to figure rain out.  And figure it out I did.
Yay Me
In fact, I wrote up a bit of Python code to help me figure this out.  It grabs the STRMON data, timestamps it as the number of seconds since the script started, converts everything to decimal so the math is easier, and then writes the data as a CSV file.  I don't show the checksum bytes in the last two bytes of every message because that would just pointlessly make the file bigger.
2426.3,224,16,33,40,1,0
2428.9,80,15,31,66,83,0
2431.5,96,14,15,255,194,0
2434.0,128,12,39,29,27,0
2436.6,224,11,36,40,1,0
2439.2,80,14,20,66,81,0
2441.7,64,12,14,255,193,0
2444.3,128,10,19,29,27,0
2446.8,224,9,29,41,2,0
2449.4,80,11,25,245,65,0
2452.0,144,13,11,21,3,48
2454.5,128,12,8,29,27,0
2457.1,224,10,29,41,3,0
2459.6,80,9,32,245,67,0
2462.2,160,10,15,176,59,0
2464.8,128,8,21,29,25,0
2467.3,224,8,29,41,3,0
The rain was coming down pretty good and I watched this stuff scroll across the screen.  When the console added another hundredth of rain, I wanted to see the message that caused it to happen.  Let's cut the irrelevant crap out of the above.
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
2467.3,224,8,29,41,3,0
Message 244 is 0xe0.  I had suspected before that this message held rain, but I expected to see it in the second last field above.  What I thought would happen was the console would send a "1" any time the rain bucket tipped.  But then I saw this field bounce around between 1 and 3 randomly.  It turns out I was off by one byte.  Rain is actually in the byte before (40... 41).  What the ISS does is send a running total of rain between 0 and 255.  In the example above, it would continue to send 41 until the rain bucket tipped again.  Then byte 3 (counting from 0) in message 244 (0xe0) would change to 42.

This is smarter than what I was thinking.  My method could have had the console miss a count of rain every now and then if there were interference.  But by sending a running total, this can't really happen.  It is up to the console to track the changes in this byte.

I haven't figured out what those values bouncing around between 1 and 3 are.  I'm suspecting they are just noise from a sensor that I don't have and isn't connected.  Or something like that.  I plotted this field against the rain plot above and there was zero correlation.  In other words, I don't care.

One thing I discovered along the way and that I do care about.  In the example above where the STRMON 0xe0 message changes from 40 to 41, the change doesn't show up immediately on the display.  In fact, it didn't show up until the next 0xe0 message came along ten seconds later.  Interesting, and good to know as I continue my hunt for humidity.

"I'm an excellent driver."

4 comments:

  1. About the 1, 2, 3 ... The above snippet is consistent with ~(x & 1) being "different to last cumulative rainfall transmission". Perhaps the console waits until (x & 1 == 0) to be sure that it's received two readings in agreement before it commits the rainfall to the display?

    (x & 2) might relate to whether the rain bucket tipper is in "see" or "saw" orientation.

    Or not. Try it on your full dataset and see.

    ReplyDelete
    Replies
    1. Deborah, as Fabio points out, the data is checksummed and doesn't know the see vs. saw orientation. And I can't really try it on my full dataset: I had to watch the console display as the messages scrolled by to see this happen in the first place.

      Delete
  2. While your idea of the difference from the previous reading is good, I don't think the console should wait to get a zero difference before displaying information, because it has checksums to verify data correctness (link issues).

    Also, I don't think that the sensor can sense the bucket orientation, because (afaik) it has a single reed switch that gets a cycle (open-closed-open) while the bucket is tipping (in mid-tipping, when it is horizontal), so it is impossible to know if it's sitting on its left or right side.

    Speaking of this, I really don't get what the "metric unit" add-on for the rain bucket is. Is it a weight? Is it a magnet?

    ReplyDelete
    Replies
    1. The metric unit is a slightly ligther magnet so it flips more frequently. Every 0.0078 of an inch. So if you want better resolution from the gauge, use the metric unit. It is a different magnet rather than an add on.

      Delete