MPPT-2420-LC support status
hogthrob opened this issue · 36 comments
Hi, I tried to upgrade my MPPT2420 controller software to the latest commit from master branch (it runs with firmware from Oct 18 w/o problems). The new commit builds and uploads okay. However, nothing happens. No leds, no nothing.
The code seems not to reach main() since I successfully enabled the OLED (could see the splash screen, so the upload works) but my attempt to put anything on the screen failed by calling the oled functions right in the first line of main.
Before I get out the gdb , I'd like to know, if there is any known issue with this device and this branch?
Hey, I recently used mainly the 1210-HUS for development and didn't always cross-check with the 2420-LC. But I'll do that right now and come back to you.
I had an issue with the 1210-HUS that it got stuck before the main if the solar panel was connected before the battery. Just found out an hour ago that putting a wait(0.1); after control_timer_start(CONTROL_FREQUENCY); in the main solves the issue, but I'm not entirely sure why... Maybe this solves your issue aswell?
Unfortunately I can confirm that the 2420-LC doesn't start up. I'll try to figure out why... That wait function was not the reason.
The OLED seems to cause trouble. If I take it out, it starts up and everything works fine.
There were some other small issues which I corrected in the latest commit ead6f2b. But I didn't figure out why the OLED stopped working with this hardware... it works fine with the other charge controller.
Hi,
thanks. Good to hear. Will give it a go tonight and see what happens.
Check the I2C lines of the OLED, sometimes that maybe where the error could be present, my hardware isn't completely done yet, I should have tried to help in finding the error . Meanwhile EAdog (st7565 / st7567) LCD is still my favorite display, since the support has been abandoned, I will add the support to my hardware, OLED is kinda expensive for me to use .😎
Where do you get cheap ST7565 based LCD from? OLEDs from China are much cheaper than EAdog displays, at least from all suppliers I know.
The strange thing is that the whole program crashes. If the I2C lines were broken, it should just not display anything.
I know of $2 st7567 display I plan on using, 2.1 inches but $8 for OLED of the same size , unlike the OLED which is normally 0.9 inches. Am not building one Mppt or two, I have many sites I need to install as many units of Mppt , so am considering cost .. that's why I choose EAdog .
Maybe I will search more for 2.1 inches OLED under $4
Here is my result:
It works if OLED is disabled. It does not work if UART_SERIAL_ENABLED is not set. Which is strange, since it doesn't contribute to running the main activities.
Got CAN to work again. However, it is an very ugly hack at the moment. It is just sufficient to run my internal logging via CAN as I have done with the "old" firmware from last year.
It is not clear to me how to align this with the serial ThingSet code, as it works very differently (we cannot just pass a buffer to be filled...).
Anyways, I think, I'll switch to the new firmware and see how to get this done with your help.
@atochukwu0 : There is no problem with the OLED electrical connection on my end, the splash logo is being displayed just fine when the firmware starts up (which is done before main starts when the OLED object constructor is executed). Unfortunately the normal operation of the controller does not work, so there must be something going wrong).
Actually, if the logo shows up, there's something wrong somewhere ..
@hogthrob Thanks for the feedback.
I'll check regarding the interference with the UART serial, also on the other hardware. It's really a bit strange.
Regarding CAN: I was not aware that anyone else is actually using CAN at the moment, so improvements on that interface was at low priority on my ToDo list. Now I realize that the code is probably completely broken, as some names in the ThingSet library changed. I should have included the CAN option into Travis CI to make sure it will at least keep working... ;)
Please find the suggested specification of ThingSet via CAN here: https://thingset.github.io/spec/can
The code in the charge controller repo is currently only a first preliminary hack to allow monitoring (i.e. publication messages), but I didn't yet include any device configuration functions. With the ThingSet library now working quite well, it should not be too hard to implement. I'd be happy to work on that together.
Did you already fix the broken names? If yes, can you send a PR so that I don't have to do the work twice? I also suggest to rename the file interface_can.cpp to thingset_can.cpp.
By the way, if you didn't find out yet: The ThingSet library now allows to easily user-define all battery settings (as we disussed some time ago) via the serial. It also does plausibility-checks before accepting it. Just send e.g. !conf {"LoadDisconnect_V": 11.2} to change the setting and store it in the EEPROM. This works for any setting defined in data_objects.cpp. Other useful commands:
!output {}to see live measurement data!rec {}to see recorded data like accumulated energy, SOC, etc.!input {"LoadEn":false}to switch off the load!input {"DCDCEn":false}to switch off the DC/DC (useful during testing)
Hi,
by the light of the day I had to find out that the actual charging does not work for unknown reasons. So it displays all the values, enables the load etc but even though the panel voltage is high enough, it does not start charging, I also noticed that the green led is on all the time (like the red one).
Not able to look into this more, had to reflash the old binary for the moment.
Use of CAN: Well, this is with the MPPT-2420 HW unfortunately required if the logger is to be powered by the load output. Otherwise the load power is measured incorrectly and cannot be switched off at all.
CAN ThingSet: Yes, interface_can should become "thingset_can".
However, this has not the highest priority now. First of all I would like to get it properly charging.
Sad to hear it's not even charging. I tested charging in the lab yesterday and it worked. If I find the time today, I'll also have a look again.
Use of CAN: Well, this is with the MPPT-2420 HW unfortunately required if the logger is to be powered by the load output. Otherwise the load power is measured incorrectly and cannot be switched off at all.
Can you explain your use case a bit more? You want to include the logger power consumption in the load output measurement or not? For the charge controllers with MPPT the USB output power is included in the load measurement, which makes sense in my opinion. And USB can be switched off independently, i.e. get different priority than the load output.
What could be the actual cause of not charging ?
Hi,
it might be a settings issue. Since I know now that the software is actually charging with @martinjaeger hardware, I would suspect something like this. I am not able to control or read out the settings via CAN (yet), just the publishing works.
Logger: No, I don't care too much if the logger consumption is actually logged or not. The problem is, that my logger (a raspberry PI) consumes about 40Wh of energy a day. And if the battery is low and the sun is not shining for a couple of days, I want the logger to be turned off instead of depleting the battery. Which it does if connected to the 5V internal voltage. I must admit, I have no BMS in place which does cut off everything if the voltage goes too low. The chinese ones switch off very late anyways (around 2.4V per cell). BTW, if I shutdown the RPi by itself to save energy, it will not "wakeup" if energy is restored...
Ah, interesting. Do you also use this RPi hat? https://github.com/LibreSolar/CAN_RPi-ZeroW
We faced the same problem with the RPi, but used the bus power supply provided by above shield. It's not "nice" to just cut its power when the battery is low. So ideally the charge controller would send a message to tell it to shut down first and wait one minute before it cuts the power.
Did you mean 2.4V per cell for lead acid? That would be very high. But 2.4V for LFP would be far too low...
Well, I have the PCBs unpopulated laying around after seeing the prices for a ready-made simple CAN module on eBay. Cutting the power is never "nice" but worked so far. BTW, the reason why there is the RPi in the first place was that my previous charger had no monitoring at all so I used an RPi with some ADCs to measure the currents and voltages and then switched to use the MPPT2420. Today I probably would go for the ESP32...
by the light of the day I had to find out that the actual charging does not work for unknown reasons. So it displays all the values, enables the load etc but even though the panel voltage is high enough, it does not start charging, I also noticed that the green led is on all the time (like the red one).
Just realized that the behavior of the green LED is correct. I changed it some time ago. The green LED indicates the load state (on = on). The red one is the "power" LED. It's continuously on in stand-by and starts blinking as soon as solar power is coming in, i.e. the DC/DC power stage is on.
I guess, for whatever reason, some of the range checks are "failing" and as a consequence charging is not enabled. I have a 3s LiIO (NMC) battery connected and configured.
Hi, my MPPT-2420-LC has been running the "newest" firmware today. In fact, I ran the CAN code on top of this. The code is here: https://github.com/hogthrob/MPPT-Charger_Software/tree/working_can_after_rebase One can clearly see, it is a hack, not more. It would be nice to go ahead with it, but I'll only be able to make slow progress. In any case, it works for now for me.
Wow @hogthrob, that's impressive .. let me take a look .
Did you fix the OLED error you once experienced ? And the uart related issues too .. @hogthrob
src\interface_can.cpp:182:47: error: no 'int ThingSet::pub_msg_can(unsigned int)' member function declared in class 'ThingSet'
int ThingSet::pub_msg_can(unsigned int channel)
threw this error , upon enabling CAN @hogthrob
Hi, I said it is a hack. I add the method declaration to the ThingSet library. Eventually, most if not all of thingset can will end up in the ThingSet library. As a quick fix, you may add
int ThingSet::pub_msg_can(unsigned int)
to the ThingSet class in the .piodeplibs/ThingSet/src/thingset.h file. No other change required, should compile.
Did you fix the OLED error you once experienced ? And the uart related issues too .. @hogthrob
Nope, did not look into this. Want to figure out how to run the debugger from VS Code, but not the Platformio Plus one.
Did you know that pio plus is now free and open source? Don't need an account anymore.
No, did not. At least my VSCode still says:
You are not logged in. Please log in to PIO Account using PlatformIO IDE > PIO Home > Account or pio account login command and try again.
pio update seems to be the solution. I had 2.5.0 now 2.5.2 and it does something, have to connect to the ST-LINK now.
This issue not yet fixed ? 🤕 .
Well, yes and no.
I got everything working on the 2420-LC except USB. It compiles, it registers even the device with Windows / Linux but I don't get any data through it...
Maybe we should close this and open an USB issue.
I agree, USB is a separate topic. It's a bit annoying that the USB stack included in mbed seems to require the RTOS enabled and thus it's hard to use it for the tiny F0/L0 micros... maybe it works with the memory optimizations by hogthrob.