SparkFun Qwiic Soil Moisture Sensor

[gigapod]

Board

SparkFun Qwiic Soil Moisture Sensor

Notes

• Driver

[sfe-SparkFro]

Tested examples on XRP, the basic driver functionality appears to work fine.

Example 2 changes the I2C device address. I ran it and set the adress to 0x5B as suggested by the example, and the sensor now seems to be bricked or something. Nothing shows up when doing an I2C scan. Not sure if this is an issue with the sensor or the Python driver.

[sfe-SparkFro]

So, after a bit too much troubleshooting, it appears that any address in the range of 0x40 to 0x77 causes the ATTiny to stop communicating over I2C, not even ACK. I've only actually tested 0x40, 0x5B, and 0x77, because it takes a while to actually test each address. 0x08 through 0x3F are all fine. No idea what the root problem is, everything seems fine to me in the firmware. I've tested 2 different boards, both exhibit the same behavior. Will just update the library to limit the address range I guess...

[sfe-SparkFro]

Tested on XBee as well, all good!

[faludi]

Having some trouble with the soil moisture sensor when running at bus frequency 400000. The device should be returning 10-bit values but is reporting some kind of 16-bit value instead. Also crashes frequently and becomes non-responsive until power cycled. Changing the bus frequency to 100000 fixes both of these issues completely.

My old code for the moisture sensor used the 100000 bus frequency because I had similar problems pre-library. I believe this might be a hardware issue? Simplest fix might be for qwiic_i2c to accept frequency values, and then pass freq=100000 from the moisture sensor library?

[sfe-SparkFro]

Thanks for the report! Do you have code you can share so I can test? And do you have any other devices connected to the I2C bus?

[faludi]

No other devices on the bus. Here's a code snippet. When the qwiic_i2c library is set to freq=400000 it produces values like 65407 when the probes are dry. And the device crashes easily, especially if moved or touched. Changing it to freq=100000 with the same code returns 1023 for dry as expected and the device is fully stable during normal use, returning 10-bit values.

import qwiic_soil_moisture_sensor
import time
moist =  qwiic_soil_moisture_sensor.QwiicSoilMoistureSensor()
moist.begin()
while True:
     moist.read_moisture_level()
     print(moist.level)
     time.sleep(0.5)

[sfe-SparkFro]

Thanks!

Hmm, I'm unable to replicate on my end, 400kHz works just fine. I've tested with 2 different soil sensors, both are fine. Are you able to look at the I2C traces on an oscilloscope and/or logic analyzer to see what's actually happening on the I2C bus?

Something else to note - the ATTiny on the soil sensor does perform clock stretching on the I2C bus, which is especially noticeable at 400kHz:

Like I said, it's working fine on my end, so there's not a lot else I can do to help debug unfortunately. Do you have a second XBee you can try, or a second soil sensor?

[faludi]

No difference when changing XBees. Tried swapping cables but it seems like longer cables make the problem worse. Setting freq=100000 makes the sensor work reliably with all cable lengths. Unfortunately I only have a single soil sensor right now, so I can't swap that out. Inspected it visually with a loupe just in case and didn't see anything amiss. I don't have a scope here so that's all the useful insights I can provide at this time.

For the moment I'll just hand-code a lower bus rate for this device and move on to the next build. We'll be starting a parts order next week so when that arrives I can try swapping out the sensor. Thanks for looking into this!

[sfe-SparkFro]

Interesting. I just tested again with some exceptionally long Qwiic cables (about 1m total length, plus an oscilloscope probing in the middle of it) and it's still getting data just fine. The data pin does have some ringing on it when the clock pin changes, but the data is still coming across fine at least.

One other thought - I'm currently using the XBee while it's inserted into our upcoming Arduino shield (actually, a previous revision of it). This is the entirety of my setup (sans 1m cable), which works fine at 400kHz:

Perhaps you could share a picture of your setup? Trying to figure out what's different between our setups to better understand what could be the root problem. I even tried disconnecting the pullup resistors on our Arduino shield, but it's still working at 400kHz (rise times are slower, but still good enough with the 1m cable).

[faludi]

I'm using the development board. This is the setup that's working fine with the lower frequency. And bugs out when I go to 400000.

[sfe-SparkFro]

Gotcha, thank you! Let me see if I can nab one of those to play with.