[Backtracking on a flat E-W inclined plane]

From PVsyst help:

Backtracking on a hill

The backtracking strategy is based on the relationship between pairs of neighbour trackers. See the description of the backtracking strategy.

It requires that the tracker's array is perfectly regular, with the same width/pitch ratio, as well as altitude.

The altitude differences will necessarily be the same for all trackers (i.e. if not horizontal, the tracker array will be on a same flat E-W inclined plane).

With different and irregular altitudes like on a hill, the Backtracking strategy is geometrically impossible, neither in PVsyst nor in the reality.

 

I want to do a sensitivity analysis on the performance of trackers vs the East-West slope of the terrain. Since the backtracking on a hill cannot be simulated, I created a flat E-W inclined plane, descending toward East, I put down the trackers on the inclined plane with "Automatic altitude", I re-aligned the baseline slope to zero (since this changed after the Automatic Altitude" command) and I set the backtracking on.

All the trackers have the same pitch and the same elevation difference; I believed a backtracking strategy could be simulated in this case.

But I still have relevant mutual shading in the afternoon.

Do there is a workaround to avoid this? Is this simulation possible?

I also tried adding a couple of additional trackers in the same shading scene, and putting them at the same elevation and with a little higher GCR with respect to the others, and set the backtracking based on this couple, but did not work: I don't have shadows between the sample trackers but I have it for the trackers in the sloped plan... even decreasing a lot the distance between the reference trackers I still have shadows in the sloped plane.

Looking at the shading animation, we can see that the backtracking starts also in the afternoon, but too late, when the mutual rows shadow has already started

[Inverter Maximum DC Current]

It does not work.

I simulated one invereter with "2 x strings x 9 mppt" and "3 x strings x 9 mppt", in both cases not checking multi-MPPT option nor power sharing,

in the 1st case give negiglible losse, in the 2nd case give huge losses.

Are you suggesting to do a weighted average of the two results based on the number of MPPT inputs with 2 strings and with 3 strings?

In my case, 2 strings x 7 mppt + 3 strings x 2 mppt

Doing this, the weighted averaged result (obviously) "in the middle" between the 2 extreme cases.

But the result of the weighted average is not equal to the result of simulation with "2 strings x 7 mmpt +3 strings x 2mppt, multi MPPT option, shared power with all Pnoms identical", but it is lower.

Interestingly, it is almost exactly the straight average between the above configuration and the same, but using shared power but NOT all Pnoms identical

The truth is in the middle? For sure, but it is not a satisfying answer.

André, what are your suggestions?

[Inverter Maximum DC Current]

Thank you very much.

I am in situation "b". However, it is not clear to me (also after a conversation with Huawei) if the MPPT inputs of this inverter share or not share power.

Someone has a clear understanding of Huawei 185KTL internal architecture? Possibly something "official", from Huewei (that's unlikely, but... asking costs nothing :)

[MPPT efficiency]

Thanks,

does someone has guidelines to quantify this additional loss?

Mauro

[MPPT efficiency]

Hello,

I would like to know if and how PVsyst manages the MPPT efficiency i.e. the ability of the inverter to follow MPP. I suppose it depends on inverter MPPT algorithm, sampling frequency, global and local MPP etc...

Does PVsyst include this MPPT efficiency in inverter .OND model?

If not, what is in your opinion the pecentage losses attributable to the MPPT in-efficiency?

thanks a lot