Archived Forum

It's on my "To Do" list....

There's a screw terminal block with GND, 3.3 V and Dig 2, Dig 5 and Dig 19 available, also Dig 9 as a hole waiting for a terminal block, adjacent. It's just a matter of deciding which is the best choice and proving it. Depending on the current required by the opto-trigger, it might be necessary to change to the low-current version that Martin Roberts used, as current is in short supply when the ac adapter is used as the power source.

[Do I detect the sound of a trumpet?  ;-)  ]

Thanks Robert, I've just taken an order for a 'complete' system without its main board on the basis that an emonTx V3 will be OK for controlling the output stage.  I have no doubt that a suitable inter-connection method will soon be devised for this purpose :)

Hmmm, sounds more like an avalanche to me ...  

I plan to work on the new next revision to V3 soon, let me know if you have any recommendations or ideas which would make it easier for mkii operation. I'm thinking about moving to an rj45 connection solution for temperature sensors and possible aux digital,  similar to  emonpi prototype, see thread

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

The hardware difference between Martin's and Robin's is Martin used the high sensitivity opto-trigger and an active-high output, whereas Robin used the "standard" one, but had to use the active-low connection as there is less voltage available in active-high and it was impossible to get a standard resistor that met all worst-case conditions.

What timescale do you have in mind, Glyn?

The information at http://openenergymonitor.org/emon/pvdiversion/pll/hardware shows that the more sensitive MOC 3063 is indeed a pin-for-pin replacement for the standard MOC 3041 trigger device that I have always used. 

The sense of the control signal can be changed very easily in the code.  The order of the 'on' and 'off' states in the triacStates enum definition just needs to be reversed.

With these changes in place, it would seem entirely possible to use an AC-powered emonTx V3 in conjunction with a standard output board that I can supply.  The value of the series resistor may need to be changed, its normal value being 120R.

Rather that using an LED to show when the control signal is 'on', my preference is to use a neon which is connected to the switched 240 V AC output.  This will illuminate whenever the output stage is 'on', but it will also light up if an override (aka "constant") switch is fitted and turned on.  This is the arrangement which is shown in the wiring diagram for use with my new Mk2 Router hardware.

I hope anybody using your output board with an emonTx V2 has changed the output series resistor. 120 Ω is OK for a 5 V Arduino, but it needs to be reduced to 75 Ω to guarantee operation under worst-case conditions at the 3.3 V that the emonTx runs at.

Here's how to calculate the resistor:

The MOC3063 requires a minimum current of 5 mA @ 20 °C, 5.5 mA @ 0 °C, and it can take no more than 60 mA.

The minimum supply voltage @ 3.3 V from the ac input regulator is 3.227 V (-(2% + say 0.2% for load regulation), the maximum is 3.366 V.

The ATMega328P output high voltage is Vcc - 0.7 V when sourcing 10 mA, the output low voltage when sinking 10 mA is 0.6 V.

The MOC3063 drops a maximum 1.2 V approx at 5.5 mA and 0 °C, falling to about 1.16 V @ 25 °C.

We require a minimum current of 5.5 mA, the available voltage worst-case (active high) is 3.227 V - 0.7 V - 1.2 V = 1.327 V. This gives resistor value of 241 Ω. Less 1% for the resistor tolerance gives 239 Ω. We need a lower value so that we have more current than the absolute minimum, so a standard value of 220 Ω is reasonable, Checking now with the lowest resistor and highest voltage, the current works out to be (3.366 - 0.6 - 1.16 V - allowing for a slightly lower drop in the output driver as the current is less than 10 mA) / (220 - 1% Ω) = 7.37 mA. That is well within the limit of the processor and the trigger, so a 220 Ω resistor is fine. For the active-low case, the maximum current will be 7.83 mA, so either configuration can be used.

The maximum additional load for the emonTx V3 using the ac adapter as a power supply, and after allowing for one temperature sensor, is 9.4 mA. Therefore it can be used to drive your (Robin's) output board provided the MOC3036 and a 220 Ω resistor are substituted.

You should not use a resistor less than 180 Ω, as at maximum voltage that is getting close to the maximum current at which the ac adapter power supply fails to regulate properly. Neither should anyone use the original MOC 3041 and the 120 Ω / 75 Ω resistor as the current drawn (the minimum it requires is 15 mA) is far too high to be supplied by the ac adapter, and a 5 V USB power supply would be required.

RW: I hope anybody using your output board with an emonTx V2 has changed the output series resistor.

As calculated by your good self, Robert, the original schematic diagram for my Mk2 PV Router had a 180R series resistor for the input side of the trigger.  That was when the controlling device was an Arduino Uno, which runs at 5V.  When I started to use the (3.3V) emonTx V2, I reduced this resistor's value to 120R and have never seen any problems. 

When I re-drew the output circuit for use with my new main board, which also runs at 3.3V, I specified that same value of 120R for the series resistor.   Under normal conditions this will provide just over the maximum current of 15mA that the device should ever require. 

To cater for worst case conditions, maybe I should be using a lower valued resistor as you've suggested.  The voltage drop across the trigger is never more than 1.1V, so a series resistor of 100R in a 3.3V system would result in a similar current flow as does a 180R resistor in a 5V system.  But only if the PSU can supply the extra load.

"I reduced this resistor's value to 120R and have never seen any problems."

Luck is on your side, then! So far...

The data sheet says it needs a maximum of 15 mA to guarantee to trigger, there's no "typical" and no "minimum" stated. The 120 Ω gives only 11 mA worst-case, but it gets better as the trigger heats up and its forward drop decreases. Even if every one made so far has worked, unless you design for worst case, there's no guarantee that at some point you won't get one that doesn't.

Thanks Robert,

My recommended value for this component may soon be reduced on this basis.

I think the way the data sheet phrases it is not good. It is:

That's written as the maximum current needed to trigger the output, but I interpret it to mean the minimum current that is guaranteed to trigger the output. At the top of the page it quotes 60 mA as the absolute maximum forward current. Obviously, you are giving it a lower current that happens to work satisfactorily.

I used a V3 EmonTX for my diverter, because I didn't read the forums carefully enough and assumed that it would work with no issues. I wanted to use the RF module to switch a second load, unfortunately the Arduino pins used are completely different, so that was a lost cause!

However, some head scratching and circuit diagram perusing led me to try using the Digi 5 pin for the main output and the ADC5 pin for the second output. A bit of modification to the sketch and it's been working reliably for about 6 weeks.I used 82 ohm series resistors to the 3.3V supply.

The pin configuration was changed.

const byte surplusPV_LED = 6;  
const byte physicalLoad_0_pin = 2;
const byte physicalLoad_1_pin = 5;

// analogue input pins:
const byte voltageSensorPin = 0;
const byte currentSensorPin = 2;

The second current sensor was used because there seemed to be some interaction between current and voltage sensing if input one was used. Unfortunately I can't remember the details.

I ignored the switches and over/underflow LEDs.

Robert: thanks for your interpretation of the MOC3041 datasheet.  I must try sending 60mA through one of these trigger chips for a day or three to see if anything bad happens to it.  If not, then it probably would be sensible to reduce the value of the series resistor that I'm using.

billt: As you're running this circuit with a series resistor of 82R, and the trigger has not complained, it looks as if the reduced value would be fine for my needs.  Does your V3 emonTx V3 have a separate DC supply?

With the Mk2i Router code, I did go rather overboard on the LEDs.  The novelty has long since worn off, a single neon provides all the feedback I need.  If a second load were in operation, some visible indication of this status would make good sense.

I wouldn't anticipate any difficulty using RF to control an additional load with an emonTx V3.  Isn't the RF setup all dealt with by standard library calls?  Maybe I've misunderstood something.

"I must try sending 60mA through one of these trigger chips for a day or three to see if anything bad happens to it."

Don't try it sourcing it from an Atmel 328P - the absolute maximum current on one pin is 40 mA. If you use something else (a car battery? ! ! !), you'll probably find the package gets hot and it expires, my guess is the emitter (IR LED) will go short-circuit. Beware, the package might just shatter due to local thermal expansion.

Beware, the package might just shatter due to local thermal expansion.

Hey, this sounds like a fun experiment!

(but thanks again, Robert, for the heads up)

I wouldn't anticipate any difficulty using RF to control an additional load with an emonTx V3.  Isn't the RF setup all dealt with by standard library calls?  Maybe I've misunderstood something.

It's probably me who isn't understanding, as I just muddle along finding just enough information to get things done, rather than understanding them thoroughly!

When I was trying to map the output pins I noticed that some of the V3 pins that were available for use were, apparently, used for RFM communication in your sketch.

The V3 uses

Digital 3 - RFM IRQ

Digital 4 - RFM SEL

Digital 11 - RFM SDI

Digital 12 - RFM SDO

Digital 13 - RFM SCK

Your sketch seems to use

Dig 2 - RFM IRQ

Dig 10 - RFM SEL

Dig 11 - RFM SDI

Dig 12 - RFM SDO

Dig 13 - RFM CLK

Looking at it now, it's only the IRQ and SEL that differ, but presumably those are needed to communicate with the RFM12; but maybe they aren't and it would have worked.

It didn't look promising, and as wires are more reliable than RF, I used a hard wired solution.

The pins that I've always used for the RF are just as per the V2 emonTx, i.e. digital pins 2 and 10 - 13.  This means that the standard functions in the Jeelib libary can be used.  

As the pin allocation has been changed for the V3, that presumably means that different library functions must be used, or some pin translation must be included in the sketch.  Hopefully, someone will be able to clarify this ;)

You must NOT use the old JeeLib library with the emonTx V3 - it goes into a reset loop from which there is no escape without a fully-fledged programmer. You must to use RFu_JeeLib. Probably the best solution is to take an example emonTx V3 sketch and graft Robins code into it, using the V3 pin definitions.

And no, I haven't converted any of Robin's sketches.

Presumably that only happens if you use the RFM12.

The sketch that PV_Router sketch that I modified still has

#include <JeeLib.h>

in it, and it hasn't crashed yet!

Ignorance is bliss.

Glyn hasn't specified in detail the changes he made to JeeLib to turn it into RFu_JeeLib, so I am in the process of comparing the two. When I've done that, I'll understand the situation a bit better.

On a slightly different note, I have been using an emonTx v3 with Martin's PLL code to control a SSR to switch my immersion heater. This has been working well for several months now. I have added another DS18B20, so I now have 2 termperature sensors (top and bottom of cylinder).

I use a separate 5V supply to the emonTx v3 and have updated the sketch to handle both temperature sensors and also cut off diversion once the maximum temperature has been reached.

I have so much data coming out to play with on emoncms, it's great fun to see how it all works together I have several projects in the pipeline for additional ways to heater my 300l cylinder, as an immersion heater doesn't seem the best way (a huge amount of stratification).

It's great reading the experiences people are having doing this.

Will anyone be concerned when smart meters are installed? Will we be losing out on exported earnings?

I am assured that you do not have to accept a smart meter. You have let the supply company replace the meter - but it doesn't have to be smart. So you can avoid letting the company know your exports.

Has anyone got this working? Can someone point me at where to download the right code from and how to connect the emonTX V3 to a Mk2 PV router. I would like to use one of the jacks and have a cable between the two units.

Have you read "Choosing an Energy Diverter"?

No - but I am reading it now. Many thanks.

I currently have an emonTx installed and successfully monitoring via 3 CTs. Can I use it to also control an output stage Mk2 PV router at the same time?  

Ketan

Hi Ketan

MartinR's PLL sketch was originally written for the emonTx v2 and 2CT's but has been used many times on the emonTx v2 with 3CT's, it has also been ported to the EmonTx v3, but I'm unaware of any confirmed use of a v3 and 3 CT's, yet !

I use a modified 3CT PLL sketch on a v2 and the pin arrangements for a v3 are currently being discussed on http://openenergymonitor.org/emon/node/5714. See Choosing an energy diverter for more info on hooking up to a "switch" including the Mk2 output hardware. 

i can see no reason why the 3CT version cannot be remapped for the v3 too.

Paul

But MartinR's PLL is NOT  Robin's MkII PV Router! The software is quite different, although both achieve the same result.

I currently have an emonTx installed and successfully monitoring via 3 CTs. Can I use it to also control an output stage Mk2 PV router at the same time?

The answer to this question has to be "yes", but the code may not yet be in existence ...

My Mk2i Rev6 code provides datalogging via RF and also diverts surplus power.  A second CT is used to monitor the amount of surplus power, and it should not be difficult to add a third CT if needed.  This code has been written for the emonTx V2, but it would not be difficult to change the IO connections for the V3.

Another option would be to add the diversion logic into one of the "continuous monitoring"  sketches that have been posted on Github.  Those are already set up to monitor power continuously using the emonTx V3. 

Thanks all very much for you suggestions.  I'll have a crack at modifying the Mk2i Rev6 code (I'm currently using the 'continuous monitoring' code in the sensor and an Arduino + RF and 2 line LCD for display).

I wondered if by running the emonTxv3 with a dual purpose, the performance of monitoring or PV routing (or both) would be impaired compared to dedicated units?  Am I asking the CPU to do too much?

Thanks again

Ketan

Good.  I've not heard of anyone using my Mk2i Rev6 code yet.  A similar sketch is available on the Downloads page of my website but with different IO pins to match the alternative hardware that I have developed.  That sketch is called Mk2_RFdatalog_2.ino

Providing that floating-point calculations and serial statements are are used sparingly, the processor should have no trouble doing all that you require.  It's occupancy should be no more than around 65%.

My Mk2 code requires the ADC's sampling process to be continuous.  You may need to check that  this process is not upset by any addressing logic for your 2-line LCD.   The Mk2 sketches on my website can all drive a simple persistence-based 4-digit display.  Despite needing to be refreshed every few milliseconds, that process is very fast and does not have any effect on the sampling process. 

That's great.  Many thanks once again.

Finally got round to converting the code from here http://openenergymonitor.org/emon/pvdiversion/pll to work with emonTx V3. Code read three CT and temperature. Had a little problem with temperature but now all resolved.

Happy to share to code but don't know where to share it. The code can be conditionally changed from V3 to V2 but has not been tested on a V2.

[Two very similar posts deleted. Moderator (RW)]

Martin's sketch was, if you read the description, written for the emonTx V2, so it is asking for trouble to convert it back. Section 10 of the article does in fact list the changes that are necessary. If you needed to change anything not listed there, can you let me know? If you want to make the code freely available, attach the file to your post.

Attached is the code. Issue I had with the temperature sensor is that it needs to be powered on the V3 which I assume is not a requirement for the V2.

Reformatted and refactored the code. Added opening and closing braces on single line 'if' statements as this is not best practise - white space makes improves the readability of code and does not sacrifice performance. The code could be refactored more for example the code for CT1 to CT3 could be table driven. This would then be easier to maintain - but something for another day.

Unit tests would be good but as I am new to the Arduino I have not investigate how to mock input and output for test purposes. TDD is a better approach than code and it and see.

Great project and lots of good advice and support on the site. 

I see you're not doing anything with the 4th current input. Was this due to processor loading constraints, even though you are down to 32 samples per cycle, or simply because you didn't need it?
The temperature sensor problem is indeed that it is permanently powered in the V2 - that is covered in the table and the note in Part 10.

I am not using the 4th current input as I have no reason to just yet. I do want to use it compare calculated diverted power versus measured diverted power. For this I will need to purchase a new CT.

No profiling done - I don't know how to profile Arduino code. 32 samples per cycle comes from the original code. I will investigate when I have time.

Note in part 10 was overlooked by me. Rather see it in code than notes. Doxgen helps to produce documentation from code and should be able to get this working on .ino files. The truth is always in the code. Notes and code, if not maintained, grow apart and are often missed.

32 samples per cycles comes from picking the code up for 60Hz. I didn't expect the 50/60Hz change to require anything more than change to SUPPLY_FREQUENCY. Probably better to group the constants that rely on the frequency together and again make these condition.

Likewise I have similar concerns over 120/240 volts. The 120 code still has references to 240. 

divertedPower = divertedPower*(Vrms / 240)*(Vrms / 240); // correct power for actual voltage

Why the 240? I would guess (and this is a guess) for 120 setup this calculation should use 120 and Vrms will be close to 120. I have tried calibrating my setup so Vrms is close to the actual voltage I am measuring with a meter. I still need to calibrate all the CTs as my power usage (CT3) does not equal power consumed(CT1) + PV produced (C2). CT3 - (CT1 +C2) is about 40W. I am sure with calibration I can do better. 

I need to understand the code more. The ISR code is unclear to me as are the low level details of which register is doing what.

More time studying the code is required.

I think it would be advantageous to maintain a roughly constant sample rate for the two supply frequencies, as this would tend to maintain the timing between voltage and current samples and hence the phase error correction would change less (and probably be smaller at the lower mains frequency).

Many of your complaints about the code I think stem from the fact that it has had a number of contributors since MartinR's original was published, and as they say, there's a tendency for "Many cooks [to] spoil the broth".

I presume you understand why "divertedPower" isn't necessarily what it says. And believe it or not, a lot of people don't read comments in the code either.

I would phase my comments as observations rather than complaints. In the line of work I do we have code reviews and code guidelines. Code guidelines may exist on this project and I may have failed find them and honor the coding standards.

I prefer to be evidence led. "I think it would be advantageous..." should have some solid evidence to support this claim. If we cannot test it how do we know it is doing what we expect?

I think I understand what is meant by "divertedPower" which is why I am to measure what really is being diverted rather than calculated. I would expect to see a significant variation.

Even if you do manage to keep your "internal" phase errors the same at 50 and 60 Hz, the CT induced phase error will vary with line frequency, at least on the ones I've tested.   I've just re-tested one of my 20A->333mV CTs at 2A (so 1/10th of its nominal max current) and the phase error was 1.68° at 50Hz and 1.27° at 60Hz.

I calibrate my precision front-end at 50 and 60Hz, and then choose the correct calibration coefficients at runtime, based on the actual line frequency observed.

"...then choose the correct calibration coefficients at runtime, based on the actual line frequency observed."
Because of the many different variables that affect this, especially if you have the "standard" set-up, that's probably the only realistic way of doing it - and even then it will only be accurate under those specific conditions (but hopefully 'near enough' the rest of the time).