Is the continuous sampling option now not available on the emonSD-03May16 Release?
I see it’s not an option to comment/uncomment in ~/emonpi/emonpiupdate and discrete sampling hex is now in
/home/pi/emonpi/firmware/compiled/latest.hex where previously the continuous sampling hex used to live.
I have been running this sketch on an emonpi for some time with no apparent problems.
The Continuous sampling code has been moved to it’s own branch. There were several issues with it’s functionality. @Robert.Wall is there a thread noting the issues with emonlibCM?
For these reasons we have decided to put rolling out continuous sampling on hold. If you want to use it as before you can just checkout the emonPi continuous sampling branch.
No! I’m still finding them! There is about a screen-full as it stands (from memory) of varying severity.
Quickly scanning my notes, a partial list of the main problems is:
“offset creep” causes errors at low currents,
Jitter,
Overflows at > 10 s reporting interval,
Filter time constant wrong,
Wh accumulator error,
Irms wrong values.
This has proved to be a much bigger job than I expected. I believe I now have the core functions of the library working and capable of being calibrated accurately, but there is little spare processing time available. It will not work with JeeLib, but it will with a stripped down version that is only capable of transmitting.
What remains then is to integrate the pulse input logic and prove compatibility, and integrate the RFM code.
Thanks for the update on CM, Robert. I’m still using a mildly tweaked version of the emonPi Continuous Sampling firmware.ino from March, without any obvious problems, as whatever inaccuracies it has are beyond my ability to discern, so I’m not losing any sleep over it.
I’m looking forward to a new release whenever it appears, and many thanks for continuing to work on it.
Dont know why this new continuous sample project appeared if a lib was already available since 2013 made by myself and used with great success since then.
Take a look : https://openenergymonitor.org/emon/node/2406
Your library is phase locked, is it not? The CM library is free running, so although both are intended to achieve the same result, they do it in different ways. Some users prefer one method, others prefer the other. Some argue one is better, others argue the other is.
Hi Robert, short answer is no,
Its free running via interrupts so it lets you do other things in the main loop and did started its existence with a PLL implementation to keep jitter low but since version 2 i disabled the PLL (via config) as i could now compensate the jitter on the long term by using the timer1B to trigger ADC reads consistently.
Take a look at it…
The emonPi’s demands are somewhat different to the emonTx, in that the radio must be polled very frequently as it is used to receive incoming data from any sensor nodes and pass it on to the RPi via a serial connection; so the processor is much busier.
At this time, I cannot say whether it will be possible to have ‘continuous’ monitoring given the demands that the radio makes on processor load.
Never looked at the code of emonPi but assuming there is no bitbangin stuff happening and only SPI / I2C / serial and there is free memory, it should be doable in cpu time terms.
I’m using my library with ethernet comms via spi bus and serial data for debug on the same mcu,
I wrote my comment in the light of my experience with the 3-phase PLL code. There was no possibility of using the JeeLib RFM12B compatible library routine because the interrupts and processing around the ADC required to handle the measurements were preventing the radio from sending a continuous stream of data, so the checksum was failing. Or in simple terms, JeeLib’s RFM12B code requires almost exclusive access to the processor while it’s transmitting. Similarly, serial comms above 9600 baud was not possible. The radio problem on transmit was solved by using the internal buffer in the RFM69CW (which the RFM12B does not have), but this limits the size of payload. I have never looked hard at the receive part of Jeelib nor the receive part of the RFM69CW, hence I’m cautious about the feasibility.