Archived Forum

If the outgoing cables from your consumer unit all go upwards, I wouldn't have a problem with a hardwood (= less likely to catch fire than softwood), plastic or an earthed metal box inside which you split the cable to mount the CT. I'd have it in contact with the top of the CU, so you'd not have to worry about grommets or glands to protect the cables (just one big slot across the bottom!), but where the cables exit upwards you will need to protect against sharp edges (if a metal box). It should be OK as long as you need a tool to get inside - but you should also put a "Live Parts - Isolate at Main Switch below before removing this cover." warning label on the cover.

Bear in mind you need the CT to go around both legs of the ring main.

Ideally, you want to physically segregate the CT secondary cables from the mains wiring, just in case anything cooks and melts the insulation.

On the number of inputs question, you could have an 'off-the-shelf' solution with three emonTXs and a RPi with the RFM12Pi receiver board. But the way you phrase your question, I think you're really talking in terms of a custom front end and one of the more powerful Arduino processors, if you want to monitor "continuously", or a complicated multiplexing solution if you're happy with "discrete samples". The Atmel 328P is pretty much fully loaded doing 4 inputs continuously, though it could handle another one doing discrete samples (but noting 5 currents and one voltage doesn't really help you!).

Hi Robert,

Thank you for the reply.

We don't need continuous - every few seconds or a minute would be fine.

Luckily we caught our electrician in time who put a bigger box in for us instead of a normal Consumer Unit :)

He seems to understand what we want to achieve, so I've ordered the emonpi, together with an emonTX and 3CTs to try out.

Wish us luck :)
 

I'm also thinking about adding emon to my house. Would love to meter all individual circuits, but of the shelf that gets way too expensive.

How would you go about multiplexing the inputs? I'm thinking an external board that has the (or several) multiplexer on it would be the best way to go. But can the Arduino still handle that? Does it still have enough outputs? Is the code 'ready' for multiplexing, or do you need to modify a lot?

What about multiple voltage logging? I'd like to monitor all 3 phases. They should be almost identical, but because I have a 1 phase PV system, I guess they won't.

Multiplexing for all channels is fine for me. I have 16 circuits that I want to monitor, with 4 channels and 1 sec sampling of each sample, that is still plenty of data.

The best way to monitor additional CT clamps is to add extra EmonTX units as required.  EmonTX v3.4 comes ready-assembled and will connect wirelessly to EmonPi.

> How would you go about multiplexing the inputs?

The Arduinos have a multiplexer internally (the 328p in the Uno etc. only has a single ADC which can be connected to the 6 analogue input pins via the internal multiplexer, so can only do an analogue read on one pin at a time).

If you wanted to do all your stuff on a single MCU, then perhaps something like the Teensy 3.1 would be a good choice - it's a (much) faster processor, and has 2 16-bit DACs.  I don't know what the analogue input quality is like, or sampling speed etc., but it might be worth a look.

Otherwise, there's a lot of Arduino-like boards to choose from these days: https://en.wikipedia.org/wiki/List_of_Arduino_boards_and_compatible_systems

Finally, I don't know much of a bottle neck the calculations are, but the emon code uses a lot of float point maths at the moment, and optimising that if possible, may increase the throughput (I think a floating point divide takes >400 clock cycles on an AVR).

"emon code uses a lot of float point maths at the moment"

But there are versions available that use integer maths and are noticeably faster. I think pretty much every microsecond has been squeezed out of the floating point versions, but they are retained since it is a lot easier to appreciate the principles when the sums are 'obvious'.

On the other hand, some of the operations inside the integer maths versions are at best obscure and the reason for their existence only becomes apparent after working through the code a few times.

It's also possible to speed up the code with a minor hardware change! If all the input transducers share a common (probably buffered) bias supply, then it's only necessary to filter one input to determine the bias offset, and the same number can be used for all the inputs, the gain being you remove the low pass filter algorithm from all the inputs except one.

"But there are versions available that use integer maths and are noticeably faster"

OK, that's good to know - I have only looked at the 3 phase + voltage code, and since I knew that was based on the emonlib code, I had assumed it was all floating point...

Sounds like perhaps the integer optimised versions could use a few more comments tho' - always good to use comments to document assumptions in that sort of hairy code!

No, Robin's "continuous" sketches use integer maths in critical places, as does MartinR's PLL sketch.

If you're looking for an arrangement which will allow reading multiple circuits, without custom hardware, then the most cost effective may be to use multiple Arduinos (I used some Leonardo clones in a similar arrangement) each with it's own emonShield.  Try to use a good quality power supply (see other threads - avoid cheap'n'nasty 5v USB 'chargers'), and put them in your own casework.

My analogue electronics knowledge is poor, but I believe you'll end up with a setup similar to an emonTx (it'll lack some over-current protection tho' I think?).

The other big "sin" of the standard sketches is that they use the standard Arduino synchronous  interface to the AtoD.  analogRead(A0) starts a conversion running, and then sits in a busy loop waiting for it to finish so it can return the result.  That's 104 usecs of wasted CPU time right there with every conversion.  Think of all the maths that could be done during that time!

Banging on the ADC registers directly, setting the ADC into continuous mode, and not being afraid to do stuff at ISR level are all features used by the "continuous" sketches,  and by anybody who has been using AVRs outside of the Arduino environment.   That synchronous API offered by the Arduino interface is easy to understand, but really not suitable when performance matters.

Many resist that next step because they fear ISRs.  Even for them it would be very simple to enhance the Arduino synchronous interface to at least split out the initiation of the ADC conversion from the waiting around for the result. You could do that without the need for any interrupts at all.  It would be the ADC equivalent of the non-temporal load instructions found on most modern CPUs.  A start fetching this because I'm going to need it soon approach that lets you get on with other work and only stall when you really need it.  The API could be as simple (and as compatible with the existing one) as something like:

  analogStart(A0);           // initiate a conversion
  while (1) {
    V = analogRead();        // wait for the conversion to complete
    analogStart(A1);         // initiate the next conversion
    // <do maths on V here>
    I = analogRead();        // wait for the conversion to complete
    analogStart(A0);         // initiate the next conversion
    // <do maths on I here>
  }

"The other big "sin" of the standard sketches..."

Is it really a sin? It might be for performance, but as examples of how to calculate electrical power moderately accurately, even those sketches are way too complicated for some novice programmers. Remember that the spread of skills and knowledge, both hardware and software, of the members of this community is just about as wide as it can get. That's not to say we should refrain from pushing the boundaries, as many members have done in the past and hopefully will continue to do.

For continuous metering, highly precise, see EmonLibPro i've been using for past 2 years:

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

dBC: "then sits in a busy loop waiting for it to finish so it can return the result.  That's 104 usecs of wasted CPU time right there with every conversion"

Hmm, that is pretty poor, isn't it.  I knew it was synchronous, but I assumed it put the processor to sleep to minimise noise in the ADC during the conversion.

chaveiro: "For continuous metering, highly precise, see EmonLibPro i've been using for past 2 years"

That looks nice.

[Tim added a further comment that's been moved to http://openenergymonitor.org/emon/node/10867 - RW]

Hi guys,

Thanks for all the comments, and sorry for the delay in replying.

In the end, we bought 1 emonpi, 1 emontx and 3 CT clamps to test with.

We had to get our electrician to add a new junction box and split out all the circuit wiring so that the live wires were separate from the neutral and earth.

We did some tests with them, and they seem to monitor no problem, so we bought 3 more CT clamps to connect to the emontx.

They all seem to work fine, and so I've ordered another emontx and 4 clamps, which should record 10 out of the 12 circuits.

One thing I'm not sure about is how accurate the clamps are. When I first plugged them in, 1 of them was showing 3-5W, even when it wasn't around any power cables.

So far the only problem we've had is that the edimax wifi adapter isn't very stable. It went for weeks without disconnecting, and within 1 week it's disconnected 4 times.

I've been reading some articles about it and its use on the PI, and it could be due to power management kicking in (unplugging the adapter and plugging it back in again fixes it every time). Next time we go to the house I'll try tweaking some kernel module options for it to disable the power management.

I've now got to figure out how the dashboard works, as at the moment, I don't seem to be able to add anything but empty squares where graphs should be!

Once I've got it all sorted, I'll post pictures of the set up if anyone is interested.

Chris

"One thing I'm not sure about is how accurate the clamps are. When I first plugged them in, 1 of them was showing 3-5W, even when it wasn't around any power cables."

The CT's accuracy is specified as ±3% linearity from 10% to 120% of rated current, but most likely what you were seeing was noise pickup from somewhere. 5 W in 24 kW is a pretty small percentage.

@Robert Wall - fair enough. Thanks.

I'm still having problems with the WiFi dropping out.

I've tried 2 kernel parameters to supposedly stop power saving mode, but it's made no difference.

Every time I can fix it by unplugging the USB Edimax dongle, and then plug it back in again :(

At this rate I'm getting rather annoyed and I'm thinking of swapping it for something more reliable.

Does anyone else use other WiFi dongles that are more reliable?

Thanks,

Chris