Cable length increasing IO errors


#1

I purchased a range of cable lengths from Seeed when I bought my sensors - from 5cm to 1m, plus a couple of the RJ45 cable extenders - so I could position sensors on the various bits of equipment that needed to be monitored.

When I use cables longer than 20cm between my GrovePi and DHT Pro sensors, the error rate climbs sharply. From my logging data, it looks like I’m getting an error on every read. Still investigating.

I have not yet tried these on the Arduino/Grove, but I presume that longer cables work b/c the error rate I’m seeing is too high for Seeed to be selling these if they don’t work with Seeed’s own Grove shield.

Are there known issues with the GrovePi talking to sensors over “longer” cables? If so, are there known solutions?


#2

Hi nexuswest,
We have not tried using Grove cables over 20 cm.

The reason might be that the particular sensor that you are using might not work over longer cables. A lot of simple modules like LED and button should still work and that might be the reason Seeed sells them.

I don’t know of this sensor, but cable length drastically reduces the performance of the I2C sensors.

It would be interesting to know if they work with the Arduino/Grove shield. According to me, you should see the same performance there too. Please let us know how it goes if you try using it.

There are no other solutions other as such for this problem. Browsing through Seeedstudio’s grove page, I found this http://www.seeedstudio.com/depot/DevDuino-Sensor-Node-V2-ATmega-328-AAA-battery-holder-p-1850.html?cPath=19_22 . It looks pretty neat and you should be able to attach a sensor at one module and connect another other module to the GrovePi. We have not tried this and cannot say how well it works but it looks pretty good. This will involve some effort on coding through the Arduino IDE too.

-Karan


#3

Hi Karan,

For some reason my update did not post. Here is a recap.

I have tested the same sensors and long cables using an Arduino with a Grove Base Plate. Cable lengths are 1m and RJ45 + 6ft + RJ45.

I get reliable readings using these cables, with only occasional errors. The error rate using the longer cables with the Arduino / Grove is comparable to the error rate I experience using 10-20 cm cables with the RasPi / GrovePi. Basically an IO error occurs every 5 - 30 minutes. No big deal.

This is in contrast to almost 100% errors using these same sensors / long cables with the GrovePi.

This testing rules out sensor failures, I2C bus length and cable failures because exactly the same units were used in both tests. This leaves (a) GrovePi hardware, or (b) GrovePi low level software as the likely causes.

I need your help finding a solution.


#4

Hi,
Thanks a lot for testing it out at your end. I just tested the GrovePi and the DHT pro sensor on a 50 cm cable. There I get the IO error’s very infrequently. I get 1 IO error is 200-300 readings. I cobbled together two 50cm cables with jumpers to make a 100cm cable and with the jumpers the total length is ~130cm. Even there I see the same behavior as the with 50cm cable.

Can you try updating your local GrovePi repository and run grove_dht_pro.py to see if it helps. You should also try updating the firmware.

Also, do you have anything else also connected to the GrovePi or the RaspberryPi. Can you test it again with only the GrovePi and one DHT sensor to see if it works.

Let me know if this helps.

-Karan


#5

Thanks Karan, I will run further tests as you suggest. I do have other sensors and a few LEDs attached to the GrovePi. I’ll strip it down to just one for testing. Also will test a more systematic range of cable lengths. I’ve primarily tested 1m and the RJ45 extender bc those are the ones that I need for this project. Will post my findings.


#6

Karan,

How much power does the GrovePi require by itself? Any idea how much additional items like DHT, air quality sensor, digital temp sensor and the RGB connectors require? Would longer cable lengths create IO errors by under-powering devices at the end of longer cable runs if power demand approaches available supply?


#7

Karan,

Think I solved this.

To set up for a new round of testing, I put one DHT Pro sensor on a 1m wire and the second on a RJ45 extender with a 6’ Cat5. Also I put the Grove temp sensor on a second RJ45/Cat5. I left the air quality sensor, 3 LEDs and 2 relays on their existing 5cm to 20cm wires. This will be approx the cabling when fully deployed.

First step was to run my program to gather a baseline error rate. The next step would be removal of all but one DHT Pro on a long cable, as you suggest above. Then I planned to add 1 sensor at a time.

Surprisingly, step 1 generated few errors this time: 82 IO Errors logged after 1578 minutes of up-time. Sensor cycle is once every 2 minutes, so ~800 cycles with an error every ~10 cycles. Obviously this is much better than ~100% errors in previous tests with 1m and RH45 cable extenders on 1 DHT Pro and the temp sensor. This 1 error in 10 cycles error rate is comparable to my past experience using “short” cables only.

What changed? Since my previous testing on this issue I’ve moved the Pi from the wall to the workbench in the rabbit building - easier to debug on the bench. The bench power tap didn’t have enough room for the old wall wart, so I swapped in a 2A unit that Adafruit recommends. Cables and sensors are same as before, and I’ve added a second pair of RJ45 (which should have made the problem worse, all other factors unchanged).

I think the cause of this problem is power supply stability or output.

From what I’ve read, any (reasonable) 5v 2A USB supply should run a RasPi with a shield or two and WiFi. The old USB wall wart was rated at 2A, as were the outputs on the 2 Anker multi-port units used before moving the project to the rabbit building. I’ve used all 3 of these supplies successfully for RasPi’s and Arduino, but none of the other projects involved as many powered parts as this one.

I don’t know where the “limits” are short of seeing Pi crashes. My understanding is that insufficient power can cause the Pi itself to crash or reset, especially if multiple shields or USB devices are added that consume a lot of power (relative to USB levels). I’ve not experienced Pi crashes with this (or any other) project, and I have used multiple shields plus USB WiFi on other projects with these and other supplies without problems.

I have found articles about cable length at low DC voltages. Sounds like current or voltage drops as the wires get “longer”. I don’t know enough electronics to know if my cable lengths “qualify”, but the symptoms I’m observing suggest they could. Otherwise why would changing power supply make such a dramatic difference in system performance?

I would appreciate input on this from you and your team. Am I diagnosing this correctly? Are larger Grove setups are more sensitive to power supply output stability (again, multiple assuming shields and USB devices)? Could the IO Error rate indicate that current or voltage had declined at the sensors enough to cause communications or sensor failure? I’ve assumed that one could fill up all the Grove ports because they were there - haven’t seen anything to the contrary, but is this assumption valid?

Here is an inventory of the parts in my project:
1 - RasPi mod B
1 - 2.8" TFT shield (Adafruit, goes into power save unless I am using the keyboard)
1 - RGB LCD shield (Adafruit, displaying all the time)
1 - USB WiFi (Adafruit - large antenna version)
1 - USB RF dongle for a Logitech wireless keyboard
1 - GrovePi
2 - Grove DHT Pro sensors on RJ45 cables
1 - Grove temp sensor on 1m cable
1 - Grove air quality sensor on 20cm cable
3 - Grove LEDs (one is on at any given time, others off)
4 - Grove RJ45 extender endpoints (2 pair, 2 cables)
2 - Grove relays (10A version, used to open/close override circuits on 2 Johnson 419 thermostat controls)

Scanning my error logs, the majority of errors that I am seeing come from the DHT Pros and temp sensor, all of which are on “long” cables. The next most common seems to be the air quality sensor. Errors seem evenly distributed between write and read.

I am letting this run for a few days. Will update.


#8

Great to hear that you setup is running now. Even we have faced problems in the past because of faulty wires or power supply units. One thing that you should be very careful with is to check with the multimeter if the voltage on the VCC pin is indeed 5V. There are too many crappy cables out there which don’t give out 5V which lets the Raspberry Pi to run but as you keep on adding multiple sensors, a lot of unexpected things start happening.

The best results that I get are usually with a bench-top power supply which gives out 5V at 2A. For your setup 2A should be good enough. The best way to make sure of this would be to use a multimeter to measure the current. Also, it might be worth the effort to check the voltage that the sensors farthest from the Pi are getting. With our setup of 1m cables, we only had a voltage drop of a few mV.

Let us know how the testing goes and sorry for all the troubles that you had to face.

-Karan


#9

Hi Karan,

Thanks.

Update to my previous post - no action needed. I stated that 2 of the power supplies that gave problems were Anker. One was. The other was an Ezo.

Re cables between the power supply and RasPi - That’s something I had not examined other than I avoid the scrawny ones, and discard any that won’t charge my Galaxy SIII (my benchmark device for “sensitive” to charging source). I’ll check voltages at the power cable to the Pi and at the sensors.