Fusion of the MK2 controller with the emonGLCD

The MK2 controller and a bit more

My initial goal was to devise a PV dump controller as I already have several energy monitors. I stumbled across open energy monitor by accident and got rather interested in the fact that it is possible to measure the actual system export and not just the import (a failing of many systems that I already have). Having never played about with micro controllers but being familiar with real time programming and system control I saw a fusion of a PV dump controller with an energy monitor as an interesting project.
I decided to base my work upon calypso rae's (AKA Robin) energy bucket principle. My starting point was Robin's mark 2 software and I have added additional capability to it for energy monitoring and remote display.  My circuit uses the emonTX kit (arduino) with a few LED's.

The emonTX showing the LED's and the monitoring jacks. I've since added a port extender so that the it can be programmed without unscrewing the front panel from the case.

I use the high voltage control circuit that Robin has in his design and I have added connectivity to the EmonGLCD. The emonGLCD is the stock kit without modification. As you will be able to see in the pictures I have installed both units in plastic enclosures. The emonTX, which sits in the garage, is more a functional presentation than an elegant unit.

 

The emonTX wall mounted in the garage. The 3.5mm jack at the front is the triac fire feed

I decided to  isolate the high voltage section from the emonTX enclosure. A 3.5mm jack plug takes the 3.3V power and control trigger along a 15 metre or so cable to the airing cupboard. The high voltage circuit is mounted within a large section of aluminium extrusion which acts both as a heat sink and as protection from small fingers. I've added an isolating switch in series with the feed to the immersion heater. As we never use the immersion heater aside from PV dump there is no bypass arrangement. The whole extrusion is mounted upon a hardwood board and then screwed to the wall. The hardwood has flame retardant properties and acts as an additional safe guard.

I've made more effort with the emonGLCD as this unit sits in my home office and is seen by the family and friends.

The emonGLCD showing the system heating the hot water. The mains voltage isn't quite as high as indicated. That error has since been addressed

In Robin's design he focuses upon the energy bucket. While I use that software to control the PV dump I also measure the power generated or consumed at the point of measurement.  Measured  information is transmitted by the RF12 wireless interface on the emonTX to the emonGLCD every four seconds where this information is displayed. With a view to trying to get an accurate representation of the power used or exported a certain amount of calibration of the current and voltage sensors is performed when the system first boots.
The emonGLCD displays the power that the system sees, the energy bucket level, the number of triac fires taking place during the measurement interval and the unit temperature. The GLCD LED's are programmed to shine green when exporting and red when importing from the grid. The unit senses the ambient light and brightens the screen when the light levels are high and dims the screen and inhibits the LED's when the light level is low. Both the TX and the GLCD maintain a heart beat feature to show when a hand shake transmission has taken between the two units irrespective of ambient light level.

 

This is the emonGLCD when importing. The soft focus isn't for romantic effect. One of my enviR monitors is sitting next to it. This one monitors PV generation and wont correlate with the GLCD

The emonTX has LED's which indicate when the system is exporting, importing and a signal is being sent to fire the triac as well as the heart beat already mentioned. Strictly speaking, these LEd's are not required but they do act as a decent visual indicator with regard to operation. As the dumper is close to the electricity supply meter, I can visually correlate import, export and triac fire with the supply meter LED going green without having to turn on the serial monitor and read the data being sent. Given that a serial monitor transmission takes a little time from the loop, just running with the LED's and periodically checking the GLCD display is a more representative account of the system under normal operating conditions than with a serial monitor which is sometimes enabled or otherwise disabled when debugging is not taking place.

 

Limitations:

 

As with any project, there are always improvements to be made. Rather than continuing forever I thought it better to offer the design and the sketch so that others can use or learn from it.

The key areas where improvements could be made are in the accuracy of the power monitor. As many have demonstrated, it's actually quite difficult to measure the power accurately with a vanilla design of the emonTX. I didn't want to get too heavily involved in instrumentation electronics as this is too much like my day job. I feel that the huge range of current measurement required together with the design of the kit and the relatively poor resolution of the arduino makes really accurate measurement over the whole usage range a pretty tough ask. This is in no way a criticism of the design of the kit or the choice of components. It's simply a function of cost against performance. With this in mind I decided to take a different tack with regard to accuracy: One of my other monitors consists of an enviR display with an optismart pulse reader. I've found this unit to correlate well with my PV meter and I have extensively scatter plotted this against the emon and applied a curve fit algorithm in my code. The emon correlates to within about 20W of the optismart from 250w right through to about 4Kw.

 

As I sit here now, the emon is measuring 396W and the enviR is measuring 407W. If I turn on the electric grill the emon reads 2364 and the enviR is on 2380.

 

As the pictures show, my emonTX has some voltage and current monitoring jacks on the front. Measurement of quiescent current in our house is pretty difficult as the signal is both low in amplitude and pretty noisy.

Low household load showing voltage transformer monitor with current superimposed. Noise dominates and the current is barely sinusoidal and pretty difficult to accurately measure

With a low nyquist sampling frequency there is huge opportunity for loss of information and aliasing. I've added nothing to the circuit to deal with this so it's asking a lot for the arduino to do a good job with just an amp or two of incoming current. Much easier, I feel, for it to deal with a higher resistive load such as a toaster, a grill or an oven where the background noise is far less than the fundamental of the current waveform.

 

Huge thanks go to calypso_rae for not only providing the foundation of one of the sketches (and the concept which fuels it) but also for being patient in answering the many questions that I asked him during the development.

They are still a little bit work in progress but here are the sketches as they stand (if I don't publish them now, they will never get uploaded!)

 

Here's the modifications to the emonTX kit, the high voltage circuitry and the cabling. The emonGLCD kit doesn't need modification. The plastic enclosures came from Maplin.

Note, there is a minor error in the schematic below, the IO lines for the red and green LED's should be swapped over.

Sergegsx's picture

Re: Fusion of the MK2 controller with the emonGLCD

Amazing setup !! Congrats !

Thanks for sharing info and pictures.

stuart's picture

Re: Fusion of the MK2 controller with the emonGLCD

I've been working on a similar setup, links over here...

http://openenergymonitor.org/emon/node/1002

 

Sleepwalker's picture

Re: Fusion of the MK2 controller with the emonGLCD

This is really good especially as it uses the existing kit. yet seems to have slipped by the forum un-noticed. I'm running this as my sketch at the moment but without the switching circuit added yet, i'll do that later in the week.

a couple of minor issues, I'm not too keen on the display preferring the layout of the old one, particulary as it had the accumulated readings for the day and the current time. could you not adapt that and add the energy bucket & firing pulses where the min & max temp used to be.

Do you intend including the Emonbase code in the sketch for sending the data over the interweb?

 

Series530's picture

Re: Fusion of the MK2 controller with the emonGLCD

 

Thanks for the positive comments. The thread didn't seem to catch many people's eye and I am pleased that a few people like what I have done.

I'd be happy to add any features that people request if they are possible with the existing hardware. As I already upload usage data using the enviR I haven't really considered integrating a bridge to the web using this system. If there is a way to get date and time using what I have I will be pleased to introduce it. If there isn't and I have to buy an emonbase ii will need to think about it a little bit before taking the plunge. If there is sufficient interest there's a more than reasonable chance that I could  spending more money and getting my soldering iron out again.

Does anybody know of a way to get time and date information with just the TX and GLCD units.

 

nbown's picture

Re: Fusion of the MK2 controller with the emonGLCD

very good work, i see that you can a get an arduino rtc shield from ebay for fiver, it may be worth a look.

Sleepwalker's picture

Re: Fusion of the MK2 controller with the emonGLCD

Hi,

Back again - Circuit made and in place, but without the LEDs. I just need to ask a few simple questions before I commit myself to switch on.

Firstly I'm new to c++ and am finding it strange trying to follow, let alone alter so some of the questions may seem basic.

Where (on the emonTx board) are you picking up your trigger pulse from, looking at the circuit schematic i'm thinking that pin 15 IO9 of the chip goes to SPI/ISP pin 8 for the output. But this is also the onboard LED so what happens to that? 3v3 from pin 1 of the same SPI/ISP

Does it matter if I have a type 1 or type 2 PV installation

Which Channels do you have you CT's Connected to. I'm 1 consumption, 2 PV generation, yours in the photo are 1 & 2 yet you are using 1 & 3 in the sketch or have i got that completely wrong.

As I haven't been running the sketch with the firing cct connected, should I ever see the energy bucket reduce.
It remains at 3600j, the display always shows grid (is this because of line 326) and the red led always on, never green apart from at boot up.

 

Thanks

nbown's picture

Re: Fusion of the MK2 controller with the emonGLCD

My understanding is that you need DIO5 for this setup. I asked Ian the same question only a few days ago.

it's the purple wire close to the AC jack in the above images 

Series530's picture

Re: Fusion of the MK2 controller with the emonGLCD

Sorry, I've been away on another business trip and just noticed your questions:

Where (on the emonTx board) are you picking up your trigger pulse from, looking at the circuit schematic i'm thinking that pin 15 IO9 of the chip goes to SPI/ISP pin 8 for the output. But this is also the onboard LED so what happens to that? 3v3 from pin 1 of the same SPI/ISP

 

It's a little confusing because my code tries to retain compatibility with the hardware that Robin is using. In Robins design he uses a different trigger to mine. If you use DIO5 as Nigel suggested it should work fine.

Does it matter if I have a type 1 or type 2 PV installation

I'm sorry, I don't know the difference between the two. If it's of any help, my system is a 3.5KWp installation using micro inverters. As far as any current transformers are concerned, they simply sit on an AC tail.

Which Channels do you have you CT's Connected to. I'm 1 consumption, 2 PV generation, yours in the photo are 1 & 2 yet you are using 1 & 3 in the sketch or have i got that completely wrong.

Sorry to confuse you again. Initially, I was planning to build an energy monitor which monitored incoming as well as generation data and, in addition, provided the PV dump control. So I purchased two current transformers with this in mind. Having spent many a while conversing with Robin I became concerned that reading three ADC inputs per loop was going to dilute the accuracy of the energy bucket far more than just reading a single voltage and a single current reading. In any case, I have EnviR monitors which can monitor my solar generation. Thus, one of the clamps does nothing and hasn't been coded. You can use which ever input you like. You simply need to re-assign the ADC number in the variables CT1, CT2 and CT3.

As I haven't been running the sketch with the firing cct connected, should I ever see the energy bucket reduce.
It remains at 3600j, the display always shows grid (is this because of line 326) and the red led always on, never green apart from at boot up.

I very much doubt that the energy bucket value will drop because it needs a dump load connected in order for the loop to work. I've seen that when the system is firing and power is being dumped the energy bucket value will drop and hover around 1800 joules. Once you reach a point where the immersion heater has charged the tank fully and no more current is taken by it, the energy bucket will climb to 3600 again.

The unit will always show grid because this is the only measurement that the unit makes. The plan was to monitor the solar generation as I said earlier but, so far at least, I haven't implemented it. Having the enviR, I doubt if I ever will.

The momentary turning on of the lights in sequence in boot up is deliberate. It provides a visual diagnostic as the system monitors anc calibrates each of the sensor inputs.

 

nbown's picture

Re: Fusion of the MK2 controller with the emonGLCD

sleepwalker are up and running?

Series530's picture

Re: Fusion of the MK2 controller with the emonGLCD

I've found a problem with the sketch that I have posted for the emonTX. I'm in the process of fixing it and also addressing some other shortfalls that I have noticed with the calibration.

I plan to have a fixed and, hopefully, improved version very soon.

Ian

 

 

Sleepwalker's picture

Re: Fusion of the MK2 controller with the emonGLCD

Hi, nbown not up and running yet - been out and running instead, weather too good to spend indoors. Might take a look tomorrow

Sleepwalker's picture

Re: Fusion of the MK2 controller with the emonGLCD

Thanks series 530,  I'll take a look again tomorrow.

Type 1 or 2 PV  are shown on this page http://openenergymonitor.org/emon/applications/solarpv but i've since realised  you use neither but just monitor the incoming power.

the rest are just confusion on my part  I thought you were using 2 CT clamps so that you could monitor PV and that green LED's would show excess generation. I'll have to look to add that myself sometime or look to using the energy monitor sketch.

Ta

 

Series530's picture

Re: Fusion of the MK2 controller with the emonGLCD

I thought you were using 2 CT clamps so that you could monitor PV and that green LED's would show excess generation. I'll have to look to add that myself sometime or look to using the energy monitor sketch.

 

I'm working on an addition that allows dual measurement with two clamps. It's functional but I'm not especially happy with the error against my reference monitor at this point in time.

 

nbown's picture

Re: Fusion of the MK2 controller with the emonGLCD

How difficult would it be to add the facility of when the tank is up to temp. (open circuit) to divert to another source such as a heater for example?

Nigel

divad's picture

Re: Fusion of the MK2 controller with the emonGLCD

Hi I am new to this forum. 

I have had my PV system for about 18 months and been looking at ways of monitoring with meaningful displays and using the spare electricity. Upto now none of the systems on the market have done all that I want. Looking at this thread Ian,s system seems to be ideal. I am capable of soldering PCBs etc and understand mains wiring but the electronics and computing that I understand are well out of date.

So the first question is do you think I will be able to build and program these.

My system has a max generation of 3.6 KW, Sunny Boy 4000 Inverter south west facing most productive time in afternoon.

I have an Economy seven Tank with two immersion heaters bottom and 2/3 up and also an indirect loop to gas boiler for topping up. At the moment I use the cheap rate economy seven electricity to heat the tank from the bottom immersion overnight this works without having to top up during the day.

My idea would be to use spare solar on bottom immersion and cheap rate at night on top immersion and if possible do what Nigel is asking divert to a storage heater any spare surplus. Unless people who read this have any other ideas.

My PV system is wired through a spare in my consumer unit making it a type 2 system.

David 

nbown's picture

Re: Fusion of the MK2 controller with the emonGLCD

David,

Firstly welcome to the forum.

Until a few months ago in had not done any programming or soldiering for 20 years, it’s not that difficult, and there is plenty of help here. Loading the software is pretty straight forward.

The route that I have gone down is to buy the emon kit, I bought all 3 units, emontx (that’s the part that sit next to the fuse box and gathers the data) the second is emon GLCD to display the data sent wirelessly and thirdly the emonbase which I have not used to its full.
I have all this up and running as an energy monitor system with no problems. My next step is to use what I’ve got we some mods to divert the energy that I’m exporting to heat my hot water.

Robin’s mk2 controller dose just that very well but, does not use the emon bits. And some people have added a display on top of that. My understanding is that the MK2 works with type 1 or 2 systems.

With Ian’s system this uses the emon kit as the main source of the hardware, which I already have. but you don't need the emonbase. The software is based on the mk2 . I’ve have not got my system up and running yet but I'm very close.

Whichever route you choose to go down you will need to consider.  How to connect to your immersion? Wireless is to slow (but not impossible), you will need a cable. I ran a cat5 cable smaller and easier to route, you can run twin and earth so that you have a separate supply, or if you luckily you got that installed already.

Nigel

divad's picture

Re: Fusion of the MK2 controller with the emonGLCD

Thanks for the quick response Nigel 

I have been sorting out my soldering iron station and tools. (They where resting in the Attic)

Looking at the shop am I best purchasing Solar PV Monitor Kit Bundle 868Mhz (Europe only) UK plug which seems to have all in it to do Ian's system and then purchasing locally CPC the Triac etc after I have got the Emon kit working.

I already have 2 separate 2.5s going to the immersions. 

David

nbown's picture

Re: Fusion of the MK2 controller with the emonGLCD

David,

Looks good don't forget to buy the USB to UART programmer, for uploading Arduino software sketches and reading serial data

 

Series530's picture

Re: Fusion of the MK2 controller with the emonGLCD

Welcome David,

 

although my background is in electronics and control its all to do with low power stuff. Controlling power electronics and programming micro controllers has been alien to me. It isn't difficult though and is well worth the effort. Why spend several hundred pounds on a system that a third party designs and forbids you to customise when you can spend substantially less, learn a lot and still have the ability to adapt as you see fit?

 

Just to give followers of this thread an update: I have fixed the problems that I had with the calibration of my rig and have added a few additional features. I now have a secondary monitor functioning but have yet to successfully calibrate this second channel against my reference. The ultimate plan is to be able to monitor grid and solar power reasonably accurately, display the results on the emonGLCD and control a PV dump at the same time. Testing of what I have so far corrected and improved is in progress.

 

 

Series530's picture

Re: Fusion of the MK2 controller with the emonGLCD

On the issue of the divert, in principle, its quite easy: if the software detects and excess of PV which would ordinarily dump power to the immersion heater but, over a monitoring interval, the energy bucket remained full, it would indicate that the dump load is open circuit. That being the case another IO line could be used to switch a different triac so as to route the power elsewhere and the process would then be repeated.

It isn't something that I'm planning to add to my design because I don't need a secondary source into which to dump power. 

divad's picture

Re: Fusion of the MK2 controller with the emonGLCD

Thanks Ian

I am purchasing the Kit Solar PV Monitor Kit Bundle 868Mhz (Europe only) UK plug along with a USB to UART programmer as Nigel reminded me. CPC is close to where I live so getting the other items shouldn't be difficult but can wait until I have the monitoring system working.

My background has been in Telecoms but always an interest in automating processes so they work in the background without intervention. However it has been a long time since I did any PCB work but am looking forward to doing this project. Your system seems to match all what I want to see to control and display a PV system using all or nearly all of the electricity generated.

   David

calypso_rae's picture

Re: Fusion of the MK2 controller with the emonGLCD

Nigel: How difficult would it be to add the facility of when the tank is up to temp. (open circuit) to divert to another source such as a heater for example?

As posted, my Mk2 circuit diverts power to the dump load whenever the level in the energy accumulator gets to 1800J.  If the thermostat were to open, then the energy level would rapidly rise because there is no longer any load to consume any surplus power. 

A secondary load could easily be included by defining a second threshold (e.g. 2200J)  at which point surplus energy would be sent to the second circuit, via a second trigger and triac.

By this means, the priority of the two loads is maintained.  If some DHW is run off and the primary stat opens, then surplus power will once more be sent in that direction.

Sadly, this is summer talk, it's been several days since we had any hot water worth speaking of :(

Series530's picture

Re: Fusion of the MK2 controller with the emonGLCD

It's been a while since I posted on this topic. I want to assure anyone who is following this topic that work is still on going. A few of us are running trials with a new version of the software and the results are encouraging.

 

i hope to post new sketches for both the emonTX and the emonGLCD in the coming week or so.

If any one else would like to participate in the beta trials, please send me a private message which includes an email address and I will send them the sketches.

 

jeffreyross25's picture

Re: Fusion of the MK2 controller with the emonGLCD

SPAM POST partly dealt with, account blocked. [RW]

PaulOckenden's picture

Re: Fusion of the MK2 controller with the emonGLCD

Grr...

So annoying when you get excited because you're waiting for an update on a topic. You see  a new message - AT LAST. 

 

And then it turns out to be spam.

 

P.

calypso_rae's picture

Re: Fusion of the MK2 controller with the emonGLCD

If you're referring to the message at 12:07, at least someone is paying an intelligent interest in the construction details.  Some maverick postings are a lot less on-topic!

nbown's picture

Re: Fusion of the MK2 controller with the emonGLCD

and the mailing at 13:07

calypso_rae's picture

Re: Fusion of the MK2 controller with the emonGLCD

I think there's a problem with the time-stamping.  My screen shows: 

Submitted by jeffreyross25 on Wed, 14/11/2012 - 12:07.

Submitted by PaulOckenden on Wed, 14/11/2012 - 12:48.

Submitted by calypso_rae on Wed, 14/11/2012 - 13:05.

Submitted by nbown on Wed, 14/11/2012 - 14:16.

The system doesn't deal with time-changes automatically, the +/- 1hr shift has to be entered manually in one's Profile.

 

PaulOckenden's picture

Re: Fusion of the MK2 controller with the emonGLCD

I suspect nbrown's time zone isn't set correctly in his/her profile.

Actually, I reckon probably half of the people here are on the wrong TZ, as the site doesn't have an auto DST. You can probably tell whether people first joined in the summer or winter by checking whether they are an hour out or not! 

P.

nbown's picture

Re: Fusion of the MK2 controller with the emonGLCD

I stand corrected, and have changed my profile settings.

for all those waiting to see something on this tread, i have uploaded my data on to cms. here's the link. it's only basic but you can see when the sun is out and triac is firing.

http://www.emoncms.org/nbown/  it dose not work well in IE, i use Chrome

 

 

Series530's picture

Re: Fusion of the MK2 controller with the emonGLCD

The sketches are still work in progress but, as Nigel has had success with the latest ones and as I know that they work on my rig I'll post up the latest ones.

The area where there is still some issue is in the calibration of the power measurements vs. a known reference. I have published in the sketch some calibration constants (line fits) which bring the measurements into line with what I see on my enviR pulse monitors. They may or may not be suitable for everyone. What I did with mine was to compare what the enviR pulse monitor saw as steady state power under 45 conditions of varying grid load and solar generation (90 in total) with what the emonTX measured. I loaded these values into excel (enviR on X axis and emon on Y) and produced a scatter plot. From there I produced a line fit and have implemented this in my sketch. So, what the emon reads is transformed with a Y=mX+c into something closer to the enviR. The enviR, I know, is pretty accurate based upon previous correlation exercises.

 

On Monday evening I tried cross correlating these curve fits with a wire loop/light bulb measurement technique that many others have used. The results were less than flattering. My line fits against the enviR proved to be much closer than using 7 sets of coiled wire and a 100W light bulb. 

 

I'm not saying that my approach is better. Simply that it gives different results. In many respects the sketches give the wrapper to control the emonTX, transmit the data and for the emonGLCD to display them them.

 

Please feel free to having a try with the latest ones and see how you get on... you may need to play about with the calibration though!

Series530's picture

Re: Fusion of the MK2 controller with the emonGLCD

Some files would be useful ...

Robert Wall's picture

Re: Fusion of the MK2 controller with the emonGLCD

Attention All,

Please make sure you don't reply to a spam post. If anyone does, when I put on my moderator's hat and delete it, all subsequent replies will be deleted too. I can't help that.

Series530's picture

Re: Fusion of the MK2 controller with the emonGLCD

I feel its time to provide the forum with an update. I have been working on these sketches in the background. The issue has been spare time.

I had wanted to include the Elster AC100 read routines in my sketches. Try as I did I failed to get that running. I was able to read the meter successfully but as soon as I added code to detach the interrupt and later re-attach it, the readings no longer came through. In the end, for now at least, I gave up on that idea. So, if you were holding out for that, my sincere apologies but I failed miserably on that score (but I haven't given up hope completely!)

 

So, I would like to offer what I have to the forum again. The code is heavily revised and has a few additional features:

  • It is still a fusion of Robins PV software with and energy monitor and a GLCD display but I have also added remote temperature sensing. The software senses a single input on the emonTX and displays the temperature on the GLCD. It also displays the temperature of the senor on the GCLD as well. It will deal properly with sub zero temperatures and there is space on the display to add additional sensor readings as well. The code doesn't support more than one remote sensor but its pretty easy for people to add additional ones. The software will only read temperature when the energy bucket isn't in operation because the PV dump needs to take priority.
  • I've also added routines so that users can run phase cal sweeps on both the grid and the solar channels. This is especially useful if you have a plug in energy monitor and wish to correlate your unit with this external reference. I have used this approach quite successfully to tune my software and hardware.
  • There is a feature to run the software on the emonTX is simulation mode. It will generate and measure simulation waveforms with variable amplitudes and phase offsets. The default condition gives certain solar and grid channel power values (detailed as comments in the program). These can be changed and the effects monitored using the serial monitor or the GLCD display.
  • I have also totally rewritten the measurement algorithms. They now very closely resemble the algorithms on the OEM site but with the difference being that they work in tandem with Robins PV code. I now get pretty close correlation with plug in energy monitors and with my enviR and Optismart units. The final part of the jig saw was finding that my grid channel CT had a slight airgap and this was causing all end of correlation problems.
  • The GLCD sketch has a visually different interface now. I display the grid and the solar channels on the left hand side of the screen (the grid channel being a larger font). On the right hand side of the screen I display the temperature monitor channels and the state of the energy bucket. I have an additional icon which is a black circle if the house is consuming power from the grid, shows a tank and a heating element if in PV dump mode or is a white circle if the the system is only exporting. Similarly, the LED's are Red, combined red and green together or green if just exporting. They still turn off in low light and pulse each time a packet is received from the emonTX.

A few of us have been playing with these sketches as I have worked on them in the past few weeks. Thanks to you (you know who you are!). 

Feel free to having a play... and I'll put some effort now into understanding why the interrupt detach is screwing up the Elster section of my code.

 

 

Series530's picture

Re: Fusion of the MK2 controller with the emonGLCD

Please also note that there is a minor modification to the schematics -The green LED on the emonTX should connect to IO7 and the red LED to IO6 (and not visa versa as in the original schematics).

 

Series530's picture

Re: Fusion of the MK2 controller with the emonGLCD

Files :

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.