@martinjaeger: Amazing project !!! I have been hoping that someone would start an open source MPPT project for some years now so I am very excites to try it out !! I’m more of a firmware guy than hardware so I dont expect I’ll be making recommendations to the circuit or layout but I’ve got plenty of experience in implementing & testing of embedded systems.
Some questions to whomever might have an answer:
- Is there a tally somewhere of how many systems have already been built?
- Is there a suggested board house in Europe, one that might offer discounts of repeat orders of the same design given that the can reuse the silk screens?
- To those that have built samples already, what is the expected cost, PCB & BOM?
Thanks in advance for thr feedback!!
Great to hear that you like the project!
I’m not entirely sure how many people rebuilt the hardware, because not everyone is telling me 
I know of about 5-10 people from different places in the world who rebuilt and use the MPPT 2420 LC. The MPPT 1210 HUS is currently installed in a small pilot in rural India, supplying households with energy for lighting. I just ordered 100 pcs to sell them to interested people as evaluation boards for own projects. It will take approx. 1-2 months (production takes some time) and price will be slightly below 100€ for fully assembled PCBs.
As my main focus during the last year was development of the “smaller” MPPT with USB output and the PWM charge controller, which are both suitable for solar home systems for rural electrification, I didn’t work on the 20 A MPPT anymore. But I’d like to start including some improvements into that design in the next few months.
Also firmware development support is highly appreciated, of course. The current firmware is based on mbed framework. The basic functions are all working fine now, but there are some open points for improvement:
- Faster MPPT algorithm (ideally implementing a complete digitally controlled DC/DC)
- Switch to an RTOS if this makes sense (would make communication e.g. to GSM or WiFi modules easier as you don’t need lots of state machines to avoid blocking waits anymore)
- Improved electronic load switch protection (detect and distinguish between short circuit and connection of capacitive loads, switch off faster than fuse)
- Better hardware abstraction (currently still not completely clean separation)
- Support of more communication methods and integration into existing data monitoring tools.
I’m curious to know your thoughts regarding improvements on current firmware.
I find that the best way I learn is when I get my hands dirty. As such, I would be interested in started with a kit of PCB and components that I can assemble myself. Would that be possible out of your order of 1210’s? If yes, what might be the lead time on that? Otherwise, is it possible to get just PCB’s and I can order the components separately ? For a first go, I would be looking to build 2-3 units; only having 1 is always risky for the timeline :-). I basically have a quiet month ahead of me (while all my customers are on vacation) to work on putting a solar system together.
Once I’ve got something working, I’ll be very happy to take a look at the firmware. I’ll be honest, I’ve never used a RTOS in an embedded application. I have more worked with 8-bit micros with only one interrupt vector and as such usually use my own developed task-based OS. But I have recently started my first project with an Atmel 32-bit running at 300MHz and I was thinking of trying FreeRTOS but then decided not to take the risk given the timeline. This may be a better opportunity for trying FreeRTOS out.
I’d also be interested to discuss your architecture, centralized vs distributed. You have CAN, which makes me think that you are looking to gang lots of these devices together; CAN is so very good for distributed networks (I developed some years ago a distributed BMS based on a CAN network where each node measured the voltage and temperature of a one battery). But you seem to still be doing things rather centralized. Wouldn’t it be more economical to have a node that is listening on the bus and who relays out information it hears from all kinds of nodes via WiFi/GSM rather than each node having it’s own WiFi/GSM? Also, CAN is a great architecture, but relatively expensive and certainly much faster than what I expect is needed for solar and relatively slow charging battery systems. In addition, CAN is only suitable for a system that is relatively small (car sized or less). I’d think you want something a little more scalable. Just my thoughts…
Hi,
CAN busses can have quite a long length: with 250k up to 200m, with 50khz 1000m (https://www.ti.com/lit/an/slla270/slla270.pdf). I would not call the length an issue. It is not only used in cars but also in factory automation for instance.
With can you can easily add a concentrator such as a RPi to do the heavy lifting. But if the main use case is isolated small chargers, the direct WiFi / GSM approach makes more sense to me.
BTW, I am running the MPPT 2420 via CAN and it works fine for me (monitoring only).
The main issue I have with the current MPPT 2420 design is the fact that it is using low-side switches witch makes it difficult to drive a RPi from the load connector AND connect it to USB/Serial as this creates a GND short over the low-side load switch, effectively bypassing the switch. The MPPT 2410 design does not have this issue as it uses high-side switching for the load.
CAN bus is in this case a good way to communicate with the MPPT 2420 since this does not require a shared ground reference.
Quick response: I still have some blank PCBs for the MPPT 1210 HUS, but I’m on vacation this week and can have a look how many and which version after August 5th only. Happy to send some over to both of you.
Will also give you an overview about the approach with central/decentral and CAN then so that we can discuss how this makes sense. Good hint regarding the low-side switch. I’m also thinking about moving it to the high-side for the next revisions. But it’s not that easy for 20A anymore, as it gets difficult with P-channel MOSFETs. And N-channel high-side drivers are quite complicated. Let me know if you have simple solutions for HS-switch with N-MOSFETs
Thanks, would like to get a MPPT 1210 HUS!
I am currently looking into using the Infineon ProFET BTS 50085-1TMA from Infineon for a high-side power switch, should do the job (https://www.infineon.com/cms/en/product/power/smart-low-side-high-side-switches/automotive-smart-high-side-switch-profet/classic-profet/bts50085-1tma/) . There are other of these fully integrated high-side switches in the ProFET product family.
Technically, yes, but commercially ? How much does 1km of wire cost ? In addition, connectors are typically a cost driver and are often a source of failure. CAN is also relatively expensive and I don’t see the need for high speed communication. If you are making 1-2, who cares. But Martin is up to a build of 100 units. Component choices start to have an impact.
In my experience, technology and component choices should be in line with the goals of the project (aka specification), so I asked the question. Definitely if the goal is 1-2 panels per system working independently, then the architecture should be centralized, but then why the CAN. If there are lots of devices on an installation, then it is typically more efficient to do things in a more distributed fashion.
I’ve ordered 10 boards from EuroCircuits. With shipping, cost is about 14€ per board on a 5 day turn (+ transit time). On the components, Digikey is running about $45 / board without L1. I’ll probably order 3 sets of components.
I still wanted to give feedback regarding the centralized / decentralized approach. Here it is 
My original idea was to build a plug-and-play DC energy system, consisting of one or more charge controllers, batteries and possibly inverter(s). If you start with a simple system with only a battery and a charge controller, I agree that you don’t need CAN communication. But as soon as your system grows and you connect two charge controllers to one battery bank, they have to communicate to align their charging profiles. Otherwise one charge controller could try to maintain the trickle voltage while the other one is in equalization mode. And if you have a lithium ion battery, it makes even more sense to have communication, as the battery management system can then “tell” the charge controllers which voltage it needs for proper charging.
Some commercial charge controllers use RS485 for this type of communication. But RS485 has the disadvantage that it is master/slave only. With CAN you can develop a communication protocol that doesn’t need any master. Every device can communicate with every other device.
In my opinion, CAN is a good compromise regarding cost and reliability. Of course you cannot use any simple single-ended communication like I2C or UART to connect multiple devices over some distance. The next level would be Ethernet, which is way more expensive than CAN.
@greanie: What do you understand as a more efficient, distributed fashion? In my opinion the CAN bus is suitable to do exactly that. You don’t want to spread the system over 1km of course, but you could have your solar panels on the roof, the battery in the ground floor and a smart load (e.g. a water heater to burn excessive solar energy) in the basement.
@solar4572: Can you send me your address via email so that I can send over some PCBs? @greanie You have some PCBs already, correct? BTW: For PCBs where 35 µm copper thickness is enough, I can higly recommend aisler.net.
Now I forgot to talk about the centralized approch. The decentralized approach is the system using CAN. If you only need a small charge controller and a panel in the range of 150 W with a single lead-acid battery, the additional cost for CAN doesn’t make sense indeed. That’s why there is the MPPT-1210-HUS, that does not have CAN, but a serial interface using a RJ25 connector. Using this interface you can still read out data and configure the single charge controller, but it’s almost at zero additional cost because no CAN driver and transceiver are needed.
The stand-alone charge controller also has a USB charging output, as this is often a very useful feature in small systems. The higher power version with CAN doesn’t have it, as most people designing larger systems won’t need it. Let me know if that makes sense to you.
