Archived Forum

To divert surplus PV energy for heating water using a triac, you will need some suitable code to be running a processor platform.  This site offers two versions which use different measurement techniques, but they both  have a similar mechanism for diverting surplus energy.  Burst-mode is the usual method of control, but phase-angle control (as for a light dimmer) can also be used.  My Summary Page includes two sketches of the phase-angle type, the details of the original one being:

Mk2_PV_phaseAngle.  A phase-angle controlled variant.  This requires a trigger which acts immediately rather than a zero-crossing one.    Originally posted, with full supporting information, on 01/11/12 at http://openenergymonitor.org/emon/node/841#comment-6990, this code is available at
http://openenergymonitor.org/emon/sites/default/files/Mk2_PV_phaseAngle.ino_.zip

This sketch uses analogRead() to obtain samples of the voltage and current signals.  That mechanism uses all of the available processor time so would not be suitable when other tasks need to be done as well.  More recently, the same phase-angle control algorithm has been incorporated into a sketch in which the sampling is done by smarter means which frees-up the processor to do other activities.  Details for this one are:

Using an Emontx V3.4 as a MK2 PV Router with phase angle control This describes using the emonTx V3.4 rather than an Arduino to supply the processing power. Posted, on 09/07/2015, at http://openenergymonitor.org/emon/node/10865

I have only run this code on the Atmega 328.  But with the appropriate input sensors in place, I see no reason why it should not provide similar performance when running on any other platform, such as the emonPi.

Hi.

I believe that all the processing is need is already done by the EmonPi.

I only need some kind TSR routine that controls the triac phaseAngle, and then based on the Power readings of the emonPI I regulate the power that the triac lets pass by altering some variable used by the TSR.

TSR as in Terminate and Stay Resident, or interrupt (like I used in Z80 assembly programing).

I think this should be viable.

Creers.

The ATMega 328P inside the emonPi does very little extra when compared to the 'standard' emonTx, so I don't see a reason not to use (a) the 'continuous' sketch to get around your problem with accurately reading the burst-mode power (and that problem is of course not just confined to the emonPi) or (b) to run one of Robin's phase-angle sketches more or less unchanged. That will do all the power control inside the 328P, nothing will be done inside the Raspberry Pi.

What might well be an expensive problem is the harmonic filters that you are likely to need to reduce the harmonic currents that you inject into your supply to an acceptable level.

Hi.

You lost me on that last paragraph. My electricity knowledge is not going so far.

When you refer to "your supply" do you mean the utility grid?

Isn't the burst mode worse to cause fluctuations in the voltage?

My PV is 500W so the power I will supply to the heater will be always less than that and when on grid (during the night) it will be full power. The main objective is to heat the water at night (at the low tariff) and dump the excess power during the to keep it warm during the day.

Maybe this is to much hassle to be viable...

When you chop up the current wave, you generate harmonics of the 50 Hz supply frequency in the public electricity supply. There are limits which you should stay below (a) in order to remain a good citizen and (b) you probably need to satisfy local regulations. [(a) is because harmonics on the supply can cause various problems with equipment.] A harmonic filter will attenuate those harmonic currents.

Voltage dip is slightly different because the amount of dip depends both on the fault level of the supply (i.e. its impedance) and your load. If you have a supply with a high fault level (low impedance) then voltage dip with a 500 W load will be less of a problem.

You should check the regulations that apply where you are to see what you need to do.

Hi.

I don't think that kind of information (regulations that apply) is available to the general public...

I also thought of rectifying the AC and use a FET, or somehow use two FETs, one for the negative part and one for the positive part (don't even know if it could be done) and control them with an analog port... but it would also be very farfetched,,,

Cheers.

I am almost certain that the regulations applicable to you will be available - but they might take some effort to find.

"rectifying the AC" ... "use two FETs"
The rectifying idea is old - very old. The first thyristors were so expensive that any trick to use fewer was a good idea, so to control a.c, a diode bridge was put in series with the load, and the thyristors - there had to be two in series because their voltage rating was not enough to cope with the full mains voltage - controlled the rectified current 'output' of the bridge.

I believe the 'two fets' idea is basically a Class D amplifier, and it's used in the Immersun Trusine controller.

Hi.

I've made a quick search, and have using one FET IXFH20N100P with one bridge rectifier Kbpc2010, I would be able able to do the job, my next problem would be how to connect this all to the ATMega/EmonPI isolating things at the same time.

Is there anyone out there that has the knowledge to answer this question I made:

I've noticed that there is pin in the RJ45 port of the emonPi that is identified with ADC6/D20: could I use this for the Triac connection?

With this present circuit I have in mind I would need to output an analog signal through this port to drive the FET, not the Triac.

What is puzzling me is why there aren't more information about doing this kind of control with a FET when it seems much more efficient compared with the triac. Even at ATMEGA programing I think we can set the level of the output port and changing it as needed instead of needing to modulate the sine wave at least 100 times per second (50 to turn on + 50 to turn off).

PS: I'm glad that I boarded this project, I've learned quite a few things since I started, at least in the electricity area (in the programming area only the info about the IDE itself, the programing is old news)...

Cheers.

"...when it seems much more efficient compared with the triac"

From what you've written, I get the impression that you are intending to drive the FET with an analogue signal, as in a "Class A" audio amplifier. Have you calculated the power dissipation that you will have? And how are you going to get that heat away - and where to?

I wouldn't call dissipating 125 W into the air, and 125 W into the water, "efficient", which is what will happen in the worst case.

Hi.

You lost me there with "125 W into the air, and 125 W into the water".

I think that I'm going over my head with this...

I'm calling this off for today, I was checking about PWM for driving the FET, but this is too much information.

Still about the triacs: I've seen on ebay dimmers for 5000W that are so small and cheap that I can't believe would comply with the regulations of harmonic currents... If that regulations where met I would buy one and change it in order to use it for my purpose...

Cheers.

"You lost me there with "125 W into the air, and 125 W into the water"."

Oh dear. That is very basic theory indeed. I'm a little worried for you.

Without wishing to hurt your feelings, I think you are in danger of causing some damage or hurting yourself, or someone close to you, if you continue when you do not understand what you are doing. Please do remember that electricity can start fires and can kill, and we wouldn't want you involved with either of those things.

You are going in the right direction when you say PWM and the FET, but I've been in electrical engineering for nearly 50 years, and I'd hesitate to take that on, because I KNOW what could go wrong.

Hi.

You are probably right, my area is computers and electronics, mainly in low power and low voltage.

I know that I would be required to have a good heat dissipation for the FET (and for the triac also), but do you think that the FET would take almost 10% of the power? (the heater would be in the range of 1500 to 2500 W)

I'm not yet to give up, but I don't want to spend much money on this also and don't want to build something that isn't efficient enough, unsafe, or out of law...

Do you have anything to say about this one (search for 261846884159 on Ebay or others found there)?

I've seen plenty of this, some without enclosure but I'm not certain that it is the right way to go, at least I wouldn't have to gather hardware parts that is hard to find, like coils that most of the time have to be hand made to the spec.

Edit:
What would be the electronic devices you refer for the harmonics filters?
Why do you seem to imply they are expensive?

Cheers.

"261846884159"
It is impossible to be able to say anything about this, as there is no real information about it.

"the heater would be in the range of 1500 to 2500 W"
That makes the problems even bigger - you wrote earlier "500 W".

As your speciality is computers, it is time to construct a spreadsheet and try the numbers. Imagine you have two resistors connected in series across your mains supply. One is the water heater, the other represents your FET, which you're using as a variable resistor. First, calculate the resistance of the heater from the power and the voltage. Now set up a spreadsheet. The resistance of the heater is the first column and it won't change. The second column is the second resistor, start with the value of zero, and increase its value in steps (they don't need to be equal, they can increase exponentially), starting at about 10% of the resistance of your heater until it is about 10 × the value of the heater. In the next column, calculate the voltage at the junction of the two resistors, in the next column the current in the resistors, and then three columns with the power in each resistor and the total power. Then plot the graphs of power by rows.

That will show you the power that you will get in your heater as you turn the FET on and off, and the power that the FET needs to lose to the air.

The heat dissipation of the triac, or the FET when it is acting as a pulse width modulated switch, is far less because it is a totally different calculation. In this case the active device has a constant voltage across it of only a couple of volts when it's on, and zero current so zero power when it's off, so the power dissipated is a lot less. (And before somebody points it out, there is some power dissipated as it transitions between the two states.)

I think your best route by far is to purchase a ready-built module. Calypso_rae can help you.

Hi.

Thanks for the explanation.

The max variable power I would be powering the heater is 500W that is the max available PV power at any time, but the max power the heater can consume is more than that but it would never be regulated between 500W and the max. Basically during most of the night it would be always at the max and let its thermostat do the job.

About the power dissipated by the FET I would expect it to have a very very low resistance, a fraction of the heater. I've made low power tests with FET and transistors to dim DC lights and the power drawn seems to be consistent with what the lamp draws considering the emitted light. You seem to imply that the FET will draw as much power as the heater a situation that I know would happen if the a variable resistor was used... but a FET is not a variable resistor, at least that's what I thought.

About buying a ready-built module, it is possible, but I also want to learn things and I would like to take advantage of the material I already have and at the same time prevent this part of the project to interfere with the readings: I'm convinced that the ready-build (at least the burst model) will interfere with the emonPI readings and possibly be "detected" by the utility meter and consume power from grid even when delivering it from the PV.

UpDate:

I've read much more information about this and it seems that the same triac configuration is used for Burst and  Phase Control, and that triac configuration doesn't seem to have any prevention for the generated current harmonics when using the Phase Control mode.

My first step is to find the right circuit to control an up-to 4000W resistive load that keeps the current harmonics within the acceptable limits. I willing to buy this part of the project from Robin at a reasonable price, how should I contact him?

My Second step is find the right way to find a port on my EmonPi board to drive the triac. Maybe the pin 8 on RJ45 port does the job, I still don't know, but from what I understood about the Arduino/ATMega design that pin couldn't be used for PWM output.

My third step is to pinpoint an existing software for the arduino that is close enough to what I need, understand and adapt it to work with my existing EmonPi software.

Cheers.

CiDiRome: I've read much more information about this and it seems that the same triac configuration is used for Burst and  Phase Control, and that triac configuration doesn't seem to have any prevention for the generated current harmonics when using the Phase Control mode.

Correct.  For the phase-angle controlled version, the user is reminded of the need to provide appropriate protection against EMI effects.  Commercial filters are available for this purpose.

My Second step is find the right way to find a port on my EmonPi board to drive the triac. Maybe the pin 8 on RJ45 port does the job, I still don't know, but from what I understood about the Arduino/ATMega design that pin couldn't be used for PWM output.

Any IO port (analog or digital) can be used to drive a triac via its associated trigger circuit.  An un-synchronised PWM signal would not be suitable for this purpose.

Robin (calypso_rae) can be contacted via a Private Message on this forum or by email via the Shop page on his website.  However, a public discussion may be of more benefit to you as useful input can be gained from multiple sources.

Hi.

So I was right...

"Commercial filters are available for this purpose". Is this a so hard to build device that one can't build it from parts that we can buy online and integrate it in the triac system?

Isn't it built of a few capacitors of specific rates and/or probably some coils?

I admit that the coils can be the real problem to buy, but those we can probably make our own from scrap parts like computer power supplies that I have plenty...

What is the term I should search for on google about building my own filter?

PS: Robin is you... ok, Can you give me an indicative price for the device I need (triac system + filter)?

Cheers.

This is one commercial filter for use with SSR or triac-based switching systems:

http://uk.farnell.com/crydom/1f25/filter-ssr-1-phase/dp/1200270?MER=en-mer-0713-pd-r2-acce

"Is this a so hard ..."

Yes, I'm afraid it is. It is a very specialised area, which is why I suggest buying one that has a guaranteed performance.

Hi.

Thank you for pointing in the right direction, the price is acceptable but there is a bug with that device:
By itself, It can consume almost 10W (stated as max), and by the way it shows how to use it in the diagram seems that it can be permanent as the datasheet is very vague about almost everything.

In order to use a device like this, if on test I conclude that it really consumes that kind of energy, I would have to add another triac or relay behind it to prevent it from consuming while the load if offline.

Has any of you tested one of this devices?

Cheers.

Where does it say that the device consumes 10 W?

I cannot see that anywhere. It does say "Current Drain at VRMS max: 40 mA" but that does not necessarily mean 10 W. What temperature will a box of that size reach if it has to dissipate 10 W? 10 VA I will believe, but the power will be nowhere near 10 W, probably less than 1 W, and that will only be because there will be a high value parallel resistor to safely discharge the capacitor when the supply is turned off.

OK.

So that 40mA cannot be considered for real power but apparent power. I confess I forgot about that, my bad.

That information should be present in the datasheet in the datasheet anyway...

I will soon start with my second and third steps, that won't require expenses, and when I believe I'm in the right track I will buy the parts.

Cheers,

Hi.

Advancing in my project, I've found contradictory information about emonPI.

On EmonPi Wiki about RJ45 Pin 8 is stated "RJ45 pin 8 – ADC6 / Dig20", checking the diagram I can see that it is connect to pin 19 of Atmega328 that is ADC6, but I can't see any reference to D20 in the datasheet, that I assume would be an alternative configuration to ADC6 on pin 19...

ADC7:6 (TQFP and QFN/MLF Package Only) In the TQFP and QFN/MLF package, ADC7:6 serve as analog inputs to the A/D converter. These pins are powered from the analog supply and serve as 10-bit ADC channels.

What is this Dig 20/D20 that appears on the wiki and schematics?

Also, it appears as D19 in the firmware comment...

//const byte emonPi_RJ45_8_IO=           A6;           // RJ45 pin 8 - Analog 6 (D19) - Aux I/O

It seems that it would be simple to connect another CT sensor to this port (there ir a thread about it), but I believe that for my project on driving the triac I will need a port that can be configured as output digital or analog.

I also have questions about the emonPi firmware, but I will post them in the right forum area since that is classified as software.

Cheers.

The emonPi has an Atmel 328P processor which is the same as is used on the emonTx V2.  This Design Reference page for the emonTx V2 is very useful as it lists all on the pins/ports along with their function:

http://openenergymonitor.org/emon/emontx/reference

The Atmel 328P has 20 IO ports in total: 14 digital and 6 analog.  The naming convention in the above Design Reference shows the digital ports as 0-13; the analog ports are numbered 0-5 but they can also be used in a digital manner as 14-19.

If the numbering convention were to start at 1 rather than 0, then A5 / D19 would become A6 / D20.  I suspect that the emonPi documentation which you have found is using this alternative scheme.

.

Hi.

Thank you for you answer.

But I think something is mismatching somewhere.

While the Port C 0 to 5 (PC0-PC5) are described in the datasheet as:

Port C (PC5:0) Port C is a 7-bit bi-directional I/O port with internal pull-up resistors (selected for each bit). The PC5...0 output buffers have symmetrical drive characteristics with both high sink and source capability. As inputs, Port C pins that are externally pulled low will source current if the pull-up resistors are activated. The Port C pins are tristated when a reset condition becomes active, even if the clock is not running.

The Port ADC6/7 (where the RJ 45 pin 8 is connected to) are described as:

ADC7:6 (TQFP and QFN/MLF Package Only) In the TQFP and QFN/MLF package, ADC7:6 serve as analog inputs to the A/D converter. These pins are powered from the analog supply and serve as 10-bit ADC channels.

These two ports (ADC6/7) are not in the list of ports described on that link. If fact I know why: the chip package used in EmonTX v2 (28 PDIP) don't have that ports.

So is the Digital port 20 a bug?

I think my option is to use the ports that are assigned to the LCD witch I don't have/use.

Cheers.

Update:

After further analyzing the EmonPi diagram, it seems it was not so obvious to use the LCD communication ports because they seem also to be used to communicate with the Rasp.

Faced with this situation I opted to use the Pulse count sensor pin that I also don't use and already passed the first step of having a flashing led controlled has I want inside the the firmware.

I've started to read emonTxV3_4_as_Mk2Router.ino code and I can say that it is a bit complex and I don't fully understand most of it.

I was hoping to find some function I would be able to call to change the % of power that the triac is letting pass and it would modulate the was as needed, e.g. change_triac_power(n) where n would vary between 0 and 65535 and (0=off to 65535 full on), but the code is more complex than that.

My next step will be to try understanding the code better or try to write my one code...

Edit: for tests, I have, from old projects, MOC3011 and BT139. I've seem that MOC3041 has a slightly different functionally, can it be a problem on my tests to use MOC3011 instead of MOC3041?

Cheers.

I've started to read emonTxV3_4_as_Mk2Router.ino code and I can say that it is a bit complex and I don't fully understand most of it.

That sketch performs a similar function to the original Mk2 Router code for which there is a detailed description at:  http://openenergymonitor.org/emon/mk2/versions

I was hoping to find some function I would be able to call to change the % of power that the triac is letting pass and it would modulate the was as needed, e.g. change_triac_power(n) where n would vary between 0 and 65535 and (0=off to 65535 full on), but the code is more complex than that.

Your supply meter measures energy, not power, and the Mk2 Router does likewise.  The operation of the Mk2 Router is reactive rather than predictive, hence "the % of power" is not a concept that is relevant within its terms of reference.  Over what timescale are you considering this "power" to exist? 

Before designing the Mk2 Router, I heated water using an alternative approach which was similar to your thinking,  That arrangement had a number of discrete steps to which the output stage could be pre-set.  It can be seen working here:

https://www.youtube.com/watch?v=-lk6Me3cwuw

The external controller is described at 1'20" - 1'50".  Although I am using it in a "whole-cycle" mode, this device can also operate with "phase-angle" control whereby the load is on for a pre-determined portion of each half cycle.

The output stage is a Carlo Gavazzi AC switch which was controlled by PWM from my Arduino.  I still have this device here with its original box and instructions.  It cost me £70, yours for £35 including postage.  Send me a PM if you're interested.

PS.  My 'Mk1' code is at http://openenergymonitor.org/emon/sites/default/files/Mk1_in_Garage_2.ino_.zip

Hi.

The device you purpose would only replace the triac system, the control system would still be needed to arranged.

About your code, it is more complex than I anticipated, and I can't go striping it off of parts I don't need, instead I have to understand it and gather the parts I need.

Don't forget my base start is the EmonPi with only two sensors, This two sensors are already in use (Grid + PV), My idea was to monitor de the Grid power and when it goes -4W or less increase the triac % for a relative value (calculated with base on the max load power) and the opposite when the power goes over 0W (or -1W).

I don't have a third CT, at least for now, so I'm not considering controlling the consumed energy of the load, rather I would log the theoretical power it is consuming based on the % of the triac for the sake of statistics.

I was thinking about doing the verification once a second.

I wasn't even considering the bucket system, my utility meter is very recent and I'm afraid that it has a very small energy packet that can screw that kind of functionality, anyway I will also see the model and search about it.

Best Regards.

"The device you purpose would only replace the triac system, the control system would still be needed to arranged."
That's correct.

"Don't forget my base start is the EmonPi with only two sensors"
You only need one CT, on the grid connection, for Robin's control system to work, because it only needs to know the nett energy flow at the grid connection. Everything else is information for you.

"I don't have a third CT, at least for now, so I'm not considering controlling the consumed energy of the load, rather I would log the theoretical power it is consuming based on the % of the triac for the sake of statistics."
If you have a thermostat on your heater that overrides the triac, your calculation will be wrong when the thermostat opens. You can avoid this by fitting a temperature sensor to your water tank and using the temperature to override the control when the water reaches maximum temperature. Then set the thermostat to 5° higher to act as a safety cut-out.

"I was thinking about doing the verification once a second."
That is probably far too slow. Robin's program calculates every 20 ms. You will have an average of ½ s overshoot or undershoot in addition to the time it takes to alter the firing angle of your triac every time something switches on or off.

"I wasn't even considering the bucket system, my utility meter is very recent and I'm afraid that it has a very small energy packet that can screw that kind of functionality, anyway I will also see the model and search about it."
You are confusing two different ideas here. The 'burst fire' mode is like a bucket with a big hole in the bottom with a plug in it - the plug can be either in the hole (and the bucket fills quickly) or out of the hole (and the bucket empties quickly). The 'proportional' mode is like a bucket with a tap on it. If the level in the bucket starts to go up, you open the tap a little, and if it continues to go up, you open it a bit more. If the level in the bucket starts to go down, you close the tap a little, and if it continues to go down, you close it a bit more. When the level stays the same, you leave the tap where it is. So the bucket idea will work for you, it's how you empty the bucket that is different.

Hi.

So, it is efficient.

I will do my best to understand their code and adapt it to use with my EmonPi.

About the 3rd CT sensor, I'm thinking about ordering one and hook it to the RJ45 Pin8 ADC6.
About this subject: EmonTX has high sensitivity sensor input, what is different: the circuitry, the sensor or booth? Would I be able to make this new EmonPi Sensor a high sensitivity one?

Cheers.

It is only the value of the burden resistor that changes. You can remove the SMT component (R17, R28) and solder in a wire-ended one - holes are provided (R22, R26).

The CT is a current source, the secondary current is determined by the primary current and the current ratio (100 A : 50 mA for the shop one), therefore you choose the burden resistor to give you ~ 1.1 V rms at the maximum current that you will have in your load - 12 A will give you some in hand (if your voltage is 230 V). So I make that 180 Ω to the nearest E12 value below.

Is the result very different compared to what I did?
I'm referring to passing the live wire 3 times thought the CT for the incoming grid wire and 10 Times for the PV system (and then divide the value in the firmware for the according turns).

From what I've seen, changing the values of the burden resistor also causes the max Amperes to drop, with what I did the same happens, which one is better?

Cheers?

You did not say that you wanted to use a multi-turn primary winding. That is the better way because the errors due to transformer magnetization losses are proportionately smaller.

Thank you.

That is what I thought, so when possible I will use this method for better accuracy. If I add a 3rd CT, I'm thinking about use the same circuitry (only external) and get the 3.3V from the board (since they aren't available in the RJ45 port). My reason to do this instead of building the external circuitry according the 5V power source was to keep all CTs with the same schema thus as much similar as possible.

If it was you, would you get the 3.3V to keep the same schema or change the schema to work with 5V?

PS: in answer to: "If you have a thermostat on your heater that overrides the triac, your calculation will be wrong when the thermostat opens", I think a little check would be enough, if the % of power given to the load is greater than the power being produced than the logged power for the load would be zero...

Cheers.

Regarding the bias supply for the outboard input, I would use 5 V and keep all the same components except for the resistor in the R27 position, which needs to be adjusted so that the voltage at the junction with (C4) and (R25) is 1.65 V, which gives a value of 954 kΩ. That, very inconveniently, is almost exactly mid-way between two E24 preferred values. Using 910 kΩ, the voltage is fractionally closer, but 1 MΩ is only fractionally worse and probably easier to obtain. You will lose about 1.5% of the range, which is nothing to worry about. Or you could use 910 kΩ + 43 kΩ in series. If you can get a 953 kΩ resistor, that would be ideal, but values in the E48 series can be hard to find and costly.

Hi.

I didn't know about the E* system. One more thing I learned today.

What about 560k + 390k + 4k or 680k + 270k + 4k? it is a little sketchy, but this values we have in E12, but E12 has 10% and the end can have a big variation of almost 100k while E48 would have only 20k.

In your opinion, if one can calibrate the resistor while measuring it with the multi meter (try different values in series or use a 1M potentiometer) would be better or worse than sticking to a set like this 560k + 390k + 4k of standard resistors?

Cheers.

First, 1% tolerance resistors are common and inexpensive (e.g. http://spiratronics.com/0.6w-metal-film-resistor-390k-pack-of-10.html). Second, there is no point in trying to get closer than 1%, because that is the tolerance of the other resistor in the chain. So I'd use 2 E12 resistors in series and forget the difference from the ideal value. I would certainly not use a potentiometer.

CidiRome:  The device you purpose would only replace the triac system, the control system would still be needed to arranged.

A few days ago, I pointed you towards the software and hardware design for the phase-angle version of my Mk2 Router which appeared to do what you wanted.  Since then, I've provided some earlier software which appears to  match your needs more closely, and also offered you the crucial bit of hardware to go with it. 

I'm now wondering what else you are hoping for ...

Hi.

At this point, the hardware is not my concern, I already know what I will use, I'm now looking at the code and trying to adapt it to my needs.

Since I want to add that functionally to my existing emonPi and the mk2 code is very different from the emonPI.

I've understood almost all the EmonPI code, but the MK2 is far more complex, I'm trying to get my head around it a few hours a day after work.

Sorry if I seem not to know what I want... You have to understand that I'm new to this, I only have my emonPi for one month (today) and the PV system for less than two weeks.

Cheers.

I've understood almost all the EmonPI code, but the MK2 is far more complex, I'm trying to get my head around it a few hours a day after work.

OK.  Have you studied the description of this code at http://openenergymonitor.org/emon/mk2/versions ?

I was hoping to find some function I would be able to call to change the % of power that the triac is letting pass and it would modulate the was as needed, e.g. change_triac_power(n) where n would vary between 0 and 65535 and (0=off to 65535 full on), but the code is more complex than that.

In the "Mk1" code which I mentioned recently, all of the measurement side is taken care of by the standard OEM library routine, calcVI().  With a 256-step PWM output that is updated each second, this control structure seems  just as you have been asking for.  Extra hardware is however required to convert the slowly varying analogue output from the processor into a dynamic phase-angle signal for switching the load.

The phase-angle version of my "Mk2 Router for emonTx V3.4" sketch, as referenced in my initial reply, does a similar job but in a reactive rather than predictive manner.  If implemented within your emonPi code, no other hardware would be required to hook it to your MOC + TRIAC.

Hi.

Yes that's it.

Since I started I've learned some things and I can see that your expertise on the field is plenty and luckily I have you to orient me.

If you say that the Mk2 system is better I will try to adapt it to my usage, instead of Mk1.

About the Mk1 needing more hardware, that is another thing I would avoid and my idea of interrupts was to do the modulation for the triac in background and controlling it in the main/loop code... Never mind that is not my way now, and I think I would have lack of memory problems with it and the actual EmonPi firmware anyway...

Cheers.

Hi.

I've been converting your code to EmonPI. I'm not saying I would do better (probably not), but some variables names are a bit confusing... I think that, for example, I would always use the CT sensor naming as CT1..CTn and in the definition I would somehow (maybe some king of variable aliases) inform the software that CT1 is grid, CT2 is PC, CT3 is diverted, etc... This way with little changed in the code we would be able to use the CT as wanted and easely port the code to other devices like I'm doing.

Please don't take me wrong, I truly appreciate your work, this is a constructive critic.

Just to confirm "const byte powerForDallasSensor = 19;" in EmonPI the Dallas sensor is not powered this way, this is not necessary, isn't it?

How do I convert this calibration value:
float Vcal_EU=261.558345; //<Original Line was (230V x 13) / (9V x 1.2) = 276.9 ...

Into this:
const float voltageCal = 0.875; // <-- using a Fluke 77 multimeter for my own setup - RAE

Cheers.

When posting this code (Mk2 Router for emonTx V3), my primary objective was to achieve continuous monitoring on four channels, with diversion of surplus power, and RF.  Having restructured the code to move all the time-critical stuff inside the ISR, temperature measurements could then be included without disrupting the other aspects.  If the way that I've supplied power to the Dallas sensor is different than elsewhere, you or anyone else is welcome to change this detail.

Regarding the names for variables, more logical names often appear after the event.  If anyone wishes to post a version with alternative names, they are welcome to do so.  Personally, I prefer not to pre-allocate what each channel is likely to be used for.  You will appreciate that my efforts these days are mainly in support of my own business/website where software runs on hardware that is similar but not identical to the emonTx.  

voltageCal is my way of calibrating the voltage sensor.  My intention is that it is adjusted until the reported value is the same as is measured by any external piece of kit that can be trusted.  My preferred approach is to measure and adjust this value rather than the calculating what it should theoretically be.   

Hi.

"I prefer not to pre-allocate what each channel is likely to be used for"
Is this sentence correct or did I understood you wrong? You seem to pre-allocate what each channel is used for...

The value I have for Vcal for the present EmonPI is not theoretical, I archived it by calibration as explained for EmonPI, I changed unit I got readings very close to the ones I got with my multi meter (it is not a top quality one, but I believe is accurate enough. I also have a cheaper one and can tell the difference).
How do I measure voltageCal for your code?

Can you point me where should I divide the readings by the number of turns I use in each CT? I know that I can make that division before sending the data to EmonHUB, but the readings will be wrong for the phase angle and other calculations made before.

About the power to dallas sensor: I don't know about EmonTX, but in EmonPI it doens't seem to come from a port on ATMega.

One question about this: "* July 2015, upgraded for phase-angle control.". Was this a definitive change in code or there is flag to choose (I couldn't find it). I'm asking this because the ones who could be using your code with burst mode shell not change to phase angle if they not have the harmonics filters in place, am I wrong?

It seems that you haven't worked with EmonPI to help me enough to port the code to it and at this point I don't know if I'm up to the task. I think that I don't understand the MK system well enough to be able to port it by myself...

Anyway, I thank you for your efforts on helping me even where theres little chance of selling and I understand that you have your business and have to take care of if before anything else.

Cheers.

Hi.

Since my last message I've been making changes to the code and understood a little more of it.

There is one thing that is puzzling me:
I noticed that the constant voltageCal is only used when the values are returned and never when the calculations are made...

The fact (as I stated before) is that I don't understand your code completely, but, how do you make calculations to obtain power and energy if you seem not to be dealing with correct/accurate voltage? (I think that 87.5% to 100% is not a negligenciable error)

Most probably there is something I'm not seeing correctly, I don't know.

Cheers.

CidiRome: how do you make calculations to obtain power and energy if you seem not to be dealing with correct/accurate voltage?

Most of the code that I have posted uses integer maths for greater speed and efficiency.  Cal factors are only applied when absolutely necessary.  This approach is no different than working through an algebraic exercise in its pure form, and only substituting real-world values at the end.  If you are interesting in understanding the details, this process is thoroughly described in the code, e.g.

  // The next stage would normally be to apply a calibration factor so that real power
  // can be expressed in Watts.  That's fine for floating point maths, but it's not such
  // a good idea when integer maths is being used.  To keep the numbers large, and also
  // to save time, calibration of power is omitted at this stage.  Real Power (stored as
  // a 'long') is therefore (1/powerCal) times larger than the actual power in Watts.
  //
  long realPower_for_energyBucket  = sumP_forEnergyBucket / sampleSetsDuringThisCycle;

Providing that your measurement system is linear and repeatable, the reported values for real energy and power should be OK.  Appropriately scaling the signal to be measured within the working range of the ADC is helpful to minimise the effects of quantisation distortion at small signal levels.  

Hi.

I've read that.

I've seen that the calibration value for the CT is applied to the bucket capacity

capacityOfEnergyBucket_long =
     (long)SWEETZONE_IN_JOULES * CYCLES_PER_SECOND * (1/powerCal_grid);

I understand that this will cause the bucket to work in some kind of internal measuring unit for the system...

But, it seems that there are calculations of power (watts) where the Vcal is not included...
If P=U*I, can we obtain correct values of P while U is not accurate?

And about

Can you point me where should I divide the readings by the number of turns I use in each CT? I know that I can make that division before sending the data to EmonHUB, but the readings will be wrong for the phase angle and other calculations made before.

Can you point to the best place where I should make the divisions?
I think it shell not be before outputting them, because that will mean all the prior calcullations will be wrong. at least the ones of grid  CT.

Cheers...

As far as I am aware, all calculations in my sketches are in good order.  I am primarily interested in monitoring Real Power/Energy for which any phase mismatch between the V and I waveforms has minimal effect.  The phaseCal algorithm may be useful for anyone who wishes to monitor Power Factor etc.

If you intend to have multiple turns around your CT(s), it would seem best to calibrate your system with this setup already in place.  Then no other changes to the code should be necessary.

OK, if you say so..

From what I understand of the code, it may do the job correctly on diverting the surplus energy because the units are not very important and are close enough to the reallity.

But this calculation

      instP = filtV_div4 * filtI_div4;  // 32-bits (now x4096, or 2^12)

Cannot return an accurate power value because one of its origin values is not correct: filtV_div, it is obtained and it the calibration is not applied to it.

I'm sorry if I'm annoying you (probably am), but I like to understand things i'm dealing with.

About:

If you intend to have multiple turns around your CT(s), it would seem best to calibrate your system with this setup already in place.  Then no other changes to the code should be necessary.

I don't understand this statement, if I don't make changes the code, I cannot have multiple turns in the CT because the reading will be wrong...

Cheers.

monitoring Real Power/Energy for which any phase mismatch between the V and I waveforms has minimal effect.

I think that depends a lot on the nature of the signal you're measuring.  It's certainly true for big beefy in-phase sinusoidal loads but less so for the misshaped loads you see if you're primarily measuring switch mode power supplies (or big reactive loads).

The phaseCal algorithm may be useful for anyone who wishes to monitor Power Factor etc.

Power Factor is just RealP/ApparentP so the only way phase error correction improves that is by improving the RealPower measurement.

"About:

I don't understand this statement, if I don't make changes the code, I cannot have multiple turns in the CT because the reading will be wrong..."

P = V × I

Whether that is an instantaneous value that is used for real power calculation, or V and I are rms average values, that statement is always true. (Always assuming you do not mix real and apparent power.) If either V or I or both are wrong by a constant value, you can always remove that constant and apply it, or the product of two constants if both are wrong, to P.

P = a.V × b.I

is exactly equivalent to

P = (a × b) × (V × I)

is exactly equivalent to

P = c × (V × I)

if c = a × b
- and then you can call it powerCal.

Multiple turns on your CT is equivalent to changing b, therefore if you change powerCal by the appropriate number, you will have the correct calibration.

Robin wrote "Then no other changes to the code should be necessary." - meaning that you change powerCal but nothing else.

Hi.

You are right.

I didn't notice the "power" in powercal and I was fixed on Ical =90.9 found on the EmonPi. Wrongly I was assuming that calibration value was only applying to I, not the P. That is sorted out.

So this means I will have to calibrate it all before any use because my AC-AC adapter is not any of the standard ones. If I use the standard powecal values I will get wrong values like I obtained with the original EmonPI firmware before calibrating its Vcal (Ical was accurate enough because the hardware was the same).

I have to make tests with the voltageCal to obtain accurate Voltage readings.

Then with a true resistive device obtain V and I values to calculate the power and calibrate powerCal, don't know exactly how.

The value that powerCal presently have (0.25), how should I calculate mine with what I have available to do it: resistive load and an accurate enough multi meter? (I also have the current EmonPi FW working, but I cannot use at the same time, yet I could make some changes on it to pickup values for calibration in this new mk firmware)

The ideal would be to have Ical and Vcal, so the firmware would calculate it's Pcal for it's own usage...

In the end (after calibration with single turns), will it be enough to divide powerCal by the number of turns on the CT to obtain correct values?

Cheers.

@CidiRome, you are critical of this line in my code because the parameters have not been calibrated

      instP = filtV_div4 * filtI_div4;  // 32-bits (now x4096, or 2^12)

Here is the equivalent part of the emonLib library where data samples are treated.  As you will see, much of "my own" code is very similar to this:

    // A) Read in raw voltage and current samples
    //-----------------------------------------------------------------------------
    sampleV = analogRead(inPinV);                 //Read in raw voltage signal
    sampleI = analogRead(inPinI);                 //Read in raw current signal

    //-----------------------------------------------------------------------------
    // B) Apply digital high pass filters to remove 2.5V DC offset (centered on 0V).
    //-----------------------------------------------------------------------------
    filteredV = 0.996*(lastFilteredV+sampleV-lastSampleV);
    filteredI = 0.996*(lastFilteredI+sampleI-lastSampleI);
   
    //-----------------------------------------------------------------------------
    // C) Root-mean-square method voltage
    //-----------------------------------------------------------------------------  
    sqV= filteredV * filteredV;                 //1) square voltage values
    sumV += sqV;                                //2) sum
    
    //-----------------------------------------------------------------------------
    // D) Root-mean-square method current
    //-----------------------------------------------------------------------------   
    sqI = filteredI * filteredI;                //1) square current values
    sumI += sqI;                                //2) sum
    
    //-----------------------------------------------------------------------------
    // E) Phase calibration
    //-----------------------------------------------------------------------------
    phaseShiftedV = lastFilteredV + PHASECAL * (filteredV - lastFilteredV);
    
    //-----------------------------------------------------------------------------
    // F) Instantaneous power calc
    //-----------------------------------------------------------------------------   
    instP = phaseShiftedV * filteredI;          //Instantaneous Power
    sumP +=instP;                               //Sum  

The main difference between "my own" code and that in emonLib is that the former has to run continuously, with no gaps.  V & I amples are taken at fixed intervals and all processing needs to be completed within the allocated time interval; otherwise, data will be lost.  In emonLib, everything is done sequentially using floating-point maths, and the process takes as long as it takes.  The emonLib approach was designed for battery-powered applications and is not intended to run continuously. 

Each technology is good for its intended purpose, but they do not combine well.  As you have found, their approach to calibration is very different.  Each of them has stood the test of time and is working reliably in countless applications for users.

Yes.

On my last post, with help from Robert, I already understood that I was being miss leaded with the powercal thinking it was only for I, but it is for P (I*V)... This removed any doubts about your code working correcly...

At this point I can understand most of your code and have already made most of the changes I need to use it in my EmonPI, I'm only (a little bit) stuck on how to calibrate it, specially the powercal value... I think the Vcal won't be a problem and I'll able to nail it easly.

Can you point me into the right direction about calibrating based on what I stated on my last post?

Cheers.

In response to a similar question, I have written a complete explanation of how powerCal is derived and calculated. If you search the forums carefully, you should find that.

Hi

Update:
Before thinking about calibrating I compiled my altered code using the default calibrations.
I thought I would get readings with differences of a few volts and watts, since the code was made for EmonTX and there is not huge difference to EmonPI, in fact the only difference I expected was that my AC-AC transformer to give a little higher reading compared with the default EmonPI (my vcal was 261.56 and the original EmonPi was 276.9)
Don't know why but I got reading on voltage between 9 and 11 Volts (changing the timesten to time100 as EmonCMS in PI is configured to use) and wattage reading of less than 20W when expected would be about 300W.

Tomorrow I will look more into this... That's enough for today.

PS: I didn't account the CT turns I have, but even so, the reading are too much off. I already started porting the code from the beginning again. this time I will be quick since I already understand it.

Hi.

Calipso_Rae:
I'm working on this code (don't know the exact file name but file starts with /* emonTxV3_4_as_Mk2Router.ino -> emonTxV3_4_as_Mk2Router_PAcontrol.ino) and it seems that there a few mixup situations about the values read from the ADC and where the values are stored.

As I understood in each case of the program reads the ADC value and immediately after sets the next to be read.

I noticed that a few comments seem to be off and there seems to be at least one situation that the value is not the correct one.

on case 2, the requested value for the next is CT1;
on case 3, the read value is used/stored on sumP_CT2

Am I wrong?

Cheers.

@CidiRome,  Some of my later "Mk2" sketches are a lot more complex than the original version.  In the one that you've mentioned, all of the time-critical background activities take place within the ISR rather than in the main code.  By this means, the main processor can be freed up for slower activities such as RF, temperature measurements and Serial. 

The ADC is in free-running mode, so the "next" conversion always starts automatically.  The ISR therefore has to setup the conditions for the one after that.  This somewhat convoluted mechanism is all explained in the comments. To really appreciate what's going on beneath the surface, you may have to think about it for a while and perhaps  draw a diagram or two.  I am not aware of any "mixup situations" in any code that I have posted.

Am I wrong?

Well, I think it is unhelpful of you to keep criticising my code without well-founded reason.  These sketches seem to be working OK for everyone else.  Anyway, I thought you had got everything sorted out except for calibration ...

Hi.

I think I've already understood how the processor and ISR work.

So, this code

      rawSample = ADC;                    // store the ADC value (this one is for Voltage)
      ADMUX = 0x40 + currentSensor_diverted;  // the conversion for current_grid (CT4) is already under way

reads the present sample into rawSample and sets the one that will be read next time we get a sample with rawSample = ADC
Please tell me if this statement is wrong...

I'm not criticizing anything at least not in a negative way like you seem to be implying, and when I'm wrong I'm the first to admit it.

I may not be an expert on electricity, I know I'm not, but in the field of programming that's another story, I do not consider myself an expert in this field also but I know my capacities on programming language are above average.

I may not be able to completely understand you code that relates to mathematical and electricity calculations, but generally I can detect mistakes.

Please tell me that this is not a mistake (not important an one, but a mistake):

      ADMUX = 0x40 + currentSensor_CT1;  // the conversion for current_CT2 is already under way

Unless I understood it wrong, you explain in the comment that CT2 is under the way but request CT1, isn't it?

I'm sorry that I'm trying to add value to you creation as I would like very much to use it and later share it with others...

At this point I'm very sad: I ported all the code again, chunk-by-chunk for emonPi compatibility with exact the same results as yesterday. I would like to have better news, but unfortunately I don't.

I only have one EmonPi that I want to keep down for the least time I can because it is monitoring my home energy.

Is there anyone out there with a spare emonPI and knowledge to test my code on it? If yes I can post it somewhere.

Cheers.

"Unless I understood it wrong,"

Yes, you did "understood it wrong". Earlier, you wrote "I think I've already understood how the processor and ISR work." Clearly, you don't. Please read the Atmel data sheet where working of the processor and the interaction between the operation of the ADC and the trigger, which in this case is the interrupt that it itself generates, is explained much more fully than is possible in a single line comment in a sketch. As Robin suggested, you need to draw some diagrams to understand how the four actions - pre-loading the multiplexer, generating the interrupt, switching the multiplexer and doing the conversion, and handling the interrupt - interact.

You claim your programming knowledge is above average, sadly I think your evaluation of average programming knowledge might be little different to that of others. One thing that you must remember is, if something (software, hardware, whatever it is) has been looked at and used by many people before you, and nobody has found fault, there is a good possibility that it really is OK - it might not be, of course, but such cases are rare.

You have indicated that you intend to publish your version of Robin's work. I have to warn you that unless the original source (Robin Emley - calypso_rae) is properly credited, the moderators will view your contribution as plagiarism and will act accordingly.

CidiRome, I'm not at all familiar with the sketch in question, but I can explain how the ADC works in free-running mode.  It's not that complicated and the technique has been around for a long time (and well and truly pre-dates the Arduino).

There are three conversions you need to be aware of:

1. conversion just completed
2. conversion currently being worked on
3. conversion you want it to do next

The result of #1 is available in the ADC register right up until #2 completes at which time it gets overwritten and they all shuffle along by one.  Conversion times depend on clock settings, but a typical time is about 110usecs 104 usecs.

If the ADC is truly running in free-running mode than the ISR is not involved in starting the next conversion.   When the current conversion completes, the ADC immediately starts on the next conversion.  Optionally, an IRQ is raised if so configured.

When setting up the MUX, you're actually telling it which input it should sample on the next conversion (#3 above).  There are some constraints on when you can write to the MUX but provided you stay away from the 110usecs 104 usecs boundaries it is very flexible.  Likewise, you need to take a little care at the beginning,  as your state machine can't assume a "conversion just completed" (#1 above) exists (unless you manually fired one off).

is explained much more fully than is possible in a single line comment in a sketch

Perhaps one of the improvements CidiRome can make to the code is to use multi-line comments for that bit.

Hi.

@dBC: thank you for your constructive explanation, it is really very helfpul.

In this case the code uses sets up MUX, so the next reading will be the one we setup in the present cycle.
The 110usecs time is how long the value stays available before being replaced with other, or how long it takes to be available? (the second option seems to long to be the correct answer)
Even when MUX is set, the ADC changes to the next sample after that time?

@dBC: can you please look to this chuck of programming and tell me that I'm seeing it wrong.
Please note that it is the original Code I didn't make any changes (This first part is only to see how the ISR was setup):

(...)

  // Set up the ADC to be free-running 
  ADCSRA  = (1<<ADPS0)+(1<<ADPS1)+(1<<ADPS2);  // Set the ADC's clock to system clock / 128
  ADCSRA |= (1 << ADEN);                 // Enable the ADC 
  
  ADCSRA |= (1<<ADATE);  // set the Auto Trigger Enable bit in the ADCSRA register.  Because 
                         // bits ADTS0-2 have not been set (i.e. they are all zero), the 
                         // ADC's trigger source is set to "free running mode".
                         
  ADCSRA |=(1<<ADIE);    // set the ADC interrupt enable bit. When this bit is written 
                         // to one and the I-bit in SREG is set, the 
                         // ADC Conversion Complete Interrupt is activated. 

  ADCSRA |= (1<<ADSC);   // start ADC manually first time 
  sei();                 // Enable Global Interrupts  

(...)

ISR(ADC_vect)  
/*
 * This Interrupt Service Routine looks after the acquisition and processing of
 * raw samples from the ADC sub-processor.  By means of various helper functions, all of 
 * the time-critical activities are processed within the ISR.  The main code is notified
 * by means of a flag to show when fresh copies of loggable data are available.
 */
{                                         
  static unsigned char sample_index = 0;
  static long sampleV_minusDC_long;
  int rawSample;
  long filtV_div4;
  long filtI_div4;
  long instP;
  long inst_Vsquared;
  long sampleIminusDC_long;
  long phaseShiftedSampleV_minusDC_long;
   
  switch(sample_index)
  {
    case 0:
      rawSample = ADC;                    // store the ADC value (this one is for Voltage)
      ADMUX = 0x40 + currentSensor_diverted;  // the conversion for current_grid (CT4) is already under way
      sample_index++;                   // increment the control flag
      //
      sampleVminusDC_long = ((long)rawSample<<8) - DCoffset_V_long; 
      if(sampleVminusDC_long > 0) { 
        polarityNow = POSITIVE; }
      else { 
        polarityNow = NEGATIVE; }
      confirmPolarity();
      //  
      checkProgress(); // deals with aspects that only occur at particular stages of each mains cycle
      //      
      // for the Vrms calculation (for datalogging only)
      filtV_div4 = sampleVminusDC_long>>2;  // reduce to 16-bits (now x64, or 2^6)
      inst_Vsquared = filtV_div4 * filtV_div4; // 32-bits (now x4096, or 2^12)
      inst_Vsquared = inst_Vsquared>>12;     // scaling is now x1 (V_ADC x I_ADC)
      sum_Vsquared += inst_Vsquared; // cumulative V^2 (V_ADC x I_ADC)
      sampleSetsDuringThisDatalogPeriod++; 
      //      
      // store items for use during next loop
      cum_VdeltasThisCycle_long += sampleVminusDC_long; // for use with LP filter
      lastSampleV_minusDC_long = sampleVminusDC_long;  // required for phaseCal algorithm
      polarityConfirmedOfLastSampleV = polarityConfirmed;  // for identification of half cycle boundaries
      sampleSetsDuringThisCycle++;  // for real power calculations
    break;
    case 1:
      rawSample = ADC;               // store the ADC value (this one is for Grid Current on CT4)
      ADMUX = 0x40 + currentSensor_CT2;  // the conversion for current_diverted (CT3) is already under way
      sample_index++;                   // increment the control flag
      //
      // remove most of the DC offset from the current sample (the precise value does not matter)
      sampleIminusDC_long = ((long)(rawSample-DCoffset_I))<<8;
      //
      // phase-shift the voltage waveform so that it aligns with the current waveform at CT4
      phaseShiftedSampleV_minusDC_long = lastSampleV_minusDC_long
             + (((sampleVminusDC_long - lastSampleV_minusDC_long)*phaseCal_int_CT4)>>8);  
      //                                                            
      // calculate the "real power" in this sample pair and add to the accumulated sum
      filtV_div4 = phaseShiftedSampleV_minusDC_long>>2;  // reduce to 16-bits (now x64, or 2^6)
      filtI_div4 = sampleIminusDC_long>>2; // reduce to 16-bits (now x64, or 2^6)
      instP = filtV_div4 * filtI_div4;  // 32-bits (now x4096, or 2^12)
      instP = instP>>12;     // scaling is now x1, as for Mk2 (V_ADC x I_ADC)       
      sumP_grid +=instP; // cumulative power, scaling as for Mk2 (V_ADC x I_ADC)
      sumP_forEnergyBucket+=instP; // cumulative power, scaling as for Mk2 (V_ADC x I_ADC)
      break;
    case 2:
      rawSample = ADC;    // store the ADC value (this one is for diverted current on CT3)
      ADMUX = 0x40 + currentSensor_CT1;  // the conversion for current_CT2 is already under way
      sample_index++;                   // increment the control flag
      //
      // remove most of the DC offset from the current sample (the precise value does not matter)
      sampleIminusDC_long = ((long)(rawSample-DCoffset_I))<<8;
      //
      // phase-shift the voltage waveform so that it aligns with the current waveform at CT3
      phaseShiftedSampleV_minusDC_long = lastSampleV_minusDC_long
             + (((sampleVminusDC_long - lastSampleV_minusDC_long)*phaseCal_int_CT3)>>8);
      //
      // calculate the "real power" in this sample pair and add to the accumulated sum
      filtV_div4 = phaseShiftedSampleV_minusDC_long>>2;  // reduce to 16-bits (now x64, or 2^6)
      filtI_div4 = sampleIminusDC_long>>2; // reduce to 16-bits (now x64, or 2^6)
      instP = filtV_div4 * filtI_div4;  // 32-bits (now x4096, or 2^12)
      instP = instP>>12;     // scaling is now x1, as for Mk2 (V_ADC x I_ADC)
      sumP_diverted +=instP; // cumulative power, scaling as for Mk2 (V_ADC x I_ADC)
      sumP_forDivertedEnergy+=instP; // cumulative power, scaling as for Mk2 (V_ADC x I_ADC)
      break;
    case 3:
      rawSample = ADC;               // store the ADC value (this one is for current_CT2)
      ADMUX = 0x40 + voltageSensor;  // the conversion for current_CT1 is already under way
      sample_index++;                   // increment the control flag
      //
      // remove most of the DC offset from the current sample (the precise value does not matter)
      sampleIminusDC_long = ((long)(rawSample-DCoffset_I))<<8;
      //
      // phase-shift the voltage waveform so that it aligns with the current waveform at CT2
      phaseShiftedSampleV_minusDC_long = lastSampleV_minusDC_long
             + (((sampleVminusDC_long - lastSampleV_minusDC_long)*phaseCal_int_CT2)>>8);  
      //                                                            
      // calculate the "real power" in this sample pair and add to the accumulated sum
      filtV_div4 = phaseShiftedSampleV_minusDC_long>>2;  // reduce to 16-bits (now x64, or 2^6)
      filtI_div4 = sampleIminusDC_long>>2; // reduce to 16-bits (now x64, or 2^6)
      instP = filtV_div4 * filtI_div4;  // 32-bits (now x4096, or 2^12)
      instP = instP>>12;     // scaling is now x1, as for Mk2 (V_ADC x I_ADC)       
      sumP_CT2 +=instP; // cumulative power, scaling as for Mk2 (V_ADC x I_ADC)
      break;
    case 4:
      rawSample = ADC;               // store the ADC value (this one is for current_CT1)
      ADMUX = 0x40 + currentSensor_grid;  // the conversion for Voltage is already under way
      sample_index = 0;                 // reset the control flag
      //       
      // remove most of the DC offset from the current sample (the precise value does not matter)
      sampleIminusDC_long = ((long)(rawSample-DCoffset_I))<<8;
      //
      // phase-shift the voltage waveform so that it aligns with the current waveform at CT1
      phaseShiftedSampleV_minusDC_long = lastSampleV_minusDC_long
             + (((sampleVminusDC_long - lastSampleV_minusDC_long)*phaseCal_int_CT1)>>8);  
      //                                                            
      // calculate the "real power" in this sample pair and add to the accumulated sum
      filtV_div4 = phaseShiftedSampleV_minusDC_long>>2;  // reduce to 16-bits (now x64, or 2^6)
      filtI_div4 = sampleIminusDC_long>>2; // reduce to 16-bits (now x64, or 2^6)
      instP = filtV_div4 * filtI_div4;  // 32-bits (now x4096, or 2^12)
      instP = instP>>12;     // scaling is now x1, as for Mk2 (V_ADC x I_ADC)       
      sumP_CT1 +=instP; // cumulative power, scaling as for Mk2 (V_ADC x I_ADC)
      break;
     default:
      sample_index = 0;                 // to prevent lockup (should never get here)      
  }
}

RobertWall, dBC,

Thanks guys.  I am in complete agreement with your descriptions of how my free-running ADC code is operating.

Robin

CidiRome, I've no plans to review that code you posted, but I'm happy to answer any ADC questions you might have.  In particular:

The 110usecs time is how long the value stays available before being replaced with other, or how long it takes to be available? (the second option seems to long to be the correct answer)

In free-running mode there'll be a new result every 110 104 usecs.  That means you have 110 104 usecs to read the result before it gets overwritten by the next conversion.  So I think the answer to your question is both.... it's how long you've got to read the result, and it's how long it takes to do a conversion.

Even when MUX is set, the ADC changes to the next sample after that time?

I don't understand that question, perhaps you can re-phrase?  In free-running mode, writing to the MUX has no immediate effect on the ADC as it's busy converting the currently stored voltage.  At the next 110 104 usec tick it will complete the current conversion, and start on a new one.  It's at that time that MUX setting matters.  The first 2 or so (from memory) ADC clocks is when it captures the voltage, so that's when the MUX setting matters.

Humm.

Thank you for the explanation.
So it is possible that when I read a value and request the next, this next value is not the one that is obtained in the next cycle. in this case the configured cycle is (/128).

I was thinking like this:

Cycle 0:
Read valueX;
Request valueA

Cycle 1:
Read valueA
Request valueB

Cycle 2:
Read valueB
Request valueC

> go to the beguining making the valueX be valueC

But depending how long the cycle is seems that it can be something like this (just an example):

Cycle 0:
Read valueX;
Request valueA

Cycle 1:
Read valueX2
Request valueB

Cycle 2:
Read valueA
Request valueC

> go to the beginning making the valueX be valueB and ValueX2 be valueC

 If I made the calculation correctly, the ISR will occur at a rate of 125Khz and this means evey 8 micro-seconds. It seems this can mess up the values being read it takes 110 micro-seconds to have a reading available.

I just have a few more information to think during the day...

PS: Robert and Rae. Taking in account the way you have been answering to me lately, If you want, I will stop posting my findings and troubleshoots and do my investigation off-line. I was posting every bit of information thinking it may be usefully to others, if you think otherwise just say... I don't say that any help is appreciated, but if it is the way this forum is supposed to work I will abide.

CidiRome, you may find it helpful to look at the ISR structures in my Mk2i code.  Two different ways of controlling the ADC are provided, with a compile-time flag being set to determine which one is used.  In one case, a fixed-duration hardware timer determines when the next conversion will start.  In the other case, the ADC is free-running.  Because of the high workload, my recent code for the emonTx V3 uses the latter approach. 

The latest version of my Mk2i code is available at:  

http://openenergymonitor.org/emon/sites/default/files/Mk2i_PV_Router_rev5e.ino_.zip

If I made the calculation correctly, the ISR will occur at a rate of 125Khz and this means evey 8 micro-seconds. It seems this can mess up the values being read it takes 110 micro-seconds to have a reading available.

125kHZ is a typical ADC clock rate, but the ADC takes 13 clocks to complete a conversion so you'll get an interrupt every 13*8 = 104 usecs.  The ~110 usecs quoted by me above is incorrect, I should have said 104 usecs.  In any case, the interrupt occurs when the conversion is complete, so you don't need to worry about it.  (I'm referring to free-running mode here).

Yes, when conversion N has finished, an ISR is called.  The ISR sets up the relevant conditions for conversion N+2 because conversion N+1 is already under way.  This is how my code behaves when the ADC is in free-running mode. 

For the version that uses a hardware timer of 125 us, the conditions for conversion N+1 are set up within the ISR that occurs at the end of conversion N.  The sampling rate, and hence the processor's workload, can be changed by adjusting the duration of the timer.

These interrupt-based regimes for operating the ADC were supplied to me by Jorg Becker circa December 2012, and they have both proved to be entirely reliable since then.

Humm, very good, that explains it, I think.

Can you elucidate one thing to me:
At the very first cycle of the ISR, ADMUX has not be defined yet, how do you know the reading you are doing is for Analog port for Voltage and the second for CT2?

I would think of a flag to ignore the first few readings until the ISR is reading the expected values...

Cheers.

Update:

With this last indication I made the necessary changes in the ISR and I'm now reading valid results:
Next JOBS related with calibration:
- Take in account for the 3 turns in CT1 and 10 turns in CT2;
- Calibrate the VRMS, it seems to be reading a voltage about 6 Volts over the real.

On EmonPI base firmware was getting a Night Production of about 3W, with this firmware it seems to be worse about 7W (reading before turn division is 70W)...

Cheers.

I would think of a flag to ignore the first few readings until the ISR is reading the expected values...

Have you checked the effect of the existing flag, beyondStartUpPhase ?

Hi.

I've seen that flag, if I remember correctly, that flag is checked the first time after the first Voltage reading has been made.. but the counters seem to be reset, so any miss reading are reset... Ok, understood.

At this moment I'm implementing a mix program that uses, in intervals of 20 seconds, the emonLib and your program to be calibrate it without the need of measuring everything again because the system is in-place and the CT Sensors inside the breaker box. Tomorrow I will continue.

Cheers.

CidiRome, The flag, beyondStartUpPhase, is checked at the start of every new mains cycle throughout the lifetime of the program.  A quick check of the code will reveal this.   This flag is initialised to false, and is then set to true after everything has settled down a few seconds later.  This same approach has been taken in all of my Mk2 code variants.  The presence of this flag hopefully meets with your approval.

I would be grateful if you could refrain from complaining about my software unless you have found that the original version is deficient in some way.  Learning about how other people's code behaves is fine, but please do not make negative assertions in public that are ill-founded.

When I want to learn about someone else's code, I run it as posted to see how it behaves.  I then make strategic changes as necessary to improve my own understanding.  At any stage, I can revert to the original version as a reminder of how the author intended it to be.

As soon as you have made any alterations, you need to take responsibility yourself for the new version.  Any changes that you make could have significant side-effects on the program's behaviour which only you can investigate, analyse and resolve.  If any suspected errors are found in the original code, it would be courteous to raise the matter in private with the author rather than posting your initial findings in public view.  There could well be an explanation that you had not thought of.

Finally, may I add a word of warning that my "Mk2" code must be allowed to run continuously.  This observation is in response to your posting that:

At this moment I'm implementing a mix program that uses, in intervals of 20 seconds, the emonLib and your program

Thank you for your answer.

That was the last statement I made about your code, your last message made it clear that you feel offended about me questioning how your code works as if I would be diminishing you or your work in any way.

My objective was always to learn and maybe help others to learn  on how it work and if I implied that something may not be correct, was to obtain an explanation that would contradict me and I apologize if at any time I gave other impressions.

So, since, by what you say, the code is perfect and works flawlessly, my experience feedback on emonPi hardware is not welcome and has ended to be public.

Have a nice day.