Shop OBEX P1 Docs P2 Docs Learn Events
Sensirion SHT3x Driver — Parallax Forums

Sensirion SHT3x Driver

Good afternoon Parallaxians!

I've started writing a driver for this combination Temperature/Rel. Humidity sensor (only the I2C variant - there's also an analog variant, if I'm not mistaken):
https://www.sensirion.com/en/environmental-sensors/humidity-sensors/digital-humidity-sensors-for-various-applications/

The driver lives on github https://github.com/avsa242/sht3x-spin

It should work with SHT30, 31 and 35, although I only have a 31 to test it with.
It's still relatively early in development, although most everything is implemented. It uses one additional cog (for the PASM I2C driver - as always, many thanks to JonnyMac for this).

Included is a serial terminal-based demo that can be used to continually read the sensor data, as well as the serial number and status reg. All that might need to be changed are some constants at the top of the file for things like clock speed, pin assignments (this was developed on a PropBOE, so the "standard" I2C pins weren't used)

Cheers,
Jesse

Comments

  • Nice job Jesse, I'll take a closer look. I use the SHT31 a lot these days and can confirm that the SHT30 and SHT35 use the same code base. I think I posted my own Spin driver for it somewhere on the forum, but all I find is my BASIC Stamp code. My Spin is different from yours, in that it implements only the one-shot mode with clock stretching, pretty utilitarian.
  • Thanks Tracy...
    Before I bought the module (and also after I received it), I tried to find evidence that anyone else had created a spin/pasm driver for it, Googling the forums and the OBEX. I did indeed find some BASIC threads related to it, and I think there was even a brief Forth-related post that had the text "SHT31" in it, but couldn't find anything that looked obviously related to SPIN.

    It's funny you mention the one-shot mode only, as when I was writing this object, and especially now, I wonder a bit about the thought process behind Sensirion's implementing both it and periodic mode. I think the one-shot method is much simpler - I mean either way, you have to poll the sensor for the current reading, so...? The only detail that caught me though, is that it's at least implied in their Alert application note, that the Alerts only function when the Periodic mode is used. This does seem to be true, as it seems the alert bits are only set in the status register when the sensor is actively in periodic measurement mode. I haven't yet tried it, but I assume the alert pin is also only asserted in this case. Maybe some of this is moot when being used on a microcontroller that doesn't have interrupts, though?

    FWIW, my version needs a lot of simplifying, which I intend to go back to do - there's currently a lot of duplication of the I2C calls, as I ran into some issues when I got the first version of the driver mostly done and realized some of the problems I was having was that not every write or read transaction is performed with exactly the same conditions as others, despite seeming like they should work the same way. *shrug* Frustrating at times, but fun to make milestones learning it...

    Cheers,
    Jesse
Sign In or Register to comment.