Hi
I am starting to use GrovePi. I can get data from separate sensors, but, when I connect the 4 I want to use, the data displayed for 2 of them is shared or interfeering.
I have given more details in my post in seeedcc forum https://www.seeed.cc/interference%20of%20sensors%20data-t-12019.html
I hope you can help me to know where the problem is and how should I continue with this.
Thanks,
Carol
Can you list the exact sensors (specs) so the we can look at them.
Quite often it can be a conflict of addressing problem that causes this. If your sensors r all plugged into I2C ports then they r all connected to each other much the same as your USB ports on your computer. Each item plugged in has an address and when the master computer wants to speak to the item it uses its address. As long as everything plugged into the master has a different address then it works great but if you plug 2 items in with the same address they both respond to the same address call at the same time. If this is the problem then there 2 solutions, many I2C items have select able addresses so that you can change the address of it so not to conflict, if it doesn’t have a selectable address then you have to use a multiplexer (a computer controlled switch that turns each 1 on or off depending upon which one you want to speak too)
Post the spec on the sensors as we can have a look 
Hi,
I am using the starter kit, I can give you the specifications of the sensors when I get home. But does this problem only happen when using more than one I2C port? In the image attached in the seeed forum you can see that the display is the only element I have attached in I2C.
Thanks for your help!
Carol
Here it is the list of sensors =)
Grove-LCD RGB Backlight v.4.0 connected on I2C-2
Temperature & Humidity (blue) v1.2 on D7
Ultrasonic Ranger v.2.0 on D8
Light sensor v1.1 on A2
LED socket kit v.1.5 on D5
Sound sensor v1.6 on A1
Hi @berm,
From your seeed post I see you’re using multiple scripts at the same time.
As far as I know, running multiple processes at the same time is going to break the normal operation of the GrovePi board.
So, could you try using only one process at a time and tell us if it works?
Thank you!
I looked close at your post on the seed studio and the rest are plugged into separate digital and analog ports so shouldn’t cause a hardware conflict, As Robert says it looks more like a software problem.
Hi,
The first thing I tried was running everything from one script, but then one of the values was copying other sensors´ value, that is why I tried to separate them and it works a bit better, at least it s not completely a copy… only interferences.
Hi @berm,
I can replicate your issue on my GrovePi.
It seems like the values of the Grove Sound Sensor's port are blended with those of the Grove Ultrasonic Sensor.
Here’s a screenshot of what I’ve got.
On the left I’m running the following script.
On the right side of the screenshot, I’m running this script.
Again, these values don’t seem to match by chance.
It’s like everytime I’m moving the Grove Ultrasonic Sensor around, the values I read with the sensor are the same as the values of the Grove Sound Sensor - at least some of them.
To me, it looks like a pattern, so it’s definitely a correlation between some of these values.
Also, the Grove Ultrasonic Sensor seems to be giving real, good readings of the distance from the measured target.
So, I think the Grove Sound Sensor's readings are “contaminated” and not the other way around.
Basically, it’s like the Grove Ultrasonic Sensor is working properly, but the Grove Sound Sensor isn’t and instead it “borrows” some values from the Grove Ultrasonic Sensor.
I’m bringing @John on this discussion as I think there’s a firmware issue on the GrovePi.
Thank you!
I got this reply from seeed.cc technical service:
> We have tested it, and we found that it is the problem of sound sensor, which is not so sensitive and that causes your problem.
> This is the code we used, ultrasonic sensor works well here and sound sound sensor is not good.(You could change sound sensor to light sensor, then both sensors will work well)
They just run one of the examples that comes with Grove and say that it does not work and that is all.
Also about the reply, how “the sound sensor is not sensitive” explains that values get duplicated in different ports? If the sound sensor were not sensitive I would just get results far from reality, but still consistent with the system.
I don’t know what to think… if anyone has any suggestions of other add-on board I could use with this purpose or a way to make a system that makes sense even if it has some bugs, please let me know.
Thanks,
Carol.
Hi @RobertLucian ,
Could you provide me with any documentation that points me to the direction of understanding why exactly I should not run multiple processes on the Pi?
I am trying to learn as much as I can about Grove to find a good solution for my project.
Thanks,
Carol.
Hi @berm,
There’s no problem in running multiple processes on the Raspberry Pi.
What I wanted to say is that GrovePi's firmware wasn’t built on the idea of providing multiple “streams” of data for different processes at the same time.
Even though it works, we haven’t tested it much so we may not know all of its “hiccups” when multiple processes try to access its resources.
That’s why we don’t recommend using it this way.
Now, regarding your issue, I still think there’s an issue with the firmware otherwise, the values wouldn’t have got “shared” between the sensors.
I think there’s a timing issue somewhere, so adding delays between readings could make it work.
I’m going to have a talk with the guy that wrote this firmware and get a resolution on this matter.
Until then, I suggest you keep everything within one process and add delays between any readings.
This should solve your problem.
If you still want parallelization, then you can have a multi-threaded process. But I’d be more careful as you’ll need to use locks for prioritizing the access to GrovePi. The use of locks will help you add delays between readings.
Unfortunately, the multi-threaded alternative is inherently more complex than the use of one single-threaded process.
I hope we get this issue solved one way or another.
Thank you!
Now this might be a long shot but is it possible that the sound sensor is listening to the ultrasonic sensor??
Like an ultrsonic sensor works by having a speaker and a mic, it emits a sounds then listens for the echo back and measures the time taken.
Could the sound sensor just be hearing the sound being put out by the Ultrasonic speaker??