Power load from panel instead of battery after reaching full charge

If the battery reaches full charged state, the charging is finished and the dcdc conversion is completely stopped. Which means that a potentially connected load now discharges the battery, even if there is enough solar energy available for powering the load.

Wouldn't it be a good idea to power the load from the panel?

Technically, in a MPPT controller in buck mode, the DCDC conversion has to keep the out->current in the _dcdc_control negative and as close as possible to 0 (which means battery discharge, but only as little as possible).

For the other modes, I haven't thought through it. Before I'll do this, my question is: is there any reason not to follow the idea of trying to minimize discharge of a fully charged battery?

I think for lead-acid batteries it does already work like this. It will only completely stop the DC/DC for a short period of time until the battery voltage drops to the trickle voltage. Afterwards it will try to keep the voltage at the trickle voltage. If power is drawn from the load, it will automatically increase the DC/DC power to maintain the voltage.

However, for Li-ion batteries (where trickle mode is disabled) it does currently not work and would make sense, I agree. For Li-ion batteries it's just not good for their health to keep them constantly at their target charging voltage (e.g. 4.2V), so we can't just enable trickle mode and set it to the same as topping voltage. It must be current-controlled in some way, exactly as you say, keeping discharge current as close to 0 as possible.

Didn't yet look closer into it, but it might already work if we just reduce the allowed charging current to 0 and don't completely disable charging here:

charge-controller-firmware/src/bat_charger.cpp

Line 394 in 7e1d137

bus->chg_allowed = false;

My change proposal exploits exactly this: we already set the charging current to 0 after detecting full load. The problem with the existing was that when battery charging was disabled (out->chg_en == false) the dcdc conversion would be stopped right away. My change prevents this so that the current control takes place and indeed, it keeps the out (read battery charging current) below 0, i.e. the battery is actually discharging at the "slowest possible" rate. Which is different from trickle charging, as we don't want to charge.

However, while my fix works nicely while the sun is shining, it has some issue when it gets dark. It will essentially not turn off the half_bridge until the lower discharge limit of the battery is reached.

Disabling the half bridge once there is not enough power being produced by the input should be implemented. I am currently experimenting with a little (!) more sophisticated code for doing so, which takes into account the actually produced input power (if it is too low, turn off the half bridge). That seems to work. Need a couple more days of nice sunshine to run some more experiments :-)

That sounds great!

As part of my experiments I played with high load changes and found that a high load change (high to low) basically changes from buck to boost mode for a brief moment, because the dcdc ls current seems to drop below 0.1 temporarily. I understand that for nano grid this makes perfectly sense as we want it to switch direction as needed but shouldn't we have the direction fixed for the other two modes? Why would we want to push energy into the wrong direction?

charge-controller-firmware/src/dcdc.cpp

Line 113 in 7e1d137

if (dcdc->ls_current > 0.1) { // buck mode

Yes, that's right, we don't want to push energy into the wrong direction, but the zero current switching point is not perfectly easy to detect, as the current sensors might have some drift, even with calibration at startup.

How long does it switch to boost mode? Only till the next call of the control function or longer? Because the idea was that the DcBus of the solar is set such that it is not allowed to "charge" it. So this should be prevented. Maybe the control is just too slow?

For a nanogrid we will need faster control anyway. We are currently working on simulation + implementation of a proper digital DC/DC control (PID). But we are not yet close to starting implementation in the firmware. The current status of the simulation can be found here.

Very good illustrations about the ongoing simulation .
Good job Boss.

@martinjaeger
As part of my investigation I stumbled about these lines of code:

charge-controller-firmware/src/dcdc.cpp

Lines 82 to 85 in 7e1d137

    
           else if (out->current < 0.1 && out->voltage < out->dis_voltage_start)  // no load condition (e.g. start-up of nanogrid) --> raise voltage 
        
           { 
        
               return 1;   // increase output power 
        
           }

I found that this code was consistently blocking the MPPT part being reached in my buck converter code when the battery was discharging (due to powering the load) and being below the reconnect voltage (which happens if you discharge from a charged enough battery and after some time the voltage is above load disconnect but below reconnect), In this window the PWM will simply go to max PWM and stay there until the solar power is higher than the load demand plus 0.1 A.

I would think that we should use the dcdc power here as it characterizes the transferred energy from input source to output sink. For MPPT it works perfectly to replace out->current with (dcdc_power_new < 1.0) which is roughly (!) equivalent to 0.1A.

BTW, really being able to see this effect requires that the input (solar) bus dis_voltage_stop is set to a value close to the battery voltage, otherwise the effect of this piece of code is even worse as it drives the output voltage lower than the switch off voltage, which then kills the power transfer immediately for a while until the next "test cycle" starts, which then drives the voltage low quickly and cuts the panel again (and again) until enough panel power is available. You'll see a lot of start/stops of the dcdc transfer in this case.

See https://github.com/hogthrob/MPPT-Charger_Software/tree/pr48

I recently digged out Victron 150/70 MPPT schematics, I think there's a few things we can mod from .. especially high side PV isolation circuit..

For the 24_20 mppt

Part of the circuit .

Interesting. But what is the PV isolation you mean?

You used negative Voltage isolation, victron used positive PV isolation.

I mean high side solar switch, instead of low side switch used on 24_20 . I never liked the idea of using low side switch.

I don't think low-side switch is an issue for the PV input, as it should not be connected anywhere else. And reverse polarity protection is easier using LS switch. Or why do you think high-side is better?

I agree that the load output should be better switched at the high side, as you could have a separate ground path. This is planned for the next generation of the CC.

I think I will close this as the respective PR has been merged...

	else if (out->current < 0.1 && out->voltage < out->dis_voltage_start) // no load condition (e.g. start-up of nanogrid) --> raise voltage
	{
	return 1; // increase output power
	}