I was able to do some performance characterizations today in the lab. I could only go up to 1 amp of supply current, but what I got was that the efficiency was largely inversely proportional to the input voltage. That is, the higher the input voltage, the less efficient Pi Power gets. At 6 volts, the efficiency is in the mid 90s; at 9 volts, the high 80s; at 12 volts, the low 80s and at 15 volts the mid-to-high 70s. That appears to be a constant across the load conditions I was able to select.
The temperature of the MOSFET was also seemingly tied to the input voltage as well. So for best results, go for as low a voltage as you can. The downside of that is that the lower the input voltage, the higher the input current requirements. The sweet spot seems to be around 9 volts. If you have an ordinary R-Pi and are not trying to go nuts powering peripherals, you probably could do just fine with an 800 mA @ 9V supply. That will give you some headroom.
I power mine with a 10 watt 12 volt supply, and that works well too (it draws around 300 mA).
The actual boards that are going to go in the store likely will not have the thermal issues the prototype did. I have high hopes that the full 2A draw will be available with the upgraded MOSFET and thermal design.
Monday, July 14, 2014
Pi Power & Raspberry Pi model B+
It's early yet, but so far as I know, Pi Power should be compatible with the new Raspberry Pi model B+, but with a caveat.
The new model B+ has a 40 pin rather than a 24 pin GPIO header.The 24 pin header that comes with Pi Power won't fit. The 24 pin header that comes with Pi Power can be used, but the result will be that the bottom 14 pins of the GPIO header will be at a different "altitude," meaning that you can't just plug a 40 pin GPIO connector into the top of Pi Power. You have a few choices:
The new model B+ has a 40 pin rather than a 24 pin GPIO header.
- You can buy a 40 pin stacking header. Install Pi Power over the first 24 pins. This is the best option if you can find a 40 pin stacking header.
- You can obtain a 14 pin stacking header and stick that onto the bottom 14 pins of the GPIO header, raising them up to the same level as the other 26. You can also do this with two 7 pin SIP headers.
- If you're trying to connect a 26 pin IDC cable to your model B+ and don't need the bottom 14 pins, then just use your Pi Power as an adapter for your 26 pin cable. You won't need to snip off pins 27 and 28 like you would if you wanted to squash the IDC cable directly onto the 40 pin GPIO header.
Again, I haven't actually had a chance to try it yet, but so far as I know, Pi Power's 5 volt output should work just fine powering a B+ model.
Sunday, July 13, 2014
Pi Power - prototype testing results
Well, the prototypes are not perfect. They're good, but I'm going to revise them once and that will be what sells when (and if) someone buys one.
On the bench, the output voltage regulation stayed good everywhere from 6 volts to 14.75, where the bench supply itself dropped out (it couldn't quite make it to 15). This was on no load, .5A, 1A, 1.5A and (briefly) at 2A. The ripple stayed within 25 mV P-P everywhere above 9 volts. Lower than that and the ripple started to increase up to a maximum of around 45 mV P-P.
I spot-checked efficiency. I didn't have an ammeter on the load, so I could only estimate it with the resistance values in use - which may not have been fully accurate. Nevertheless, efficiencies were in the 80% range or so.
The only problem I encountered was that at high current draw, the switching MOSFET on the board got very, very hot. I didn't fully understand the thermal implications and assumed that a MOSFET rated at 700 mW dissipation could handle <~150 mW without special attention, but now that looks like a bad assumption. The next board will have a MOSFET that comes in a TSOP-6 case instead of an SOT-23-3. It has 4 pins bonded to the drain, and I've made a bigger-than-recommended heat spreader for it with chimneys leading to another heat spreader on the bottom. The new MOSFET is also rated at >3W dissipation. All in all, I expect similar performance, but without quite as much thermal drama.
Meanwhile, the item is for sale in the store. If you order one today, you'll be assured of getting the new version in about two weeks when the boards come back from OSHPark.
On the bench, the output voltage regulation stayed good everywhere from 6 volts to 14.75, where the bench supply itself dropped out (it couldn't quite make it to 15). This was on no load, .5A, 1A, 1.5A and (briefly) at 2A. The ripple stayed within 25 mV P-P everywhere above 9 volts. Lower than that and the ripple started to increase up to a maximum of around 45 mV P-P.
I spot-checked efficiency. I didn't have an ammeter on the load, so I could only estimate it with the resistance values in use - which may not have been fully accurate. Nevertheless, efficiencies were in the 80% range or so.
The only problem I encountered was that at high current draw, the switching MOSFET on the board got very, very hot. I didn't fully understand the thermal implications and assumed that a MOSFET rated at 700 mW dissipation could handle <~150 mW without special attention, but now that looks like a bad assumption. The next board will have a MOSFET that comes in a TSOP-6 case instead of an SOT-23-3. It has 4 pins bonded to the drain, and I've made a bigger-than-recommended heat spreader for it with chimneys leading to another heat spreader on the bottom. The new MOSFET is also rated at >3W dissipation. All in all, I expect similar performance, but without quite as much thermal drama.
Meanwhile, the item is for sale in the store. If you order one today, you'll be assured of getting the new version in about two weeks when the boards come back from OSHPark.
Saturday, July 12, 2014
Pi Power - the rest of the CarPuter solution
A couple of people responded to my Twitter announcement of Pi Power by asking about achieving soft shutdown of an R-Pi when a car's power switch is turned off.
That's not a problem I'm 100% sure I'm prepared to solve, but I'll meet you half-way.
There's two parts of the problem: one is easy, the other is much harder than it sounds.
Detecting power on the accessory bus is easy:
You put 12 volts from the accessory bus on the left connector, and connect the right one to the R-Pi ground and a GPIO pin configured as an input. When the accessory bus shuts off, the pin will go low. Write yourself a little daemon that waits for that pin to go low and executes "shutdown."
And that's the easy part.
The hard part? Actually cycling the power on and off.
The assumption of the above circuit is that the R-Pi itself is powered from the battery bus - that is, it's power that never goes away even when the key is out. You need that, because if you power a *nix computer from a power supply that can just disappear, well, that's not terrific for the filesystem. So that's why we went to all the trouble of the circuit above.
But here's the thing... How do you know when a *nix system is shut down? If you're shutting it down, there's no processes left that can tell an external component that the kernel is all the way dead. You need a kernel process of some sort that will trigger an external event at or near the end of kernel shutdown. How you achieve that in the R-Pi kernel is an unknown to me.
You could guess... You could say, "well, we'll just leave the power on for a minute after shutdown and then just yank it." But how do you know that some rogue process/driver doesn't delay shutdown?
Even if you do solve that problem... What if you start shutting down the processor and the yahoo at the wheel turns the key back on? You've already started shutting down the OS. At the end, it's going to sit there like a rock. You still need to cycle the power - or at least reset the CPU - if the power came *back*.
All of that argues for something really smart - like an ATTiny85 or something like that - to intelligently communicate with the Linux kernel itself to control an external power switch and/or the R-Pi reset line.
That's not to say it can't be done... but it's not something trivial and tiny like Pi Power.
That's not a problem I'm 100% sure I'm prepared to solve, but I'll meet you half-way.
There's two parts of the problem: one is easy, the other is much harder than it sounds.
Detecting power on the accessory bus is easy:
You put 12 volts from the accessory bus on the left connector, and connect the right one to the R-Pi ground and a GPIO pin configured as an input. When the accessory bus shuts off, the pin will go low. Write yourself a little daemon that waits for that pin to go low and executes "shutdown."
And that's the easy part.
The hard part? Actually cycling the power on and off.
The assumption of the above circuit is that the R-Pi itself is powered from the battery bus - that is, it's power that never goes away even when the key is out. You need that, because if you power a *nix computer from a power supply that can just disappear, well, that's not terrific for the filesystem. So that's why we went to all the trouble of the circuit above.
But here's the thing... How do you know when a *nix system is shut down? If you're shutting it down, there's no processes left that can tell an external component that the kernel is all the way dead. You need a kernel process of some sort that will trigger an external event at or near the end of kernel shutdown. How you achieve that in the R-Pi kernel is an unknown to me.
You could guess... You could say, "well, we'll just leave the power on for a minute after shutdown and then just yank it." But how do you know that some rogue process/driver doesn't delay shutdown?
Even if you do solve that problem... What if you start shutting down the processor and the yahoo at the wheel turns the key back on? You've already started shutting down the OS. At the end, it's going to sit there like a rock. You still need to cycle the power - or at least reset the CPU - if the power came *back*.
All of that argues for something really smart - like an ATTiny85 or something like that - to intelligently communicate with the Linux kernel itself to control an external power switch and/or the R-Pi reset line.
That's not to say it can't be done... but it's not something trivial and tiny like Pi Power.
Pi Power is a go!
Finally! The power supply the Raspberry Pi should have come with!
Pi Power is a 2 amp rated switching power supply that should work with basically any voltage from 7 to 15 VDC on a standard 2.1mm center-positive barrel connector. It's ideal for car-puter use, as the input has a 16 volt TVS across it to protect from transients.
It plugs into the GPIO connector, and I use an extra-tall stacking header so that you can still use both the GPIO connector for something else, and plug into the display header underneath.
I've not had a chance to find where the edges of the specifications are, but I was able at home to draw an amp through it and saw no more than 20 mV of ripple on my scope, and a rock-steady voltage output of 4.96 volts with both 1A and 0 draw!
Running a Raspberry Pi with a keyboard and WiFi plugged in, it draws anywhere from 250 to 300 mA at 12 volts.
It's available in the store now at $15.
Pi Power is a 2 amp rated switching power supply that should work with basically any voltage from 7 to 15 VDC on a standard 2.1mm center-positive barrel connector. It's ideal for car-puter use, as the input has a 16 volt TVS across it to protect from transients.
It plugs into the GPIO connector, and I use an extra-tall stacking header so that you can still use both the GPIO connector for something else, and plug into the display header underneath.
I've not had a chance to find where the edges of the specifications are, but I was able at home to draw an amp through it and saw no more than 20 mV of ripple on my scope, and a rock-steady voltage output of 4.96 volts with both 1A and 0 draw!
Running a Raspberry Pi with a keyboard and WiFi plugged in, it draws anywhere from 250 to 300 mA at 12 volts.
It's available in the store now at $15.
Thursday, July 10, 2014
OpenEVSE II - ground failure testing
Chris H over at the OpenEVSE project brought UL standard 2231 to my attention the other day. What it amounts to is that UL mandates a ground impedance test for EVSEs.
This is kind of a wrench for the Hydra EVSE, since it requires you to intentionally create and then measure a ground "fault." But the Hydra EVSE puts the GFI coil on the AC input so that it can have only one GFI circuit. But if you're going to have a ground test as well, then you either have to siphon off the current for it before the GFI coil, or the GFI is going to see the ground test current as a fault.
The normal architecture of the Hydra is that the AC hot lines go into a distribution bus module where the hot lines are divided to go to each relay. That's the only place where the AC can be broken out. But if you put the GFI coil after that, then you have to try and squish four 10 (or even 8) gauge wires through the coil instead of just two.
The other way to go is to leave the GFI in front and then simply account for the leakage by desensitizing the GFI circuit accordingly. That only works, however, if the leakage is constant - which means that the traditional OpenEVSE relay test system won't work, because the leakage would depend on how many cars were being powered (never mind that the OpenEVSE system doesn't allow for continuous ground testing, which is required by the UL standard).
For OpenEVSE II, I believe I've come up with a workable ground test solution.
This is kind of a wrench for the Hydra EVSE, since it requires you to intentionally create and then measure a ground "fault." But the Hydra EVSE puts the GFI coil on the AC input so that it can have only one GFI circuit. But if you're going to have a ground test as well, then you either have to siphon off the current for it before the GFI coil, or the GFI is going to see the ground test current as a fault.
The normal architecture of the Hydra is that the AC hot lines go into a distribution bus module where the hot lines are divided to go to each relay. That's the only place where the AC can be broken out. But if you put the GFI coil after that, then you have to try and squish four 10 (or even 8) gauge wires through the coil instead of just two.
The other way to go is to leave the GFI in front and then simply account for the leakage by desensitizing the GFI circuit accordingly. That only works, however, if the leakage is constant - which means that the traditional OpenEVSE relay test system won't work, because the leakage would depend on how many cars were being powered (never mind that the OpenEVSE system doesn't allow for continuous ground testing, which is required by the UL standard).
For OpenEVSE II, I believe I've come up with a workable ground test solution.
The OpenEVSE II HV + Contactor board schematic
The reason the original OpenEVSE solution couldn't test ground impedance continuously was that when both relays were turned on, then a circuit path existed from one hot, through one of the MID400s, to the ground line running between the two MID400s, then through the other one and back to the other hot - there was no requirement for the current to actually flow to ground. You could only make the current flow to ground by lighting up one hot line at a time (which you obviously can't do while charging).
My solution is to use a pair of rectifier diodes to break that cross-conduction path. That done, the test can be run continuously. With a comparator acting as a threshold, the microcontroller should see high logic levels no less frequently than once every 15 ms (3/4 of a cycle at 50 Hz).
The other optoisolator just above the bottom one is acting as an isolated voltmeter. The same voltage divider that supplies the threshold for the comparator is also used to supply a biasing offset for a transimpedance amplifier, which converts the phototransistor's collector current into a 1-5 volt output for an analog pin. The controller will simply look for a peak and scale it. The peak voltage will be 1.414 times higher than the RMS voltage because (unlike the ammeter) we can be sure that the input will be a pure sine wave. Peak reading should allow for the most linear portion of the phototransistor's operating range to be used, which hopefully will yield reasonably accurate results.
Note that the optoisolator in this case is actually an AC input one - there are two LEDs in opposing parallel on the input side. This means that both AC half-cycles will create light.
Tuesday, July 1, 2014
Pi Power schematic
Here's the schematic for the v0.1 PiPower boards that went off to OSHPark:
It doesn't use the MC34063, which is my new go-to DC-DC converter, because the output current requirements are too high for the 63's built-in transistors. Instead, I've gone with the LM3485, which is quite similar except that it controls an external power MOSFET, and it's an SSOP rather than an SOIC package (probably because it doesn't need the extra surface area to dissipate the heat from the internal current switch).
C2 is the main difference from a typical 34063 buck converter design (along, obviously, with the external Q1). It's purpose is to 'soft start' the current limiter so that the startup current doesn't trigger a shutdown.
I expect the first prototype to be done mid-month.
C2 is the main difference from a typical 34063 buck converter design (along, obviously, with the external Q1). It's purpose is to 'soft start' the current limiter so that the startup current doesn't trigger a shutdown.
I expect the first prototype to be done mid-month.
Subscribe to:
Posts (Atom)