Interfacing

1-wire and Dallas DS18b20

34 20402
luetzel  
Anything new about the cpu_freq patch? Doesn't seem to be fixed, yet. And the above patch returns:

patch: **** malformed patch at line 11: @@ -500,7 +501,7 @@ static int sunxi_cpufreq_settarget(struc

In other words the code above has some broken lines. Something is missing.

Hi to everyone!

I have a quite annoying problem with my banana pi and two DS18B20 sensors. If both sensors are connected the readings are quite problematic. Earlier problems made me write a script to see how many of the readings are errors.

The results show that if only one sensor is connected, there are only a few errors, say less than 100 from 10.000 readings. However if both sensors are connected, the reading errors drastically increase.

The syslog is full with this message "w1_slave_driver 28-SENSOR_ID: 18S20 doesn't respond to CONVERT_TEMP.". After a few hours I noticed that the sensors disappeared from /sys/bus/w1/devices.

I tried to replace the 4.7k resistor to a smaller one, and I ended up with two 4.7k resistors in parallel resulting in 2.35k resistance. With this setup my sensors don't disappear, but they continue to fail some readings.

Another interesting thing now, the sensors' error rate is not equal. One of the sensors have longer wire, and the errors are about 5% of all readings on this sensor. The another sensor has shorter wire and almost 20% of readings are CRC errors.

I use the latest bananian linux and the wiring is the following: approximately 30 cm wire comes from the banana to an external phone outlet with two plugs. Both sensors are connected with RJ11 plugs to the outlet. The sensor wires are about 3 and 7 meters long and both are 4 wire copper cables used for ADSL before. The sensors work from 3.3 Volts, connected to banana pin1, GND connected to pin6 and data wire connected to pin16.

Has anyone got any solution to this problem? I'm out of ideas. Thank you for any help in advance.

luetzel  
I have exactly the same problem with only one DS18S20 connected. The hardware sits on a breadboard, connected via a PI-Cobbler. If plugged into a Raspberry Pi, readings are 100 % reliable. The problem must be located either within the 3.4.103 Kernel or related to the Banana Pi as such. I'd like to try the patch above, but it contains some truncated lines at 11, 20, 29 and so on. Is it possible to fix it?

luetzel  
luetzel replied at Sun Dec 14, 2014 04:57
I have exactly the same problem with only one DS18S20 connected. The hardware sits on a breadboard,  ...

Some quick research on the web revealed that the error occurs as well on the Raspberry Pi
if there's not enough power supplied. I've switched to another USB power supply and will
see what happens.

I tried with the power cable connected to my PC, and I noticed that the error rates were similar on both sensors, and the errors were way less than with the adapter I use, so part of the problem might be coming from the adapter. (Unfortunately I can't test with another power supply, because I don't have another one with 2 amps rating, and I need 2 amps because of a hard drive.)

Since then I replaced the old telephone cables with CAT5 UTP cables. The lengths are almost the same, about 2 meters to one sensor, and 8 meters to the another. The DATA and GND are twisted together, and I put 100nF capacitors next to both sensors. The pull-up is 2.35k (2x 4.7k in parallel).

The errors are not fully gone, but the error rate is around 1%, that is the best I could achieve so far. The CONVERT_TEMP error still appears in the syslog, but the sensors didn't disappear since then.

luetzel  
anderson14 replied at Mon Dec 15, 2014 13:16
I tried with the power cable connected to my PC, and I noticed that the error rates were similar on  ...

After changeing the power supply, the issue remains. Although, I switched from a 2.1 A supply to 1 A there was no difference.
I believe that it requires a patch for the cpu_freq, however, it seems that nobody is working on it. Without keeping the frequency
above 600 Mhz, my sensor is not recognized. Hope that it'll be fixed in a new kernel version.

tomek  
Edited by tomek at Sat Jan 3, 2015 16:20

DS18B20 & parasite power

Hi,

I managed to connect DS18B20 in parasite power mode (we need only 2 wires):


I tested few resistances and finally decided to use 470 Ω for 2 sensors at the end of 10m wire.

red: DQ
blue: GND+Vcc
resistor: 470 Ω



red: +3,3V
black: GND
yellow: GPIO




luetzel  
Edited by luetzel at Tue Jan 20, 2015 00:55

Since many lines were truncated in the patch above, I changed cpu_freq.c manually and compiled a new kernel. Although, one has to keep the frequency still above 600 MHz, the "spikes" that I observed previously are reduced to one in 24 hours. The "w1_slave_driver: 18S20 doesn't respond to CONVERT_TEMP" error still occurs, but is less frequent.

I wonder if someone is working at all on a new kernel version, since this bug is pretty annoying and a lot of users have sensors connected ... IMHO the slow release of new kernel versions/patches speaks strongly against migration from a RasPi to BananaPro.

tkaiser  
luetzel replied at Tue Jan 20, 2015 00:52
Since many lines were truncated in the patch above, I changed cpu_freq.c manually and compiled a new ...

Why do you still patched the kernel? Is installing/running cpufrequtils and adding
  1. echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
Copy the Code
to /etc/rc.local not enough?

luetzel  
tkaiser replied at Tue Jan 20, 2015 03:03
Why do you still patched the kernel? Is installing/running cpufrequtils and addingto /etc/rc.local ...

No, unfortunately, it wasn't enough to set the frequency scaling in rc.local. Only both, keeping the frequency above 600 MHz
AND the patch reduced the number of "spikes". Without kernel patch, there were still a lot of

w1_slave_driver 10-000802b478b7: 18S20 doesn't respond to CONVERT_TEMP.

entries in /var/log/messages. It seems, that not only 18S20 is affected, but also other sensors, such as DHT22.

You have to log in before you can reply Login | Sign Up

Points Rules