Archived Forum

For info Robert, I've created a 'git' pull request to revert the changes as per your post above, until a better fix is available for the other issue.

It's important that both issues are fixed eventually, but I think that these current errors outweigh the preceding problem.  

Paul

I'm working on it. There's a fix in the sample sketches that's been working well for a long time: exercise the filters for about two hundred or so iterations during startup - throw the result away (but leave the "last" values in the filters).
But it was a bit naughty of Jack to submit an untested change, don't you think?

But it was a bit naughty of Jack to submit an untested change, don't you think?

It was probably done in good faith, and unless the author is a seasoned programmer, it's very easy to cure one problem whilst creating another. I blame Glyn - he authorized it!

Paul

I'm pleased to report that none of my sketches uses emonLib (other than RawSamplesTool.ino which has been replaced by the improved version, RawSamplesTool_4ss_2.ino, both on my Summary Page )

Happy New Year to all!

As of 1300 UTC on 1 Jan 2015, Glyn advises that the earlier EmonLib (SHA: a3272aeb5e86ede0e9a1e41ba573d9d572fb2412) has been restored.

The new library is available for testing at https://github.com/openenergymonitor/EmonLib/tree/Dev.

You should carefully test and verify the data produced before relying on the readings from any sketch that uses this library.

Using the library: Replace your existing EmonLib directory with this one. No changes to any sketch are necessary, however the section in some of the example sketches near the end of the setup( ) method, following the comment "Do some measurements to allow the software filter to settle - don't use the result" that calls calcVI( ) or calcIrms( ) a number of times is redundant, and can be removed with no ill effect. If these statements are not removed, the only difference that is the setup( ) method takes a little longer to complete.

The change has now been incorporated into the main download of emonLib.

The change concerns how the d.c. offset of ½V_CC, introduced by the hardware, is removed. In the original version of emonLib, this was done with a high pass filter that removed the offset directly by the action of the filter. At start-up, it took a few hundred iterations of the filter for the offset to be removed sufficiently for the output to settle, giving erroneous values until that happened.

The change has been to replace the high pass filter with a low pass filter, whose output is the d.c level introduced by the hardware. Given the correct resistor values, the value of this will be ½V_CC, or 511, to within around 1% and the filter can be pre-loaded with this number at start-up, thus effectively removing - or at least dramatically reducing - the time taken to reach the final value. The offset can then be removed from the input signal by a simple subtraction. The principal benefit of the rapid start-up is that the output is available for use immediately, with little or no error. A side effect is the filter time constant can be increased significantly, thereby improving the performance of the filter.

As noted above, no change to the sketch is necessary, but a little time will be saved at start-up if the change described in the post immediately above this is implemented.

Can this thread by renamed now and unstickyed, since emonHub is now 'fixed'! Thanks for your help. 

It's now past tense! - but how has it only just popped up in "Active Forum Topics"?

It was me, I edited it to make it 'un-sticky' as the problem has now been fixed. This has the side effect of brining it back to the top of the forum, however it will now gracefully descent hopefully to never be seen again! 

Yep, as does commenting on it.

Yes, but it took from Saturday until Tuesday before it popped up!