Jump to content
Genetry Solar Forums

Sid Genetry Solar

Administrators
  • Posts

    1,747
  • Joined

  • Last visited

  • Days Won

    186

Everything posted by Sid Genetry Solar

  1. It would be a good idea to have one on the inverter's AC input. There's a small MOV internal to the inverter on the AC input--but if that isn't sufficient to clamp a surge, the inverter might not survive too well.
  2. Possible. I don't know for sure--I would need more diagnostics from the inverter to determine. Obviously, the inverter doesn't need to error out when dropping back to battery unless there is a problem. If it does it again...could you get me pictures of 2 channels on the WiFi board "scope" before resetting the inverter? They're DVLT and DAMP (diagnostic voltage, diagnostic amps)--those show what was going on with the power before it errored out. (OUT tab -> press Enter -> press Down twice (should highlight "Scope") -> press Enter. Once in the 'scope screen, you can press Down until you reach channels #6 [DAMP] and #7 [DVLT].) Screen should look something like this, though the graph shown likely will be considerably different than here with my bench inverter at idle! I would appreciate photos of channels #6 [DAMP] and #7 [DVLT] after an inverter error, and BEFORE you reset it (i.e. while your power is out and the inverter's beeping!) That should help narrow down what the inverter's tripping out on.
  3. Add 2 for voltage sensing lines (PV and battery)... ...2 more for UART if you have any intentions of connecting to a "central controller", maybe even for firmware updates, etc., etc. ...and remember, there's nothing worse than wanting to add a feature, and having backed yourself into a corner with lack of I/Os. Also remember the fact that the XIAO is a 3.3v processor, while all of the signals likely are 5.0v. The ADC on the XIAO will reach max value at 3.3v...which is 60% of the full scale that the existing circuitry (likely will) provide. Obviously, you can scale analog signals with an appropriate resistor ladder, but that's just something more to do. It'd also be a good safety if the MCU has a hardware shutdown for the PWM modules--that would be a good overcurrent protection for the FETs.
  4. Weird. What's the control board version on your inverter? (A.1 / B / C.) And, what's the firmware revision? (OUT -> Diagnostic Info -> top lines) With that info, I should be able to determine what could cause that error.
  5. Good to know. Would help to know a tad more info from the inverter--obviously I'm sure you've reset it by now 😉. Will have to tweak a few more things and do another update. Obviously, the firmware needs to keep the inverter safe (even if that means shutting down) and not let anything potentially damaging through. Do you have a surge suppressor on the inverter's input power wires?
  6. Well, you don't need all that processor speed in the first place--not unless the Arduino abstraction layers slow the MCU down too much. Just before you jump out and buy a couple of those boards, there's two significant problems to consider first: The XIAO is 3.3v only. The NUC100 supports up to 5.0v, and I believe the MSB runs it at 5.0v. This means that you'll likely end up needing to redesign ALL of the analog feedback circuitry to a 3.3v scale instead of the 5.0v designed scale. Prepare to get very familiar with SMD rework...! The XIAO is simply too small. 11 I/O pins will go...well...right about nowhere if you add everything up: figure at least 3 I/Os for an SPI OLED display probably another 3 I/Os for buttons 2 I/Os for UART comm (if you want computer connection) 4 I/Os for the synchronous MPPT buck drivers (2 per phase, as they're run out-of-phase to reduce output ripple)--these will need driven with proper half-bridge PWM control outputs on the MCU (dead time, current limit, etc.), and definitely not "a simple Arduino PWM command." You'll likely need to dig into the processor datasheet and start poking values into registers to get the necessary functionality--that of course is assuming it does have at least 2 half-bridge PWM modules. (Disclaimer: I haven't studied the MSB design, so you'll have to figure out what they did and what it needs.) 4-5 analog I/Os (input/output voltages & currents, temps) and keep at least another 4-5 I/Os for spares/expansion. (I haven't studied the MSB design, and don't know what else may need controlled.)
  7. I couldn't quite figure it out either; I got a Nuvoton dev board with a built-in programmer...followed the step-by-step instructions and got the Eclipse IDE to work with it...but I couldn't figure out how to use it properly. For Windoze, there's drivers and a programmer for the entire product line. But I couldn't figure out how to connect those to Wine, etc. That particular programmer is for the N76E003, which is an 8-bit product family. Not the 32-bit ARM core of the NUC100. Nuvoton seems to have quite the convoluted programmer ecosystem, which doesn't help either... For example, the "ICP-ISP" programmer...is only for the 8-bit product families: https://direct.nuvoton.com/en/isp-icp-programmer The "Nu-Link-Pro" (which I have) is for most of them (NuMicro M0 / M23 / M4 Family & 8051 (1T): MS51 / ML51 / N76E Series.) Worth noting that the NUC100 is under the "M0" family.) They also have the "Nu-Link", but I'm not fully sure what all it supports. Worth noting that both the "Nu-Link-Pro" and "Nu-Link" say that they are a USB-SWD bridge. That right there might be a huge clue... The goldmine basis of a Linux programmer that I found for the 8-bit series is https://github.com/erincandescent/nuvoprog . But on that homepage, he DOES reference OpenOCD. Considering the above USB-SWD bridge programmer modus, as well as the fact that MOST of the Nuvoton processors are ARM-core based...there might be some way to pull these pieces of the puzzle together? If you can get the official Nuvoton ICP tool to work w/ USB (should be easy in Windoze, but if you're on Linux, maybe you can sort it out--I couldn't!), that makes life CONSIDERABLY easier, as it should work with the Nu-Link-Pro programmer on the entire Nuvoton product line. One of the downloads on this page...! https://www.nuvoton.com/tool-and-software/software-tool/programmer-tool/ I have to say, this sort of convoluted ecosystem is why I'm not surprised that Nuvoton processors are in ready stock, and so cheap. If someone can capitalize on the lack of ecosystem, it's a goldmine--especially in the chip shortages when ALL of the common chips (ST, Microchip, Atmel, etc.) are hard to find and/or simply out of stock. That quite stymied me when I was trying to figure out the Nuvoton stuff the first time...ALL processors that I've used (mostly Microchip) have "configuration bits" that configure initial oscillator, code protection, peripheral control, etc., etc. And for some inexplicable reason, I can't find anything about "configuration bits" in ANY of the Nuvoton stuff. But when I did finally get the MS51FB9AE programmer thing working (8-bit MCU)...wouldn't you know, there were configuration bits to set (and code protection is one of them). Chances of finding a pin-compatible MCU outside of the Nuvoton ecosystem are slim to none. But not impossible.
  8. You can buy some Nuvoton supplies from Digi-Key (alternatively, you can purchase direct from Nuvoton). I don't think Nuvoton has a "Nu-Link-Pro" driver for Linux...though if you're really handy you'll probably be able to either find something or hack something together 😉. The "Nu-Link-Pro" driver I'm using on Ubuntu for the MS51FB9AE was an open-source project on GitHub...which was forked, and someone else added the necessary processor support.
  9. I seriously doubt that you will be able to download any firmware from it--all MCUs have a "code protection" bit that I pretty well guarantee you will be set. What you CAN do is desolder their WiFi dongle and cobble a serial adapter to it and get some stats/data from it--and print it on a meaningful screen. I will say (having just started to work with Nuvoton MCUs this year) that their ecosystem is extremely crude. But the MCUs are extremely powerful and cheap--possibly because the ecosystem is SO hard to work with! Spent some frustrating weeks trying to get a dev system working for their (very cheap but highly capable) MS51FB9AE MCU--which their official system only works on Windoze, and costs some $3k for a Keil uVision license. Managed to get it working with FOSS (free open source software), but boy was it difficult!
  10. Technically, as I do have a Nu-Link-Pro Nuvoton ICP/ISP tool--and I don't care if I brick the MSB--I could technically try to get a chip ID out of the "BettSun" for positive ID. If I could find my photos of the previous board/MCU, I could check pinouts and be able to say for sure...
  11. I believe your guess is correct here. I don't know for sure, but I would be highly surprised if they've changed the MCU, especially when the "BettSun" unit still sports "v119" firmware. The MCU used to be a Nuvoton 32-bit ARM-core processor; unfortunately I don't have any of those "older" MSB units, and the only unit I have has the rebranded "BettSun." But from my web search history (when I looked up the previous one out of curiosity), I believe the original MCU is a Nuvoton NUC100LE3AN (closest I can find on the Nuvoton website is a "DN"...https://www.nuvoton.com/products/microcontrollers/arm-cortex-m0-mcus/nuc100-200-advanced-series/nuc100le3dn/ )
  12. A much simpler proof-of-concept design would be to increase the dead-time to 1uS+ and see if that helps. If it's too long, the transformer will start to get "buzzier." If it has been too small, your no-load current will decrease as you increase the dead-time.
  13. Why do you need separate TLP351s for each FET? You could just as easily use a single TLP350 (2.5A) per quadrant...or if you can find it, a TLP358 (6.0A). EDIT: there's also TLP352 (2.5A), and TLP700 (2.5A). TLP352 has a propagation delay of 200nS, error +/-80nS. Considerably better than the TLP351 (at 700ns, error +/-500nS) or the TLP350 at 500nS max.
  14. At least so far as I've seen, BJTs are CONSIDERABLY slower than FETs. (This could become quite problematic if Miller spikes are an issue; at 24v, you likely won't have a serious issue with them.) The TLP351 has a propagation delay time of <1uS--I will be surprised if you can match that speed with BJTs of any significant size. Also worth noting is that with the fully isolated opto-drivers, they become the "failure end" point--in GS inverters, damage never once has traveled upstream from the opto-drivers to the CPU. However, seeing up to 700nS listed on propagation times PLUS a variance of up to 1uS...yeah, your dead-time at 500nS is way too short 😉. You need a longer dead-time...totem pole BJT or not. Whoa, really like that Rds(on) of 2.4mOhm... ...gate capacitance isn't too bad (5000pF), reverse transfer is OK at 55pF... ...switching speed is EXTREMELY fast at 32nS total on, 82nS total off...good luck finding a BJT that's anywhere close to THAT! Looks like a solid FET to me. EDIT: You might be able to get an even lower Rds(on) if you drop to 40v FETs. For a 24v system, 40v FETs should be decently adequate.
  15. Hmm...unless you can prove otherwise via your 'scope, this might be a little too low. Remember, transformer inductance/behavior changes CONSIDERABLY between no-load vs loaded--so just because it works at no load doesn't necessarily indicate that everything's kosher. All it takes is the transformer pulling a bit harder--increasing the FET "pull down" time, and you can easily have an H-bridge cross-conduction event. If one there's one thing those DC bus filter caps have (assuming they're sizeable), it's enough power to fry FETs instantly! GS inverters run closer to 2uS dead time; for software debugging, I hard-limited the dead-time at no less than 500nS--as the no-load current starts to notably increase as the dead-time is reduced much below 1uS (due to cross-conduction). The longer the dead-time, the more "buzzing" noise you'll get in the transformer (as the transformer's kickback is allowed to "build" before the FETs clamp it). The shorter the dead-time, the quieter the transformer will get...until H-bridge cross-conduction starts to increase no-load current. (You should easily be able to see the dead-time on your 'scope when observing drain-source and/or the transformer primary.) Can you zero in on parts of the waveform and/or "freeze" the view? I personally misunderstood what was meant by a "storage" scope for the longest time. I currently have a Siglent SDS1104-X...and "storage" seems to simply mean that I can hit the "Stop" button and it'll "freeze" what's on the screen. Depending on the capture depth, I can then zoom in and examine things a bit closer, etc. If you were only using a single FET per quadrant...your FETs have a 25C continuous rating of ~90A. At 24v, that's barely 2kw without considering inefficiencies. (It's worth noting that the "pulsed drain current" rating of 300A+ is more or less useless for calculating "inverter surge"--as said rating is usually specced at 100uS, not the 250mS an AC startup surge can easily run to!) I personally prefer to calculate FET maximums by using their 100C rating, as that gives a solid safety margin regardless of FET temperature. (Which for the IRFB7545 is all of 67A...and if you had 2 per quadrant, that's 67 * 2 = 134A * 24v = just over 3kw.) If all measurements (under load) look clean and good, and the dead time isn't too low...you might just need more parallel FETs. But if it blew out with a 250W light bulb, then there's probably something fishy going on with the FET signals. So a negative-based control (same as the GS inverters due to the boostrap requirements)...and funnily enough, makes those low side FETs quite a trouble 😉.
  16. Groan....more than I care to admit 🤯. Blew through nearly 200pcs trying to figure out a frustratingly precise explosion at 3kw on a 12kw test prototype (different FETs than the ones that work well). Turned out that my 0603 gate resistors were...a little undersized, and were blowing open-circuit, leaving the FETs to basically kill themselves across the battery... Very first set of FETs I blew up was thanks to the ridiculous 'scope grounding rule--grounding the probes. Touched the probe negative to the high-side FET gate (by accident), and *poof* there went the FETs. Next step was to rip the ground prong out of the 'scope power cord.... Getting a bit cobbled there...but I think I see why. Doesn't look like the ATMega328 has any proviso for motor drive PWM (i.e. complementary outputs, dead-time settings, or PWM shutdown)...so it appears to me that you're using the IRF21844 chips for their complementary output design and dead-time functionality (i.e. the functionality that the ATMega328 doesn't have). And then tagging the TLP351s on the end of the whole thing... Worth noting that the GS boards literally feed the MCU's SPWM outputs directly into FET drivers (same design concept as the TLP351, though rated at 4A instead of 0.6A), and directly out to the FETs. Lot simpler....but the GS MCUs also have full complementary PWM outputs, dead-time and hardware PWM shutdown capabilities built-in. IRFB7545 = 55v...IRF3205 = 60v... What's your DC bus voltage here? I'm assuming you're shooting for 24v...because those FET voltages are too low for 48v 😉. Other thoughts: What's your dead-time delay? ("programmable" on the IR21844 chips w/ a resistor) if it's too small, you'll obviously have possible cross-conduction across the H-bridge if it's too large, the transformer will have time to start to "kick" back (particularly with inductive loads). This does become problematic... the body diodes on the FETs are NOT ultra-fast recovery (i.e. <35nS). This means that they MAY not switch fast enough to clamp a transformer kick-back, depending on the dv/dt of the spike. (Datasheet on the IRF3205 indicates 69-104nS reverse recovery time for the body diode.) the longer the H-bridge is "open", the more opportunity for an unclamped kick to damage the FETs. What capacitors are you using for DC bus filters? (particularly important is the ESR rating) if they're too small and/or have too high of an ESR, they won't be able to absorb transformer kicks/spikes--and the FETs will be damaged through overvoltage. This is even if (and especially if) the FET body diodes are gating transformer kick back to the battery rail. these capacitors' main function is absorbing spikes and preventing the battery cables from turning into giant inductors. Is the SPWM H-bridge methodology top-down (a la PJ), where the transformer is clamped to battery positive and pulled to ground? Or is it bottom-up (transformer clamped to battery negative and pulled to positive)? this only affects which side of the H-bridge is most likely to be problematic Do you have any ferrites / E-cores between the FETs and the transformer? I presume you are checking BOTH high and low sides (though not simultaneously)...at no load as well as under load? Transformer impedance and behavior changes CONSIDERABLY from no-load to loaded--this is why it's important to 'scope the gate signals under load. Basically all of my smoked FET tests looked beautiful at no-load (or even small loads). It generally isn't until 3-6kw that the gremlins really start to show. Frankly, these are significantly over-rated 😉. If you have any sort of dangerous transients on the FETs, you need to reduce the switching dead-time. A little 100nF capacitor against a giant transformer...is like trying to use an ant to hold back a falling boulder. Have you 'scoped the drain-source on both the low and high-side FETs as well? Under load? I'm assuming you have a DSO (digital storage scope)--they might well be dubbed "Nintendo scopes", but are VERY handy for capturing and examining waveforms up close.
  17. 1.1r7...it will actually be 1.2.0 once I'm satisfied the bugs are out of it (due to all of the changes). I've made MAJOR changes to the local server, WiFi handling, as well as a software core update (which was the biggest pain of all). So far so good with the field beta testers...but I found some internal issues yesterday that I need to sort out. (Multithreading is so much fun...) I wish I could say that I've made progress on that...but I haven't. It's awfully hard being responsible for every single aspect of the inverter (rewarding, but slow!), as I often feel like damage control, where the squeakiest wheel gets the attention first. The core update, complete revamp of the inverter's local server--plus soldering parts on the PCBs, programming, testing and packaging them up.......... ...one of these days I'll get back to the parallel functionality, as well as hybrid load sharing, etc. There's also a lot of pressure to get the 12kw design solidified and ready to order--and with good reason. Unfortunately, however, I can only do one thing at a time. 12kw probably will get the attention first--the parallel functionality can (for the most part) be implemented via firmware update anyway.
  18. Most MCUs designed with H-bridge PWM control will have a hardware path for cycle-by-cycle current limiting (including the MCU used in the GS inverters) with reaction times measured in nanoseconds. And yes, I fully agree that software-controlled overcurrent protection is not much of a protection. Fully agreed...the rules change significantly between low power systems and high power systems. "Oh, let's make a 12kw inverter, it's just double the size of a 6kw." Whew, was that an understatement! Transformer's DC current (i.e. short-circuit/saturated) goes from 3,000A in the 6kw (with FETs absolute max of 3,600A) to over 18,000A in the 12kw (and FETs at 5,940A absolute max)--now the FETs aren't intrinsically protected by the circuit's DC resistance anymore. I'm not saying that the circuit is useless or even fatally flawed when used in the right application. It has useful applications in many fields--and is commonly used in analog designs and chips. Like you said, it's used in linear amplifiers and linear control circuits. I am just saying that for high-current SPWM-driven inverters (with non-linear control), the "linear current limit circuit" is an unmitigated, total and complete disaster. If we should even think of running the FETs in linear range "to limit current at 1,100A", they are going to blow up--and that's a guaranteed end result. Been there, done that. The UCC5870 datasheet shows sample circuits using the ADC inputs for current monitoring across a current sense resistor--but I did not see any examples of linear current limiting. Worth noting that "desaturation detection" will shut the FET/IGBT down, not run it further into linear state--otherwise you're guaranteed a blown FET/IGBT. Didn't study the datasheet to see if it has automatic threshold cycle-by-cycle current limiting ability built-in or not (through digital shutdown)...but wouldn't be surprised if it did. Really powerful chip.
  19. Remember, "Power Jack" is not the Webster dictionary's definition of an inverter. It is quite possible to design an inverter to function at 120F ambient--simply the losses have to be less in order to avoid overheat.
  20. I think someone other than me is overlooking a couple elephants in the room. Your "protection" circuit uses a fundamentally fatal design flaw as the basis for its existence. As a baseline, the IRF250 (ancient dinosaur of a FET!) has a rated "Rds(on)" of 85mOhm (0.085 ohms), and rated maximum continuous current of 30A @ 25C. (I won't mention that the GS inverter FETs are 3.5mOhm [0.0035 ohms] with a rated current of 180A @ 25C [limited by package leads to 100A].) With Ohm's Law, we can determine that 30A through a 0.085 ohm resistance will dissipate 76.5W, dropping 2.55v. If we are pulling 30A from a 50v supply, then the "load" resistance will be (50 - 2.55v = 47.45v across the load with 30A) = 1.582 ohms, resulting in 1,423W dissipation in the load. Total equivalent circuit resistance is 1.667 ohms. But let's say we have an overload condition, and the total circuit current increases to 90A @ 50v. Load resistance drops to 0.47 ohms--and this factor becomes extremely important. This "protection" circuit will activate, and pull the MOSFET gate down just far enough to drop the DC current through the circuit to 30A. So far, so good...the MOSFET max continuous current is 30A, so we're good, right? Well...only if you overlook any further calculations. So let's recalculate now. For 30A at 50v, the circuit resistance is determined by Ohm's Law to be 1.667 ohms. But due to the overload condition, the "load" is 0.47 ohms. This means that in order to drop the circuit current to 30A, the MOSFET must fill in the remaining resistance of (1.667 - 0.47) = 1.197 ohms. Here's where it all goes wrong: 1.197 ohms @ 30A = 1,077W of heat that WILL be dissipated in the FET. But the datasheet lists the maximum dissipation of the IRF250 as 150W--this is where the FET is going to explode. While the FET package does have some mass, the real issue is the RthJC specification--thermal dissipation between the junction and case, of 0.83C/W. So 1,077W of heat * 0.83 = 894C on the actual FET junction almost instantaneously (regardless of FET case heatsinking)...which guarantees instant failure. Without the "protection" circuit, Ohm's law finds that 90A @ 0.085 ohm Rds(on) results in 688W dissipation in the FET. Still fatal for a 150W-rated FET--but not as bad as the "protected" FET circuit. In order to actually protect FETs from an overcurrent condition, you need to clamp them all the way to full off (open circuit = no power flow). In normal modern motor controllers, this is generally done with a current sense comparator that shuts down PWM outputs down on the MCU. Depending on the implementation, this can be either until user intervention, or on a cycle-by-cycle basis. For that matter, the "inevitable turn off pulse" is a completely useless argument--if it had any merit at all, there would not be any need for a protection circuit in the first place. Bottom line: "protecting" an overloaded FET by increasing it's heat dissipation is a rather effective way make a bigger smoke show. I guess if you're going to go out with a bang, you might as well make it a good one....
  21. If the bus voltage ends up transienting beyond the max FET voltage rating...absolutely.
  22. Worth noting that the IRF3205 has about double the gate capacitance than the IRFZ44...not a problem if the gate signals aren't rounded, though. Since the failure modes seem to be rather random, I would suggest you check the following with a 'scope: voltage across the DC bus to the H-bridge (to see if the power supply filter caps are absorbing any kickback/spikes from the motor). voltage across one (active) FET quadrant to see if the body diodes aren't being fast enough (i.e. brief high voltage spikes during switching)
  23. Gotta love that feeling. "Oh, there was a power outage? Somehow I must have missed that." Without getting too deep into theories, I can undisputedly say that it was basically entrusted to USPS via mail-ins. And about all I can say about THAT was that USPS shipping was downright HORRIBLE from Nov-Jan through that period. Sean mailed a package to my local town via USPS--and it took an entire MONTH to travel that distance. And they outright lost other packages that Sean mailed (he'd go back to the post office with a receipt from when he'd mailed a package, and they'd say, "That tracking number doesn't exist"), etc., etc. Not just once, either. For comparison, UPS will send a package between Sean and me literally in one day. If I mail it one day, he'll have it the next. And vice-versa. Consistently. Sure, UPS oftentimes costs a bit more than USPS for small items, but... Around the similar period, I mailed a package to New Jersey via USPS. I'm in Ohio--and the next tracking update some days later showed the package in Indiana. Now, I'm not a rocket scientist, but I do know that Indiana is the opposite direction from New Jersey. And the central hub for my area is Ohio's capital. Gotta love it.
  24. Do you have a good DSO? (digital storage scope.) Helps considerably to put the probes in 1x mode (reduces amplifier noise and cable ring). So if you just have to replace the FETs, it sounds like the gate resistors aren't blowing 😉 Approximately what is the H-bridge bus voltage? And...what's the FET part number? Is the H-bridge drive mechanism push-pull? (In other words, when the H-MOS is turned OFF in the PWM cycle, does the driver turn on the L-MOS at this point?) If not...we might be dealing with the body diodes on the FETs. (OR...failing bus voltage capacitors that aren't absorbing the spikes well. You'd be able to see this with a 'scope on the bus voltage.) I have read that the body diodes on the FETs are NOT ultra-fast recovery diodes. In other words, if the dirty motor kickback spikes are very high speed (which is probable!), the FET body diodes might not be conducting fast enough to short the spikes to the power rail--in other words, allowing them to overshoot the rail and (possibly) the FET voltage rating. (This could result in long-term FET degredation and random failure.) With the blown FETs usually being diagonal on the 'bridge, it does NOT sound like a Miller spike problem. (That's ALWAYS on the same side, as the FETs can only cross-conduct across the power supply on one side--not diagonally.) If you can provide some details about how the motor drive utilizes the H-bridge, that would help narrow down the possible failure modes.
  25. I've got a lot of ideas/thoughts...but let's see what can be determined first. Have you been able to replace FETs and restore functionality on a blown controller? (Or are you just replacing the entire controller?) If so, are there any other damaged parts that also need replaced? I ask because after blowing through over 150 FETs ($$$), I discovered a connection between load-based FET blowouts...and failed gate resistors. Which makes logical sense: if the Miller spike has a significant strength (i.e. more kickback/dirty brushes), it will put a significantly higher load on the gate resistor. In my case, said resistors were 0603 SMD (I know, dumb), and apparently they will just fail open-circuit without warning. This of course turns the FET loose to deadshort the battery and any other sort of concluding end results. You might consider a ferrite choke on the motor leads to try to absorb some of the brush noise (if not already present.)
×
×
  • Create New...