That’s great to hear! thankyou for testing that. Is there any chance that you could try reducing that delay up to the point that it stops working again? It would be good to get an idea of the amount of delay that is required.
Thank you for the input on the temperatureEnabled line. lm not personally too worried either way. I can see what you mean that it could easily confuse but also Roberts point that it does work functionally. I will discuss with Robert privately. Roberts done this work off his own back, contributed voluntarily and I know he has a lot of things going on in parallel at the moment.
Thanks again for your input and help with testing the timing modification @NickT and happy new year to you too!
Sure, I’ll get to it in a day or two. Would this delay in any way affect the calibration? Now that I’ve got it all working I’m cross-checking the outputs with my electricity meter and find that peak readings are over-reading by 30% and off-peak are under-reading by 10%. I can calibrate (need to RTFM first) but am reluctant to if it’s going to change again.
I would not expect it to change the power readings in such a significant way, the effect I have seen from enabling temperature sensing in parallel with power measurement is closer to 1% and only on CT6. That sounds like another cause to me?
Is the voltage sensor being picked up correctly? Do you see varying voltage readings?
I notice in your log from the emonTx aboove suggesting no AC Voltage sensor, is that the case when it’s installed? If it is, that is very likely to be the cause of the error that you are seeing.
Yes, perfectly legal but as @NickT points out, it’s also a common source of typo error. I’ve lost count of how many debug hours I’ve wasted over the years because I’ve accidentally typed an “=” instead of an “==” in a simple conditional test. Having the compiler ask if I really meant what I typed is a huge step forward and as Nick points out,you only have to double up on the parentheses to tell the compiler (and other readers) “written as intended”.
That construct dates all the way back to when compilers were pretty dumb at optimisation. Jamming the assignment and conditional test all into one expression made life easy for the compiler writers of the 70s. These days it doesn’t matter which form you use, so go for whatever you think is clearest. All four of these are guaranteed to produce the same behaviour…
if (temperatureEnabled = _enable)
if ((temperatureEnabled = _enable))
temperatureEnabled = _enable;
if (_enable)
temperatureEnabled = _enable;
if (temperatureEnabled)
And in the case of the AVR gcc compiler I checked and all 4 produce the exact same 3 instructions so there’s no performance difference:
It might be worth investigating why the delay helps, especially after EmonLibCM_TemperatureEnable() is called. That routine appears to do all the bus discovery stuff so is presumably successful at that with or without a later call to delay() - that would imply it’s not a power settling kinda’ issue.
It looks like the last thing that routine does is a global COPY_SCRATCHPAD command to store the conversion resolution, followed by its own call to delay()…
oneWire.write(COPY_SCRATCHPAD, true);
delay(20); // required by DS18B20
It’s not clear where that 20 comes from, according to the datasheet that transaction typically takes 2 msecs and worst case 10, so you’d expect 20 to be sufficient:
In my ds18b20 code I poll the bus to see when the TCONV command is finished - that enabled me to write up this report on vastly varying conversion times amongst the clones. I don’t currently use the COPY_SCRATCHPAD command, but when I get time I’ll hack something up that does, and see how reliable the 2 to 10 msecs datasheet claim is across my samples.
@NickT - do you happen to know the UID of your ds18b20s?
I reduced the delay by half until I reached 5mS. The temperature sensors came up each time. I then re-loaded the original firmware (using the Admin Update function just to be sure) with the same result: the problem has gone.
28 B0 F0 75 D0 01 3C 56 So family 3C - some clone?
28 E9 A9 61 09 00 00 F0 so family 0 - the original (from the OE Shop)
I read through the post on the DS18B20, fascinating stuff. The fact that many clones put out 25 degrees in the initial phase matches the behaviour I saw on T1 (the clone) but the initial 304 that I saw on T2 (the genuine one) seems odd.
That’s typical isnt it! did you unplug the power supply, USB-C cable in between each upload, if it’s power related that would only show up after a full power cycle with a decent gap to allow any charge in capacitors and other power supply components to drain…
I didn’t unplug for the first half dozen attempts, but then when it got down to 10mS I did unplug but somewhat briefly (~20 sec). And right now I just unplugged and left the EmonVS for over a minute. Reconnected and temperatures are fine. The problem has somehow gone. Note that the EmonVS/EmonPi was running for over a week with the issue, so success is not the result of some burn-in in the PSU. Also the kit is now bolted to the wall and all leads etc are fixed in place. The only thing I move is the USB-A end of the cable linking the two units.
Just as you guys are possibly moving towards thinking the call to delay() might be a red herring I’m starting to think it might be significant. Recall the last thing EmonLibCM_TemperatureEnable() does is send out a COPY_SCRATCHPAD command and then calls delay() for 20 msecs. Your calling delay() immediately after your return from EmonLibCM_TemperatureEnable() is effectively just extending that 20 to something longer.
I got around to measuring how long the COPY_SCRATCHPAD command takes on my various sensors and have updated my table with a new column:
Then genuines all took 11 msecs - a little surprising given the spec says 2 msecs typical, 10 max. My s/w timer only has a 1 msec resolution, and there’s potentially a bit of measurement overhead, so they could be in spec (just). I’ll try to confirm it all on the scope when I find time.
My fav clones (the “80” class) also excelled at this task. Immediately after issuing the command I poll the bus and they reply “yep, done”. I’ve not confirmed the command was actually actioned, but I’ve no reason to believe it wasn’t.
My least fav clone (the “03” class) were also poor performers at this task too… taking 28 msecs, well outside the spec and even outside the generous 20 msec allowance at the end of EmonLibCM_TemperatureEnable().
Not completely conclusive, but it leans me towards thinking your “3C” class might be the same as my “03” class - they just ran out of “03” addresses and moved to “3C”, so maybe yours also takes 28 msecs to complete the COPY_SCRATCHPAD command.
Rather than adding another call to delay() after the call to EmonLibCM_TemperatureEnable(), it might make sense to change the existing delay(20) to a delay(30) at the end of that routine, to allow for sensors like my “03” class - and possibly your “3C” class.
BUT - I guess the other thing to keep in mind is why EmonLibCM is changing the temperature conversion resolution in the first place. I’m not fluent with the detail there, but I believe it’s about making the timing work alongside the ADC interrupts. If you look at that table above, changing the resolution doesn’t help with the timing on my “03” class sensors (and possibly your “3C” class sensors). It may be that those non-compliant sensors are just fundamentally incompatible with EmonLibCM timing requirements.
These guesses about ds18b20 suitability based on a single byte in the UID really are just guesses. The only way I know of to determine if it’s a dud, is to time how long it takes to do a conversion, after you’ve set the resolution.
That might be a possible way forward for you guys. You only support a smallish number of temperature sensors right (4 or 5?). After the bus discovery, and the programming of the resolution, you might want to consider issuing a one-time directed temperature conversion command to each sensor. Time how long each one takes. Any that are out of spec can be flagged as duds and from then on in you could skip reading the dud conversion results and instead replace the temperature with yet another reserved temperature to indicate an unsupported non-compliant fake.
I guess the downside is a slightly longer start up time of a few seconds, while you probe each temp sensor for suitability.
As proof not all clones are bad, this manufacturer is out and proud about their improved conversion times compared with Maxim’s, and the part is quite a bit cheaper too…
Conversion time is one thing but what is annoying about the clone that I have is the 25 degree readout - as others have pointed out this might be tricky to remove from a dataset. Much happier with 304 degrees (or even 85) for my use case. Incidentally I tracked the clone probe I bought to a well-known Raspberry Pi reseller (one that is for idiots apparently ) and they advertise it as a clone, and it was cheaper so I can’t complain.
Yes, the best clones do the fast conversions and comply with the 85C startup temperature. That UMW clone claims to do that although I’ve not seen or tested one.
In my limited sample space, the clones that return 25C at start-up also fail to comply with the conversion timing specs - in particular they don’t get faster with lower resolutions - a feature that EmonLibCM needs. They also don’t comply with the COPY_SCRATCHPAD timing specs.
did you unplug the power supply, USB-C cable in between each upload, if it’s power related that would only show up after a full power cycle with a decent gap to allow any charge in capacitors and other power supply components to drain…
) and they advertise it as a clone, and it was cheaper so I can’t complain.