Update
continuous sampling firmware for the emonPi is currently in beta testing:
https://github.com/openenergymonitor/emonpi/tree/master/firmware
Latest version: V3.2 (31/01/15)
https://github.com/openenergymonitor/emonpi/blob/master/firmware/CHANGE%...
To update the ATmega328 on your emonpi you need to edit the file ~/emonpi/emonpiupdate and comment out the discrete sampling fimrware and un-comment the continuous sampling firmware. Then run admin > update emonpi e.g.:
# Discrete Sampling #echo "Discrete Sampling:" #echo "avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U #flash:w:/home/pi/emonpi/Atmega328/emonPi_RFM69CW_RF12Demo_DiscreteSampling/compiled /emonPi_latest.hex" #avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U #flash:w:/home/pi/emonpi/Atmega328/emonPi_RFM69CW_RF12Demo_DiscreteSampling/compiled /emonPi_latest.hex # Continuous Sampling echo "Continuous Sampling:" echo "avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/home/pi/emonpi/firmware/compiled/latest.hex" avrdude -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/home/pi/emonpi/firmware/compiled/latest.hex
https://github.com/openenergymonitor/emonpi/blob/master/emonpiupdate
Known Issues
Issues with receiving data from other RF nodes stopping working after about 24hrs, require a reset, power cycle or change of settings to restore operation.
--------------------------------------------------------------------------------------------------------------------------------------------
Earlier last year, Robin Emley built a continuous sampling example for general OpenEnergyMonitor emontx v3.4 use. Due to work on other things at the time, I couldn't do the final integration work needed to replace the existing discrete sampling approach that we are using in our standard emonpi and emontx v3.4 firmware.
Over the last couple of weeks, I have spent some time on this again and have now created an example for both the emontx v3.4 and emonpi that uses Robin's continuous sampling code while also supporting all the other requirements.
One of the requirements of the emontx v3.4 is the ability to run in both battery powered mode where it sleeps between discrete readings, and powered mode where it can be on all the time. I adapted Robin's code to be able to be stopped and started again so that the emontx v3.4 can be in continuous sampling mode when powered from the ACAC adapter and USB, but can also switch to discrete sampling mode when being powered by batteries.
I've wrapped the code up into an Arduino library to make the main firmware examples neater, which can be found here:
https://github.com/openenergymonitor/EmonLibCM
Here's a code example using the library for an idea of what it looks like:
#include <Arduino.h>
#include "EmonLibCM.h"
#include <JeeLib.h>
ISR(WDT_vect) { Sleepy::watchdogEvent(); }
void setup()
{
Serial.begin(9600);
Serial.println("EmonTx v3.4 EmonLibCM Continuous Monitoring Tester");
EmonLibCM_number_of_channels(4); // number of current channels
EmonLibCM_cycles_per_second(50); // frequency 50Hz, 60Hz
EmonLibCM_datalog_period(10); // period of readings in seconds
// number of cycles to let ADC run before starting first actual measurement
// larger value improves stability if operated in stop->sleep->start mode
EmonLibCM_min_startup_cycles(10);
EmonLibCM_voltageCal(0.84); // 260.4 * (3.3/1023)
EmonLibCM_currentCal(0,90.9*(3.3/1023)); // 2000 turns / 22 Ohms burden resistor
EmonLibCM_currentCal(1,90.9*(3.3/1023)); // 2000 turns / 22 Ohms burden resistor
EmonLibCM_currentCal(2,90.9*(3.3/1023)); // 2000 turns / 22 Ohms burden resistor
EmonLibCM_currentCal(3,16.6*(3.3/1023)); // 2000 turns / 120 Ohms burden resistor
EmonLibCM_phaseCal(0,0.22);
EmonLibCM_phaseCal(1,0.41);
EmonLibCM_phaseCal(2,0.60);
EmonLibCM_phaseCal(3,1.25);
EmonLibCM_Init();
}
void loop()
{
if (EmonLibCM_Ready())
{
Serial.print(EmonLibCM_getRealPower(0)); Serial.print(':');
Serial.print(EmonLibCM_getWattHour(0)); Serial.print(',');
Serial.print(EmonLibCM_getRealPower(1)); Serial.print(':');
Serial.print(EmonLibCM_getWattHour(1)); Serial.print(',');
Serial.print(EmonLibCM_getRealPower(2)); Serial.print(':');
Serial.print(EmonLibCM_getWattHour(2)); Serial.print(',');
Serial.print(EmonLibCM_getRealPower(3)); Serial.print(':');
Serial.print(EmonLibCM_getWattHour(3)); Serial.print(',');
Serial.print(VrmsTimes100);
Serial.println();
// UNCOMMENT TO TEST STOP/START SLEEP OPERATION
// EmonLibCM_Stop();
// delay(50);
// Sleepy::loseSomeTime(10000);
// EmonLibCM_Start();
}
}Crucially, Robin's code runs in the 'background' on an ISR (interrupt service routine) and so is compatible with other code running in the main loop including temperature sensing and RFM12/69 radio operation.
I've put together a EmonPi and EmonTx v3.4 example here, these include temperature sensing, pulse counting and rfm12/69 radio operation and all the other bits and pieces in the standard firmware. I'm currently running tests on these and early results look good.
EmonPi continuous sampling example
EmonTx v3.4 continuous sampling example
My last test with the emontx v3.4 code showed a small amount of power consumption when there was nothing physically connected - about 0.3 kWh over 5 days which I need to check. I also added in radio ACK's to the emontx v3.4 code and watt hour calculation on the emontx. I'm still testing the reliability of the radio comms with this much longer data packet.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
The small amount of power consumption measured with nothing connected is around 2.5W on average and is present to a similar extent with the discreet sampling firmware on some of the channels on the emontx that I'm testing with.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
I'm happy now that the EmonPi Continuous Sampling example is ready for final testing. Would anyone perhaps with a MK2 or other triac based PV diverter and an EmonPi be interested in testing? Or anyone who can do parallel testing with a utility meter. We will keep testing here over the next week and aim to move over to it as the standard firmware on the emonPi if all goes well in a week's time.
The steps to upload the emonpi continuous sampling code are:
ssh in to the emonpi
cd emonpi
git pull
sudo service emonhub stop
avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/home/pi/emonpi/Atmega328/emonPi_RFM69CW_RF12Demo_ContinuousSampling/compiled/emonPi_RFM69CW_RF12Demo_ContinuousSampling.cpp.hex
sudo service emonhub start
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
This sounds like a great improvement. Do you end up with the same calibration values with the new firmware compared to the old? I spent a long time calibrating one of my EMONTX's and redoing it will be physically difficult
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
can this work on an emontx 3.2 for 3 phase monitoring?
cheers
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Probably not, without a lot of work. You would need to take the basic 'continuous' sketch, graft in the array that's needed to delay the voltage samples to synchronise them with phases 2 & 3 currents, and deal with timing issues. My approach - when I can find the time - will be a phase-locked loop, and that should completely negate the problems with timing.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
thanks Robert,
I take it there's no continuous sketch for 3 phase for the 3.2 that is currently availalbe?
Cheers,
Alex
/edit: i have had a nightmare of trying to calibrate my emontx, i assume because of the timings you mentioned, and i don t think it s right still..
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
The testing I've performed this week with the emonpi continuous sampling code is showing a slightly more noisy reading with a standard deviation of ~5W at around 150W instead of 2-3W that was typical with the discreet sampling code on the same emonpi at similar power levels. I would have expected it to be less than the discreet sampling as the power values should be averaged over a longer time. Testing continues..
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Trystan, from my tests while coding EmonlibPro some months ago i could get 0-0.01W if CT was not attached to cable and 0-0.2W readings when the live measured power cable was unloaded.
Assumed residual W's due to rf noise picked up from the environment as electric cable acts as an antenna. Long term test shown that noise was lower during night.
If you're not getting such low values check power supply noise, etc. Or try to use my lib as a test.
Found that post:
http://openenergymonitor.org/emon/node/10111
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
alexg:
"I take it there's no continuous sketch for 3 phase for the 3.2 that is currently availalbe?"
That's true at the moment, but I'm working on it. It's based on MartinR's PLL, which should negate a lot of the timing problems.
As it stands, your 3-phase sketch depends on the mains frequency being stable. If it drifts, it will introduce phase errors - all details are in the comments (I think!).
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
thanks robert, eagerly awaiting :D
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Thanks Chaveiro, I was referring to the standard deviation on a 150W night time level rather than the zero power level, but your 0-0.2W sounds really nice and low compared with the 2.5W I read above. Yes might be a power supply or other issue will do some more testing.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Sometimes, I find an idle channel that displays a drift of zero. A while later, the same hardware channel can display a positive drift of maybe half a watt. Occasionally, I've seen a negative drift.
When full scale is set for several kW, I think these minute drifts are more to do with quantisation effects than with any genuine errors in the measurement system.
Reducing the range over which the measurement system operates should help to minimise these effects.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Thanks Robin, Testing again now with an emontx v3 and Im getting better results than the discrete sampling code.
Standard deviation @ 52Watts direct sampling code 1.2
Standard deviation @ 2335Watts direct sampling code 2.5
Standard deviation @ 30Watts continuous sampling code 0.4
Standard deviation @ 2335Watts continuous sampling code 1.9
kWh calculated on the emonpi with the power to kwh accumulator:
Continuous sampling: 14.38
Discrete sampling: 14.83
A100C billing grade meter: 6109.9 → 6124.5 14.6
Voltage calibration was set to 260.4 on both continuous sampling and discreet sampling code and current calibration was also the same 90.9. Continuous sampling is 1.5% below and Discreet is 1.5% above which is within the range of possible error. That's without individual calibration to take into account the voltage reference and component tolerances: http://openenergymonitor.org/emon/buildingblocks/ct-and-ac-power-adaptor...
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Latest emonTx v3.4 continuous sampling code: https://github.com/openenergymonitor/emonTxFirmware/blob/master/emonTxV3...
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
The emonhub decoder for this example is:
[[10]]
nodename = emonTx_CM
firmware = emonTxV3_4_Continuous_Beta_0_2
hardware = emonTx_(NodeID_DIP_Switch1:OFF)
[[[rx]]]
names = msg,power1, power2, power3, power4, Vrms, T1, T2, T3, T4,pulse,fail
scales = 1,1,1,1,1,0.01,0.1,0.1,0.1,0.1,1,1
datacodes = L,h,h,h,h,h,h,h,h,h,L,L
units = n,W,W,W,W,V,C,C,C,C,n,n
I've missed out the sending of the accumulating watt hours in this example for now as the power consumption in sending the longer packet alongside all the temperature values causes the emontx to reset.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
I've just given this a try and it appears as node 42 in EMONCMS v8.5 lowwrite, despite the code suggesting it should be node 10 which it is with the discrete sampling firmware.
EMONHUB (EMONPI Version) says
MQTT INFO Received mqtt message: emonhub/rx/42/values 39,0,801,540,1,2,23200,380,655,663,3000,0,0,38,0
the debug window says data: 809 540 1 1 23200 0 378 655 663 , 4477ms
The received data appears to be
msg, ???, power1, power2, power3, power4, Vrms, T1,T2,T3, ???, 0,0,??,0
Which is different to the EMONHUB settings above which I entered into my node10 config section.
I have 4 x CT, Mains, 3 x 1Wire's connected to the EMONTXV3.4
What am I missing?
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
In JeeLib a "node id" bettween 32 and 64 is basically a node between 0 and 31 with the "ack bit" set, I suspect you might be using an rfm12 or early rfm69 type RFM2Pi, there was a firmware issue that didn't mask the first 3 bits of the byte to only pass the remaining 5 bits as a node id.
This is not usually a problem if you do not use ack's. Trystan was working on this at the same time as researching the reliability of the rfm network so I suspect this sketch had the acks enabled and the "fail" count at the end. Updating the firmware in the RFM2Pi should fix this issue properly although you could also edit the emonTx sketch to not require acks.
The other problem with the value count and payload format is due to the use of Longs in the emonTx payload so the first 2 ints are actually 1 long and the same for the last 4 ints being 2 Longs
msg, ???, power1, power2, power3, power4, Vrms, T1,T2,T3, ???, 0,0,??,0
[[[rx]]]
names = msg,power1, power2, power3, power4, Vrms, T1, T2, T3, T4,pulse,fail
scales = 1,1,1,1,1,0.01,0.1,0.1,0.1,0.1,1,1
datacodes = L,h,h,h,h,h,h,h,h,h,L,L
units = n,W,W,W,W,V,C,C,C,C,n,n
There are also 4 temperture sensor values, the 3 you have populated and the 4th is automatically set to an "out of scope" value of 300 so it is obviously not a temperture rather than being 0 which could be interpreted as a temperture and if there are several zeros it could cause a "bitslip" issue and packets get dropped.
Paul
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
While trying to understand the fine details in EmonLibCM (and also EmonLib) I have spotted what I think is an error in EmonLibCM (as of Latest commit 84993d5 on Nov 25, 2015) dealing with phaseCal
In function EmonLibCM_interrupt(), when processing a voltage sample (sample_index=0) the (static) variable sampleV_minusDC_long is calculated, and later copied into the (global) variable lastSampleV_minusDC_long. Also in function EmonLibCM_interrupt(), when processing a current samples (sample_index >=1), a calculation is done:
phaseShiftedSampleV_minusDC_long = lastSampleV_minusDC_long + (((sampleV_minusDC_long - lastSampleV_minusDC_long)*phaseCal_int_CT[sample_index-1])>>8);
To my understanding, the part (sampleV_minusDC_long - lastSampleV_minusDC_long) will always result in zero, effectively zeroing the effect of phaseCal.
The assignment:
lastSampleV_minusDC_long = sampleV_minusDC_long; // required for phaseCal algorithm
has to be moved upwards (first in section), before the new value of sampleV_minusDC_long is calculated.
In EmonLib, the corresponding processing works, as the old value is saved first in processing (lastFilteredV = filteredV;) then the current value is calculated. Later the new and the old value is (correctly) used in the phaseShift calculation:
phaseShiftedV = lastFilteredV + PHASECAL * (filteredV - lastFilteredV);
Per-Ake
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Certainly, I get a power factor of 1.00 irrespective of the value I put for phasecal (even stupid values). And that isn't right. In Robin's original diverter sketches, from which this is derived, the assignment lastSampleV = SampleV was at the end of allGeneralProcessing( ) and that appears to have been missed in the conversion.
Also a question for Trystan: why is the voltage returned as an integer? Clearly, there was an intention to return it as Voltage * 100, for compatibility with emonCMS one presumes, as that's what is in the example sketch - and which doesn't work because it doesn't exist!
I've flagged this to Trystan.
[Edit]
I agree. Moving the linelastSampleV_minusDC_long = sampleV_minusDC_long; // required for phaseCal algorithm
to just abovesampleV_minusDC_long = ((long)rawSample<<8) - DCoffset_V_long;
seems to be what is required. This position is equivalent to where Robin had it (after the first voltage sample had been processed). I can't see any side effects as yet.I've spotted the real problem. In Robin's version, lastSampleV_minusDC_long was declared as "static". Changing the declaration to static long lastSampleV_minusDC_long; to make it persist between calls to the ISR is the correct solution to keep the versions aligned as far as possible.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
To my understanding, as the current declaration of the variable is done in the global space, it behaves the same as static in the aspect of keeping the value between interactions, so only changing to static long doesn't solve the issue.
The sequencing is still the problem as these variables are intended to hold values from two separate (adjacent) voltage samples, not one single.
/Per-Ake
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
The phaseCal algorithm synthesizes a time-shifted version of the voltage stream which can serve to offset any phase error in the measurement equipment. For each such calculation, the latest and previous filtered voltage values are needed. With this latest library code, phaseCal calculations for individual CT channels are done during separate visits to the ISR, so both of these values must persist from one visit to the next. Whether these two variables are defined as globals or static will not affect the behaviour of the code, only its readability
As I understand it, the basis for these latest routines in EmonLib is the "continuous" code that I supplied for using the emonTx V3.2 as a Mk2 Router. This code can be found at at http://openenergymonitor.org/emon/node/10171
In that code, the filtered values of the latest and previous voltage samples are stored as globals. These two variables are sampleVminusDC_long and lastSampleV_minusDC_long. Because these variables are only used in ISR(), it would be tidier for them to be defined as static within that routine. But they will work equally well as globals.
At the top of ISR() is an unhelpful declaration for static long sampleV_minusDC_long. This variable is never used so is serving no purpose other than to cause confusion. Sorry about that, I should have removed it.
In previous versions of my "continuous" code, a complete set of ADC samples was dealt with during each visit to the processing routine so only one voltage value (for the previous filtered voltage sample) had to persist from one loop to the next. But with this latest version, where all of the time-critical processing takes place within the ISR, two persistent values are needed. This alternative scheme was devised to prevent slow activities such as temperature sensing from disrupting the underlying sampling process.
In previous versions, the latest value for filtered voltage was calculated at the top of the processing routine, then repeatedly used for each of the current streams, and finally stored as 'previous' at the end. With the new arrangement, I now agree with Per-Ake that the 'previous' value needs to be stored before the new value is assigned rather than afterwards as occurs at present. Given the way that my code is currently structured, none of the subsequent phaseCal calculations will have any effect. For this error I can only apologise.
Phase-shift and phaseCal have minimal effect on calculations for real power which is my main area of interest, hence I have never needed to use this aspect of the code myself.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Thanks Robert, Robin, Per-Ake, Is this the correct change: https://github.com/openenergymonitor/EmonLibCM/commit/2e5a74e727db412758... I havent had a chance to test this yet.
We're getting some stability problems on the EmonPi with the continuous sampling code which I need to look into. Arduino does show a "Low memory available, stability problems may occur." error at compilation.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Trystan, I don't see any need to change the declaration of any variables. The only change that's needed is as described by Per-Ake a few posts ago, i.e.
The assignment:
lastSampleV_minusDC_long = sampleV_minusDC_long; // required for phaseCal algorithm
has to be moved upwards (first in section), before the new value of sampleV_minusDC_long is calculated.
RE
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Robert has highlighted a couple of issues with EmonLibCM and has kindly offered to help debug. For anyone thinking of trying the code, it may be best to wait for now until these issues are resolved. Robert or I will post up once we are happy its ready for further testing.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Paul,
Thanks for the reply, can you point me to instructions how to update the RFM2Pi please - didn't know the modules were updatable. It's an RFM69 type shipped April / May last year
thanks
Kevin
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Sheppy,
Hi, Per-Ake jumping in.
The article
http://wiki.openenergymonitor.org/index.php/RFM69Pi_V3
describes setup and maintenance of the RFM69Pi_V3-module
Per-Ake
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Thanks very much, will get onto that later, although I'll keep away from this sketch until it's ready for testing again
cheers
Kevin
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
OK, just tried that and I don't think it went that well. When I issued the AVRDude command I got the following back - does anyone have an idea what's wrong? I've tried it with an earlier sketch before I installed Openhab with the same results
avrdude: Version 6.1, compiled on Jul 7 2015 at 13:18:47
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/home/pi/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/ttyAMA0
Using Programmer : arduino
Overriding Baud Rate : 38400
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x4f
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x4b
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x20
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x39
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x20
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x36
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x32
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x20
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x31
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x20
avrdude done. Thank you.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
After an extensive spot of searching the forum I found this
http://wiki.openenergymonitor.org/index.php/RFM12Pi_V2#Upgrading_RFM12Pi...
once I followed that I got a successful flash and then flashed it with the correct RFM69 version. Hopefully that will have me ready for testing the continuous sketch when its ready.
Thanks for your help!
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
By running the the git clone-command specified in the RFM69Pi_V3 article above, the original avrdude is renamed to avrdude-original and a wrapper is installed replacing the name avrdude. This wrapper manipulates the DTR-line and invokes avrdude-original.
Correct invokation of the wrapper and the wrapper invoking avrdude-original results in the following start of messages:
avrdude-original: Version 6.1, compiled on Jul 7 2015 at 13:18:47
It seems that your installation is not correct.
/Per-Ake
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Is anyone running the continuous sampling code on emonPi?
See the top post for update instructions and latest version info.
I have noticed an issue with received data from other RF nodes not working after about 24hrs. Requires a reset, power cycle, or change of settings to restore operation. Has anyone else notice this?
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
I've just installed this code on an emonpi as per update instructions on first post. No RF nodes at the moment so not really helpful for the requested test but I just wanted to say that this code seems to be more accurate and generates smoother graphs. Attached is a screenshot of the before and after code deployment at 09:13.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Great, good to hear.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Quick question...
Does this code auto detect temp sensors connected to the RJ45?
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Yes, it should. Please let us know if it does not
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
The temperature sensor is detected but readings jump from actual temperature to 25.5ºC every once in awhile. I tested with the discrete sampling code and that does no happen.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Following a previous post here, further investigations revealed major flaws in the initial version of emonLibCM, leading to inaccurate results in at least two areas: reporting the value of current and accumulating the energy measured. This should be borne in mind when calibrating and testing. I think the voltage and real power readings are credible, current and energy readings - any anything derived from either - are not. I think these problems will not directly affect the temperature measurements, but a further timing problem might well be the cause.
And for anyone waiting for the three-phase sketch, I'm afraid work has stopped pending resolution of this.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Is anyone running the continuous sampling code on emonPi?
See the top post for update instructions and latest version info.
I have noticed an issue with received data from other RF nodes not working after about 24hrs. Requires a reset, power cycle, or change of settings to restore operation. Has anyone else notice this?
Glynn, this is the behaviour I was seeing when I had a Jessie image created from the December instructions on my Rpi with a continuous sampling sketch on my emontx. The Rpi ceased receiving rf nodes after 24hrs and only a reboot would start it receiving again. When I rebuilt the Rpi using Minibian from January instructions this locking out of RF nodes ceased and everything has ran fine since.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
@Robert wall
is the inaccuracy fault still present?
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
The library is still a work in progress. I've no intention of releasing an update until I am sure it works correctly and accurately. I'm not aware of anything that's happening to the emonPi version, but Trystan & Glyn know that I'm working on this, so it's unlikely that they will duplicate the effort.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Thanks for the clarification, do you have a rough eta for the new version?
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
I don't have. I'm trying to get it done as quickly as I can, but I won't be making any promises.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
All good, no point in releasing it before it's sorted.
my system needs recalibrating as there is a discrepancy between the meter and EMONCMS. So I'll insert a calibration value and wait until the continuous firmware is perfected before I do it properly
cheers
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
If it's the kWh accumulator, I found an integer multiplication where a floating point was needed - that's what was making the accumulated energy wrong. Here's my note:
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
@RobertWall I'm currently on the discrete firmware and my plan is to move to continuous sampling when its ready and recalibrate everything when I do. I use EMONCMS itself to calculate accumulating energy. My biggest problem is with PV Exported which EMONCMS reports to be around double what it is in reality which I think is caused by my phase angle power diverters causing an incorrect value at low export readings on the grid CT, and higher readings on the water heater receiving the divert. I'm hoping the continuous firmware will be more accurate for my setup
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Kevin - a continuous monitoring sketch will indeed be far more accurate but it may not resolve the discrepancy you are seeing in accumulated import and/or export numbers, when using a diverter the principle of oscillating in the "sweet zone" means you are switching between export and import and the greater the accuracy of your monitor the more likely you are to record a fair chunk of diverted energy in both the imported and exported totals despite having done neither.
e.g. 1hour of 50% phase angle diverting a 3kW will probably rack up both 3kW of export and 3kW of import
I regularly see this happen. I have a set up that simply doesn't export except on the hottest summer days. This is confirmed by the grid CT power flow and the permanently lit led on the meter, and yet my accumulated export continues to grow, I have also confirmed my import is over by the same amount and the numbers are that accurate that I can get a pretty accurate "meter reading" from emonCMS by subtracting my phantom export from my import. This all goes out the window during the summer as I produce too much to use and as soon as actual export occurs there is no way to differentiate real from phantom export.
The phantom export is a direct indication of how well the oscillating part of the diverter is functioning so as annoying as the discrepancy is, the greater it is the better. This has been brought up before and some code in the firmware to ignore import/export whilst in the "sweet zone" is needed.
(I'm currently using "MartinR's PLL" based firmware not CS)
Paul
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Paul,
thanks for the reply, I too am setup to avoid exporting. I'm not seeing the same discrepancy as you, in fact right now I'm showing 26 watts of import, 2147 watts of solar, 896 into the spa pool and 67 into the HWC. Usually the grid according to EMONCMS sits somewhere between -120 & +120Watts, but in reality the export according to the meter is about half what it shows and the import is higher.
Take a look at the attached - is this as good as it'll get?
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Been running this code for 4 days. All OK except temperature sensor readings jump from actual temperature to 25.5ºC every once in awhile. I tested with the discrete sampling code and that does no happen.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Is there any value in me trying the emonTX beta firmware and sketch at this point - all my CTs are on one emonTX and not the Pi - or has there been enough feedback and it's easier to wait for another release?
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
See my answer to Sheppy above. I'm still working on it.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Just for interest, I recently bought the emonTXShield for my Arduino Uno, and I have it now running a slightly tweaked version of the current emonPi Continuous Sampling firmware, and connected via UART serial to an adjacent Raspberry Pi 2 running the Feb2016 SD image. The tweaks to firmware.ino were just amending the calibration factors for a 5Vcc Arduino Uno, as opposed to the 3.3V emonPi, and dealing with the lack of LCD and RF hardware on the shield.
I had some bother with the CS firmware steadfastly not reporting any data even though the startup phase showed credible Vrms, and CT1 detected, etc, and after putting in some diagnostic lines in it to display a couple of variables, it seemed clear that while credible voltages actually were seen, no current was apparent, so no power, and even with the perceived voltages, the structured data output never reported any of it, all I ever got was an unremitting stream of zeros after the OK and 5, terminated with (-0).
So I set about testing various other serial inos all of which reported credible volts and amps, but the CS versions would report nothing. I was beginning to suspect that some hardware difference was getting in the way, but could not see why.
By the fourth day I (yesterday) tried the EmonTXV34CM.ino, and it worked perfectly, reporting CT1 power,and Vrms even via the structured output! And when I returned to my tweaked emonpi firmware.ino that also worked perfectly, even though nothing had changed in it since the last time it had been run without result. I know that the EmonTXV34CM.ino was an early version, but it worked right away. I suspect it did something to the ADC or Interrupt which the firmware version hadn't, but was retained in the Arduino when I resent the firmware.ino, allowing it to run correctly.
I would love to know what that could have been!
I am running the emoncms app on a cheap Android tablet, and the reported power matches pretty well with a commercial energy monitor unit I bought from Maplin, usually within a Watt or two. The Maplin unit claims accuracy of +/- 1.5%, and updates its display every second, while emoncms updates much more slowly so comparisons are going to be inexact for a varying power usage anyway.
I am delighted with the result and will be migrating the kit from the test bed onto the house feed in the next day or so.
Mike
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Apologies, it was the emonTxV3_continuous.ino that worked the miracle, not the EmonTXV34CM.ino. The emonTxV3_continuous.ino did not use the EmonLibCM, and applied its own ADC configs.
Mike
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Hmmm... I think something else worked the miracle, the ADC settings for the emonTxV3_continuous.ino are identical to the settings in EmonLibCM. A mystery.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
As I have repeatedly written, there are serious problems with the emonLibCM library. I am working on it. Unless you are really, really desperate, there is no point in duplicating what I am doing.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Hi, Robert, I was not attempting to step on anyone's toes, and no, I am not at all desperate, I was merely mentioning that I had got something working, because it was something I was interested in doing.
I haven't the slightest intention of duplicating your work because my level of understanding in these matters is pretty shallow, and I fully expect to use any future release you come up with that I can make work with my TxShield, and I shall do so with real gratitude for your sterling efforts, and for that of any others who can and do make significant contributions for this or indeed any other aspects of this project.
I do not consider myself to be one of them, so rest easy. If you feel that I was adding to the pressure on you then let me apologise for that, it was certainly not my intention to do that.
Mike
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
I am currently looking for an option not measure the power consumption without blocking other functionalities built in the Atmega328.
Therefore a continuous sampling is mandatory.
I am a little bit confused that the above descried library is not working correct. Based on that I was looking for alternatives. I found the following library:
https://github.com/chaveiro/EmonLibPro
Does anybody know this Lib or already tried it? Maybe it could also help you finding the issue?
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
I made emonlibpro and use it on a few instalations for some years now. Other people use it also.
Its precise and let you run other code on the atmel. I have an Ethernet shield uploading data directly to emoncms.
Give it a try you wont regret it.
Re: Continuous Sampling EmonPi and EmonTx v3.4 examples
Is the continuous sampling 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.
BR