Topic: Deciphering STRMON output

[DeKay]

If anybody wants to join the party, all you need is Excel.  Here is a link to the humidity data I collected via Cumulus and my DIY datalogger after running STRMON for a while.

And here is a picture to catch your interest.  You can see as the humidity drops, Byte 3 cycles through couple times while there are some discrete steps in Byte 4.  The weird thing is that Byte 4 isn't flat as in a high byte, low byte kind of thing.  There is jitter on it that I wouldn't expect.  Weird.  Anybody care to tackle figuring out the formula that combines Byte 3 and Byte 4 to compute humidity?

[Weather Display]

the blue line, byte 4, must be a multiplier (i.e a constant (which though steps when the other byte wraps around)

[Kurgan]

EDIT: see my next post!

Well, it seems to me that the jitter on byte 4 should somehow be ignored. Maybe you have to discard the least significant bits of byte4. As you can see, byte4 stays "around" a determined value while byte 3 goes up and down following the hum curve. If you consider byte4 values in steps, eliminating the jitter, you have what seems to be a good correlation.

Or maybe the sensor outputs two bytes that for some internal weird method are interwoven, so you see jitter on byte 4 that is actually a "part" of a more-than-one-byte number that should be byte 3. I don't know if I made myself clear. Consider a byte 3 that is a 9 bit or 10 bit number composed of byte 3 plus bit 2 and bit 4 of byte 4, for example.

Have you found a datasheet for the sensor? It could help (if the sensor is digital in itself).

[Kurgan]

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.

[DeKay]

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 think you nailed it.  Thank you!   

I plotted the data and it lines up very, very well.  The 12 bit number works out to the humidity displayed on the console * 10, so a 12 bit value 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.  I can now interpret all of the weather related values coming back from my ISS   

[Kurgan]

I'm glad it works. Now you can set up a receiver that gets data directly from the ISS, if the data format from the ISS is the same as the STRMON output.

[DeKay]

I'm glad it works. Now you can set up a receiver that gets data directly from the ISS, if the data format from the ISS is the same as the STRMON output.

It is the same, and I can already get data directly from the ISS. 

So now I can get all the weather data my ISS can send, but other mysteries are buried in the data.  Grab the data I linked earlier and look around.  For example, here is data from message 0x90 (144 decimal).  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.  Here is a little snippet.  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.

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

C5250 tells me that the ISS also sends a reading of its battery voltage to the console  That is also hidden away somewhere in all this data.

Anyhoo, I whipped up a plot showing how well the humidity data pulled from the logger agrees with the STRMON calculation.  This makes me pretty happy.  Doesn't take much...

[johnd]

I think you should note the firmware revision of the SIM. It looks to me like the ISS data will also have a field for supercap voltage, but I'm not sure whether there always has been a slot for this, which may or may not have been populated hitherto, or if it's maybe going to be (if it hasn't happened already) a new/revised ISS packet type.

[Kurgan]

This is very nice indeed, because as an owner of a cabled ISS I can simply put a RS422 receiver in parallel to the data line from the ISS and read the data too. Now I only need to write my own datalogger program that gets data from the ISS stream, decodes it, and uses it.

This means that we could buy a cabled ISS without console, connect a power supply and a rs422 serial, and have a nice computer-based datalogger/console/web server.

[SLOweather]

This is very nice indeed, because as an owner of a cabled ISS I can simply put a RS422 receiver in parallel to the data line from the ISS and read the data too. Now I only need to write my own datalogger program that gets data from the ISS stream, decodes it, and uses it.

This means that we could buy a cabled ISS without console, connect a power supply and a rs422 serial, and have a nice computer-based datalogger/console/web server.

Without a barometer, which is in the console.

[dalecoy]

A cabled Envoy would "solve" that deficiency.

[Bushman]

Or a 40 buck 1-wire baro

[C5250]

C5250 tells me that the ISS also sends a reading of its battery voltage to the console  That is also hidden away somewhere in all this data.

Transmitter Battery status is bit 3 of the sensor/TX ID byte. Repeater Battery status is also a bit, but I don't know where that hides, yet.

[Bushman]

C5250 tells me that the ISS also sends a reading of its battery voltage to the console  That is also hidden away somewhere in all this data.

Transmitter Battery status is bit 3 of the sensor/TX ID byte. Repeater Battery status is also a bit, but I don't know where that hides, yet.

Status yes - voltage no.  I tried a while ago and came up short.

[DeKay]

Or a 40 buck 1-wire baro

Exactly.  If someone is going to roll their own interface to an ISS, it probably isn't a big step from there to use a separate pressure sensor.  And Sparkfun has several barometic pressure modules for roughly half that.

Transmitter Battery status is bit 3 of the sensor/TX ID byte. Repeater Battery status is also a bit, but I don't know where that hides, yet.

Then that bit being zero must indicate battery OK, because it is zero in all my messages.  Any other bits of info tucked away in the STRMON data you or anyone else might know about?

BTW, there is a nice array of test circuits here that would enable me to figure out where the Solar and UV sensors fit in STRMON.  Might have to play with this one of these days.

[C5250]

Then that bit being zero must indicate battery OK, because it is zero in all my messages.  Any other bits of info tucked away in the STRMON data you or anyone else might know about?

Sort of, I believe it will only be set when the transmitter has to operate off of the battery. Not sure how that would work, I did once do a STRMON capture while "Low Battery" was displayed on the Console and didn't see that bit set. But that was during the day, so it may only be set when the transmitter measures a low voltage, but before it gets too low to still function. From the looks of things, it is set if detected, and (normally) only cleared when a new day is started.

[Kurgan]

Without a barometer, which is in the console.

DOH! I keep forgetting about the barometer.

Ok, so I need a wired envoy, it seems. Does the envoy provide serial output similar to the one from the console + datalogger? Does the Envoy need a datalogger?

[belfryboy]

The envoy does need a datalogger. You could of course use one of mine, or a SLOWeather serial cable

[Kurgan]

I am waiting for the connectors to arrive from taiwan, then I will build my own datalogger. What I really don't understand is why the envoy needs a separate datalogger. Without a datalogger it's useless, isn't it?
 

[johnd]

What I really don't understand is why the envoy needs a separate datalogger. Without a datalogger it's useless, isn't it?

Why is that confusing though? The Envoy has essentially the same main circuit board as the standard console but just lacks the display PCBA. It's for users who don't need the display function of the standard console and are happy to save a little money. Inevitably the situation is that the Envoy has no more (and no less) external connectivity than the standard 6312 console. So - for most users at least - it needs the logger.

[Kurgan]

While the standard console can be used "as is", the envoy is useless without a serial output, so I think that a serial output should be included, not an option. Anyway, no problem, I can build my own serial cable.

[Faceng Ret]

If they built the envoy with a serial output, they would have to build it with a USB output and a IP output also! It is more cost effective for Davis to build it the way they do and let the user decide the output needed.

[johnd]

If they built the envoy with a serial output, they would have to build it with a USB output and a IP output also!

Exactly! The architecture of the Vantage system is that the receiver/display (ie the console) is separated from the (intended) PC interface/logger/added functionality so that the user can choose from the whole range of loggers (including eg the - sadly under-used  - Alarm unit and the other three advanced logger types, in addition to the serial/USB/IP types already mentioned).

Why should the Envoy be an exception to this general approach? The Envoy is just one component of a system, not a standalone unit.

(This isn't to say that it wouldn't have been better for Davis to bring out the COM connections perhaps to a separate RS232 connector as well, though this would obviously have added a little to the total cost. But I can see the logic behind the current approach.

[Bushman]

At almost $300 MSRP for the alarm unit I can see why it is underused.

[johnd]

At almost $300 MSRP for the alarm unit I can see why it is underused.

I know that this is primarily a hobbyist forum, but don't forget that Davis stations are widely used commercially, in education etc and in these other markets the $130 extra of the Alarm WL (almost certainly less online) over the standard logger really isn't a high price.

To some extent I think that even calling it an Alarm logger is misleading and undersells the product. It's a programmable external control module, with four pairs of contacts which will switch up to  1A @ 50v (obviously more with an intermediate relay) and each pair fully programmable to respond to thresholds, high or low, in any of the weather parameters that the weather station can measure (and still function as a standard logger). I can't believe that more users haven't been attracted to use it in all sorts of interesting applications - there are plenty of people that buy the IP logger at the same price as the 6544 Alarm logger, for example. It probably just needs to be marketed better.

Sorry - this has drifted seriously OT.