Hi,
As there appears to be a considerable amount of interest in getting an emonTx unit running Robin’s MK2 code (calypso_rae on this forum) and communicating with emonGLCD / emon Base … I thought it was about time I publish where I am at with my project.
I have had an emonTx running since April diverting excess PV power to my immersion heater or a storage heater using a Crydom and associated Filter. Although this worked, I was not really happy with my level of control at low generation power and my wife constantly reminded me about that “buzz” in the hallway!
The emonTx with CT1 connected to the Grid, and CT3 connected to the Solar PV generation meter, AC psu and 5v USB supply are also connected.
The top LED is the TriColour LED (one taken from the emonGLCD) which flashes Red or Green depending on whether we are importing or exporting.
Showing Red today as there is not much daylight out there so we are generating less than we are using. The bottom LED flashes Amber every cycle the Triac fires though sadly not today.
To the right an image of the display taken when the unit was diverting.
So I have been thinking about adapting Robin’s MK2 code for use on the emonTx since August. Then I saw Ian Beck’s post (Series530 on this forum) and thought “job done, let’s give it a go”. I needed to make some changes because I didn’t want to increase the size of my neatly boxed emonTx but that basically meant changing a few output pins for LEDs and Triac trigger. Unfortunately I didn’t have a great deal of success with Ian’s code, although it worked (once I got the current transformer around the right way), the display readings were not consistent with what I experienced with my original emonTx code and set-up.
However I was now inspired to put some effort into my original plan – Create a re-entrant version of emonlib. In this case, by re-entrant, I mean making each call to CalcVI handle only one sample of voltage and current. It would then calculate real power etc. after the number of specified crossings and reset the counters to zero ready for the next set of calls to CalcVI. I also wanted CalcVI to take into account the readings already taken this iteration of the loop by Robin’s code. I have also added some enhancements to allow for more accurate detection of crossing zero each half cycle based on Ian’s calibration routines.
A note on Ian’s calibration routines … I thought it was nice to have these routines in the code (space permitting), but I personally don’t think that it is appropriate to try and calibrate each time the unit is switched on. This is mainly because, if I understand correctly, the calibration is only valid for the specified measured mains voltage at the time of calibration. My mains voltage (on the end of overhead cables) goes up and down all day. So what I have done in my code is to allow for the measured mains voltage to be keyed in at start-up, but if after 10 secs there is no input via the serial port, then the main loop starts without any further calibration. The idea here is to capture the various parameters and then change to code to reflect the parameters of your own set-up. The 10 sec delay also allows the electronics to settle.
The net result is that Robin’sMK2 code remains virtually intact, the only addition being a few lines to turn on an LED an increment a counter to show if the Triac is fired this cycle.
Towards the end of Robin’s MK2 code, where it says processing for negative half cycles, I have added my calls to the new CalcVI (packaged in the PowerCalc library). The first call for “ct1” uses the already sampled values of V & I and the second call (I have used “ct3” in this example) provides values of zero to the new CalcVI which causes it to perform the analogue reads itself.
At the end of the main loop, I do a quick check to see how many cycles have passed and after 200, that would be 4 secs at 50cps, I pick up the latest power calculations from the ct1.PowerCalc routines, flash the LED Green or Red depending on whether we are importing or exporting and send off the data using the on board RFM12B.
Oh and I also use the Watch Dog Timer to reset in the event that the code gets hung somewhere.
My code in emonGLCD and emonBase follows the basic sketches already on the github although I have enhanced to code to :
emonGLCD
• Handle a GMT offset using the switches
• Backup cumulative power to emonBase in case the emonGLCD is restarted due to a fault
• Display the %power diverted to the immersion and provide approximate power calculation
• Provide a second menu screen to display such things as temperature, supply voltage time and GMT offset.
• Vary the backlight according to the ambient light level
• Correct the temperature display – provide a calibration offset
emonBase
• Add the appropriate GMT offset to the time (in this example Cosm / Pachube) but works just as well for emonCMS
• Hold a backup of the cumulative power readings from emonGLCD
• Only update the time from the internet if the “date” is supplied (otherwise you can reset the time on the emonGLCD to midnight which resets the cumulative results)
• To restrict the amount of data sent and stored on the internet, send the average of the individual power readings every 30 secs.
In terms of hardware, I have only modified the emonTx unit to support a Tristate LED instead of the single green LED supplied (I used one of the LEDs supplied with my emonGLCD - I thought that 2 on the emonGLCD was unnecessary) This was easily done by adding an additional resistor connected at the back of the board to digital output PD7 picked up from P4 pin 2. I then added an additional LED to the back of the board by adding a resister to PD5 which I picked up from P2 pin 2 and fixing the other leg of the Yellow LED to the GRD pin of SPI/ISP. I use this to show when the Triac has been switched on although an LED could easily be added to the same Arduino pin as the actual MOC4031 and mounted with the Triac. I connect the emonTx to the MOC4031 and BTA41 usung the jack socket labelled as the pulse counter which means I fire the triac from DIO3/PD3, Pin 5 of the ATMega328.
I have used another consumer unit (fuse box) to power my PV controlled loads – let’s call it the DPCU box for short. In my set-up I have connected the main isolator of the DPCU to a MCB in the main consumer unit. This is for two reasons, firstly I repurposed an existing consumer unit that was previously connected to storage heaters, and secondly, I can provide additional protection to the new control circuits. The system would still work if the DPCU was connected directly to the mains. Inside the DPCU I have added MOC3041(s) and BTA41(s) to switch the supply from the main DPCU Isolator to individual MCBs. A point to not is that the Triac get warm, so you need to allow for a large heat sink – I have an aluminium plate plus black finned heat sinks and it still gets warm to touch. A simple twisted pair connects the emonTx via the Pulse Counter Jack to the DPCU.
A point to note when fitting the Current Transformer. After a realising that the Triac was being armed at the wrong times, I determined that Robin’s code when run on an emonTX appears to expect to see negative as Grid Import from current sensor so if you have fitted the CT sensor to emonTx with the writing facing away from the meter as per the emonTx instructions, then you will need to turn it the other way around. You can change the code in the relevant places instead but as it worked when I swapped around the transformer I left things alone and haven’t got around to working out where and in how many places the code would need to be changed.
A point to note about Ian’s code. This is included and used for calibration only. This is not required for normal operation and could be removed. I have included Ian’s test at the beginning for completeness as well as Robin’s.
So many thanks to Robin for the MK2 code, Ian for the Calibration code, Glyn and Trystan for the building blocks as well as Paul Reed, Stuart and Robert Wall who have all made major contributions via this forum and get us to where we are today.
The picture on the left is the back of the emonTx showing how I added a couple of resistors to mount the extra LED and power the other side of the TriColour LED.
The little ribbon cable you can just see to the right is my extension cable to the programming port. This is so I don’t need to unscrew the case every time I want to upload or monitor. The extension plug mounted on a tiny piece of strip board fits neatly under the removable compartment lid that used to hold my batteries – and still could!
The picture on the right is the DPCU (Diverted Power Consumer Unit which is in my hallway with the panel removed so that you can see the Triac mounted on a heat sink in the Consumer Unit.
This is fed from the main consumer unit next to it and the data lead from the emonTx unit above it.
Below are some images that I took today when the sun decided to grace us with its presence. On the left the PV panels are generating and diverting around 26% of the mains cycles to heat my water leaving only 11w to export, On the right is the second menu display showing the time (picked up from the internet) and offset by +1 GMT and at this time the Vrms was reported as 245.2V.
These are the graphs I picked up from Cosm later so that you can actually see what was generated, diverted and what w imported / exported from / to the grid.
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
Wow! I think this is going to make a lot of people very happy.
P.
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
Thank you for sharing!
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
My only question would be whether there's enough cooling available, having the heatsink enclosed within the CU?
P.
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
It is warm to touch on full power Paul, but still operates within the spec of the Triac - I did measure it with a thermometer a month or so back, but I don't recall the exact temperature. I am currently using a bit of aluminium and two finned heat-sinks all inside the CU, expanded after I too thought it was running a bit warm. So far I haven't tried to make a better heat-sink but there is potential to add a side panel and external fins if required. Multiple Triacs shouldn't generate more heat unless you were to have a commercial system generating more than the 4kw max at present. You would only have one on at a time or more than one running at less than full power.
John
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
The triac dissipates less than 12 W at 3 kW load. I haven't done the sums, my guess is that would be in the same order as a full house of MCBs at full load. The acid test is temperature rise inside the box. If the temperature remains below about 35°C (say a 15° rise above ambient), then it's probably OK (I'm thinking of cooking the rest of the wiring and/or derating the MCB's; not the triac, which is good to a junction temperature of 120°C).
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
Can you write a bit more about how you've connected the triac to the emonTX? Is it one of the standard circuits from one of the other threads?
P.
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
I used the circuit on the MOC3041 datasheet Paul, which is the same circuit that Ian and Robin used, changing the resistor on pin 1 to the appropriate value for the supply voltage. I actually used a TLP3041 because I happened to have one lying around, and this operates in much the same way. I will draw up a circuit diagram for completeness and to show the connection to the emonTx with the minor mods I made for the LEDs and voltage connection to the 3041 - hopefully today.
J
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
Your emonbase sketch (Ex_NanodeRF_Power_RTCrelay_GLCDtemp_and_Cosm_2v5F3) won't compile in Arduino IDE v1.02 , or v1.01
What needs to be done to bring it up to date?
I'm following your work and I'm not sure how much work this would entail?
or would it be easier to download V1.0?
Still a way to go yet for me to get going
I'm building the emonGLCD unit at the moment
regards
Mark
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
Hi Mark,
Great work, this looks live a tidy setup. I though this deserves more attention, hope you don't mind my creating a blog post to highlight your work:
http://openenergymonitor.blogspot.com/2012/11/solar-pv-excess-power-into-immersion.html
I have attempted a quick summary, with link to your post for more info. Please let me know if I've made any errors.
We would really like to get the solar PV immersion control system better documented since at the moment all golden nuggets of information are dotted about the forums. I have designated an area on the wiki for the documentation of a solar PV immersion control system: wiki.openenergymonitor.org. I wold love to see your system or a similar system (Ian's?) documented there.
However, I think before a top (application level) documentation article is compiled we need a building block (http://openenergymonitor.org/emon/buildingblocks) entry detailing the basics of the how a triac works, the triac electronic circuit and the theory behind the MKII PV code.
Trystan and I feel that such documentation articles would be best compiled by those familiar with the system. Any volunteers would be much appreciated. I have been in communication with Robin, I believe he is best placed to compile the building blocks topics mentioned above. Maybe you (Mark) or Ian Beck would be interested in working on an 'application' level documentation for the wiki page?
Keep up the good work! The PV MKII developments are a great contribution to the project.
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
Glyn
Please note well
It is Jrobbie's work, I just started to follow his work
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
The key point about Robin's Mk2 code is that it operates continuously. Voltage and current are sampled 50+ times per mains cycle, every mains cycle. Distribution of surplus power via the triac is part of that sequence. Mk2 never pauses, that's why it gives such good performance.
Anything that waits before doing a time-limited measurement is really not based on Robin's code.
Regards to all,
Robin
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
Robin and I had a discussion some time ago about offering what I have been doing on a more formal level. If I am honest, I am very willing to do this. What has stopped me is two things: firstly, the fact that I have had issues correlating my results with the standard results offered in the building blocks and, secondly, almost back to back business trips, which have stifled my progress.
on the first matter I have completely rewritten my sketch so that it now uses pretty well the standard building blocks that are offered in the forum while still using Robins approach for the energy bucket. Unlike the building block method it is a pretty well continuous monitor with just an occasional RF12 transmission to the emonGLCD. I also have the feature of remote temperature monitoring but only when the energy bucket is not filling or depleting.
I wanted an additional feature whereby my Elster AC100 could be periodically read and the generation data sent to the GLCD. I had a play with that last weekend but couldn't get the system to successfully work with interrupt masking. What I want to do is to only poll the pulses from the irda port when there is no solar generation and the energy bucket is not affected. As soon as I try to mask and unmask the interrupts it doesn't seem to work.
on the issue of the calibration, it works and isn't bad. If I am honest though, it is nowhere near as good as I would like it to be. I have been using my enviR optismarts as my reference and trying to tune things with various coils of wire and light bulbs. This all works fine with wire but seems to fail miserably with a real load. I can tune to a decent correlation at some power values but it falls away badly at others. I suspect that power factor is partly to blame but I also think that there is another issue somewhere ... But I haven't worked out where as yet. I will buy an IAM device this week and see what that says. ... Another reference point so to speak.
Progress is hampered by my second issue. I've been away on business trips for much of each week for at least the past two months. With a stack of other stuff to do around the house it's a bit of a struggle to then work on the OEM. I hope to have a little more time at home as we near Christmas so that may give me time to play.
when things are working better I would be more than happy to work on something more formal. If anybody wants to PM to discuss, feel free. I'm six hours behind the UK at the moment so may take a whole to respond. I plan to return home on Thursday evening though.
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
A Mk2 + emontx + glcd + A100C reader + temp inputs combination would be almost perfection for me, and I suspect for many other people here too.
I *do* understand about the time constraints, though.
P.
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
Sorry for the delayed response(s), I have been away.
Mark Re: Your emonbase sketch (Ex_NanodeRF_Power_RTCrelay_GLCDtemp_and_Cosm_2v5F3) won't compile in Arduino IDE v1.02 , or v1.01
this is the line to change (in the DHCP_dns section)
if (!ether.dhcpValid()) dhcp_status = 0; // v1.0.1 lib if dhcp expired start request for new lease by changing status
if (ether.dhcpExpired()) dhcp_status = 0; // v1.0.0 lib if dhcp expired start request for new lease by changing status
I didn't have much with the reliability in connecting to Cosm using the 1.0.1 library code for these ethernet calls so I reverted back to using the 1.0 code. That runs with no problem.
John
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
Robin,
Re The key point about Robin's Mk2 code is that it operates continuously. Voltage and current are sampled 50+ times per mains cycle, every mains cycle. Distribution of surplus power via the triac is part of that sequence. Mk2 never pauses, that's why it gives such good performance.
Anything that waits before doing a time-limited measurement is really not based on Robin's code.
I fully understand that your code will be affected by any interruption to the the ability to sample multiple times per cycle. That is why I had to code a new version of calcVI which was re-entrant or perhaps I should have said "Real Time". There are no For next loops or While loops the samples and calculations are processed each time the routine is called and a final value generated after a number of passes through the mid point 'zero crossing'.
As it uses the same code as calcVI for the calculations the results are as good as the emonlib library.
To avoid any confusion with the original calcVI, I have now created a version of the emonlib library with a new component called R_calcVI and modified CurrentTx / VoltageTx to support the provision of the mid rail value - although I am not sure how much difference specifying the mid rail point will improve accuracy.
If Glyn would like to adopt this new emonlib - which incidentally is backward compatible with any code calling the common element VoltageTx - I am happy to provide it so that it can be uploaded to the Git Hub.
John
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
Hi Glyn,
Yes I am happy to help with some words, but may need some help from others too, like Robert and Robin to assist with the operation and logic behind the base MK2 code. As indicated in in my last post to the forum ...
I also have a new version of emonlib which incorporates my Real time, Re-entrant version of calcVI, now called R_calcVI so this could be supplied and included as a single module.
Regards,
John
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
jrobbie: I fully understand that your code will be affected by any interruption to the the ability to sample multiple times per cycle. That is why I had to code a new version of calcVI which was re-entrant or perhaps I should have said "Real Time". There are no For next loops or While loops the samples and calculations are processed each time the routine is called and a final value generated after a number of passes through the mid point 'zero crossing'.
John, the point I was making that my Mk2 code doesn't stop after a while, it just keeps on going. By that means, its rapid response time is available at all times, whenever the kettle goes on. The explanation above suggests to me that your system pauses after a while to deal with the results of the measurement that it has just taken. The line that caught my eye in your original post was:
It would then calculate real power etc. after the number of specified crossings and reset the counters to zero ready for the next set of calls to CalcVI.
Again, this suggests to me that the action stops while something different is done.
Please don't mis-understand the point I'm making. There's nothing wrong with monitoring or distributing power in this way if that's what you want to do. That's exactly how my Mk1 setup worked, it being based firmly around the original calcVI() routine, in emonLib. I just get rather touchy when people talk about adapting or using "Robin's code" within an arrangement that doesn't operate continuously.
From a personal point of view, I feel more pleased with my contribution on the measurement side of things than on the output side. The triac work had already been done by the likes of Paul Reed. The energy-bucket, which is nothing more than a simple accumulator, fits nicely between the two. Yes, I did work out how to put all the bits together, so to that extent it is my code.
If anyone wants to use "Robin's Mk2 code" in its original form, they're most welcome to do so. And if you're rather change it into something different, that's fine too. But, please, just give it a new name!
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
My set up doesn't stop either Robin, it samples continuously. However every so often there is a bit more processing to do to handle the saving of the accumulated samples and sending via the wireless interface. During this processing, the loop will clearly be slightly longer, but it does not appear to make any material difference to the operation.
J
Re: MK2 PV code on emonTx feeding emonGLCD & emonBase
During this processing, the loop will clearly be slightly longer, but it does not appear to make any material difference to the operation.
I'm glad to hear it. By only doing other things when close to zero-crossing points, any energy that is 'missed' should be minimal. With 50 samples per mains cycle, less than 1% of the energy content is in the first four samples.