EmonTX V4 not seeing DS18B20 devices

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.

Any suggestions?

You do not say how you installed them. Have you read this? Other sensors — OpenEnergyMonitor 0.0.1 documentation

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.

I suggest you email the shop and ask. - @Gwil

Hello @gonzo it might be worth checking the serial config on the emonTx4 and sending a t1 command just to be sure that temperature sensing is turned on. See configuration here: Configuration — OpenEnergyMonitor 0.0.1 documentation

Hi.

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…

Can you post the startup text, please?

@Robert.Wall any thoughts? @TrystanLea

@gonzo - if you click reply on the post another person makes, they will get a notification, else they may miss it.

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.

1 Like

@gonzo are the solder jumpers that enable temperature sensing soldered on the board?:

are these DS18B20’s purchased through our shop? There have been issues with different variants of DS18B20’s in the past, which may be causing the issue if you bought them elsewhere?

Yes the links are all made.
It does look like the EmonTX is looking for the device I have connected, but the timing I am seeing (from the one wire device) does not match the datasheet.

These were purchased from elsewhere. The TO92 device is marked as being a Dallas device, but it wasn’t from a main distributor.

I have worked with one wire devices in the past and know how touchy they are to talk to.

I may just park this for now. As I only added them, as the ports were available on the EmonTX.
Thanks for all the assistance so far.

Jules

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/expansion_boards/ESP8266/hardware/schematic.png at main · openenergymonitor/emontx4 · GitHub.

Any chance of posting that scope pic please?

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.

Here’s how it looks with an extremely loaded bus. This bus has 54 devices and about 300m of cable in a fairly gnarly configuration that breaks all the rules.


You can see the very slow rise time of the heavy bus. Even so, within 42 usecs of the master letting the bus go high, at least one of the 54 devices had pulled it low.

Re-checked…
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.

Can’t seem to attach an image with this browser.

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.

[EDIT]

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.

I think @gonzo should be able to post photos - he’s at Trust Level 1 (Basic User). There are two ways - either drag & drop or use the upload icon (up arrow) at the top of the outgoing message pane.

although I understand these limits/requirements can be customised. But moderators can’t see the settings, only the Admins can see and change them.

See if this pic attachment works.

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.

Edit - rotated screenshot. Moderator, BT

Does it still trigger with no devices on the bus? That would be a way to see the master’s reset pulse if it’s sending one out.

I’m unable to capture ant pulses with the devices off the line.
So I don’t believe the EmonTX is pulling the line low.

That might be one for @TrystanLea