Piezo sensor I2C error

Fellow Tinkers,

I am trying to get my new piezo vibration sensor up and running. However, when I run the example code, it crashes because of something going wrong with the I2C communication I believe.

I am running a RaspberryPi 3B with GrovePi+ board, and piezo sensor.

The error I am getting is:

File"grove_piezo_vibration_sensor.py", line 49, in

            print(grovepi.analogRead(piezo))

         File"/home/pi/...", line 227 in analog

Read

return number[1] * 256 + number[2]

TypeError: ‘int’ object has no atribute ‘getitem

I tried changing the line to read only return number, and got as output -1. But as soos as the script tries to read number as a vector, it crashes.

Does anybody else experience this problem? Or know how to fix the problem?

Thanks

Hi @manie.conradie,

Let’s check if it’s a firmware issue. For this kind of thing, you will have to reflash the firmware onto the GrovePi. To do this, first install the software for the GrovePi and then flash the firmware - the following 2 commands will do it for you:

curl -kL dexterindustries.com/update_grovepi | sudo bash
bash /home/pi/Dexter/GrovePi/Firmware/firmware_update.sh

That should get you the firmware onto your GrovePi.

Once it’s done, try your code again and see if it works.

Thank you!

Thanks @RobertLucian! It indeed did solve the error. I am getting a series of values out. Not sure yet if they are correct.

Do you think you could try and explain what the problem was? I am just trying to understand for future reference.

Hi @manie.conradie,

curl -kL dexterindustries.com/update_grovepi | sudo bash

This command was needed for updating the libraries on your Pi with the latest. Nothing fancy here.

bash /home/pi/Dexter/GrovePi/Firmware/firmware_update.sh

And this is the command which triggers the flashing of the firmware onto your GrovePi.

I don’t think you’ll ever have to redo this procedure in the near future, as this is the kind of thing you have to do it just once.


I am getting a series of values out.

You’d be getting these if the sensor is not mounted in the right port or if you’re using a different one than the designated one for the job. If you feed me with more details, then I could probably come up with a more detailed answer.

Thank you!

Good afternoon @RobertLucian,

I double checked the connection, and it is connected to port A0 as prescribed in the code.

Here is a list of the values that I got running the script:
17, 1022, 16, 15 ,15, 16, 16, 1022, 1023, 1023, 16, 15, 15, 15, 16, 17, 16, 16, 15, …

My guess is that the 1000+ values are a saturated value.

A colleague of mine independently did the same, and gets the same result as I do.

I played with the sensitivity also, but did not get any different result.

I am not sure what other detail to give you at the moment. Please let me know what I can provide.

Thanks for your help,
Manie

Hi @manie.conradie,

I’ve seen this issue a couple of months ago for someone else. While we didn’t find out why this happened, we suspect it’s caused by imperfect contact(s) between the cable and the sensor or the GrovePi board.
It’s definitely not caused by the I2C connection. If it were to be an issue with the I2C connection, you’d be getting an IOError and then everything would stop.

Can you tell us how often does this occur? 1% percent of the cases? 5%? 10%? What’s an fair assumption of it?

Thank you!

Good morning @RobertLucian,

So far, I always get a result like the example above. I enquired from my colleague and he is having the same problem.

If you mean how often the value jumps to ‘max’, I would guess 5%.

I have tried shaking the sensor, flicking the sensor, and some other things, but that does not seem to influence the output.

Hi @manie.conradie,

So I didn’t see this to occur on our GrovePis, but we have planned to revisit the GrovePi and fix whatever bugs it has. This will give us the chance to take a deeper look at this thing you reported.

Until then, may I suggest you just filter out those bad values? If it jumps to a max value, then it’s quite easy to eliminate or if they are just really big numbers (or low), you can then eliminate the 5-10% (by setting a confidence level) that don’t fit the “graph”.

Thank you!