Here another idea which based on spice simulation should work.
I’m wondering if you also tried your smaller MPPT 1210 in boost mode? Does the fw support it?
On another thread I read that you may have some blank PCBs for the MPPT 1210 (also 2420-LC maybe?). I might be interested in both if you still any, it would be easier to start development on real hw.
Thanks!
Nice solution. Only issue I can see is that the gate of Q5 could see too low voltage if DCDC_IN is above 30V.
Yes, I did also try the boost mode with the MPPT 1210 and it works. The firmware is the same for all charge controllers anyway.
Don’t have any PCBs for the 2420 anymore, but there are some of the 1210 left. Send me an email if you are interested.
hmm, I’m not sure If I understand the Q5 issue.
Imagine you are in boost mode and the voltage DCDC_IN is at 40V vs. GND. Now if ~LED_EN = 1, Pin 3 of T2 and the anode of D6 are at GND potential. The Zener diode D6 drops the reverse bias voltage of approx. 10V, so the cathode of D6 = gate of Q5 will be at -30V vs. its source, which is more than the absolute maximum of ±20V.
Hi!
I sent you an e-mail on 29th of august.
Have you received it?
Thanks!
Hi Martin!
I just picked up the shipment this week. Many thanks for the PCB’s!
Back to your earlier observations, I think you missed that LED_EN logic is inverted.
When boost mode is used to drive an LED, T2 should be kept OFF, so LED_EN will be at 0V, in this way gate of Q6 will be pulled high through R20 an it will switch ON, finally the LED(-) will get it’s GND.
D6 anode will not be at potential 0, it will be in series with D7 so the total bias voltage will be approx 2x10V=20V so the cathode of D6, gate of Q5 will be at 20-40=-20V vs. its source. The circuit should work fine up to 40V.
We could use BZX84C12 for example and the circuit should operate safe in 34-44V range in boost mode.
Another option could be to add a diode controller like LTC4357 for Q5, this will help to get rid of the above described limitations.
Great that you received it 
You are right, in boost mode it should be fine. However, in buck mode (LED_EN at 3.3V) you would still have a too high voltage difference at Q5 gate as soon as the solar voltage is above around 30V. Not much difference in case of 12V Zener. Maybe this issue could be solved with a resistor placed in series with the Zener diode… but didn’t check in detail.
Yes, ideal diode controller is also an option. But not the cheapest, I guess.
Right. A resistor around 10k should be ok to protect the gate in case of PV voltage up to around 50V
0r @ PV50V
10k @ PV50V
10k @ PV20V
Great, yes, that seems to do the trick.
Now that we sorted out some hw issues I will build a test config to give a try.
Meanwhile I also need to study the firmware more deeply.
I found that dcdc mode is defined in config.h “#define DCDC_MODE_INIT MODE_MPPT_BUCK”
I will need to be able to modify dc/dc mode during runtime (switch it to boost on evening, and back to buck in the morning) so I’m wondering if there is a safe way doing this?
The nanogrid mode also switches dynamically between boost and buck depending on the voltage at high voltage side, so that should be possible.
The difference between boost and buck mode is mainly that the control target changes. The DC/DC always tries to control the output port current/voltage setpoints while taking care that the limits at the input are not exceeded. So if you change dcdc.mode dynamically during operation it would change its control target. (in buck mode, output control target is LV side)
The safest way would be to switch off the DC/DC first (dcdc.enable = false), then change the settings of HV and LV ports and then switch on the DC/DC in the correct mode again.
Thanks Maritin, I will give a try.
I know it’s a little bit off-topic but I have trouble uploading the fw with my original ST-link V2.
Configuring upload protocol…
AVAILABLE: blackmagic, jlink, mbed, stlink
CURRENT: upload_protocol = stlink
Uploading .pio\build\mppt-1210-hus-v0.7\firmware.elf
xPack OpenOCD, 64-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-11:28)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : clock speed 300 kHz
Info : STLINK V2J29S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 1.087328
Error: target voltage may be too low for reliable debugging
Info : stm32l0.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Listening on port 3333 for gdb connections
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x08001a50 msp: 0x20005000
STM32L0: Enabling HSI16
Info : Unable to match requested speed 2500 kHz, using 1800 kHz
Info : Unable to match requested speed 2500 kHz, using 1800 kHz
** Programming Started **
Info : Device: STM32L0xx (Cat.5)
Info : STM32L flash has dual banks. Bank (0) size is 96kb, base address is 0x8000000
Error: jtag status contains invalid mode value - communication failure
Info : Previous state query failed, trying to reconnect
Error: error writing to flash at address 0x08000000 at offset 0x00000000
embedded:startup.tcl:449: Error: ** Programming Failed **
in procedure ‘program’
in procedure ‘program_error’ called at file “embedded:startup.tcl”, line 508
at file “embedded:startup.tcl”, line 449
*** [upload] Error 1
I will try to investigate it this evening.
I spent some time to find out why my original programmer is not working but couldn’t actually find an explanation.
For anyone facing similar problem, the only way to get it working in may case is to simply let an original tool like STM32 ST-LINK utility or STM32CubeProgrammer running in the background. No need to connect to the programmer, just simply let it running. It may be a usb power management issue or whatsoever…I may spend some more time on debugging later.
Meanwhile I also started to study the fw more deeply but is quite sophisticated so I definitely will need quite some time to understand it in all it’s aspects.
@martinjaeger, do you have some more detailed docs, flowcharts etc?
If there is someone who already knows more about the fw and willing to contribute and help me to implement my idea is welcome to this thread.
I already have working prototypes but uses different hw and architecture and I can share the logic behind it and many more details to get it running on this hw.
@martinjaeger
I was just thinking that this LED driving feature could also be implemented in your new 20A MPPT. No plans to implement such a feature in your new design?
Hi @szmolnar. Sorry for not being very responsive. I’m currently in Rwanda for a solar project and quite busy.
Yeah, the STM32L0 a bit annoying. There seems to be an issue in OpenOCD which makes flashing fail sometimes. I could not find the perfect solution yet, see also here and here. However, with the original ST software or with Segger debug probes it works fine.
It might actually be possible that the new 20A MPPT design supports your setup with LED boost converter with a few tweaks. I’ll have to double-check. And I will try to upload a first design before Christmas.
Hi Martin!
that sounds promising, I’m really curios for the first design!
If you really want to implement the LED driving feature I will prepare some notes for you with all the LED lighting features I’m already using in my other designs.
Also thanks for the OpenOCD info and have a great time in Rwanda!
As mentioned in the other thread, I uploaded the new design.
Unfortunately I think that your LED application is not yet possible, but it might be with a small modification. If we make Q8 controllable with an extra GPIO, we could connect the solar panel to the MPPT port and the LED to MPPT port positive and PWM port negative. Do you think that could work? If yes, I could make Q8 controllable for the next revision.
Hallo Martin!
If I understood you correctly your plan is to:
- Connect the PV to DCDC_HV+ and DCDC_HV-
- Connect the LED to DCDC_HV+ and PWM_SW-
- Q8 is controlled by the LM5107 Mosfet driver, but you want to control it’s gate from a GPIO so that Q8 can disconnect the PV from the DC-DC converter while it is in boost mode.
I had not much time but at the first look it should work.
…
it’ nice to have WiFi or BLE support by using a ESP32 but it requires quite a bit of power. Isn’t better to have a LoRa radio on borad?