I have an EmonTX V4 (brought from the store, just a few weeks ago) and trying to read temps using DS18B20 devices.
The firmware on github seems to support these one wire devices, if they are connected at power-up time. I don’t know what version firmware was shipped with the EmonTX though.
Tried two different temp devices. No joy. All I get is T1/2/3 = 0.
Thanks for the link.
Yes, they are connected correctly to the terminals and the PCB links are correct.
I have both a packaged sensor and a bare TO92 device, directly in the termonal block, just to make it as simple as possible.
Tried powering up the EmonTX with either/both the devices, just to rule out a faulty device.
OK, did that.
(And confirmed v1.5.4 firmware loaded.)
The firmware is not reporting seeing the temperature sensor.
Had a look on the scope and the ‘presence’ pulse is there. Though looking at the datasheet for the DS18B20 this should occur after 15-60us. I am seeing it after 300us.
So more thought required here…
I’m just rather amazed that the temperature measurements have ever worked with the emonTx4, because the One-wire data transfer is very closely integrated with the energy measurement, and the timing of all of this is quite different given that it’s using a totally different processor to the emonTx V2 & V3. Note that only some parts of the One-wire library are used.
For the record, I doubt it will be possible to do temperature measurements at all when the extender board for channels 6 – 12 is in use. I’ve been too busy working on this to look in detail at the changes Trystan made to emonLibCM and understand what has been changed, so he’s in a far better position to help.
Sounds like that could be the issue as everything else seems to be in place.
The one wire temperature sensing on the EmonTx4 does have a small (as far as I’ve been able to evaluate so far) detrimental affect on electricity monitoring accuracy. You can notice a few watts of spurious consumption on some of the CT channels. This is due to the way the one wire timing blocks the ADC ISR interrupt for brief periods of time. So if you don’t need the temperature sensing you will get better electricity monitoring results if the EmonTx4 is just dedicated to that task. We are moving temperature sensing off the AVR-DB core in the next hardware revision so that there is no compromise.
The existing EmonTx4 design does have the DS18B20 bus broken out in a way that could allow expansion boards to take over the task of reading from the temperature sensors, but it’s not something we’ve been able to push forward in terms of development yet. E.g The ESP8266 expansion board has the DS18B20 temperature bus routed to GPIO5 on the ESP8266 Huzzah module emontx4/schematic.png at main · openenergymonitor/emontx4 · GitHub.
Are you saying you’re seeing 300 usecs between the rising edge of the reset pulse and the falling edge of the presence pulse, even when both your devices are on the bus at the same time?
I’ve measured some pretty dodgy clones over the years but I don’t think I’ve ever seen that behaviour before - although I’m not sure I would notice it, because it would take just 1 good ds18b20 on the bus to hide the errant behaviour you describe of the bad one. For you to see that with both your devices on the bus suggest they’re both suffering from the same problem which seems unlikely.
Is there any chance you’re measuring 300 usecs from the rising edge of the reset pulse to the rising edge of presence pule? If so, that’s within spec, and not the cause of your problem.
Here’s how a reset/presence looks for me with a single clone on a short bus (Yellow is the 1wire bus, you can ignore Red)…
I drive the bus low for longer than most (625 usecs). But you can see that within 34 usecs of the master letting the bus go high, the ds18b20 pulls it low to assert its presence. The spec requires it does that within 15 to 60 usecs, so in spec.
Same capture, but cursors moved to show how long the ds18b20 holds the bus low to assert its presence - 118 usecs. The spec requires it hold it low for within 60 to 240 usecs, so within spec.
If you had a particularly slow device (right on the edge of the spec) it could take 60 usecs before it drove it low and then hold it low for 240 usecs. That would give you 300 usecs between the rising edge of the reset pulse and the rising edge of the presence response. I’m wondering if that’s what you’re measuring? If so, that should be fine. The Arduino 1wire library waits 70 usecs after letting the bus float high before it reads the bus, so would read a 0 and conclude there was a device on the bus.
It looks like the gpio line goes high immedatly on power up. What I am seeing is the presence pulse from the devices after the power up. Rather than a commanded gpio line low pulse to detect the devices.
I have two devices here, from different suppliers.
The first is giving a ~120us presense pulse after ~50us.
The second is giving a ~120us pulse after ~320us !
Connecting both of them I see both pulses.
I did have a play to see if I could capture the GPIO low pulse from the EmonTX, but I can see no trace of it.
Yeh, triggering on stuff that only happens once soon after power-up can be tricky.
Presumably the ds18b20s are also powering up at that stage so perhaps their behaviour there is less predictable than once power is stable. In any case, unless those pulses are active 70 usecs after the emonTX4’s reset pulse, they’ll go totally unnoticed.
That makes me think you might still have a configuration issue on the emonTX4. If it’s not sending out a 480 usecs reset pulse some time after power up, then it’s not looking for 1wire devices on that pin.
We might need a moderator to boost your powers to allow that.
That sounds like a healthy device.
That one not so much. It would be interesting to see if it responds better to a reset pulse after its supply is stable.
Interesting idea on the device giving an odd presence timeing, due to the power up slope.
I’m wondering if the firmware as shipped had the one wire support disabled. As I see a #define for that in the source.