EmonTx4 firmware update, v1.5.4 (fix for calibration reset issue)

TrystanLea · 2022-12-31T17:57:06.837Z

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?

TrystanLea · 2022-12-31T17:59:42.884Z

NickT:

AC missing - Apparent Power calc enabled, assuming 240.00 V

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.

dBC · 2023-01-01T06:25:08.238Z

Robert.Wall:

If so, it’s a perfectly legal ‘C’ language construct, and it’s correct. I’ve no idea why the compiler is flagging it.

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:

a6:  80 93 06 01    sts  0x0106, r24
aa:  88 23          and  r24, r24
ac:  51 f0          breq .+20

The parameter is passed in via r24, stored in the global variable and then ANDed against itself to set the zero bit for the conditional branch.

Robert.Wall:

The question has been asked many times, and I’ve responded many times. Maybe you didn’t find it in a search?

Maybe let that be your guiding light? Choose a version that will lighten your enquiry load.

dBC · 2023-01-01T06:42:27.718Z

TrystanLea:

It would be good to get an idea of the amount of delay that is required.

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:

Screenshot from 2023-01-01 16-34-491405×283 35.2 KB

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?

NickT · 2023-01-01T14:11:40.228Z

TrystanLea:

NickT:

I then moved it after the call (see image) and it works!

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.

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.

How frustrating is that? What next?

NickT · 2023-01-01T14:22:48.270Z

dBC:

@NickT - do you happen to know the UID of your ds18b20s?

They are:

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.

TrystanLea · 2023-01-01T17:13:02.152Z

Thanks @dBC that’s a useful pointer.

NickT:

How frustrating is that? What next?

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…

NickT · 2023-01-01T18:21:12.674Z

TrystanLea:

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.

TrystanLea · 2023-01-01T18:27:14.464Z

Ok thanks for trying your best with this @NickT I will do some more tests here this week and see if I can find a way to replicate the issue.

dBC · 2023-01-02T09:53:37.477Z

NickT:

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.

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:

Screenshot from 2023-01-02 18-55-23782×291 34.2 KB

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().

NickT:

The fact that many clones put out 25 degrees in the initial phase matches the behaviour I saw on T1 (the clone)

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.

dBC · 2023-01-02T10:07:27.720Z

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.

TrystanLea · 2023-01-02T10:11:54.226Z

Thanks again @dBC those are really useful pointers.

borpin · 2023-01-03T14:13:23.622Z

4 posts were split to a new topic: Accuracy of TX4 measurements

dBC · 2023-01-03T11:13:04.982Z

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.

dBC · 2023-01-05T00:59:25.885Z

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…

Screenshot from 2023-01-05 10-57-441364×190 15.1 KB

(although it looks like they forgot to edit Table 2 when they copied Maxim’s datasheet).

2203071530_UMW-Youtai-Semiconductor-Co—Ltd–DS18B20_C376006.pdf (3.2 MB)

NickT · 2023-01-05T21:26:29.633Z

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.

dBC · 2023-01-05T22:17:26.602Z

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.

borpin · 2023-01-06T06:59:14.268Z

dBC:

the best clones do the fast conversions

Is there any trick to getting ‘good’ clones?

dBC · 2023-01-06T19:41:41.877Z

If you’re buying the actual ICs some places like here give you a choice of manufacturer.

borpin · 2023-01-06T19:52:53.227Z

No I’d be after the encapsulated ones