> Date: Tue, 1 Nov 2016 19:11:45 +0100 > From: Jan Kandziora <j...@gmx.de> > Subject: Re: [Owfs-developers] Raspberry GPIO bus master > > Am 01.11.2016 um 16:10 schrieb Markus Gaugusch: >> >> 1.) Which value should the pull-up resistor have? I found a posting from >> Jan that 4k7 is wrong, although this value can be found everywhere. >> > The slave chips can sink 4mA. This means at 3.3V, the pullup can go down > as low as 825? without damaging the chips. I recommend using 1.5k?. > > A smaller pullup means working against the capacity of long cables to > achieve a fast raise time. Second, any pullup delivering more than a > continous 1mA allows you to forget about the "strong pullup" needed > otherwise for the DS1820 and other power-hungry chips. > > The 4.7k? pullup replicated again and again without thinking gives you > 700?A at 3.3V only, which leads to slower raise-times and will not > suffice powering a DS1820 during temperature conversion. > > >> Which pull-up should I use? And do I need pullup=1 for the w1 dtoverlay? >> > You don't need the active pullup when you use the 1.5k? pullup.
As I posted here on 19 Oct 2015, that is not always true, at least not when using a BBB. Perhaps the Pi is magically different? Here's my experience: === I have done one more experiment with my 3.3 V parasitic powered system. I determined the strongest pullup value I could safely use on my BBB GPIO pin, and used the ten-turn pot with the pyownet program to approach that value. The one of my DS18B20 sensors that has always read closer to accurate reaches a stable and accurate reading with just over 1000 Ohms as a pullup, maintaining the 1-Wire bus voltage at just under 3.0 V during conversion. The other DS18B20 requires a pullup below 600 Ohms and a bus voltage above 3.1 V to reach accuracy - but with sufficient conversion power it converges to the correct reading. Both sensors are happy to report temperature values with bus voltage as low as 2.0 V during conversion, but those values may be up to ten degrees C too high. The impression I'd received from various web sources was that the DS18B20 is a digital device, and if it reports a temperature value at all, that value is precisely accurate. Clearly that is not true! Since the digital parts of the chips work fine far below the critical voltage, I'm left to suspect that the 3.0 (or 3.1) V supply minimum is required by an ADC reference voltage source. As the reference voltage drops with insufficient bus power, the apparent temperature rises - and the digital circuitry reports what the ADC tells it. >From Maxim DS18B20 Programmable Resolution 1-Wire Digital Thermometer >Datasheet REV: 042208 --- Supply Voltage VDD Local Power +3.0 [to] +5.5 V Active Current IDD VDD = 5V 1 [to] 1.5 mA --- That typical conversion current spec is with a 5V supply. I don't see any mention of an active power conversion circuit inside the DS18B20, so I suspect the current drops proportionately at 3.0V, or worst case remains similar. In my test with the 500 Ohm pullup combination, the bus voltage dropped to 3.1 V during conversion, suggesting my two parallel DS18B20 chips draw 0.4 mA together. Carefully scrolling my scope across the entire pause between the convert command and the following read, I can't see any variation in loading. Apparently the 1.5 mA spec is an instantaneous value, and the internal capacitor (CPP) smooths out the current load of the conversion. Still, with a 3.3 V supply and parasitic power, my conclusion is that it is on the edge of impossible to reliably reach the specified conditions without an active pullup. An interesting note I found during my research: <https://www.maximintegrated.com/en/support/faqs/ds18b20.html> ----- Where physically on the device does the temperature measurement take place? The DS18B20 does not sense temperature directly through the package. For all package types, the DS18B20 senses temperature primarily through the GND pin. Ensuring a good thermal connection between the GND pin of the device and the heat source you wish to measure will provide the best results. ----- Loren === | Loren Amelang | lo...@pacific.net | ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
