Testing non-functional DS18B20

TOWER
1

Hi.
Is there any way how to test if DS18B20 is working or not. I bought two different Chinese DS18B20. One seems to work perfectly but second not.
I tried both prebuilded bcf-radio-pool-sensor-multiple-ds18b20.bin and bcf-kit-wireless-pool-sensor both option single and multiple sensor(s) init and three resolutions 12 bits, 11 bits and 9 bits but nothing help.
No combination of “working” DS18B20 + “bad” DS18B20, “bad” DS18B20 didn’t work except single “working” DS18B20.
I use sensor module R1.1. DS18B20 is connected as default to B (P5).
Any idea or advice?

Thanks,
@MatousSloboda

2

Hi, we haven’t implemented any deailed error to find out in what stage of DS18B20 communication fails.
What would be the initial test is to connect just a single sensor and take a look at the bus with scope/analyzer and see whether you get response on 1-wire presence pulse.
This test confirms electrical connection and that the sensor can operate. Otherwise wiring or sensor is faulty.
Martin

1 Like
3

Thanks @hub.martin. :+1:
I’ll test it at home on the scope.
Matouš S.

4

Ok, connect also VCC signal. It could be useful because when something is during initialization of the sensor wrong, the library disconnects power. VCC and DATA in one trace could help us to see more.

1 Like
5

Ok, fine.
Thank you.

6

I run into same situation when I was trying to connect chinese sensors. It was my first touch with BigClown and with 1wire bus too.

I’ve done lot of debugging of bcf-radio-pool-sensor. Finally I figured out that there was some electrical transition/timing errors due to very short transport delay (i guess). I had sensor connected directly to the green connector on sensor board without any cables (legs tighten with screw). I had to change delays in 1wire wave generation function, after that everything works as expected. (slightly different timing on 1wire bus was needed as was specified in datasheet and correctly implemented in code)

As soon as I add some cabling between sensor and board (approx. 30cm) everything worked fine also with original code (so I removed my changes).

If you wish, I can find and post what I’ve changed in code.

(I’m using 3-wire connection.)

1 Like
7

Hi.
I spent some time yesterday trying to figure out where is a problem. I used external power as @hub.martin wrote.
Finally after two hours of debugging and shoring the wires :grin: I declared BS18B20 as not-functional from production. Btw cable is now accidentally shorter than one cm from metal cover. :smirk:
I compared result with another Chinese DS18B20 in every step and it seems to operate ok.
If you have some advice or twick @kapitan-iglu you are welcome.
Thanks
+Matouš Sloboda

8

In my case very short cabling (no cabling actually) between connector and DS18B20 was the problem. But I’m using TO-92 version.

--- sdk/bcl/src/bc_onewire_orig.c
+++ sdk/bcl/src/bc_onewire_new.c
@@ -235,12 +235,33 @@
     bc_gpio_set_output(channel, 0);
     bc_gpio_set_mode(channel, BC_GPIO_MODE_OUTPUT);
 
-    bc_timer_delay(480);
+    bc_timer_delay(500); // 480us is minimum
 
     bc_gpio_set_mode(channel, BC_GPIO_MODE_INPUT);
+
+#if 1
+// Some devices responds little bit later than expected 70us, be less strict in timing...
+// Low state of data line (presence detect) should be definitely low between 60us and 75us from now 
+// According to datasheet: t_PDHIGH=15..60us ; t_PDLOW=60..240us
+//
+//     t_PDHIGH    t_PDLOW
+//      /----\ ... \      / ... /-----
+//  ___/      \ ... \____/ ... /
+//     ^     ^     ^      ^     ^
+//     now   15    60     75    300  us
+//
+    bc_timer_delay(60);
+    retries=4;
+    do {
+        i = bc_gpio_get_input(channel);
+        bc_timer_delay(4);
+    }
+    while (i && --retries);
+    bc_timer_delay(retries<<2);
+    //bc_log_debug("retries=%d",retries);
+#else
     bc_timer_delay(70);
 
     i = bc_gpio_get_input(channel);
+#endif
 
     bc_timer_delay(410);
2 Likes
9

Thanks @kapitan-iglu
I will try it tomorrow.