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.
Thanks
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.
thank you so much for your help, it was just what I feared…
I will follow Robert’s advice and replace the buzzer
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?
I don’t know why you can’t see it. I have, only a few moments ago, downloaded it from
and both files are in there.
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?
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.
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
Sorry, but I have no control over Github.
At the head of the Topic announcing emonLibCM, it very clearly states
and that is indeed what has been happening.
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!
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.