Paladin’s Developer’s reaction to Victoria’s ESC Proposal
An insight on Paladin’s Superior Technology to Solar Management and Diversion
In relation to the article link below, Paladin’s developer has been working away on a project in the ACT and with firmware modification, can assist the ESC and particularly power consumers to maximise their PV systems.
Victoria Regulatory Body (ESC) are planning to implement variable time based FIT to help stabilize their grid………
We have been working with an ACT installation to get Paladin into a ‘Goldilocks Zone’ with a Fronius export limiting inverter setup to defeat / overcome the problem of the inverter throttling back when export goes over 5Kw. On the face of it this is a laudable solution, but the real problem lies in execution. The inverter’s process of throttling is very slow, clunky and Teutonic (no leeway) and this results in noticeable abrupt cuts in PV production and export for often considerable time periods (in electron terms – circa 3-4 minutes) while the MPPT resets and some stable point of PV production is found.
For whatever reason, it is plain from both these sources, that the core problem is not entirely the gross amount of excess PV on the grid, but its’ variability.
Enter Paladin, another early morning revelation, some lateral thinking and a hat tip to our old friend Occam.
Using the ‘Joule Injection at Mains Cycle Frequency’ (JIMCF) software technique that was used to solve the ‘Fronius’ issue, Paladin can selectively, reliably and accurately allocate excess PV either to export or hot water heating at 20ms intervals at any values selected. Thus Paladin can now go from hot water priority to export priority at a whim; effectively holding a set value of grid export over time regardless of PV input and household use (excess PV). The only caveats are that if the excess PV is less than the demanded grid value, then there will be a shortfall and if the hot water tank reaches maximum, then control is lost. The former is a problem without batteries, but can be mitigated by using sensible values consistent with time of year etc. The latter is easily and consistently mitigated (if it is a problem with large PV values and small tanks) by using an energy sink such as a 3kW heater element as a secondary.
Paladin already has the concept of the 24 hour matrix in place for minimum temperature selection, inverter / charger control, auxiliary switching, and export control. All that was needed to make this Forced Export Demand (FED) a practical reality was to merge several existing ‘Lego’ tools already in use. The original export control was simply an ON/OFF concept – all or nothing. However using a fixed export value during surge critical periods – 0900-1500 typically (from the data provided in article 1) – could make a serious dent in the problem. This would not be a total solution, no single thing would ever be, but its’ shear elegance and simplicity speaks volumes for reliability and potential effectiveness.
Now keep thinking on the same lines to use this same mechanism to assist the grid further and possibly enhance the end users’ FIT return given the Victoria proposal……
Using the following decode, consider the 24 hour time matrix that follows.
E = Export all PV unless water temp drops below minimum.
0 = Normal Ops – export only excess PV unable to absorb with HW element – also ‘ ‘ (blank entry)
1 = Export 1000W as priority. Ditto 2-6 = 2000W – 6000W
So a typical matrix for export control would read thus – each character = 1 hour.
———————— 24 hour time base
That would decode in words:
Normal Ops to 0700.
Export everything to the shoulder from 0700-1000.
Fixed stable export of 2kW from 1000-1600 to stabilize the duck portion and reduce it. Balance to Hot Water
Export everything from 1700-2100 to assist the evening peak.
Normal Ops to 2100-2400
This would do everything in one sweep, autonomously – and that is important. Using an autonomous system the reaction time will be fast (20ms) and guaranteed.
Even without considering comm’s issues the best reaction time with internet or AWFULS type control will be 10’s of seconds at best. And at times of intermittent or at risk power the comm’s will be fragile at best. That is not to say that the content of that matrix cannot be operator modified, but that would probably be on a daily or hourly basis rather than real time.
The additional elegance of the above system is that hot water heating is deferred until the peak hours to help support the grid on the shoulder and at low PV production times (which are conveniently synonymous) and this leaves maximum HW tank energy capacity available to ‘hold the line’ during FED activity at peak.
The values assigned to FED of 2kW in the example above are nominally half of the plate value of the PV installation. In reality this might well vary between a third and two thirds (think of a number) depending upon time of year and PV penetration geographically.
Additionally the Minimum Temperature matrix can be adjusted to force a temperature boost in the small hours or as required to absorb excess grid capacity.
Just a final word on autonomy.
It is the author’s firm belief that over reliance on the ‘internet’ is a serious mistake, not only for the issue of response speed but from its’ historical tendency to be the ‘first man to fall’ when things start going astray when the SHTF. The response time issue is a real thing too, as the power correction formulas all show response time on an inverse square law – the faster the better. Paladin’s native 20ms (50hz) response is as good as it gets.
This is a Win-Win of the highest order, and that has huge value. The new firmware could be rolled out tomorrow and it would work… We are rolling out Paladin Version 650 firmware for the existing Paladins and this will be embedded, dormant until activation.