Archived Forum

I had to alter the PLL code as it seemed to be over correcting, leading to stability issues.

I think that was to be expected. Martin's code uses the voltage at the crossing point as the correction to the loop frequency, so the loop gain depends on the slope of the voltage waveform at that point. If both the voltage amplitude is higher and the frequency is higher, the slope will be steeper and the loop gain will have increased with both these factor contributing. But I'm a little surprised you found it necessary to reduce it to as low as a third to allow it to stabilise and lock.

The sign of the power readings is simply a matter of convention and the phase of your c.t's in relation to the voltage, so not a major problem. The value is a problem. My first concern is the c.t's are only rated for 0.333 V (rms) output. What value is your burden and what is your full-scale current? One thing is sure (and probably the reason for all the noise), if you are running with 0.333 V rms out of the c.t. and with a 3.3 V analogue reference, you are only using a little more than a quarter of the available ADC range at maximum current (effectively, you have an 8-bit ADC rather than a 10-bit one).
But having said all that, it doesn't explain why the non-PLL standard sketch gives good results and this doesn't - neither can I see the silly mistake.
You said the current values are "reading exceedingly high", but how high, as a multiple of what they should be? That might be a good clue.

Just so that it's clear in my mind: The voltage you are measuring is one leg (120 V), the 200 A c.t's are CT1 & CT2 and are on the two lines and facing opposite directions (such that both see the current drawn by a 240 V load, but only one sees the current drawn by a 120 V load). The PV is CT3. The total grid power is power1 + power2.

Robert,

Thanks for your looking over the code and all of your assistance over the past few weeks. Your assessment of the power / solar setup is correct with the exception that the CTs are not 200 A rated, but instead setup with a burden to max the EmonTx at about 75 A (rms), which is the limit on the main breaker. More details on that below.

In digging in the PLL timing adjustment algorithm I had seen how the voltage is used to correct the time. This makes sense as at the crossing points, the slope of the sine wave is 1, leading to y=x or conversely, x=y. So your offset from zero in your voltage is equivalent to your timing adjustment you want to make (assuming you properly scale both). I did not see where any scaling was done, just using the raw voltage value. In terms of scaling it, I did not spend a lot of time optimizing that divider, instead, found that 1/2 to 1/3 seemed to work while 3/4 or so did not work consistently.

In terms of the CTs, I did not purchase the Magnelab CTs with a built in burden resistor, so I am not at the 0.333V AC signal the web page indicates. The SCT-075-000 part number refers to the first one listed on the web page, with no burden and zener protection diodes. I felt that this would most closely match the standard CT in design. I then used the guidance under the Building Blocks section of the site to choose the correct burden resistor size based on the number of turns in the CT (7356:1 for the Magnelab CT) and the max current I expected (resulting in a burden of about 100 Ohms). I also changed the SCT-013-000 burden to about 47 Ohms to match closer to the 50A (rms) peak my PV outputs. All my testing with the standard sketch seems to indicate that these are right where they were planned to be. To calibrate them under the standard sketch I had all the kids turn on every device in the house until I felt the breaker might trip (they had a lot of fun with that!). I averaged the standard sketch reported power over about 1 minute in this mode and compared that to the average reported by my Fluke meter to adjust the parameters. For the PV output CT I did the same during the peak of a bright summer day. They now read within 2% or so when I check again.

The values I got from Martin's code were erratic, about 10X higher than expected, and jumping both positive and negative. I would have thought it could be corrected by calibration but it was too erratic to even understand the data. I am including a screen shot of the Emoncms multigraph of the consumed and generated power. The large crazy center section running for most of July 23rd is when I let the Martin code just run. The time before and after that is my normal power usage / generation, with the highest peaks at about 8 kW. My best guess is that possibly the phase correction settings, which I did not alter, are setup for 50 Hz, but I was not sure being that far off on phase would give such erratic results. Instead it would simply skew the calculated power due to the I/V waves being shifted in code out of their actual phase.

Any suggestions would be appreciated. Thanks for everyone's work on this entire project up to here. I have immensely enjoyed getting this up and running and doing the testing. I hope to be able to contribute some good benchmark data on the code to the community.

Dan

I think you misunderstood what I was getting at with the c.t's (which was are you running them within their VA rating), but as the calibration was close the theoretical value, they are probably OK. (The 0.333 V output DOES matter - at maximum current it defines their rating.)

I think you should try to correct the phase calibration - I agree I don't think it ought to make much difference, but it needs to be right eventually, so let's rule it out now. You should be able to calculate them (= * 1.25) knowing your new sample period; which being slower than Martins actually makes this worse - the other option might be to push the sample rate back up to closer to Martin's 50 * 50 * 3 = 7500 from your 25 * 60 * 4 = 6000, at say 30 samples per cycle

Those values are nothing to do with calibration, there's something not happening right in the program flow - or an overflow in the maths? You do have a stable voltage reported? Do you see the same erratic values on the serial output? (If yes, that rules out the RFM12B link.)

Yes, I did misunderstand about the CTs and I am not 100% sure I still understand. If I interpret what you are saying correctly, the concern is driving the CT to a higher voltage (~ 1.6 V instead of the 0.333V it was designed to run at) by using a higher burden resister than what a normal one would ship with, correct? I figured since this product line shipped with burden resistors scaled for up to 200 A, running it a 75 A would not drive the core into saturation, but apparently that is not the only concern, correct? So, the way to determine that would be:

Normal peak operation in their 200A model supplied with a burden resistor
200A X 1:7356 = 0.0272 A in the secondary winding
0.333V X 0.0272A = 0.009 VA - under normal conditions

My peak operation using an external 100 Ohm burden resistor
75A X 1:7356 = 0.0102A in secondary winding
100 Ohms X 0.0102A = 1.02V across resistor
0.0102A X 1.02V = 0.01 VA - about 10% difference

Did I do that correctly? In any case I agree that so far my numbers in the standard sketch match up with the power meter, so I feel that the CTs are doing their job. I will work on correcting the phase algorithm tonight. In terms of checking the RF, I believe I did hook up to the serial port and look at the data stream when the CTs were connected, but I can't be positive on that. In general when I load a new sketch on the EmonTx upstairs, I run it on the AC adapter there to verify it at least runs, then take it downstairs to the basement with a laptop that can read the serial stream to verify it is working on the CTs before looking at the data on Emoncms, but I have loaded and reloaded so many sketches this past week doing testing, I can't recall every time. All the other data is flowing over the RF connection just fine so I don't think there is a transmission error, but I will verify that.

Thanks for your help and I will return when I have more to share.

Dan

Did I do that correctly? Driving the core into saturation and the side-effects thereof are the concerns, but otherwise that's pretty much all correct!

Basically, a c.t is exactly the same as any other transformer except it is the 'wrong way round' - the primary has few turns (usually 1) and the secondary has many. So in very general terms, if you think of how an ordinary voltage transformer behaves and exchange voltage and current, you've got it. A c.t. is a constant current device, not a constant voltage one. Thus you overload a c.t. by open-circuiting it and then you get a huge voltage out, and no-load is when it is short-circuited and then you get no voltage out. It still has a maximum power output just like a voltage transformer, but that's at its rated current.

If you have a low secondary voltage, high current transformer (e.g. like the one I use for testing c.t's: 6.3 V 8 A), it should be possible to throw together a test rig that you could use 'upstairs' - with multiple turns through the c.t (s) to multiply the current and a car headlight bulb as a load. It might be worth the trouble. See the report in Building Blocks for the gory details.

Dan,

I just quickly tried your code using a signal generator for the 60Hz supply. Initially I had some jitter on the final sample but that appeared to be due to you using floating point arithmetic when updating the PLL.

I removed the timerCount-=(int)newV/3.1; and put it back to timerCount-=newV; and it removes the jitter and locks fine for me so I'm not sure why it didn't work for you.

You have lots of free time between samples so you could probably update the samples per cycle as Robert suggested.

The reason following line doesn't work is because you are converting to an integer (max 32768) and then multiplying by 16000000..

//#define TIMERTOP (int)((1/SUPPLY_FREQUENCY)/NUMSAMPLES)*16000000 // terminal count for PLL timer

I only had a quick look but it appears that you don't calculate cycleP3 anywhere but you use it to create totalP3

-martin

Martin / Robert,

Thank you for your assistance. I should have replied to your posts days ago, but I got excited by the information and went to work on it instead of returning to thank you. I saw the errors I had left in the code. In trying to change your 2 CT code to a 3 CT code I missed all of the places that the calculations occur. I am embarrased I didn't catch them before posting to the forums for assistance. In any case, I made some corrections but could not get the 3 CT code to work. I ended up starting back at your original code and making as few changes as needed to get it working on the 60 Hz / 120 V system using only 2 CTs. At that point it did lock on the 60 Hz frequency without changing the PLL equation. I ran it for a day and saw that although CT1 was reading accurately, CT2 was off by about 20%, which I then determined was due to the phase shifting calculations. I determined the changes that were needed there and am running a benchmark now. When I finish the benchmark I will share my results with everyone. Thanks again for your assistance.

Dan

Dan has posted an update at http://openenergymonitor.org/emon/node/2679