Archived Forum

Hey, nice work!

I'm definitely interested in this. I especially like the super small size and built-in wifi. I know they're not available till next month, but have you thought about using the Photon?

The photon is what got me thinking about going this route, I already had some jeenodes, but one has a bad radio and I wasn't sure if the range was going to work out. The Photon for $19 and that small form factor is ++good.  

I ordered the Photon Prototype kit.  Comes with a Core now, and a Photon when available. 

Quick update; shipping on parts is slow, but I did get my little 1.3" OLED screen.  Turns out to be something there isn't really a library for, so I am modifying an arduino one to work on the spark, it gave some output last night, but was putting my unit into panic/reboot mode.  

In the meantime I need to start putting together a schematic,  I think I am going to go with (what I assume to be) Robert Walls, Buffered Voltage Bias circuit.  Hopeful it will scale up well.  

I got good data for a few days and it matched up very nicely with what I was seeing in power usage (I get daily usage reports from my power company).  

Nope, it was originally Robin's. What do you mean by "scale up"? - as the input current is barely more than that needed to charge the Sample & Hold capacitor, you ought to be able to hang any (sensible) number of input devices off the op. amp. output.
If you have a lot of inputs, note that when using that, you need only one software low pass filter to extract the dc, because that dc 'sit' is common to all the inputs. It speeds up the input processing but you'll need to customise emonLib to get any benefit.

Scale up means I expect to have 16 inputs,and I hope to avoid having 16 voltage dividers with the use of a single buffered virtual ground.   I have 8 inputs on my arm chip and will add 8 more with a stackable "shield" using probably a MAX11615EEE, but I haven't decided on that yet.  I'll get all 8 inputs working first. 

Whether you get any interaction will depend on the input characteristics of your ADC, but if the input impedance is high, and the capacitance (S&H + stray) is low, then I don't see a problem with 16 inputs using the same buffer op. amp. The demands are not all that onerous: all that's needed for the Atmel 328 is for the output impedance with the feedback in place to be such that the input stays within one ADC step when the multiplexer switches. If you also have a multiplexer in front of a single ADC, it's an identical situation; if you have separate ADCs for each channel, then it's slightly different but the requirement is identical even though the perturbation comes from the combined effect of all the other channels 'pulling' the bias source, rather than just the one channel switching.

Anyone have comments on my first stab at making a PCB (that isn't a point to point proto).

https://github.com/officeboy/EmonCore/tree/master/hardware

Don't leave the unused inputs of the spare op.amp floating. You might as well make it a unity gain follower and tie the + input to VGround. (Now there's a confusing name! Vmid(point) or Vbias? I realise it was called that in the link you referenced earlier, but that isn't its function here, here it is an offset bias, biasing the quiescent input to the midpoint of the ADC input range.)

Thanks, Robert.  I had planed on using a single channel opamp, but the software I started using didn't have one in it's library.  I switched to eagle so that I could use the actual footprint of the 3.5mm jacks I have.

Anyway quick story.  I used to do a lot of audio stuff back about 10-12 years ago.  I was semi active in the DIYaudio forum and made a few chipamps, an aleph-x etc.  So opamps are no big deal... right?  I have dip-8 sockets.   Well I got my digikey order yesterday with my max11516 16-tsop and the lvm321 tc-70.  Holy cow.  What am I supposed to do with these things?  I think I did a decent job considering, but I may need to get some breakout boards for prototyping.  

That 16 pin ADC is going to be impossible, without a proper pad.

"So opamps are no big deal... right?"
I had no idea what your previous experience was, surely it's better to point out what might have been an oversight before you had pcb's made, rather than explaining what an unconnected oscillating op. amp was doing to its other half?

I only meant no big deal in terms of soldering to a proto board.  Selection and implementation are a whole different issue.  And I do/did appreciate the feedback, in audio work generally the extra amps would be used as an input preamp/follower, or differentials from crossover circuits or phase adjusters.  I changed that fritzing schematic, but then scrapped the whole thing and went to eagle.   

Had a chance to put some things together while I was sick today.  

http://imgur.com/a/7ZgRc

 
 
  (with flash)

Main leg CTs are working, but something isn't right with the two sub circuits.  I'll need to review if it is a code issue or a wiring thing.  They worked ok testing on a 60W light, but I should have spent more time on them.

I have 50 ohm burdens on the sct-013,and 32ohm on the sct-019's.

Turns out that the 3.5mm jacks are not making good contact with the stereo plugs that come on the sct-013's. Does anyone know of a specific jack that works OK and is less than a buck a piece?

Dustin,

Here's a 3.5mm Nickel panel mount stereo jack for $0.43

www.bgmicro.com/AUDCA017.aspx

Regards,

Bill

Sorry if this question is not adequate im new here trying to get into the project, but how are you using the graphing in real time? where did you get the code or how did you made it,  to post it in the forum, are you using the emon cms? i would really love to have a graph like that in real time for my home 

It is just the vis part of emoncms.org.

thanks i will check it out,

Nice project! Photon looks like a cool board. How easy was it to develop for? Have you heard any more info on RFM12B / RFM69CW support on the Photon?

It has been pretty easy to build, and the IDE is pretty close to arduino so there isn't much of a learning curve.  I have been pulled away to a few other projects, and haven't touched this in a bit.  The only issue I have is dropping signal.  The photon's external antenna will be a nice feature for cases like mine where the AP is 50+ feet away. 

I know there is a RFM69 library, but that is all I know about it.  

I have a photon on order and will be attempting this when I get it. I had originally ordered it to build a garage door opener, but this seems like a better use of it.

The biggest attraction is the fact that you can remotely load sketches to it and its already connected to the internet. 

If your power panel is in your garage I don't know why you can't do both.  In fact I should do that.  I am not really using any digital outputs, tie one to a relay and wire that in with the button.  Nice idea!  Could open by timer, ITTT, or webaddress (homepage link from phone).

I am already doing temperature, voltage and 3 CTs monitoring and solar diverting. Does the photon have enough of power to do more?

How does the ADC on the photon / core compare to the Arduino Uno?

The photon is a 120Mhz 32-bit ARM cpu (the core is 72Mhz).  I have no idea how that translates over to amount of work possible, but I am open to finding out, if anyone could help with that...  I suppose I could see how many samples are possible in a second?  Wish I could just run TOP, or open Taskmanager...

On the ADC, the core and photon both have 12-bit ADC, with 8 inputs on the core and 9 on the photon.  significantly better than the Uno.  The measurement range is reduced from 5V to 3.3, but there is still 6x the resolution, and some extra inputs.  

The datasheet for the micro used in the Spark Core (https://github.com/spark/core/blob/master/Datasheets/ST_STM32F103CB.pdf (page 75) ) says the total conversion time of the A/D converter is min of 1 µs and max of 18 µs.  And sample rate is from 0.05-1Mhz

The one for the photon (https://github.com/spark/photon/blob/master/datasheets/STM32F205RGY6.pdf  (page 121) ) says up to 6MSPS.  (conversion time 0.5min to 16.4max µs /sample rate is 0.6-30Mhz)

From what I can tell the uno is 125khz, so faster but possibly slower?

From what I can tell the uno is 125khz, so faster but possibly slower?

That's a typical clock rate going into the ADC, but each conversion takes 13 clocks, so the actual conversion rate is 125/13 kHZ  or 9.6 kHZ, or 104 usecs per conversion.   So the ARM based chips do conversions way way faster.  Many of them have 2 or 3 ADCs (Vs that AVR's single ADC), so simultaneous conversions are truly possible, subject to whether or not your board gives you access to the multiple ADCs.

Am still waiting for my photon to arrive. 

Looks like they had a bad batch of power regulators, hopefully shipping near end of the month.    I ordered a core and photon in march and still don't have a photon either.  

It's looking like end Aug before I receive the photon. That's when I get back into this project. 

It works a treat with the Photon. I had things working on a Spark (Particle Core) and was able to do a straight swap for a Photon except for connecting D0 to D3 and 3v3* to Vbatt.

If you are using interrupts to monitor meter flashes or gas meter reed switches then you need to avoid using Photon pin D0 which does not support interrupts.

The phase compensation will not work (at least for the amount of phase shift I have) even at the slowest standard Photon sampling speed so you need to put in a 500 microsecond or so delay in the ADC sampling loop to slow things down a bit.

Finally, both the Spark(Core) and Photon have enough performance spare that you can log the current and voltage waveforms along with the power information. That is quite an eye opener.

The Core and Photon are both capable of uploading data direct to emoncms without other hardware (OK you need a wireless router).

https://community.particle.io/t/open-energy-monitor-port/3166

Gives the history of this project.

The phase compensation will not work (at least for the amount of phase shift I have)

Somebody here:  http://openenergymonitor.org/emon/node/11021 reckons they got it to work on a fast sampling ARM by using a much bigger PHASECAL number (7.5 Vs 1.7).   I'm not sure how their sampling speeds compare with yours, and I'm not familiar enough with PHASECAL to compare their approach with your delay() approach, but hopefully others here might have a view.   

Thanks dBC It is a relief to know that I'm not alone.

The phase correction code is:

phaseShiftedV = lastFilteredV + PHASECAL * (filteredV - lastFilteredV);

so it is interpolatng between the most recent two voltage measurements. Ideally the two voltage measurements should be sampled on either side of the current (I) measurement in which case PHASECAL should be between 0 and 1. A modest extrapolation is safe but a large one changes the amplitude of the waveform.

Putting a delay between samples avoids the need for a large extrapolation. Without the delay the Photon can make a few hundred measurements per cycle and would need a large extrapolation similar to the one you mention. This would increase the measured V amplitude by about 10%. Not huge and it can be fixed with the calibration but I prefer to add the delay.

Might be worth modifying the title of this thread to include the term Particle as well as Spark Core.

This looks to be a really great solution and if I understand correctly it would allow up to 7 CT clips plus a voltage measurement for what should be much less than emonTX for 4 CT clips or the emonPi for only 2 CT clips.

The one thing that does really concern me with using the Particle as the basis for a replacement for the existing two solutions is stability or lack of history of the company producing the Particle boards.

Might be worth modifying the title of this thread to include the term Particle as well as Spark Core.

Done.

"a large [extrapolation] changes the amplitude of the waveform"

Not only that, if you have 'flat-topping' (where both positive and negative crests of the sine wave are flattened, as is common where I live), extrapolation significantly changes the shape of the waveform too.
So a much better way (possibly even better than the delay) would be to save voltage samples and pick out the best two to interpolate between.

If you can, it would be worth dropping 1 cycle's worth of values into a spreadsheet, doing the extrapolation and plotting the resulting wave shape. As you don't have a true sinusoid there, you might not like the result!

Be aware that PHASECAL corrects for three things, phase errors in both the vt and ct, and the time error between readings. Changing the order of readings could help (I before V) but also bear in mind that all 3 variables change - the first two with voltage and current respectively, the third with supply frequency (in electrical degrees, not in time!).

Yes Robert Wall, you are quite right and most perceptive. It would be better to pick the most appropriate pair of V measurements to use for the interpolation and you are also right that the lag between measurements changes due to several variables, mostly unwanted ones and also due to the change in inductive loads that we want to detect so a fixed PHASECAL will never correct perfectly.

I looked at the waveform error with  large extrapolation. I'm near enough sinusoidal that it wouldn't significantly change the calculated power factor - I guess because near zero V vs T is close to linear. I still don't like the large extrapolation idea though.

I thought about adapting to variation in the unwanted effects on the fly (since the ARM based processors would have no problem with processing power) but I don't know how much of my load is inductive at any particular time and much of the time my current has such an awful waveform I wouldn't have a clue where to put my origin.

Consequently I have to make do with a fixed adjustment for lag. If I sample at several hundred measurements per cycle I could use 

phaseShiftedV = filteredV[t-ph] + PHASECAL * (filteredV[t] - filteredV[t-ph]);

where ph is the whole number part of the phase correction and PHASECAL is the fractional part. It would just need a small buffer to store a few measurements. But is this overkill? At that high a sample rate the fractional part is not very important so phaseShiftedV = filteredV[t-ph]; would be good enough.

The alternative is to space the measurements out. It may be a bit less accurate - i.e. only as good as an Arduino ; )   but I don't think the error is significant compared with the demonstrable variation in V and I lag with power. That is why I settled for the minimal re-coding version with quite a large delay added. You still benefit from I and V being measured close to each other (especially if as you suggest you do it in the right order for your system).

I guess the really sophisticated solution would adjust the sample time to have a constant number of samples per cycle but life is too short and mains frequency stable enough. 

Incidentally, the measurement that is most important to me is the exported power as that determines when I can turn on the immersion heater. The current clamp system gives me the import/export sign and I get a completely accurate power figure by meter flash counting. My calibrated current clamp is accurate to a few percent at large loads (imported or exported) but unimpressive at low powers though I use it when the meter flashes are too few and far between. Before I got a curent clamp I used to just use meter flashes and infer import/export by correlating the power changes from the generation and general meters and it was surprisingly reliable, but the current clamp responds more quickly.

Maybe we should design a shield for this chip. It certainly seems like quite a nice device. 

There is a company that produces an Arduino like shield for the Particle Photon, 

https://www.sparkfun.com/products/13321

So maybe that with the emontx shield is a good starting point. But I notice that the hardware on the shield itself has not be updated with the latest emontx changes. So maybe that is step 1. 

I had a spark shield I was working on, but have been sidelined with a major home reno project. 

https://github.com/officeboy/EmonCore/tree/master/hardware

Someone could take that and make the few changes for a photon, and get em made up. (don't use the 3.5mm jacks I did, they are terrible!)

Trying to create a design based on all the improvement suggestions I have spotted. 

How is this as a concept for the Photon?

I've used the following bits. 

1. Allow the photon to be powered by the same 9V ac adaptor. May have to put this into VBat rather than Vin. Design taken from V3.4

2. Buffer the input voltage bias and use the same for the CTs as well, Design taken from Robin. 

3. Protect the inputs. Design taken from dBC. 

"I spotted an error in it"

So have I - in the 9 V transformer dept! But you must do a careful simulation of that half-wave supply, because the component values are critical to ensure correct operation at the current your require at the lowest supply voltage you are likely to encounter, and to verify that the voltage monitor input is not adversely affected by the voltage dip caused by the transformer regulation.

And it will be a lot harder if you want a 5 V d.c. supply - you might have to go to a 12 V transformer to have enough voltage to play with.

Might be best to ditch trying to use the 9V AC for both purposes and switch to using a dual 9V AC transformer and use one part for the AC wave detection and the other part for the 5V regulator via a Bridge rectifier. 

Or use the face that the Photon already has the mini USB with a 3.3V regulator. And stick with using the single 9V AC for the volt detection only. 

It says the Photon needs 80 mA - that's well outside the capacity of the half-wave rectifier with the component values you have. I suggest you use a transformer with two 9 V windings, using one with a full-wave rectifier for power, and the second for voltage monitoring. You will still get some interaction in the form of a dip in the voltage wave before and around the peak as the current pulse charges the smoothing capacitor, but in the full wave rectifier it is half the size of the half-wave pulse - but it happens twice as often.

Might as well use the Photons usb connection and regulator. It will keep the component count down of the additional stuff required.
It does however mean that two power sockets get used to get this running. I.e. one for the usb power adapter and one for the 9v ac adapter.

Anyone know why the voltage divider was changed on the AC sense circuit from 10K+100K in the emontx v2 to the 10K+120K in the emontx v3?

Presumably to give a little more headroom given worst-case tolerances for all the relevant components.

Not that it makes a great deal of difference - the place where you need all the resolution you can get is in the current department. The usual range of the voltage input is the nominal voltage ± 10%. People expect the current to be measured accurately over at least 2 orders of magnitude, and often a lot more (but they are usually disappointed!).

Trying to put together a circuit which has the best suggestions/improvements. So maybe a 10K+120K is the way to go. 

Any other suggestions to get the hardware side as flexible and sorted as possible. The plan was to tie the analogue inputs down to CTs and voltage reading. And expose all the Digital IOs into a terminal block. That way it's the most flexible. 

How is the attached as a starting point?

There is one bit I don't quite understand.

In Buffered Voltage Bias circuit the middle of the 10K+100K junction is fed to the chip as the voltage sense. And the 'mid-point' on the op amp is used for the CT sensors which is also connected to the 10K. 

But in his own MK2 router he uses the the middle of the 10K+100K junction and the 'mid-point' on the op amp for the CT sensors. And the 10K is used into the chip for the voltage sense. 

Why the difference? and which way is better?

"How is the attached as a starting point?"

Something's gone wrong with the current input - you've got the ADC input connected to the bias source and the burden voltage does nothing.
You're missing a few dots where crossing/meeting lines ought to join.

"Why the difference? and which way is better?"

Both present a divided-down voltage to the analogue input. The difference is probably down to either personal preference, the way the ac adapter plug is connected (because the difference is when changing from one to the other, the voltage signal is inverted), or the ease of laying out the pcb.

If you're concerned with the phase of the voltage signal (which could come from compatibility issues), one is right and one is wrong. Otherwise, neither is intrinsically 'better'.

Does the Photon have separate analogue and digital V_CC? If it does, you should pay careful attention to that and include some filtering because of potential noise problems. And you must be careful with earthing/grounding too (i.e. keep the analogue grounds separate from the digital as far as possible, and joint them at one place only).

How's this revision? I'm trying to keep the hardware design as close to the V3.4 as possible, so will stick to using the middle of the 10K+120K as the input into the ADC. 

The Photon doesn't appear to have separate Vcc. Just a single 3.3V output. There are two Grounds but again they are connected on the same Ground plane within the chip. For ease, I will utilise the Left hand for the analogue inputs and the Right hand ground can be reserved for the Digital ones. 

The STM32 processor itself has a separate Vdda pin and the datasheet specifies how to decouple it from Vdd, but that all has to be done right at the pin, so hopefully the Photon designers followed those instructions.  It wouldn't make sense to expose that pin all the way out to Photon pins and expect you to do it.  Unfortunately, the schematic here:  https://docs.particle.io/datasheets/photon-datasheet/#schematic doesn't show you how things are wired inside the P0 module, but either of pins 46 or 47 look like a possible candidate with decoupling on each.

It seems that processor has 3 ADCs each of which can access any of 16 input pins (although only 8 are exposed by your module).  If you're prepared to put the coding effort in, you could potentially get some great results with simultaneous conversions on 3 pins at a time.  Given that, I wonder if it would be worth devoting one of the 8 ADC input pins to measuring the mid-rail (at the cost of being able to measure one less CT).  I'm not sure if anyone has experimented with measuring the DC offset Vs the current method of filtering it away in software.  On the AVR based designs that would be very expensive in terms of precious ADC conversions, but you appear to have the horsepower to at least consider it.

We can always have one analogue input devoted to measuring the mid-rail. My thoughts were 3 full range CTs and 3 high sensitivity CTs, 1 used for the AC measurement, so we still have one spare.

How will I need to wire up the input to don the measurement you are talking about.
Once we get the hardware nailed down we can decide how best to use the available design features within the software.

I think it would be as simple as taking the output of the op-amp and wiring it to A1 (say), and change your CT input section to say "A2-7" instead of "A1-7".   You shouldn't need any protection on that input because there are no external forces to take it beyond the rails.

But I'm having trouble reconciling your footprint with the LMV321 datasheet I found here:  http://www.ti.com/lit/ds/symlink/lmv321-n.pdf.  Is yours 6-pin as shown in your schematic?

I have taken the LMV321 pinout from the page in the Building blocks section. Haven't checked it with the datasheet, just assumed that it was correct.

I see the issue. I used a 6 pin package in my diagram whereas the LVM321 is a 5 pin part. Will change that.
But my pin numbers are correct, just the package representation is wrong.

I haven't found the part needed that gives me a 5 pin op amp symbol yet, so ignore that. 

But I've made the changes to feed the output of the op amp into the ADC A1. Are we sure we don't want to protect this input like we are doing the others. 

"Are we sure we don't want to protect this input like we are doing the others."

Q. What are you protecting against?
A. The input voltage going beyond the power rails, i.e. less than 0 V or greater than 3.3 V.

Q. (To you) How can it do that when it is the midpoint of those two rails?

dBC: In Robin's Mk2 diverter, he uses the op.amp buffer and the low pass filter on one input only to extract the offset, then subtracts the same offset from that and the remaining 2 inputs, the objective being to economise on processor cycles. If Bruce wants, he can do the same (and keep all 8 ADC inputs available) or he can take your suggestion and simply subtract that channel from each of the others to remove the offset. But a caveat: if different ADCs are used for different channels, a small offset may remain due to errors within the ADCs. The Atmel processor has only one ADC, so any differences between channels is down to the multiplexer only.

I officeboy, i invite you to take a look at this lib : http://openenergymonitor.org/emon/node/2406

In particular read this app note for general energy metering information: http://www.atmel.com/Images/Atmel-2566-Single-Phase-Power-Energy-Meter-w...

A reliable solution is lacking for 3 phase metering. With this hardware capabilities i thing you should focus on it.

I'm trying to nail down the hardware side as much as possible using all the best suggestions. Once that is done and I have a sample batch of boards ready, I can distribute those, at cost, to anyone who wants one. Then collectively we can work on using the capability of a web connected microprocessor.
So if there is anything in the hardware design that is lacking for 3 phase metering then shout and I'll add it in.
My thoughts behind the 3 high range inputs and 3 high sensitivity inputs was to cater for a 3 phase implementation too. But always open to suggestions.

If you want to do accurate 3-phase metering, then 3 voltage inputs are essential. One voltage input can only be accurate for that phase, everything else is an assumption based on the phases being balanced.

So maybe 3 phase accuracy is a dream. Because no one is going to have 3 ac adapters plugged into this. Having a 5v usb and a 9v ac block is seen as excessive enough.

So any other suggestions? To improve on the hardware and utilise what we have on offer within the Photon.

How many milliamps will that 9V input/regulator be able to provide before the AC wave is too distorted? 

If you want to do accurate 3-phase metering, then 3 voltage inputs are essential.

I'll second that.  In some spot checks I've done in Aus and NZ, it's common to see more than 10V difference between the phases, and which phase is hottest varies throughout the day so you can't calibrate it away.

"How many milliamps will that 9V input/regulator be able to provide before the AC wave is too distorted? "

I have no idea. It depends on what you mean by "too distorted" and of course on the parameters of the adapter/transformer that you're using. If I remember correctly, I decided that about ½% reduction in the rms voltage due to the dip was the limit of acceptability. You might think that's excessively cautious, but I based it on claims by some users that with care, they had calibrated their emonTx to read within 1% of their supplier's tariff meter. Probably the only realistic way to determine what you can get away with is to measure the transformer, then build an accurate Spice model of the transformer, rectifier, smoothing and regulator, and then apply varying loads and keep checking the distortion.

There's a picture of what happens in this thread: http://openenergymonitor.org/emon/node/10715#comment-30427

I actually designed the circuit from the other direction: The required current was defined, so I chose the components (for the emonTx V3.2) to give the minimum dip whilst still able to just operate at minimum supply voltage.

Are we still trying to get this powered and voltage measured using the 9V supply. I thought we felt the power required by the Photon and all the other associated components was pushing that too far. Hence sticking with using the 5V usb and a 9v ac separate.

I think I'll start a new thread to let people comment on the design, not least because it's using the Photon instead of the Core.