To date, my Mk2 PV Router code has always been configured to run on an Arduino or an emonTx V2. Several people have expressed interest in a version which can run on an emonTx V3, in particular regarding how the output stage can be connected.
This code has been set up for the RFu version of the emonTx V3 which I understand to be V3.2. This platform requires the use of the <RFu_jeelib> library rather than the standard one. The "RFu" library uses digital IO #3 for the RFM12B's IRQ line thereby freeing up digital IO #2 for general use. Digital IO #2 is available at the terminal strip and is used to drive the output stage. By connecting the other wire of the output pair to the 3.3 V connection, none of the terminal strip's connections need to accept more than one wire. The three wires from the Dallas OneWire temperature sensor neatly use other elements of this strip (photo).
To check the operation of this new version, I set up a test rig (photo) comprising an emonTx V3 and a wired output stage with a heatsink. There are two mains circuits for generation and consumption, and three CTs (photo). The objective of the Mk2 Router has always been to match consumption with generation, and this latest version appears to do the job as well as any other.
The emonTx V3 has four CT inputs, but only CT4 has a sufficiently high sensitivity for control purposes. This channel is therefore used to monitor the grid supply. CT3 has been assigned to monitor the diverted power, and some additional code has been added to allow this flow of energy to be accumulated during each solar day. The total value is reset after a period of ten hours during which no surplus power has been detected (or 36 seconds when in its test mode).
CT2 and CT1 are available for general use. For my test purposes, CT2 has been used to monitor the circuit for 'generation', and CT1 is unused. The on-board LED shows when the load has been instructed to be in the "active" state.
The attached .txt file provides the results of a test sequence in which the operation of the system can be seen in detail. The first part of this file gives an explanation of the test method; the latter part is essentially the raw data as captured from the Serial Monitor.
In order to work satisfactorily with the Dallas sensor, this version of the Mk2 code has been substantially re-structured. All of the Mk2's sampling and control activity now takes place within the ISR. The main code is only used for slower activities such as Serial, RF transmissions and temperature sensing. Prior to this change, any OneWire activites would have caused some data samples to be lost. With this new structure, delay() has no effect on the operation of the underlying control mechanism.
The structure of each datalog message is:
typedef struct {
int power_grid_Watts; // uses CT4
int power_diverted_Watts; // uses CT3
int power_CT2_Watts;
int power_CT1_Watts;
int diverted_energy_WattHours; // uses CT3
int Vrms_timesTen;
int temperature_times100;
} tx_struct;
This version of my Mk2 Router may be of interest to anyone who already has an emonTx V3 in place, and is thinking about diverting their surplus power for some on-site purpose. With the emonTx V3 being a safe and well contained product, only an output stage would be needed. Self-contained output stages are available from my online Shop at www.mk2pvrouter.co.uk
In some premises, it is not possible for the output stage to be connected by wire. In such cases, the Router's control mechanism would have to be implemented using RF. It is possible for an emonTx to transmit both forms of RF data (for control and datalog purposes) with the remote node forwarding only the datalog messages to emonBase in an enhanced form. By this means, relevant information can be logged from both ends of the Mk2 link. If this kind of system is of interest, please contact me using the 'info' email address on my Shop page.
Re: Using an emonTx V3.2 as a Mk2 PV Router
Hi,
I'm using your code on my emonTx V3. I get data from serial, so I just deleted some useless print, but it seems doesn't work! I have only CT4 and AC/AC adapter and this is my output (by serial):
-------------------------------------
Sketch ID: emonTxV3_as_Mk2Router.ino
ADC mode: free-running
Output mode: anti-flicker
offsetOfEnergyThresholds = 0.10
powerCal_grid (CT4) = 0.0450
powerCal_diverted (CT3) = 0.2500
powerCal_CT2 = 0.2500
powerCal_CT1 = 0.2500
voltageCal = 0.8750
>>free RAM = 1165
capacityOfEnergyBucket_long = 3999999
lowerEnergyThreshold_long = 1599999
upperEnergyThreshold_long = 2399999
>>free RAM = 1155
----
1259200000325.2
1259200000257.7
1259200000257.9
1259200000258.0
1259200000258.1
1259200000258.5
1259200000258.4
1259200000258.4
1259200000258.4
1259200000258.4
1259200000258.1
1259200000258.1
1259200000258.3
1259200000258.2
1259200000258.2
1259200000258.2
1259200000258.2
1259200000258.2
1259200000258.2
1259200000258.2
1259200000258.1
1259200000258.1
1259200000258.0
1259200000258.0
1259200000258.0
1259200000258.0
1259200000258.1
1259200000258.1
1259200000258.1
1259200000258.1
1259200000258.2
1259200000258.3
1259200000258.3
1259200000258.3
1259200000258.3
1259200000258.3
1259200000258.4
1259200000258.5
1259200000258.5
1259200000258.4
1259200000258.4
1259200000258.4
1259200000258.0
What is wrong?
Re: Using an emonTx V3.2 as a Mk2 PV Router
I'm sorry, hercules71035, I don't know why you are getting that data.
Have you tried running the sketch exactly as I posted it, without changing anything?
Re: Using an emonTx V3.2 as a Mk2 PV Router
No calypso_rae, I've just commented some serial print in order to use emonTx via serial. Moreover, I added Serial.print(nodeId) at each cycle.
Re: Using an emonTx V3.2 as a Mk2 PV Router
The results file that I attached in the top post shows the display format when the sketch is run on an emonTx V3.2 exactly as posted. Yes, there is a lot of Serial, but that's no problem because all the clever stuff is now done within the ISR. The main code in loop() only deals with slower activities, which includes the Serial interface.
Re: Using an emonTx V3.2 as a Mk2 PV Router
Hi,
thanks for the suggestions. I've resolved. Some Serial.print() was worng!
Re: Using an emonTx V3.2 as a Mk2 PV Router
Okay! you're all sorted now!
I started editing and got sidetracked, when I came back you have posted. I've still attached the sketch anyway as someone else may find it useful.
Paul
PS **untested** as i don't have a emonTx v3 for test purposes.
Re: Using an emonTx V3.2 as a Mk2 PV Router
Paul, what does your 'serial direct' version do that is different than the original one?
I'm intrigued ...
Re: Using an emonTx V3.2 as a Mk2 PV Router
Hi Robin, All I've done is commented out all the serial prints and added just the serial prints to output the nodeID and data values only, so that the serial output is now a data stream of "nodeID val1 val2 ..." packets that means it can be hooked up to a Pi via the serial port rather than using an RF connection.
The serial output is "OEM" format that can be read by OEM software rather than human readable.
and I commented out the rf stuff too.
See Direct connection emonTx V3 > Raspberry Pi GPIO
Paul
Re: Using an emonTx V3.2 as a Mk2 PV Router
Thanks, Paul, that all makes sense now. I'd not appreciated that the Serial port could be used in this alternative way.
For the 3-phase Router sketch that I posted recently, the RF can be easily disabled by commenting out the statement #define RF_PRESENT. I must remember to include this feature on any future RF-enabled code.
Re: Using an emonTx V3.2 as a Mk2 PV Router
Hi,
just a question: why there is no watt_hour measure in this sketch?
Re: Using an emonTx V3.2 as a Mk2 PV Router
I remember checking out Calypso's diverter software many months ago, but was put off because they did not forward energy data to emoncms.
Reading the above, I suspect that has now changed, and the values are forwarded to emoncms, just like a normal emonTX, as well as acting as a diverter?
Re: Using an emonTx V3.2 as a Mk2 PV Router
Yes, integer data is indeed transmitted by RF, just as for the emonTx, and this sketch also acts as a diverter.
Most sketches for the emonTx transmit average power rather than accumulated energy, so that's how I wrote this one. There is a similar sketch (Mk2_RFdatalog_4.ino) on my website's Download page which accumulates diverted energy in WattHours. It should not be too difficult to copy that extra logic into this code for the emonTx.
Re: Using an emonTx V3.2 as a Mk2 PV Router
Average Power - is that the average power used/supplied between consecutive emoncms data updates.
So what data format does 'accumulated energy' use to send to emoncms? does it calculate the number of WattHours used/supplied between consecutive readings, which are then forwarded & processed by emoncms?
I'm picking up that you are steering towards using 'accumulated energy', but I'm not sure of any advantage gained?
EDIT -> It took a few minutes to sink in, but yes I can see the accuracy advantage!
Re: Using an emonTx V3.2 as a Mk2 PV Router
Average Power: Between consecutive RF transmissions, the instantaneous power (V*I) is measured a large number of times. These values are summed and then divided by the number of contributions to get the average power. After a cal factor has been applied, this is the transmitted value (in Watts). This process occurs for each of the four channels, CT1 - CT4.
Accumulated energy: In sketches where I calculate the accumulated energy, the energy content in each mains cycle is calculated, and a register is updated whenever a complete WattHour has occurred. The total number of WattHours is then presented as an integer. In the diverter units that I supply from mk2pvrouter.co.uk this number (for the diverted energy channel) can be displayed using a 4-digit display on the front panel. When data is being sent to emonCMS, I thought that "average power" would be sufficient because the accumulated energy total can be readily obtained by subsequent processing.
Re: Using an emonTx V3.2 as a Mk2 PV Router
By the strictest definitions of the terms, neither average power over an interval, nor accumulated energy over an interval is more accurate than the other. One is just the other divided by time. Provided you have one, and you know the interval, you can always derive the other. For example, my meter reports accumulated energy in WattSeconds every 10 seconds. If I divide that by 10, then I get average power over the 10 seconds.... no accuracy is lost, provided I keep the decimal place.
Now if by "average power" what you mean is a short sampled snapshot of "instantaneous" power at the beginning of the interval, and then assume that was the average power for the entire interval, that's clearly not as accurate.
Re: Using an emonTx V3.2 as a Mk2 PV Router
Looking at the sketch it's the former.
So are there any advantages either way? I seem to remember Trystan discussing this, but I can't find the post now...
Re: Using an emonTx V3.2 as a Mk2 PV Router
Depending on exactly what you're transmitting, one might be more robust than the other in the case of lossy transmissions. If your accumulated energy messages are accumulated energy since the beginning of time, then a lost message or two won't make any difference to your totals, because the lost details will at least be included in the next message you do receive. If I lose one of my "accumulated energy in the last 10 seconds" messages, then that information is lost forever.
Re: Using an emonTx V3.2 as a Mk2 PV Router
In my Mk2 Router sketches, "accumulated energy" means the total amount of energy that has been accumulated today. After ten hours of no surplus power being present, the total is cleared in readiness for the next day's haul.
"Average power" means the average of all the instantaneous power values during the preceding interval. This approach has also been termed "continuous monitoring".
"discrete monitoring" is where power values are measured rapidly for a certain interval, but the process then waits for a while before starting again. This approach is no good when actively diverting surplus power, hence none of my own sketches work in this way. They all monitor continuously.
Re: Using an emonTx V3.2 as a Mk2 PV Router
"This approach is no good when actively diverting surplus power" —and can also be misleading when a rapidly switching large load, e.g. an induction hob, is in use.