This sensor uses a TH02 sensor module and the examples for it work very well (check the python example), but the moment you connect it to the GrovePi, the GrovePi is unable to do any read operations. When you run a led_blink or a led_fade program with the GrovePi, it works, but when you run something like analog_read, it just gives IOErrors.
Without the temperature sensor, the GrovePi responds back with a 32byte array when you do analog read (good_read.jpg), but when the temp sensor is there it just replies back with a 0 and now acknowledge (no_reading.jpg). You can see the difference when hot-plugging the sensor (temp_sensor_failing.jps). We have tried changing the I2C address of the grovePi because the sensor uses 0x40 as it’s address and the GrovePi 0x04, but that did not help. We have tried it with GoPiGo which is logically almost similar to the GrovePi and the sensor works there. But when we burn the GrovePi firmware to the GoPiGo, we see the same errors. This points to a software/firmware error on the GrovePi and not something on the hardware.
It would be great if any users out there who already have the sensor can try this out and let us know how it goes for them. If you were able to get the sensor working, it’ll be great if you can share the solution with us.
Hey bigbuilder,
Are you getting the same results too or anything different. Were you able to find anything else that might be responsible for the problem.
The DHT sensor has always been flakey - but it was good enough with some clever exception handling to weed out the -1 and nan responses. However, I was playing with the firmware, hoping that an update might help in general the performance of sensors on the GrovePi+, and the performance fell on everything, mostly getting -1 responses from the DHT sensor, but also, the firmware version python program no longer works. Interestingly, even if I restore the prior firmware version (to ANY version - I tried all of them) or do back to a .txt file to “fix fuses” you posted last year, I can not longer get the firmware version program to work. It’s exactly the error you saw last year where the fix was the .txt file you posted.
I am using a well functioning Raspberry Pi 2, by the way.
I wonder if replacing with a B+ version might now yield different results?
Another problem I’ve observed that I THINK is separate (?): There is a lot of static/interference on the sensor cables that leads to poor sensor reads. This is true of all the sensors, but really a big effect on the GPS one I recently bought that operates at 9600 baud over the GrovePi+ serial port. That’s too high a data rate for an unshielded cable in my experience. The monitor interferes with the sensors through the cables, and the sensors interfere with each other (a little). I’m considering shielding solutions, right now…
Overall, it’s an interesting problem (or problems). I’m actually learning a lot by trying to fix it.
The DHT sensor has always been flakey – but it was good enough with some clever exception handling to weed out the -1 and nan responses. However, I was playing with the firmware, hoping that an update might help in general the performance of sensors on the GrovePi+, and the performance fell on everything, mostly getting -1 responses from the DHT sensor, but also, the firmware version python program no longer works. Interestingly, even if I restore the prior firmware version (to ANY version – I tried all of them) or do back to a .txt file to “fix fuses” you posted last year, I can not longer get the firmware version program to work. It’s exactly the error you saw last year where the fix was the .txt file you posted.
The DHT sensor indeed needs some exception handling but it turns out to be pretty easy to implement.
I am using a well functioning Raspberry Pi 2, by the way.
I wonder if replacing with a B+ version might now yield different results?
I am using a well functioning Raspberry Pi 2, by the way.
Another problem I’ve observed that I THINK is separate (?): There is a lot of static/interference on the sensor cables that leads to poor sensor reads. This is true of all the sensors, but really a big effect on the GPS one I recently bought that operates at 9600 baud over the GrovePi+ serial port. That’s too high a data rate for an unshielded cable in my experience. The monitor interferes with the sensors through the cables, and the sensors interfere with each other (a little). I’m considering shielding solutions, right now…
I have seen the wires misbehaving only a few times.