Battery voltage offset?

Yup.  CFG -> System -> Calibrate Readings -> Batt'y V...adjust until it matches what your meter shows.

I'm actually a little confused as to why the battery voltage readings don't match up as expected on Rev. C--because the value is mathematically calculated.

That works nicely

All the other metering was also off

Even frequency

All dialed in now 

Worth noting: the frequency trim setting may not match the actual output frequency.  I have mathematically calculated what the resultant output frequency should be--but it's worth noting that the internal oscillator has a notable tolerance, and does have an adjustment (which actually is the freq. trim setting!)  Just because the screen reads 60.06Hz (as the closest possible representation of 60Hz possible from a 16MHz source) doesn't mean the output is actually 60.06Hz.

The default trim (60.33Hz registered IIRC) was actually what I measured to be closest to 60Hz with an oscilloscope.  BUT that's not saying that my 'scope can't be off--as if your clock was running fast, then the inverter frequency was definitely high!

As far as the other metering calibration, there are parts tolerances on each monitoring circuit--and said tolerances can be rather notable.  Especially those hall sensors--they are extremely linear, but units can differ quite a bit from each other (which is nothing short of exasperating for a designer!)  I am aware that for whatever reason a negative calibration on the output/input AC amp sensors results in the readings going completely wonky due to a math error in the CPU; I will have to fix that as soon as I get time.  (I had it working perfectly at one point--this is some stupid compiler snafu that's causing it to mess up.)

60.06 was the closest to 60hz i could verify...

FYI, my battery voltage calibration is like +60... I've checked and rechecked that this is [~] the most accurate value i can get.

Sounds like I need to look into this.  It's possible that I may have introduced a bug into the "accumulator averaging" method, where it's accumulating 15 samples and dividing by 16...which would result in lower-than-expected readings.

Mine is +19 now but was still reading a bit low

My frequency is +8 to get my clocks to keep time 

Internal oscillator on the main MCU has some pretty lousy tolerances--so this is actually kinda expected.  Each inverter will be different--and temperature will affect it too.

There's better MCUs out there, just I'm extremely reluctant to switch suppliers, as then I'll have yet another codebase to keep updated.

Should be fine once tuned

If it's a crystal clock those can be tuned with a cap across them allowing toe systems to be more consistent (used commonly with composite video encoders)

My guess is its a normal mechanical clock that uses the 60 Hz to keep time.  I don't think these inverters have accurate enough frequency management to keep time.  I think its possible though with an RTC inside the inverter it could make micro adjustments but at least what I have seen there is a slight drift in the videos Sean has shown.  My current PJ drifts and my mechanical clock gains time depending on load about 1 minute per day.   

2 hours ago, AquaticsLive said:

My guess is its a normal mechanical clock that uses the 60 Hz to keep time.

You would be surprised how many plug-in appliances with digital clocks have an ear to the AC line for a 60Hz timekeeping signal.  Both convection microwaves I've had (both GE Profiles, an SCA1000 and a PVM9179) had an AC input clock signal, without which NONE of the time-based functions would even count!  Clock, timer, oven timer, etc.  Both units were equipped with microprocessor controlled vacuum-fluorescent displays.

The only reason I know this...is because I hacked both of them so all the "light electronics" ran on 12vDC, leaving just the "big stuff" to run on AC (microwave, and heating elements).  Had to create a 120Hz timebase circuit...otherwise it was pretty well useless!

2 hours ago, AquaticsLive said:

I don't think these inverters have accurate enough frequency management to keep time.  I think its possible though with an RTC inside the inverter it could make micro adjustments but at least what I have seen there is a slight drift in the videos Sean has shown.  My current PJ drifts and my mechanical clock gains time depending on load about 1 minute per day.   

The drift in said PJ inverter is from the processor's INTOSC (internal oscillator)--and the GS inverters use a smaller MCU from the same processor family.  Microchip MCUs have lousy stability on the internal oscillator.

yeah, I'm sure someone's going to argue, "But PJ inverters have a crystal on the CPU!"  Yes they do.

...and it isn't used!  Processor runs off 16MHz INTOSC with a 4x PLL to reach internal 64MHz clock speed.  Drift will not be affected by load, but more likely based on internal temperature.  (EDIT: yes...the load likely will affect the ambient temperature of the processor--so yes, while technically there isn't a connection...in actuality there is 😉)

From the Microchip PIC18F87K22-series Datasheet (DS39960D) page 504:

Yeah, automatic temperature compensation of the INTOSC would be possible....if the MCU's internal temperature sensor actually worked! 

It doesn't.

So much for a Made-In-America chip..........yup, AFAIK Microchip MCUs are produced in Arizona, USA.

Yes, an external crystal COULD be used.  But then I lose 2 I/O (and ADC) inputs--and the GS control board has pretty well maxed out the capabilities of the processor.  And I haven't been super impressed with crystal stability either...at least on my microwave timebase using a divided-down crystal.

Well Sid answered my question

The chip is running an integrated clock

My digital clocks on appliances were the ones effected just like in Sid's case

This unis is definitely stable enough to run a clock, was just off frequency

A counter is far more accurate than a scope to check frequency so I should grab mine and fine tune

Thanks this is good info.  So how I am understanding it is I will continue to have some clock drift.  That was expected so doesn't concern me, but good to know.

FWIW, i ran my appliances on the GS continuously for over 90 days (arctic summer) and had no [more than normal...] noticeable drift.

Granted... i don't really stress over their clocks anyway... lol

I do agree that there are definite "ideals"...but unfortunately, design is pretty much always a mix of compromises.

I've definitely thought about switching to another main processor.  I could very easily switch to a Taiwanese chip (Nuvoton) at 1/5th to 1/10th the cost (typical USA vs Asian cost difference for ALL parts!), but my hesitation there is that if anything goes wonky with Taiwan, we're toast.  But I guess the same could be said about China--because GS inverters are currently being manufactured there!

FWIW my experience with the Nuvoton MS51FB9AE chips (dirt cheap and extremely powerful!) is that they have quite a few ideosyncrasies and inexplicable "doesn't work" to "does work" changes that don't make any sense.  Documentation is difficult to find, and there is basically no support community--but they're SO powerful!  Said MS51FB9AE is more powerful than the Microchip MCU currently in the GS inverters (though it does lack a significant portion of the analog support functions that the GS inverters rely on)...and costs about 1/20th the Microchip MCU!

The Nuvoton processor manual is full of errors though, same with the BSP (board support package) provided.  On a test project, getting the NCO CLKOUT function to work took closer to 3 hours of frustration (and finding discrepancies of register location between different pages of the same processor manual!)  But in the end, I did get it to work.  And at $0.51/ea........that's literally cheaper than a regular TTL/CMOS logic gate here in the States!  I glanced through Mouser, and you can easily pay over $1 apiece for a 74HCT14...that's a hex Schmitt trigger inverter!