Sol-ark 12K output frequency off by .1Hz

My Sol-Ark 12k output frequency appears to be about 60.1Hz. While this might not seem like much of an error, in practice it means my clocks gain 1-2 minutes a day. Is there any way to adjust the frequency? I'm not seeing anything in the manual.

Llaves said:

My Sol-Ark 12k output frequency appears to be about 60.1Hz. While this might not seem like much of an error, in practice it means my clocks gain 1-2 minutes a day. Is there any way to adjust the frequency? I'm not seeing anything in the manual.

Click to expand...

I have seen mine Spike for a second to 60.1 but never consistently.

Not sure if any user settings that will address that.

Might want to give Sol-Ark a call.

Mine is slightly high- I gain a minute every three or four days if not connected to the grid. Please let us know if you find out anything.

I'll share whatever I hear from Sol-Ark when I hear back from them.

0.1 Hz is a lot of error on 60 Hz. That is like 1667 part per million. It would screw up SolArk's ability to meet UL1741 specification for grid limit testing and any frequency shifting to back down any AC coupled GT inverters.

A cheap 8 MHz uP xtal is worse case about 100 ppm off.
Even a 32 kHz low freq clock crystal should be better than couple hundred ppm.

New processors have internal oscillators that can run without an external crystal. These have correction tweaking capability and can even be adjusted based on an external reference but without even grid presence there is no external reference to rely on.

It sounds like a firmware issue that needs to be corrected.

My guess is the uP timebase is accurate but the firmware timers that builds the PWM sinewave generation has errors in keeping the 60 Hz repetition rate accurate. There are typically rounding errors in the timer settings that need to be constantly managed to compensate +/- errors over time. As AC voltage and load currents are constantly changing the PWM cycling is constantly adjusted making keeping track of cumulative timer errors very challenging for firmware.

RCinFLA said:

0.1 Hz is a lot of error on 60 Hz. That is like 1667 part per million.

Click to expand...

no doubt about it - when your clocks gain over a minute a day that's a pretty noticeable error.

RCinFLA said:

It would screw up SolArk's ability to meet UL1741 specification for grid limit testing and any frequency shifting to back down any AC coupled GT inverters.

Click to expand...

I tried to look up the UL1741 spec, but it costs $1000. Literally. I'm off-grid, so it's not obvious the spec applies in this case. DougFromdaUP notes that his 12K runs fast when it's off-grid, but is fine when it's grid-tied.

RCinFLA said:

A cheap 8 MHz uP xtal is worse case about 100 ppm off.
Even a 32 kHz low freq clock crystal should be better than couple hundred ppm.

New processors have internal oscillators that can run without an external crystal. These have correction tweaking capability and can even be adjusted based on an external reference but without even grid presence there is no external reference to rely on.

It sounds like a firmware issue that needs to be corrected. My guess is the uP timebase is accurate but the firmware timers that builds the PWM sinewave generation has errors in keeping the 60 Hz repetition rate accurate

Click to expand...

Pretty much my thought process too. It's just too easy to get timing accurate enough these days - that's why I'm surprised I'm seeing this.

I don't know anything about solarks.

My Victron MultiPlus II is usually 60.1hz or 59.9hz when I'm looking at my cloud monitoring. I don't let it bother me because I don't use AC clocks, but I don't know whether it's a "problem" unique to my installation or a common occurrence.

As for solarks and hz timing performance issues as it applies to grid tie, this doesn't even seem to be a data point, unless it's about a solark setup to do grid tie--which it isn't?

A hybrid inverter locked on grid will follow whatever the grid frequency and phasing is.

The grid frequency range is usually held within ±0.5%, so it is from 59.7Hz to 60.3Hz. When there is an unusual event like a sudden major area wide blackout, thing can get a little more out of control, but it is still pretty tight tolerance.

There are only four major independent grid networks in the whole U.S. so a given region has hundreds of power plants feeding the section, all in synchronization. Everything east of Mississippi river and Mid-west is synchronized with same frequency and phase. This synchronization is critical to bring individual power plant on line and share power.

Power utilities will allow voltage to vary when consumption load gets outside their predicted level. Power plants take time to react to load changes so the only realistic way to compensate for demand variation is to allow voltage to vary. Adjacent regions that are not synchronized cannot share power. Texas has its own isolated grid region and they learned the downside of not be able to share power with neighbor grid region during the ice storm of couple of years ago.

Whenever there is some variance in grid frequency the whole synchronized region grid system, area wide, will speed up or slow down a minuscule amount over the next few days to bring the long-term average back to 60.00 Hz.

^ This.

Sol-Ark merely syncs onto the grid frequency and there is nothing it can do about it in grid-tie mode.

From my earlier post

I'm off-grid

Click to expand...

In your “More” graphing options in PowerView create a graph of the Frequency for 24 hours and take a screenshot and post it.

Here's a screenshot - the line shows as dead-flat 60Hz as you trace the cursor over it. At one level this is not surprisng, since the same firmware that is regulating to 60Hz is reporting the frequency. I thought it might be an issue with my generator which I have to use to power my shop tools (which blow the 12K offline), but that's not apparently the case. The system ran an exercise cycle starting at 8AM and it doesn't create any visible change on the graph. The 12K display showed the grid frequency dancing around from 59.9 to 60.2, mostly showing 60.0 . Also, typically when I run the generator for the shop I throw the Grid breaker so the inverter doesn't even see the generator (though I've been known to forget to do this.)

Last night I wired up an Arduino and an HA11AA as a zero-crossing detector to count pulses on the line.
I measured the time of 12,000 pulse multiple times, using multiple different Arduinos. Here's the averages
Device Avg (ms)
1 100008
2 99956.22
3 99961.6
4 100005.6
Overall average = 99982.86

Aside from the disturbingly large differences between the device clocks, the error is still too small to explain the clocks.

I'm about to head out of town for about a week and will set the clocks before leaving and check them on return. The only generator use should be the exercise cycle next Monday. That should help narrow things down.

Llaves said:

Last night I wired up an Arduino and an HA11AA as a zero-crossing detector to count pulses on the line.
I measured the time of 12,000 pulse multiple times, using multiple different Arduinos. Here's the averages
Device Avg (ms)
1 100008
2 99956.22
3 99961.6
4 100005.6
Overall average = 99982.86

Aside from the disturbingly large differences between the device clocks, the error is still too small to explain the clocks.

I'm about to head out of town for about a week and will set the clocks before leaving and check them on return. The only generator use should be the exercise cycle next Monday. That should help narrow things down.

Click to expand...

I am not surprised, I actually think this is very good accuracy for a AC line Frequency, your averaging 60.016 Hz. which if averaged over a longer period of time will only get better. No way does that explain your clocks.
It sure as hell beats the accuracy of the line frequency I am getting from my power company. Mine always averages low, I know this because the few times I have measured it the freq was low and the only clock in the house that uses it as reference is the one on the Oven. We have to adjust the clock every month by about 5 minutes.

My Sol-ark is not currently running any loads at all, just charging the batteries with the panels, but I checked anyway and it has been showing dead nuts 60hz and 120v on both legs for at least a month.

I reviewed my notes. I was able to run off grid for 10 days before clouds forced me to connect to my utility. During that time, clocks in my house gained three and a half minutes. If my math is right, that's an error of 243 ppm, giving me 60.016 Hz for an average frequency.

Llaves said:

My Sol-Ark 12k output frequency appears to be about 60.1Hz. While this might not seem like much of an error, in practice it means my clocks gain 1-2 minutes a day. Is there any way to adjust the frequency? I'm not seeing anything in the manual.

Click to expand...

I have the same issue with my 12-K’s being off grid. I do not know exactly how many minutes I gain each month (6-8 mins) because I don’t track it. However, about every two weeks I set the clock on my microwave and stove back to match the time on my cell phone. I’m told it was due to sol-ark being slightly over 60hz when sol-ark is not grid tied.

Quattrohead said:

My Sol-ark is not currently running any loads at all, just charging the batteries with the panels, but I checked anyway and it has been showing dead nuts 60hz and 120v on both legs for at least a month.

Click to expand...

So I have now been running the whole house off of the solark for 3 weeks and suddenly realized that my clocks were fast by 5 minutes ?.
Her indoors is not going to be happy with that situation ?

Yeah, the graphs don't have the resolution to see the .016 Hz deviation, so you can look at all the graphs there are and never see a small difference like that.

Well I got yipped at this morning because "her indoors" got to work 10 mine early due to the clocks.
I called Solark and they want to update the firmware first....of course.
Waiting on that to happen and then will see if anything changes in a couple weeks.
On the good side, last time I connected to mains power was 3 weeks ago. Sorry FPL.....NOT

Quattrohead said:

Well I got yipped at this morning because "her indoors" got to work 10 mine early due to the clocks.
I called Solark and they want to update the firmware first....of course.
Waiting on that to happen and then will see if anything changes in a couple weeks.
On the good side, last time I connected to mains power was 3 weeks ago. Sorry FPL.....NOT

Click to expand...

Better hurry them up. You don't want to provide any excuses to stay home.
Please let us know if the firmware update fixes it. I'm using M 6.2.1.4 / S 1.7.2.4 / C 1.4.3.5 and reluctant to change since everything else works.

One minute per month is 23 parts per million. Typical microcontroller parallel mode AT cut crystal oscillators are 60 ppm accuracy if the parallel capacitors values are selected properly and PCB capacitance strays are taken into account.

Most battery-operated clocks use 32.768 kHz BT cut crystals which are about 100 ppm accuracy if temp does not range over too great a range and PCB strays are taken into account for load capacitor values. They usually run slow because the PCB stray capacitance was not taken into account and BT cut freq vs temp is upside down parabolic curve causing freq to drop either side of normal room temp.

Quality wrist watches are frequency trimmed holding watch at about 80-85 deg F which is about the average temp of wristwatch on your wrist.

You need a freq counter with an accurate time base, at least a 10-second-long count gate, and at least 8 digit readout to get a reasonable read on clock accuracy. There is always rise/fall time jitter on clock square wave signal so the longer the measurement gate period to average out this jitter the better the measurement accuracy. Or you can wait and see how much a connected clock triggered by 60 Hz input drifts in time readout.

The point of the gory details is it is not easy to set a clock timebase accurately.

A major part of PWM sinewave inverters issue is software not worrying too much about cumulative AC frequency cycle time period accuracy. Their most important focus is getting the PWM duty cycling correct for sinewave voltage/current regulation and not allowing a DC offset bias to build up between positive and negative half cycles of sinewave. A DC bias build up can be very bad for external AC output connected transformers and AC motors. Adding more attention (software) to keep cycle period average accurate is a secondary annoyance to software design.

DougfromdaUP said:

Better hurry them up. You don't want to provide any excuses to stay home.
Please let us know if the firmware update fixes it. I'm using M 6.2.1.4 / S 1.7.2.4 / C 1.4.3.5 and reluctant to change since everything else works.

Click to expand...

I had the same as you before this update, here are my new firmware versions.

SW Ver.: M 6.2.2.2 / S 0.7.1.7 / C 1.4.3.E