Deciphering STRMON output

[DeKay]

I am trying to decipher the STRMON output from the console that shows the readings from the ISS.  So far I have wind, wind speed, and temperature nailed.  Humidity is a work in progress.  Rain shouldn't be hard once it actually rains around here.  This link explains what I have figured out so far.

My problem is that I have an ISS without the various add-on sensors.  It would help me out if someone out there with such beasts was able to get a connection to their console with a terminal program and log the STRMON output for five minutes a couple different times.  Either try to work out what is what or send me a email of the raw data to the email address in my profile.  Along with the output, I'd need to know what the value displayed on the console was at the time.  I've written up how to use STRMON here using a USB to low voltage serial adapter.  However, my guess is that you could also make this same connection using the dongle that comes with the Weatherlink software.

For anyone that really wants to dive into this, here is what I've found works well.  Take the STRMON output that looks like this

0 = e0
1 = 7
2 = b7
3 = 73
4 = 3
5 = 0
6 = 98
7 = 1b

and format it so that each message is shown in a row.  Then sort the rows by the first byte.  For example:

80 04 70 0f 99 00 91 11
80 04 70 0f 99 00 91 11
80 04 70 0f 9b 00 f7 73
80 04 70 0f 9b 00 f7 73

Do this a couple of times under different conditions and look for trends.  Doing this I was able to figure out that the messages above say that the wind speed is 4 mph, wind direction is 158 degrees, and the outside temperature is 25.0F.  It is a fun puzzle to figure out.

By the way, does anyone know the part number of the analog humidity sensor used in the older ISS and Envoys?  I'm not talking the SHT11 used in the newer ones.  Based on a chat with C5250, I think it might be a Humirel HS1101 (link to datasheet).  Can anyone confirm this?

[johnd]

By the way, does anyone know the part number of the analog humidity sensor used in the older ISS and Envoys?  I'm not talking the SHT11 used in the newer ones.  Based on a chat with C5250, I think it might be a Humirel HS1101 (link to datasheet).  Can anyone confirm this?

Based on physical appearance, it's not that part. The 7346.029 H part of the T/H sensor is a vertically-mounted white rectangle that doesn't appear protected and hence always looks quite vulnerable once the standard Davis pyramid grid is detached.

[DeKay]

Based on physical appearance, it's not that part. The 7346.029 H part of the T/H sensor is a vertically-mounted white rectangle that doesn't appear protected and hence always looks quite vulnerable once the standard Davis pyramid grid is detached.

Thank you!  Your message led me to this link that has a good discussion of compatibility between the old and new sensors.  That led me to this post where someone posted a link to a datasheet they thought was for the old analog sensor.  Please take a look at this datasheet and let me know if you think that is correct.

I came across another link to yet another sensor apparently used by Davis, but I don't believe this is the droid I am looking for.

Doing all this, I stumbled across a great blog that opens up the ISS and shows some interesting test circuits for the various sensors.  This might come in handy down the road.  Take a look.  I believe this blog is from the same Mateo here who was trying to change the ticker displayed on the bottom of the console.

[johnd]

Thank you!  Your message led me to this link that has a good discussion of compatibility between the old and new sensors.

Yes, funnily enough, I do recognise that link - since I wrote it  . (Needs updating though, along with the rest of the wiki, which hopefully will happen sometime soon, but probably moved to a different website.)

Please take a look at this datasheet and let me know if you think that is correct.

It's possible but it doesn't look quite right. I'll get one out sometime and take a closer look. IIRC one of the problems was that there was no very clear identification on the sensor.

I came across another link to yet another sensor apparently used by Davis, but I don't believe this is the droid I am looking for.

No that doesn't look right at all.

[

Doing all this, I stumbled across a great blog that opens up the ISS and shows some interesting test circuits for the various sensors.  This might come in handy down the road.  Take a look.  I believe this blog is from the same Mateo here who was trying to change the ticker displayed on the bottom of the console.

Hmm, I don't know. Interesting that it has the detail about the v1.6 F/W, which is not general knowledge (unless I've posted it perhaps here previously and forgotten about it) and is actually the detail to look for to check compatibility with the .166 T/H sensor rather than the Jan 2006 date. (You do find the v1.6 F/W in a few ISS's from late 2005. Personally, I find that the 7911 and 6410 anemometers are interchangeable for all practical purposes.

[DeKay]

Thank you!  Your message led me to this link that has a good discussion of compatibility between the old and new sensors.

Yes, funnily enough, I do recognise that link - since I wrote it  . (Needs updating though, along with the rest of the wiki, which hopefully will happen sometime soon, but probably moved to a different website.)

Please take a look at this datasheet and let me know if you think that is correct.

It's possible but it doesn't look quite right. I'll get one out sometime and take a closer look. IIRC one of the problems was that there was no very clear identification on the sensor.

I had a feeling you wrote that wiki up.  What were you thinking of in terms of a new site?  I was actually tossing around the idea of starting something up on wikia.com to collect all the bits and pieces I've been sorting out.

I thought the sensor didn't look quite right, but I'd really appreciate it if you could take a look.  The humidity message in STRMON is really confusing me.  Most of the time the data in the message looks right, but at other times it makes no sense at all.  I'm hoping a datasheet would help me out.  It isn't as straightforward as I once thought.

[C5250]

I came across another link to yet another sensor apparently used by Davis, but I don't believe this is the droid I am looking for.

This is the sensor that is in my Envoy, and was likely also used in Consoles of the same vintage. It seems Phillips also made this sensor at one time and it appears that's where the "H1" it is marked with came from. The outdoor sensor could be something different.

[johnd]

Here's a picture of the analogue T/H from the VP2 ISS. Sorry, this was just taken with a phone and isn't very clear but hopefully better than nothing. The only marking that I can see on the sensor itself says Z141, but I've never been able to tie this to any maker or OEM part number.

It's a 2-pin part I think and just to provide a little description to supplement the picture, the sensor has a rectangular plastic outer frame, across the central part of which is stretched a small layer or sheet of flimsy white material - presumably the active humidity-sensing surface. There's actually a small rectangular gap at both top and bottom between the sheet and the sensor frame.

I'll see if I can get a better photo sometime but it really needs a macro shot from a proper camera I think.

NB The attached image is obviously taken with the normal 'pyramid' grid cover detached.

[belfryboy]

here is another shot of it.

[johnd]

Thanks Rob - it's obviously a 4-pin part and I was misremembering - I have had them unplugged before but so long ago that I'd forgotten. I think that when it's plugged in, only the two outside pins are obvious.

[Faceng Ret]

Sure looks like a two pin part to me as there are only two sockets on the board. That which looks like two more pins in the picture I believe are shadows.

[johnd]

Sure looks like a two pin part to me as there are only two sockets on the board.

OK I retract my retraction . I've just pulled one out myself and yes back to my original thesis that it's strictly a 2-pin part (well the one I have here in my hand anyways). And I now I come to look more closely at Belfryboy's image, the board has just two sockets.

Shame that we can't identify the part because - assuming the sensor element was still available, which I doubt - it would be a very simple swapout part for users who still have the old .029 part (provided you keep your fingers off the element surface!). And, from memory, it might be the same element as in the 7859 WMII sensor which is also no longer available from Davis.

[belfryboy]

I have had a look to see what part it is and really struggled, although it shouldn't be too hard to replicate, as i think the Davis circuit is very similar to this



I may give it a go sometime soon.

[DeKay]

I very much appreciate the trouble you guys are going to here.  Figuring out humidity is making me crazy.  This is 47% RH at 53 deg F.  Counting from 0, the humidity data is in Byte 4, I think.

a0 0a 50 d4 19 00 d2 02
a0 0c 49 d4 19 00 f7 57
a0 0c 57 d5 1b 00 1f f8
a0 0c 5a d6 1b 00 7f 2e
a0 0d 55 d7 19 00 50 c3
a0 0d 56 d4 19 00 92 4f
a0 0e 50 d5 1b 00 0a 56
a0 0f 53 d4 1b 00 0c eb
a0 0f 56 d4 1b 00 b0 ae
a0 10 55 d7 1b 00 13 81
a0 10 56 d6 19 00 d9 0f

I am 100% sure message a0 is humidity.  Power off the console, power it on, fire up STRMON, and the display updates humidity once a0 comes in.  Note that byte 1 is wind speed, byte 2 is wind direction, and bytes 6 and 7 are CRC.  Ignore them.  We are interested in the d4 / 19 type values above.

I did four samples at four different temperatures and humidities, did a linear regression, and got a fit that agreed with the console to around 1%.  And I was happy.  Convert byte 4 to decimal and 10.40 + 1.41*the reading and you're done.  But then I did another sample and for a similar humidity, and the byte 4 value was maybe a quarter of what I would have expected.

I have a feeling that the truth might be that the reading somehow ties byte 3 in.  But look at how the readings bounce around.  If one of these bytes was acting as a Most Significant Byte, then the console reading would be all over the map.  Even byte 4 bounces around.  If it is only based on Byte 4, then the console must be doing some filtering.

One suspicion I had was the console is representing the humidity as a ratio of Byte 3 and Byte 4.  Or one value over the sum of the others to somehow represent the pulse width in an RC circuit.  I don't know.  What I think I'm going to have to do is set up my DIY datalogger and record data over a long period, all the while logging STRMON output at the same time.  Hopefully from that I'll see a pattern that helps me figure this out.  I was hoping that the datasheet from the original part the ISS was designed to (the ISS seems to emulate the readings of the old humidity part even with the new sensor in place for compatibility reasons) would give me a better clue.

[SLOweather]

Well, in looking at the "Vantage Console Features" matrix on p. 26 of the 2011 catalog, it says that Outside Humidity updates every 50 seconds. So, how does that fit in with what you are observing? Perhaps the ISS sends the same value for 50 seconds, then a value that essentially means, "New value coming next".

[SLOweather]

After studying that matrix and taking out the calculated variables, the fastest updating ISS values are:
wind speed/direction at 2.5 seconds,
temperature at 10 seconds,
rainfall amount at 20 seconds
outside RH, solar, and UV at 50 seconds,

The there's:

leaf wetness at 50 seconds, and
soil moisture at 75 seconds. I don't know if those are a part of the regular ISS-style stream or if there is a different one for that type of station.

I suppose a lot of this timing is done for battery life issues, because some things just don't change very fast.

Another thing to keep in mind is that Davis has been known to tuck a value in somewhere where it's not obvious. For instance, in the LOOP data from the console, there are 4 leaf wetness values, but only 2 are allowed on a console. The fourth is really the bit-wise packed repeater battery status, and the thrid is presumably not used.

You do know that someone has hacked the cabled version of this and is selling an interface for it? Do you suppose the data packets are the same?

[DeKay]

After studying that matrix and taking out the calculated variables, the fastest updating ISS values are:
wind speed/direction at 2.5 seconds,
temperature at 10 seconds,
rainfall amount at 20 seconds
outside RH, solar, and UV at 50 seconds,
<snip>

No need to have gone to this trouble.  All this is containing in the link in my original post. 

Well, in looking at the "Vantage Console Features" matrix on p. 26 of the 2011 catalog, it says that Outside Humidity updates every 50 seconds. So, how does that fit in with what you are observing? Perhaps the ISS sends the same value for 50 seconds, then a value that essentially means, "New value coming next".

I kind of doubt it, but you never know.  All the other messages I've seen so far stand alone, and the humidity is a number from 0 -100% and could easily have been represented in one byte.

Speaking of rate, the really weird thing about the a0 message is that it is irregularly spaced and I have no idea why.  eg. 39.4F at 24% relative humidity.  Note that there is comparable jitter between all the messages.

a0 05 00 f2 0a 00 a0 86
<15 rows of data deleted>
a0 04 0d f3 09 00 51 32
<Only 3 rows of data deleted>
a0 04 0c f3 0b 00 41 e4
<15 rows of data deleted>
a0 09 07 f2 09 00 2f d3
< Only 3 rows of data deleted>
a0 07 0a f2 0a 00 8c ae

This works out to a message after 40 seconds, then 10 seconds, then 40 seconds...  The console might average the adjacent ones to come up with the 50 second interval stated above.

You do know that someone has hacked the cabled version of this and is selling an interface for it? Do you suppose the data packets are the same?

Very likely.

[C5250]

Speaking of rate, the really weird thing about the a0 message is that it is irregularly spaced and I have no idea why.  eg. 39.4F at 24% relative humidity.  Note that there is comparable jitter between all the messages.

It seems to me you only have one transmitter, so you may not be seeing the issue I have seen, and that is that the sprinptf function that STRMON uses for that stupid output format takes too much processing time and the echo of some packets is incomplete. I have 4 transmitters, and I see the output of many packets are cut short. Might be something to check for.
 

[DeKay]

It seems to me you only have one transmitter, so you may not be seeing the issue I have seen, and that is that the sprinptf function that STRMON uses for that stupid output format takes too much processing time and the echo of some packets is incomplete. I have 4 transmitters, and I see the output of many packets are cut short. Might be something to check for.
 

Yup, just one transmitter.  I'm pretty sure my packets are coming out clean.

[Kurgan]

Great detective work you are doing here. I follow your posts and (still) cannot contribute because I am waiting for the components to arrive to build my own datalogger interface.

Now I would like to go one step further. I have a cabled VP2, and I want to sniff sensor data right from the cabled connection. I understand that it is an RS422, at 4800, 8N1. When I will have built my 422 interface, I would like to decode data from that connection, so I can use the data with an APRS TNC (from my decoder) and with a weather software on a different computer (from the console + datalogger).

Now, the question is: is the strmon output the same (apart from formatting) of the raw sensors data?

[DeKay]

Figured out today that the ISS sends a running count of bucket tips representing rain in message 0xe0, byte 3 (counting from zero).  It gets up to 255 and then wraps around to zero.  It is up to the console to keep track of what that means.  This is certainly more robust than it just sending a single message whenever the bucket tips, since you could lose a tip now and then due to interference.  More here.

[dalecoy]

Thanks for the continuing investigation and documentation.

You might want to change this statement in your blog: "What the console does is send a running total of rain between 0 and 255.", or at least clarify that the information source is from the ISS - if I correctly understand what's going on.

[johnd]

Figured out today that the ISS sends a running count of bucket tips representing rain in message 0xe0, byte 3 (counting from zero).  It gets up to 255 and then wraps around to zero.  

You might want to keep monitoring that byte. My information was that the ISS counts up to 75 tips (or some nearby number but IIRC it was 75). This seems like an odd number to choose to me - it's obviously not directly a binary number - but that was the info passed to me. Perhaps it was incorrect, not deliberately but maybe a mental typo at Davis, and so it would be useful to confirm - 255 would make a lot more sense.

[DeKay]

dalecoy: I'll check that.  Thanks.

johnd: I'm seeing 99 in that byte as I type this, but I'll keep an eye on it.

[knobunc]

This may be completely off-base, but as I recall there was some discussion in the Davis manual about different humidity measurements.

I bet your station is showing relative humidity, but that may not be what the sensor is measuring.  So the station may need to transform the raw reading to relative humidity based on the temperature.

[DeKay]

This may be completely off-base, but as I recall there was some discussion in the Davis manual about different humidity measurements.

I bet your station is showing relative humidity, but that may not be what the sensor is measuring.  So the station may need to transform the raw reading to relative humidity based on the temperature.

Not a bad thought, so I looked at this.  Both the newer SHT-11 and the Honeywell analog one linked above measure relative humidity directly.  That is what is displayed by the console.

I collected a bunch of data on humidity at the same time I was looking at rain.  Davis does some strange things in sending the humidity data from the ISS to the console.  It certainly isn't what I first thought.  There are two bytes that are important, not just one, in the a0 message.  I think I just need to spend some time staring at some plots in Excel to figure the pattern out.