Open Source MPPT

[thomasow]

Originally Posted by whiskthecat

Good points. I hadn't thought of using the Pfet as I was too hung up on trying to get the higher voltage gate driver for the top fet to be always on. Your way seems simple and worth implementing.

Is there a need to really worry too much about a 100% pass-though state? Given the low leakage of the gates, perhaps just a very slow duty cycle mode to refresh the boost cap would be sufficient for these low-light cases?

Originally Posted by OceanSeaSpray

There is a need for a little more for instrumentation, but that's all I had put on my board indeed. Isolated COM ports and the like chew through more juice and make no sense to me on a boat.

On that Rough unit did you notice they use two uCs, one for the MPPT and another for the LCD. There does need to be some way to gain Vbat information. Just measuring local out at the MPPT can at times be insufficient due to drops, and esp if there are other charging sources running concurrently - depending on how the boat is wired. Having said that, I am a bit underwhelmed by individual instrumentation of the battery: We have 6x different 'Voltage Measuring' devices attached to our house battery

Originally Posted by whiskthecat

Additionally I have been rounding up on describing these "100V" panels as they are actually 86v open circuit. I just picked 100v as there are far fewer component options at 90v if any. Since they are the only panels I know of with bypass diodes for every cell and the only reason I am designing to such a high voltage in the first place, 100V is plenty of headroom for all panels.

Was wondering which specific panels you were looking at, as most the ones I found were in the Voc range of 55-60v. This individual cell bypass feature is very nice, do you know if it is protected IP by SunPower?

Originally Posted by whiskthecat

I haven't put a lot of thought into this yet but it might be possible to run both GaN fet and traditional FET in parallel to try and achieve the benefits of both. The controller would switch the GaN FET on first, which comes on very fast with little gate losses. You'd then be running at about 7mOhm and then you switch on the mosfet at your leisure (the switching doesn't have to be fast because there is already close to 0v across the mosfet since the GaN is turned on next to it) and once it comes on you now have the lower 2mOhm path in parallel. No idea if that's practical yet it might be more efficient (and expensive) to just run 2 GaNs in parallel to reduce the rDSon.

Interesting idea, IIRC there is a greater need for lower Rd on the synchronous (lower) switch, perhaps just focusing on it?

Aside from the core switcher, do need to get a fix on the 'extras' around it: talk of LCD, inter-module comms, Vbat sensing . . . Is easy to let features creep. Should think about some of the other MPPT algorithms, some approaches out there want specific core switcher instrumentation. I think it was talked about prior, but almost without exception - all the open sourced MPPT projects I have seen just use the Tim N. rough-n-ready code - am sure it can be improved upon. (And I think Tim would agree, he positioned it as a get-it-going code IIRC)

What do you see as the next steps? As mentioned, I can pitch in from the software side. I have been looking at the EFM Simplicity IDE, downloaded it and ordered a Zero dev board. Seems SI has put a bit of effort into making things simple and clear, kind of nice.

[goboatingnow]

Originally Posted by travellerw

The charger I posted is $100 for a 20A charger (150V input, 12/24V output) with a huge feature set. The 30A version is $140.
1. MPPT
2. Remote monitoring
3. Software monitoring/configuring
4. Field upgradable firmware
5. Battery temperature montoring/shutdown
6. User adjustable values for everthing
7. Brand name parts
8. Attractive, heat disipative design.

Seriously, there is no way you can beat that value.

I would really love to see you focus your energy on something that makes more sense with less competition. How about an open source Autopilot.

Seriously it makes way more sense since the current offerings are all overpriced designs using Micros that are 10-15 years old. Heck 3/4 of the work is already done if you base it on an existing RC flight controller. The Naze32 or even the KK2 board would be suitable for this task.

I think you would get my more reward going down that path, but thats just my opinion.

a low cost MPPT could be made without case etc , i.e. a PCB for about $30, out one on each panel. There is a clear case for such an idea.

" Remote monitoring" : fluff
"Software monitoring/configuring": fluff
" Field upgradable firmware": double fluff, it works, it works
"Brand name parts": I cant thing where I buy parts with actually no brand on them !

etc etc

Autopilots are not good candidates , as most of the communications protocols are actually proprietary and makes the unit difficult to integrate and anyway the hardware ( rams , pumps ) etc dwarf the electronics

[OceanSeaSpray]

Originally Posted by whiskthecat

Good points. I hadn't thought of using the Pfet as I was too hung up on trying to get the higher voltage gate driver for the top fet to be always on. Your way seems simple and worth implementing. What had you came up with for a startup power supply to run your logic before the main buck had started?

I was just going to use a simple MOSFET LDO linear regulator powered from the solar input with an output voltage lower than the buck output to start it up. Some have quiescent currents in the microamps when doing nothing. It needs to have a small load resistor that is cut out after the MCU starts to ensure there is actually enough power to run the unit when the voltage comes up.
100V input does make things a little more awkward but not impossible. It would likely need a pre-regulator to deal with the over-voltage.
Because I was looking at a power converter and not a charge regulator for reasons explained just earlier, I didn't have battery voltage available and I wanted the unit to power down completely when there was no input. Otherwise use battery voltage to keep the MCU alive, because the last thing you want is restarting a new bulk charge cycle every morning indiscriminately.

Originally Posted by whiskthecat

Yes I had noticed some of the popular brand name MPPT's quoting 99% efficiency, what a joke. Maybe when the thing isn't switching and the panel just happens to be matched to the battery on it's own.

Yes, they do tricks like measuring the standby consumption and then subtracting that before coming up with efficiency and they don't quite say at what output they measured fudged it.

Originally Posted by whiskthecat

The GaN quoted thermal characteristic are with no top package heatsink on a single layer 2oz board. This is far from what I would implement. I was looking into using proper power PCBs with copper substrate. Even still a regular board with top heatsink provided and vias to the bottom with a back whole board heatsink would allow huge improvements in the quoted thermal performance. Also remember that we are using dual phase so that current rating is about where we need to be at already, so we likely could get away with no heatsinking and these devices are especially tolerant to high temperatures (300C) but I wouldn't want to push them if not necessary.

Yes it would all be better. Or just spend a little more money on transistors and run cool off a standard PCB. Occasionally I tolerate a warm MOSFET in infrequent conditions, but these days I prefer to design things to stay almost cold. A little more expensive, but more efficient and much better ageing.

Originally Posted by whiskthecat

As for the lightning scenario I would think it hardly matters. If a device is rated at 100V there is already surge overhead room of about 20v built into that. And if lightning hits you its not gonna be just a 20v bump anwyays, nothing is going to protect from that.

You are very much mistaken there. I am not talking about lightning strike with discharge into the solar wiring (not much would protect against that!), but the effect of the intense flash of light on the solar panel itself. It can cause VOC to spike to 150% of its 1000W/m^2 rating. I use heavy-duty (3kW) transient suppressors on solar inputs for this reason. They clamp down really fast, but the voltage can still rise quite a bit if the current is intense.
If a FET is rated 100V, that's it. It would be bad enough to design for the absolute maximum rating, let alone exceed it. There is no reliability to be found there.

Originally Posted by whiskthecat

Here is the GaN I was looking at by the way. They are $6 per chip which isn't so bad when you look at the price of comparable FETs. To keep the size of the thing and the cost of the passive components down, before I ever even thought to use GaN I was looking to keep the frequency above 100khz (dual phase equivalent 50khz) I haven't put a lot of thought into this yet but it might be possible to run both GaN fet and traditional FET in parallel to try and achieve the benefits of both. The controller would switch the GaN FET on first, which comes on very fast with little gate losses. You'd then be running at about 7mOhm and then you switch on the mosfet at your leisure (the switching doesn't have to be fast because there is already close to 0v across the mosfet since the GaN is turned on next to it) and once it comes on you now have the lower 2mOhm path in parallel. No idea if that's practical yet it might be more efficient (and expensive) to just run 2 GaNs in parallel to reduce the rDSon.

Yes those would all be possibilities, they would certainly run in parallel but separate gate drivers would be needed for best result if using dissimilar types. What I would do I think is enable the second gate driver when the current is high enough to warrant it, especially if paralleling with standard MOSFETs with a gate charge around 10x higher than the GaN FET.
Such a hybrid approach could be very beneficial from a cost and efficiency point of view as it could keep the GaN FETs smaller.

Those are the same devices I was looking at yesterday. Here is another candidate with lower rDSon, but a little more costly.

Dual-phase doesn't really reduce switching frequency, it just "distributes" it, so the lowest practical frequency is still going to give the best results. The toroidal inductor in the little Genasun unit - from memory - would have been 1'' in diameter with a good 20 turns of heavy wire on it. I didn't look too closely, but it looked like a Bourne 2300-series and my guess would be that it could be clocked around 50kHz or less. It certainly isn't a high-frequency unit.

[OceanSeaSpray]

Originally Posted by thomasow

Aside from the core switcher, do need to get a fix on the 'extras' around it: talk of LCD, inter-module comms, Vbat sensing . . . Is easy to let features creep. Should think about some of the other MPPT algorithms, some approaches out there want specific core switcher instrumentation. I think it was talked about prior, but almost without exception - all the open sourced MPPT projects I have seen just use the Tim N. rough-n-ready code - am sure it can be improved upon. (And I think Tim would agree, he positioned it as a get-it-going code IIRC).

As far as MPPT goes, the algorithm doesn't need to know or care about VBat. It only needs Iout. You can literally vary the PWM duty-cycle to maximise Iout and leave it at that. It will also offer the fastest tracking.
VBat would be needed for charge regulation and then it needs to be externally sensed over a twisted pair.

My suggestion would trimming off all of the "extras" precisely. They don't actually add any value, just cost and complexity. If you have a bloody excellent unit, you can forget about it. No need for watching the cute MPPT channel on DC Power TV.

[goboatingnow]

The main form of mppt is perturbate and measure. Determining the direction of best Power , you need to also scan the range of Imp to handle ghost Vmp points as some PV cells have multiple " pseudo " Vmp points.

Whole thing would make an excellent KickStarter project.

Dave


Sent from my iPhone using Cruisers Sailing Forum

[thomasow]

So, that's just it - the most noted approach for MPPT assesses panel wattage, while there is also an approach which focuses on Ibat and maximizes it. But in the details one also needs to consider outside influences, as well as monitoring Vbat for its charging needs. Volts tends to be simple, Amps a bit less so - but perhaps what is also interesting is a less critical need to have absolute accurate of Amps measurement, vs. consistency to allow the showing of trends.

I agree one should leave the chrome off of things, there are lots of products out there with bells and whistles, lights buttons and displays. One does need to have some way to configuration for install, hopefully without an engineering degree - and perhaps a 'Doing OK, or Oh Oh' indicator of some type - but at the same time if too stripped down why not just purchase a cheap China unit?

Might add in now: This type of project will find an audience in market segments other than marine - specifically the off-grid group. Their requirements tend to mirror marine closely, with perhaps the potential for larger total deployments and an quicker embracement of 48v battery systems.

[OceanSeaSpray]

Originally Posted by thomasow

So, that's just it - the most noted approach for MPPT assesses panel wattage, while there is also an approach which focuses on Ibat and maximizes it. But in the details one also needs to consider outside influences, as well as monitoring Vbat for its charging needs. Volts tends to be simple, Amps a bit less so - but perhaps what is also interesting is a less critical need to have absolute accurate of Amps measurement, vs. consistency to allow the showing of trends.

It is because:

1/ Current is what matters when you are charging a battery. The more current, the better anyway.
2/ Because we are essentially "powering" at almost constant voltage (battery voltage), power essentially varies with current.

There is no real point in performing the product P=VxI.

This allows to implement MPPT by simply maximising current. Current is easy and cheap to get, you insert a small shunt resistor into the output ground circuit and amplify the tiny voltage drop it creates. Calibration is irrelevant as you say.

Originally Posted by thomasow

I agree one should leave the chrome off of things, there are lots of products out there with bells and whistles, lights buttons and displays. One does need to have some way to configuration for install, hopefully without an engineering degree - and perhaps a 'Doing OK, or Oh Oh' indicator of some type - but at the same time if too stripped down why not just purchase a cheap China unit?

The unit doesn't really need more than a simple LED: it is operating (a simple duo LED can show 3 colours by the way).
Stripped down is one thing, quality is another one. There are plenty of fancy-looking units to be bought which are garbage and removing "features" wouldn't make them any better. They operate poorly, create heat, age and fail quickly etc.

There is no configuration really as far as the MPPT section goes. It just does a very simple job. When it comes to charging - if this ended up integrated - in its simplest form you could just build the unit for a type of battery (Genasun approach) and because it is open-source it can always be reprogrammed if ever needed.

[whiskthecat]

Lots of replies, good stuff guys.

Is there a need to really worry too much about a 100% pass-though state? Given the low leakage of the gates, perhaps just a very slow duty cycle mode to refresh the boost cap would be sufficient for these low-light cases?

The only real reason you would need to be at 100% duty cycle is if the input voltage were very near the output. The Pfet idea will likely have other uses with startup supply. Even though a battery is present I would like the controller to be able to start on solar power voltage alone to account for the case where the battery is completely drained somehow.

On that Rough unit did you notice they use two uCs, one for the MPPT and another for the LCD.

I was already thinking about this. If we do end up deciding to add a bunch of bells and whistles, which I don't see why not as long as they don't interfere with the core function, it would likely make sense to have two uCs. Often the ones really good at high resolution PWM are not the same ones good at general data handling. I'm sure there are better PWM choices than the EFM I would prefer. I just don't know yet, haven't looked in to it. Still deciding overall power layout.

Was wondering which specific panels you were looking at, as most the ones I found were in the Voc range of 55-60v. This individual cell bypass feature is very nice, do you know if it is protected IP by SunPower?

I linked the datasheet in my last post. Those are the exact panels I'm looking at. I doubt they have a patent on including a diode in every cell, but I also wouldn't be surprised if they are the only one currently doing it.

Interesting idea, IIRC there is a greater need for lower Rd on the synchronous (lower) switch, perhaps just focusing on it?

Very good point. They are I^2R losses and the lower leg is handling much more current. It would be a cost saving measure for sure. I still haven't decided whether I want to be really cheap or really high performance, likely somewhere nice in between.

What do you see as the next steps? As mentioned, I can pitch in from the software side. I have been looking at the EFM Simplicity IDE, downloaded it and ordered a Zero dev board. Seems SI has put a bit of effort into making things simple and clear, kind of nice.

Indeed it is a great package from SiLabs. I promise you will like it. Their MCUs are just jam packed with peripherals and they are as low power as it gets. Half the time you don't even need the CPU on to be doing a lot of different stuff. As for next steps once everyone here can agree on a general goal and power layout I'd order a few different configurations of components and start playing around/tweaking to get the most efficient setup.

a low cost MPPT could be made without case etc , i.e. a PCB for about $30, out one on each panel. There is a clear case for such an idea.

Or a really high performance one with all the fluff at the same price as the barely passable chinese units. There is a lot of room for play I think.

"Brand name parts": I cant thing where I buy parts with actually no brand on them !

You need to open up and examine some chinese electronics. Some of the "brand names" written onto the components in hideous fonts are quite laughable. "SamYoung" is that an attempt to sound like "Samsung"? lol

Autopilots are not good candidates , as most of the communications protocols are actually proprietary and makes the unit difficult to integrate and anyway the hardware ( rams , pumps ) etc dwarf the electronics

I can't really comment on these as I haven't looked into them at all yet. But, I do intend to have one at some point and if I don't like what I see I'll make my own.

100V input does make things a little more awkward but not impossible. It would likely need a pre-regulator to deal with the over-voltage.
Because I was looking at a power converter and not a charge regulator for reasons explained just earlier, I didn't have battery voltage available and I wanted the unit to power down completely when there was no input. Otherwise use battery voltage to keep the MCU alive, because the last thing you want is restarting a new bulk charge cycle every morning indiscriminately.

Yea the only thing I can come up with is using a separate high voltage low current buck converter to run the logic with. Kinda lame considering the whole thing is a buck. As stated earlier in this post I really want it to be able to start off panel voltage alone. Relying on the battery to work means the damn thing wouldn't be able to charge a completely dead battery. No worries about losing memory of the last bulk cycle as we will def have nonvolatile data storage available.

Yes, they do tricks like measuring the standby consumption and then subtracting that before coming up with efficiency and they don't quite say at what output they measured fudged it.

Yea it's one thing for the chinese controllers to spew out complete nonsense figures, expected. But for the name brands to be doing it as well, quite stupid.

Yes it would all be better. Or just spend a little more money on transistors and run cool off a standard PCB. Occasionally I tolerate a warm MOSFET in infrequent conditions, but these days I prefer to design things to stay almost cold. A little more expensive, but more efficient and much better ageing.

I'm right there with you. I like to be able to hold my thumb to my IC's without it being burned. I'll certainly be doing any prototyping with regular PCBs using top heatsinks on the SMD fets and a board wide bottom heatsink with via heat transfer. I highly doubt it will be unsatisfactory, the power PCB is just a backup plan at this point.

If a FET is rated 100V, that's it. It would be bad enough to design for the absolute maximum rating, let alone exceed it. There is no reliability to be found there.

Ah, I thought you meant the bolt hitting the panel not just the light flash from the lightning. The fets are avalanche rated and will accept energy driving them over their rated drain to source voltage to their breakdown voltage.FETs usually break down and allow current through at 1.3 times their rated drain to source voltage, the current rises accordingly with power. This doesn't mean instant death. Whether or not the fet is damaged depends on the amount of current and for how long it is exposed. Your average low rDSon mosfet is rated for about 1 Joule of avalanche energy. I don't know the exposure time for a lighting strike but a quick google suggests about 30 microseconds. Basically, as long as the spike doesn't exceed the maximum current of the device for more than a tenth of a millisecond, which it likely wouldn't since low rDSon devices are often high current (100+amps), you will be fine. Like I said I'll be using 100v fets hooked to an 86v open circuit panel each fet supporting more than double the drain current it will be using so I imagine that is a fair bit of headrom. That all applies to traditional fets though, how it works with GaN I have no idea. Still reading into it.

Yes those would all be possibilities, they would certainly run in parallel but separate gate drivers would be needed for best result if using dissimilar types. What I would do I think is enable the second gate driver when the current is high enough to warrant it, especially if paralleling with standard MOSFETs with a gate charge around 10x higher than the GaN FET.

Yes, the GaN drivers are not applicable to the regular fets and vice versa. So cost will go up. But you can get dirt cheap fet drivers if you aren't all that concerned with turn on speed which we won't be since the fet will be close to 0v. It seems like this would be a novel way to implement ZVS for the fet without having to use an inductor clamp switch which is currently a bit mysterious to me.

Those are the same devices I was looking at yesterday. Here is another candidate with lower rDSon, but a little more costly.

Yea that would be better but digikey has no stock and no expectation date for stock.

Dual-phase doesn't really reduce switching frequency, it just "distributes" it, so the lowest practical frequency is still going to give the best results. The toroidal inductor in the little Genasun unit

Agreed, poor wording on my part. I meant to say it reduces the requirements for capacitors and inductors as if the frequency were higher than it actually is. This effectively reduces how low you can go and still have reasonably sized and priced passives.

VBat would be needed for charge regulation and then it needs to be externally sensed over a twisted pair. My suggestion would trimming off all of the "extras" precisely. They don't actually add any value, just cost and complexity.

Yes we need to know VBat to make sure we don't blow up the battery with excessive voltage/current. Maximizing current is great when you are at 50% state of charge. Not so much at 100% if you are going to do so by just letting the voltage rise. Some people may have more panel current available than their batteries would like to accept at once. I'd say as far as the extras go it would be nice to have some logging so you could track your own power generation throughout the day as well as an approximation of state of charge to get an idea how much you are using. Certainly not necessary but might be a welcomed feature for many. The core idea here is certainly going to be set it and forget it. Maybe just a small LCD to look at on really sunny days and admire your power generation.

Current is easy and cheap to get, you insert a small shunt resistor into the output ground circuit and amplify the tiny voltage drop it creates.

Hey now, we can't go increasing our on resistance, we should just measure the drop across the lower fet. Some people are also using hall effect sensors. Anything to avoid purposely adding resistances.

There is no configuration really as far as the MPPT section goes. It just does a very simple job. When it comes to charging - if this ended up integrated

I really feel the charge controlling needs to be integrated. It is the main load we are feeding into and without it, idk it seems odd. What else would you intend to do with the MPPT besides charge your batteries. So why not include that core functionality. The battery charging part is quite mysterious to me and there seems to be a lot of different info out there on how to go about doing it and what is a good idea and what isn't.

[OceanSeaSpray]

Originally Posted by whiskthecat

....
Hey now, we can't go increasing our on resistance, we should just measure the drop across the lower fet. Some people are also using hall effect sensors. Anything to avoid purposely adding resistances.

I really feel the charge controlling needs to be integrated. It is the main load we are feeding into and without it, idk it seems odd. What else would you intend to do with the MPPT besides charge your batteries. So why not include that core functionality. The battery charging part is quite mysterious to me and there seems to be a lot of different info out there on how to go about doing it and what is a good idea and what isn't.

I thought you would say that, but <1mOhm is not exactly much and it is by far the cheapest way of getting a good current reading after the output filters... If the current is really high, then Hall effect sensors are the way to go, ok.

The catch is that if you integrate charge control, you instantly create a problem for all multi-bank systems, which is most everybody. You can't properly charge more than one battery with a single regulator, they each have their own state of charge and need their own control.

NV storage won't really cut it as you still don't know what happened since. The easiest is keeping the charge controller powered all the time, it is a matter of microamps.
What I started building is a modular system with an isolating (non-return) solid-state multi-battery power switch, a multi-bank charge controller and the missing piece is a high-efficiency buck converter. The idea is regulating more or less all sources in one place with the solid-state switch doing the work. The solid-state switch can do PWM, dump excess power into a load etc.

Wind generators, tow generators would all produce more power if hooked up to MPPT converters... but let's do solar for now!

Just a mid-range PIC would do as a MCU because there is bugger all to process and some come with PWM generators, but the EFM 32-bit ARM chip is certainly a beast in comparison! What I would think about is long-term support and availability. You will never run out of options with Microchip or Atmel and they will be around in 10+ years.

[whiskthecat]

Originally Posted by OceanSeaSpray

The catch is that if you integrate charge control, you instantly create a problem for all multi-bank systems, which is most everybody. You can't properly charge more than one battery with a single regulator, they each have their own state of charge and need their own control.

What's the idea behind a multi-bank system anyways? Why not just parallel all your batteries. If you want a separate starting battery, keep it trickle charged topped off the main bank.

Originally Posted by OceanSeaSpray

NV storage won't really cut it as you still don't know what happened since. The easiest is keeping the charge controller powered all the time, it is a matter of microamps.

I would assume you could figure out what was going on based on SOC, but if there really is some reason it should be no problem to include a supercapacitor or small lithium watch battery for the MCU to sip on while sleeping. Should run it for years after the main bank dies.

Originally Posted by OceanSeaSpray

What I started building is a modular system with an isolating (non-return) solid-state multi-battery power switch, a multi-bank charge controller and the missing piece is a high-efficiency buck converter. The idea is regulating more or less all sources in one place with the solid-state switch doing the work. The solid-state switch can do PWM, dump excess power into a load etc.

Wind generators, tow generators would all produce more power if hooked up to MPPT converters... but let's do solar for now!

I still can't grasp it. It's like you are adding a buck after the MPPT buck. Instead of panel, buck, battery; you have panel, buck, buck, battery. And since it is mostly just logic and software to add the charging to the MPPT controller I don't see why not to add it. If you want multiple separate devices it would be easy to make a master slave setup where one MPPT handled battery charging and commanded all the others. I can't think of a reason to have an intermediate voltage between the panels and the bank if that is what you are suggesting. I feel like I must be missing something obvious?

Originally Posted by OceanSeaSpray

Just a mid-range PIC would do as a MCU because there is bugger all to process and some come with PWM generators, but the EFM 32-bit ARM chip is certainly a beast in comparison! What I would think about is long-term support and availability. You will never run out of options with Microchip or Atmel and they will be around in 10+ years.

Well as long as it is an ARM core it will be highly portable. I don't think ARM chips are going to disappear anytime soon.

[goboatingnow]

have you considered just using a low cost SMPS board and using it to implement MPPT and battery charging . in essence an MPPT charger is just an input regulated power supply

[whiskthecat]

The way I see it we are varying the output voltage in order to control how much load is applied to the panel. Higher voltage to the battery bank, higher charge current, higher load. We load the panel down until we reach the maximum power point, less load than this and we lose, more load than this and we lose. Most commercially available buck modules are interested in keeping the output voltage as stable as possible. I originally looked in to using an integrated buck regulator IC and controlling the output voltage via the feedback resistance. But, it seems to be much more flexible to just do everything yourself with your own custom solution.

For example you could probably hook this to a 100watt panel and control its feedback potentiometer with a cheap microcontroller and have the worlds cheapest MPPT. But it's certainly not highly efficient or high power.

[thomasow]

OK, going to step out here and draft up a proposed hardware set of goals and requirements. Just a start, and if there is indeed interest going forward can perhaps look for a more specific PRD.

I would offer the following high level design goals:

• Support for one ‘large’ panel in a 12v deployment.
  • 350-400w as high water mark for large panel
  • Drives need for Vpan >= 85v or so, and Iout >= 30A or so. (Call it 100v with margin, this will support Wiskercat’s monster 435w panel!)
  • Note that higher battery voltage could support more panels (Keeping Iout <= 30A - limited design heat dissipation and components selected)

• Support for 12v .. 48v batteries
  • Drives a need for Vbat max >= 68v

• Support for different charge profiles
  • FLA, AGM, LiFeP04, etc
  • Option to modify as needed

• Local voltage measurement as lowest default
  • Option to instrument remote Vbat
  • Very simple installs can make due with measuring at MPPT output, larger installs will need ability to gain knowledge of actual Vbat at battery - often bat temp as well.

• Warm-n-fuzzies:
  • High conversion efficiency
  • Low controller power overhead
  • Also being mindful of PWM off during nighttime.
  • Simple install – 4 wires, set mode (e.g. Dip switch) in min installs

• Environment:
  • Water resistance – some level t.b.d.
  • Temperature range – Need to consider unit might be installed outside, and under panel. So consider cold and hot.

• Basic status LEDs
  • Working, idle, off – etc. Details TBD but folks get nervous if they have no confirmation device is working, or faulted.

• Some ability for higher ‘Watching the MPPT show’ – but would offer this as an option.
  • No local LCDs - given the micro-controller architecture here, it is likely the controller will be installed in a location not readily accessible to the user (though simple installs this might not be true).
  • That and the increased cost of replication of LCDs on each controller – I would offer that more advanced monitoring should be done using a different (and likely remote) device.

• 3 levels of user configuration:
  • Simple – Select predefiend battery type – e.g.: DIP switches
  • Expanded – Allows custom charge profiles and options.
  • Customize – Opensource = modify source code and reflash

We should not depend on the last option for all user configurations. Opensource does not need to mean hard to use.

Originally Posted by whiskthecat

You need to open up and examine some chinese electronics. Some of the "brand names" written onto the components in hideous fonts are quite laughable. "SamYoung" is that an attempt to sound like "Samsung"? lol [IMG]file:///C:\Users\Win7\AppData\Local\Temp\msohtmlclip1\01\c lip_image001.gif[/IMG]

Or other fun and games – I received a batch of boards using a cloned uC – looked OK on the outside, but the internal chip ID did not quite match up… On that, china does not automatically = bad. It is possible to get good quality, but it takes work up front and ongoing.

Originally Posted by whiskthecat

I really feel the charge controlling needs to be integrated. It is the main load we are feeding into and without it, idk it seems odd. What else would you intend to do with the MPPT besides charge your batteries. So why not include that core functionality. The battery charging part is quite mysterious to me and there seems to be a lot of different info out there on how to go about doing it and what is a good idea and what isn't.

I have a pile of research on battery charging needs – done for the alternator regulator and DC gen projects. And you are right, there is a lot of info out there – some of it being rather creative due to the lacking of a given charging solution: meaning, they are not able to follow manufactures charging profiles, so they come up with a different approach and promote that as ‘The Way’. We need access to Vbat, and depending on the battery chemistry, battery temp and acceptance amps as well – to do it right. But this brings up the Systems conversation – perhaps for another post.





Some comments on the design:

Originally Posted by whiskthecat

The only real reason you would need to be at 100% duty cycle is if the input voltage were very near the output. The Pfet idea will likely have other uses with startup supply. Even though a battery is present I would like the controller to be able to start on solar power voltage alone to account for the case where the battery is completely drained somehow.

I think a couple of ORing diodes would accomplish that – feeding Vbat and Vsol into the power supply. Will note that bringing in Vsol raises the max voltage, further restricting available power supply options out there


One or two CPUs, I think much of this will really come down to how your propose to drive the PWM ckt. Solar MPPT really does not have a lot of computing needs, and one tends to run out of code space well before the uC runs out of steam. However, if you have the uC doing PWM under software control – need to be mindful of the risk of software errors halting the uC. A watchdog can recover, but it might be too late at that point.

And along that lines, the uC selection is a bit open – and I would say perhaps dependent on other considerations: price, availability, support in the community, integrated features (that last one perhaps the most critical one of the reasons I selected the ATmega32M1 for my MPPT project: its hardware based PWM engine with hardware based overAmp detection and shutdown). The EFM looks to be low cost, and a nice simple design. And it does look like they have put a lot of effort into their support tools – I esp like how their reference libs are easy to follow, none of nonsense like the high minded ‘my code is so good it needs no comments’. Nothing particularly against it, but would offer as a core design gets sketched together might be time to then look at the uC selection.

OK, as I said a proposed start for design goals.

-al-

[goboatingnow]

As an EE , I find there is some confusion here in mixing MPPT and battery charging. Perhaps it might be better to define the MPPT first , the charging is easier, because in reality MPPT only applies in Bulk charge mode, with any sort of high output panels.

As an embedded engineer, I would suggest CorTex M0 is the preferred platform. ( as a former Atmel developer )

[OceanSeaSpray]

Originally Posted by whiskthecat

What's the idea behind a multi-bank system anyways? Why not just parallel all your batteries. If you want a separate starting battery, keep it trickle charged topped off the main bank.

Paralleling batteries is the crappiest way of dealing with the multi-bank issue. People do that because they think they understand it and marine electrical dealers are so happy to sell them paralleling switches, VSRs and other similar garbage.
At best it is wasteful and otherwise just consider two batteries of different types and the whole edifice collapses.

Originally Posted by whiskthecat

I would assume you could figure out what was going on based on SOC, but if there really is some reason it should be no problem to include a supercapacitor or small lithium watch battery for the MCU to sip on while sleeping. Should run it for years after the main bank dies.

If battery voltage is available there is nothing to fuss about. It is always available to a charge regulator.

Originally Posted by whiskthecat

I still can't grasp it. It's like you are adding a buck after the MPPT buck. Instead of panel, buck, battery; you have panel, buck, buck, battery. And since it is mostly just logic and software to add the charging to the MPPT controller I don't see why not to add it. If you want multiple separate devices it would be easy to make a master slave setup where one MPPT handled battery charging and commanded all the others. I can't think of a reason to have an intermediate voltage between the panels and the bank if that is what you are suggesting. I feel like I must be missing something obvious?

A switch is not a buck. Also there is a need for isolating parallel banks. The buck does the power conversion, the switch distributes it according to charging algorithms. There is no such thing as "intermediate voltage" because we are just pumping current. The buck output voltage is determined by the batteries and it doesn't actually matter.
It would make no sense at all to run several buck converters in parallel off the same source just because the power has to go to different places. Distribute it afterwards.

It isn't quite software only to add the charge controller to the buck. If you just do that in its simplest form, you can only ever charge one battery, end of story. At a minimum, if charging was integrated, it should offer dual isolated outputs for house bank and starting battery. I run three banks:
1/ Engine starting
2/ House
3/ Instruments, compass light etc. Some loads like nav lights can be switched from 2 to 3 if ever needed. This is only a modest battery with no large loads on it.

I have built charge controllers for over 20 years. I have now separated the power switch/isolator from the controller so the switch can be scaled as required and the controller stays the same. A single control point allows to do things like priority charging and not wasting energy into trickling juice into fully charged batteries while another one still needs bulk charging.

If an integrated single-output charge controller is present, leaving a few parts off the board and tweaking the code will quickly fix it however. It is not a show-stopper.
Now this being said, properly and efficiently charging a lead-acid battery requires external, at-the-battery, current sensing. This is nowhere to be found on all the garbage marine charge controllers on the market. They have no idea of when to terminate absorption, they just do "after a while".

Originally Posted by whiskthecat

Well as long as it is an ARM core it will be highly portable. I don't think ARM chips are going to disappear anytime soon.

The idea would be not having to port it precisely... That would be the least of my worries however. The code will be so small and so simple, the MCU could be swapped on the fly. My thoughts were more along the lines of using something truly common and intended for this type of application.