EmonLibCM - Version 2 (Support)

[nicsergio (Sergio)]

thanks for the answer, probably for the sampling time it would take me 2-3 seconds to command the buzzer (even now I managed a delay in exceeding the threshold), for the temperatures I go on studying the library

Thanks again

[nicsergio (Sergio)]

I’m slowly moving forward with my project (it’s not easy with a baby girl).
I made a slight modification to the V2.0.4 library, which I wanted to share, if @Robert.Wall deems it useful (and above all correct) he could integrate it in a future release.

For those who need quite fast clocks in electrical parameter measurements, but not for temperature measurements, I added a property:

temperatureSamplingRatio (default = 1)

to be considered as a multiplier of the “datalog_period”: if this property is not changed, the measurement clock will be the same as the electrical parameters (datalog_period_in_seconds) and the library behavior will be standard, otherwise the temperature data will be available every (datalog_period_in_seconds * temperatureSamplingRatio).

For example by setting datalog_period_in_seconds = 0.5 and temperatureSamplingRatio = 120, the temperatures from the sensors will be read every minute.

I then added the EmonLibCM_setTemperatureSamplingRatio(int) property-setter
and the return value of EmonLibCM_Ready() will no longer be a boolean, but a bitmask indicating the type of data available (only electrical or even temperatures).

I also removed the inclusion of the Wire and SPI libraries, as they don’t seem to be used in the library.

I’ve done some testing and everything seems to work, I haven’t tried in acPresent==false mode.

EmonLibCMmod.zip (15,6 KB)

[djh (Dave Howorth)]

@nicsergio

For those who need quite fast clocks in electrical parameter measurements, but not for temperature measurements, I added a property:

temperatureSamplingRatio (default = 1)

to be considered as a multiplier of the “datalog_period”: if this property is not changed, the measurement clock will be the same as the electrical parameters ( datalog_period_in_seconds ) and the library behavior will be standard, otherwise the temperature data will be available every ( datalog_period_in_seconds * temperatureSamplingRatio ).

What’s the benefit of doing this, versus just discarding the unwanted samples?

[nicsergio (Sergio)]

I see some advantages:

• with clock less than 0.2 seconds the temperature measurement would not be possible, the library returns BAD_TEMPERATURE

• with clock lower than a second the resolution is forced to the minimum (9 bit)

• if I just need a temperature recording every minute, but I need to measure the electrical parameters every 0.5 seconds (see my example above) doesn’t seem like a good idea to invoke a temperature conversion on all sensors 120 times per minutes where 119 are done for nothing

[Robert.Wall]

I need to look into the timings in detail before commenting.

[nicsergio (Sergio)]

a question for my curiosity: in my Arduino project, as written in some previous posts, I command a buzzer to signal that power exceeds a settable threshold

the command is done using the tone() statement:

tone(BuzzerPin, 2500);

I noticed that, compared to the use of the discrete EmonLib library, with the CM the tone emitted by the buzzer is different, a lower frequency: this behavior derives from the use of interrupts?

[Robert.Wall]

I won’t investigate (as I’m too busy), but I would be almost certain that this is the case.

The solution of course is to use a self-contained sounder that needs only a d.c. signal to drive it, and turn on a digital output for the duration you want the sounder to sound, rather than driving a piezo element directly as you appear to be doing.

[nicsergio (Sergio)]

Thanks

[dBC]

See also Tone

[dBC]

Be aware that the interference may well happen in both directions. It’s been a while but from memory AVR interrupts aren’t nestable - they’re all at the same priority. So just as the latency introduced by the ADC interrupt impacts on the tone’s timer interrupt, so too the tone’s timer interrupt might introduce enough latency to disturb the ADC work.

[nicsergio (Sergio)]

thank you so much for your help, it was just what I feared…

I will follow Robert’s advice and replace the buzzer

[cjcar (Chris Carruthers)]

Continuing my (on and off) efforts to make emontx (and firmware EmonTxV3CM) work for me, I downloaded version 2.1 of the library from github and bumped into a compile error involving variable assumedVrms. Further digging around reveals that github no longer hosts the most recent version (2.2.1), which I downloaded as provided elsewhere in this forum. This version fixes the problem by renaming the variable, just as I did!

However, looking at the zip file I downloaded, I do not see the .h file for v2.2.1. Am I missing something?

[Robert.Wall]

I don’t know why you can’t see it. I have, only a few moments ago, downloaded it from

EmonLibCM - Version 2.2.2

EmonLibCM is a Continuous Monitoring alternative to EmonLib. Whereas emonLib repeats, every 5 or 10 s, a sequence of voltage and current measurements in each of the input channels for a short period, normally 200 ms, and then reports the measurements back to the sketch for onwards transmission to (for example) emonCMS; emonLibCM continuously measures in the background the voltage and all the current input channels in turn, calculates a true average quantity for each and then informs the sketch t…

and both files are in there.

[cjcar (Chris Carruthers)]

Hmmm…let me try again. Is this the zip you just downloaded:
(https://community.openenergymonitor.org/uploads/short-url/cki8rw81NPsluJrDRIhlJxXI9QO.zip)

If so, what I see in that file is a directory named emonlibCM within which is a .cpp and .h file containing comments indicating version 2.2.0. I also see at the root directory of that zip a .cpp file, but not a .h file, with comments indicating version 2.2.1. Is that what you see?

[Robert.Wall]

That clarifies the problem. The release seems to have got tangled up, the header file was always the correct one - it was unchanged, the cpp file just hadn’t got put into the sub-directory to replace the 14th Sept version. I’ve updated the release page with a new zip file, but not changed the version number as the code is unchanged.

Thanks for spotting it.

[OffGridder (Andrew Wedmore)]

I have just experienced the same problem (“compile error involving variable assumedVrms”) and eventually solved it using the information above.

However, I think there is still an issue to be fixed, as GitHub - openenergymonitor/EmonTxV3CM: EmonTxV3 Continuous Monitoring Firmware (Default shipped EmonTxV3 firmware) refers to version 2.1, which gives the compile error. I got version 2.2.1 from https://community.openenergymonitor.org/uploads/short-url/tPz0uVfDxInGNWuPgvVhwchs6IG.zip. I couldn’t find version 2.2.1 on Github - maybe my ignorance but at any rate it wasn’t obvious.

Best wishes and thanks for all the software.

Andrew Wedmore

[Robert.Wall]

Sorry, but I have no control over Github.

At the head of the Topic announcing emonLibCM, it very clearly states

@Robert.Wall

It is my intention to post any updates here.

and that is indeed what has been happening.

[halol]

Hello,
Unless I missed something, the Arduino Due doesn’t seem to be supported at all by EmonLibCM. Is this correct (although I saw a reference to the board in the code)?
And if so, any chance to see support for the Due in a near future? Is there any I could help with this, despite my near complete lack of development skills?
Thanks!

[Robert.Wall]

@halol

Unless I missed something, the Arduino Due doesn’t seem to be supported at all by EmonLibCM. Is this correct

You are indeed correct. The code is very closely integrated to the timing characteristics of the Atmel 328P. No consideration has been given to using an alternative host, and I don’t foresee being able to offer very much assistance to anyone who wishes to attempt a port within the foreseeable future; I am far too preoccupied not only with the Atmel-DB, but with commitments outside of OEM.