I’m rich in flash space in this application so I used a spreadsheet to build me a lookup table of tenths of a degree, along the lines of:
static const int16_t temp_lookup[4096] = {
-457,
-457,
-456,
...
1713,
1714,
1715,
1715
};
The exact values in the table are unique to my front-end so not relevant to you, but to build it I just used the standard pt1000 formula and you can find that all over the web, one example here.
Just to throw in comment (or 2) about the ds18b20’s, I’ve heard, here and elsewhere that they can be troublesome, but I have used hundreds of these and never had one fail. I cannot say i haven’t had some duff reading but they are rare and the majority get filtered out, resulting in a missing reading rather than a contaminated data feed.
This maybe because I don’t trust low DC over any real distance so I have always used 5v to stay well away from the ds18b20’s lower limit, but I always read the data line at 3.3v levels. This came about from the original emonTx v2 having an error in the PCB that powered the ds18b20 at 5v despite the ATmeag328p being run at 3.3v. It worked well and never had any issues, i have just chosen to continue that approach to this day. eg when I connect ds18b20’s to a RPi, I will power them from 5v rather than the 3.3v 50mA rail. A project last year had 80 ds18b20’s connected to one RPi this way and read every 10secs at 12bit resolution (4 buses), there was an insignificant number of “null” values which was totally acceptable.
Do not be tempted to use more than a single core (of the Cat5e) for each line and do not ground the unused conductors, I use a twisted pair for gnd and data, then a single core from another twisted pair for 5v. When connecting multiple ds18b20’s, try to keep the distance between the master and each ds18b20 unique, ie star configuration with all the sensors the same length is the worse possible configuration, when chaining sensors along a Cat5e, do not have a 1meter spur, then 50cm further along, a 50cm spur, make the second one shorter or longer so as not to clash with the first sensor distance. Personally I solder splice each sensor’s wiring into the Cat5e with glue filled heatshrink to add mechanical strength and water tightness so there is little or no chance of a bad connection (fingers crossed).
all good advice.
This is what I use:
orange solid +5V (pin 3 of sensor, pin 1 of RJ45)
white/brown stripe Data (pin 2 of sensor, pin 2 of RJ45)
brown solid Ground (pin 1 of sensor, pin 8 of RJ45)
I follow T568B
also good advice 
I avoid using RJ45 if I can, but when I do I make sure they are the right type for the cable, did you know (I assume you do) the “usual” RJ45 are intended for multi-strand and not solid core? the terminals “stab in multi-strand” rather than “crimping around solid core”. Most of the RJ45 “dodgy connections” I have encountered (on non-factory fitted RJ45’s) have been due to the wrong RJ45’s used(the term doesn’t stab in, it just slips to one side of the solid core and rests against it). You can get “solid and multi-strand” RJ45’s that do both, but they tend to be a tad more expensive and not mainstream, these are the only ones I carry now to avoid accidentally fitting the wrong ones or running out of one type or the other.
So what sort of maximum cable length are you guys finding you can get to? I guess it depends a lot on the topology along the way, but maybe with just one sensor say?
I can’t say I’ve ever really pushed the distance very far. I did make up some sub-assemblies with 8 or 10 ds18b20’s across an approximate winding 10mtr cable span and left them soak testing for a month with 20mtr tails (coiled up), I have no idea what the finished length was once they installed them.
There’s an app note for that:
https://www.maximintegrated.com/en/app-notes/index.mvp/id/148
I have never tried to push the distance. 3 meters is about as far as I have tried.
Do you need a level converter on the data pin in that case? What strength pull-up do you use with 5V?
EDIT - or do you power it at 5V but pull the data line to 3.3V?
Theoretically I guess so, but no, I don’t use any level matching.
The usual 4K7 or sometimes a 5K0 depending what I have to hand.
No, just power at 5V, pullup to 5V and read via a standard 3V3 IO pin, usually a Pi or Atmel ATmega328p running at 3V3.
This isn’t that uncommon to OEM kit, it’s just not widely known to be the case.
It all started with the emonTx V2 pcb v2.2 (Changlog) and a minor fault on the PCB, if you look at the schematic there is SJ2 solder bridge pads to allow the user to select a 3V3 or 5V supply, but the board was made with a permanent link to 5V (see picture below, the left and centre pads linked in red) so unless that track was broken, all emonTx v2 temp sensors were 5V powered but the MCU was 3V3.
This was my first encounters with using ds18b20’s so when I started using them else where I just stuck with what I knew worked, perhaps because of my background of working with automotive 12VDC electrics for many years and rarely, if ever, did you get the expected voltage at the other end of a cable, voltage drops were unavoidable and now working 3-5V, I came to believe this might be the reason so many people report issues with ds18b20’s whilst I had not experienced any issues at all. That and the fact I make sure every connection is 110%, again from the automotive background, 99% of all vehicle electrical faults basically end up being a problem with 1 of 3 things, connections, connections or connections.
I’ve never done the theoretical maths or taken any exact measurements as I haven’t really needed to do any debugging of ds18b20 circuits, but I’d come to the conclusion that by giving it 5V it probably ends up performing nearer to 3V3 levels than 5V levels once it’s travelled several metres and passed through a few connectors too, but your question about pulling up to 3V3 rather than 5V now raises some doubt as at rest the pullup to 5v must result in a >3V3 level? But there are no reports of damaged MCU’s (that I’m aware of) and I certainly haven’t had any issues. (so cheers for that @dBC ignorance was bliss for a while 
)
Although the emonTx v3.4 ds18b20 connections via the RJ45 are 3V3 not 5V and the pullup is to 3V3 too, the emonPi’s RJ45 pin 2 is 5V (not 3V3 like the emonTx v3.4) and it uses a 4K7 pullup to 5V like the old emonTx v2.
The emonPi also powers the optical pulse sensor with 5V and reads at 3V3, it’s performance differs to the emonTx v3 optical pulse counter input (identical sensor) as it is all 3V3 on the emonTx v3. The only difference to the way the circuit compares to the ds18b20 connections on these devices is that the pulse counter uses an internal pullup/down on both, so the pulse counter is pulled to 3V3 even when powered via the emonPi’s 5V RJ45p2.
Especially the corroded ones! 
I thought that was deliberate?
Maybe it was retrospectively deliberate (accidentally done on purpose) 
From the emonTx v2 build guide “voltage selection notes”
On the latest version of the emonTx PCB, two solder jumpers have been added near the IRQ I/O and temperature (DS18B20) ports. They enable the user to decide what voltage to use on these ports. The emonTx runs at 3.3V. More details can be found in this blog post. Connection is made by joining the middle pad the either of the outer pads with solder.
If you look carefully, the solder jumper above the temperature port is connected to 5V (small PCB trace). This was an error, but actually work out well. The temperature sensors always use 5v (which is good) and when the emonTx is powered by 2 x AA’s the the 5V rail becomes 3.3V anyway. Therefore, you can ignore this solder jumper, it will disappear in the next generation of emonTx PCBs. However the pulse counting voltage selection jumper (pictured) above must be connected to either 3.3V/5V.
Found a reference to the data pin being 3.9v when connected this way with pullup and power to 5v on the old forum (ref DS18B20 temperature sensing | Archived Forum)
Using a pull-up to 5V on a 3V3 MCU can be just fine if the MCU is designed for that. Some are rated for it and some have a design the will work okay. Since it is a pull-up, when the MCU input protection circuit goes active it will be able to lower the voltage without needing to disapate too much current.
I used to use 5V for the power pin and didn’t have problems. I now use 3V3, since the esp8266 is not rated for 5V on the input pins (there is some debate on this, but it isn’t clear that it is 5V tolerant). I have not had any more problems since I switched, so I don’t believe 5V is necessary if runs are short. The datasheet does recommend using 5V for both pull-up and power when you need maximum range, ie 100m or so.
I think what you’re witnessing there is a battle between your 4K7 pull-up and the internal protection diodes. If you disconnected it from the input, I’d expect it to be at 5V. When the bus is idle (most of the time) there is no load on the data pin so it should be sitting at 5V (I’m excluding parasite mode here).
I’m pretty sure neither the ATmega328p nor the RPi have 5V tolerant input pins. You’re probably only putting about 0.3mA through the protection diode which is below the 1mA max Atmel specify (don’t know what the RPi specs are). But those diodes are primarily intended for ESD protection, not as voltage clamps.
I’ve been doing some extreme OneWire tests lately, and was all set to post in here … “don’t be shy about making your pull-up much stronger”. You’ll see plenty of Maxim stuff using 1K pull-ups for good bus reliability. The only limiting factor there is the amount of current the ds18b20 can sink when it’s trying to hold a ‘0’; to stay within that spec you can go to about 910R with 3.3V and 1K3 with 5V. Had I offered that advice in this thread and someone followed it, I reckon they would have blown their inputs. The only thing protecting those 3.3V inputs from the 5V you’re feeding them is the current limiting provided by that 4K7 pull-up.
RPi, 3V3 maximum.
From the post at the link above:
ALL the Pi GPIO are 3V3. NONE of them are tolerant of voltages outside the range 0 to 3.3V.
With the ATMega328, it depends on Vcc
and
In my experience, particularly true if it was built in Solihull. @Robert.Wall you’re from that nick of the woods aren’t you? Duck around there and sort ‘em out would ya’ please.
I don’t have any contacts there now. There was a time when I could look up the IEE list of members, but I’m not the local Hon.Sec any more.
