Archived Forum

A couple of months ago, chaveiro posted some new interrupt based code developed from the Solar Controller code (PV Router) by MartinR and others (please correct me if I have the authorship on these wrong). This code (and the original code it was based from) used interrupts to drive sampling routines that continuously sampled the various inputs integrating the power, and reporting out the summed power at user defined intervals (usually the standard 5 seconds). This is fairly different than the standard sketch that only measures 20 mains cycles every 5 seconds, assuming that represents the average power for that interval.

The original code included two sample implementations of the subroutines, one for running on the Emon shield and one that simply reported values out to the serial port. Neither were setup to transmit using the RF module on the EmonTx. With chaveiro's assistance I was able to get this code to run on the EmonTx, and later to transmit by joining the measurement routines of the EmonLibPro library with the bare minimum RF transmit routines written into the PV Router code. From that I wanted to share what I learned in the hopes of giving feedback to the original EmonLibPro author (as requested in the original post) and also as a guide to others who may want to test it out. My code is attached at the bottom.

Running EmonLibPro on EmonTx without RF transmit

The first step was to use the example code that simply output to the serial port. I had to modify the ADC pin order in that code to match the different pinout of the EmonTx versus the shield. I also had to adjust the sampling rate down for the 3 CT setup and 60 Hz frequency, reducing it from the default 2000 samples/sec to 1500 samples/sec.

const byte adc_pin_order[] = {2, 3, 0, 1, 4, 5};

#define SAMPLESPSEC   1500

In running that with only the AC transformer connected (no CTs since they are located in my power panel in the basement...) I was having issues with the code indicating timer overruns (shown by outputting a $ on the serial port) and then within 5 seconds or so, it would lock up. I tried reducing the sampling rate and other parameters without success. The lockups may have been caused by some memory overruns created when the loop does not properly lock onto the frequency, and starts measuring longer and longer intervals. Ultimately it appears to be related to an overcorrection of the PLL part of the algorithm. By taking the timer adjustment code in the .cpp file and using a fraction of the timer adjustment (0.75 or so), the code would lock on the 60 Hz AC voltage signal fine and read the measured current (nothing) as a very accurate 0.00 W. You could tell when the loop was well locked as the reported frequency was dead on at 60 .00 Hz, the measured power was 0.00W (instead of 0.04W or something similar), and the reported power factor was unity instead of 0.5 or lower. Again, this was all with no CT attached. When it was not locked, the reported power (which should be zero) would read +- 0.1W (still very accurate). When locked it was always 0.00W and 1.00 PF.

Adding the RF Transmit Code

Trying to integrate the EmonLibPro measurement routines with the standard sketch RF data transmit routines did not work. The code locked up and was unstable. Once I reviewed the PV Router code and saw the more minimalist RF code I attempted that and it worked better. You can see that the PLL algorithm becomes unlocked once you start adding in the RF transmissions. I noticed this while watching the output of the serial port. Using a delay of about 30+ seconds from the time it starts measuring to the first RF transmission, you can see the PLL locking well (>80% of the data reported) before it starts transmitting, and then it shows almost exclusively unlocked once transmissions begin. Even with the PLL not fully locked, the data reported is very stable.

The code is sensitive to the SAMPLEPSEC value, as changing that value made it improperly lock onto other frequencies and stay there. For example, trying 1920 samples/sec resulted in the loop locking onto a frequency of approximately 72 Hz instead of 60 Hz. I was able to get it to settle properly at a sampling frequency of 1620 Hz and that is what I am running at now.

Code Stability

When the code first starts up, it typically reports a frequency of 62.5 Hz on the first output, and then locks onto the proper 60 Hz frequency. Benchmarking the code over several days I could see the frequency occasionally jumping to 62.5 Hz and then back to 60 Hz. i was unsure if the PLL was really unstable, or the system had locked up and the watchdog timer I had brought over from the other code was rebooting it and I was seeing the first erroneous data measurement. In the most recent version of the code (posted here) I have added a routine that checks if a RF transmission is the first one and if so, sets the frequency to zero, to show up differently on Emoncms compared to just the PLL becoming unlocked for a few seconds. In the 24 hr since I have added that change I have not seen any reboots.

Code comparison

As I have mentioned elsewhere, I am working on a benchmark of this code, the PV router code, and the standard sketch to post here. I was mostly interested in which was the best for my own personal accuracy, but I figured the data would be useful to others as well. I need to crunch the numbers a bit more but I hope to be able to post that in the next week or two.

Thanks to all whose code I have been able to learn from and utilize. Let me know if you have any questions or corrections.

Dan