Re-vamping the Radio Shack Electronics Learning Lab
Voltage divider settings for MAX882; grey fields are inputs.
x-gnumeric - 5.72 kB - 02/16/2018 at 10:00
So, I have a need to figure out what resistances to use in this battery charger circuit. I'm using MAX882s as the regulators; these are pre-settable using a couple of fixed resistors.
Now, in a perfect world, I'd just figure out some values, buy the resistors, and … job done, right? I mean, those resistors aren't going to drift?!
Cue sad tuba crescendo.
Of course they drift! As much as 5% for the cheap ones. Question is, what can I get away with? I decided to throw a spreadsheet at the problem. This is that spreadsheet.
I used gnumeric because it's lightweight and crucially, it has a killer feature for this use case: engineering notation. The grey fields are the inputs; there's 5 to set: R1 and R2 resistances, resistor tolerances, and the min/max target voltage.
Start by choosing your upper and lower bounds; then flip over to sheet 2, the E24 combinations that meet that criteria are highlighted in green. Pick a couple of values; scale both by whatever factor of 10 you like, and plop those values into the R1 and R2 inputs on sheet 1.
You'll see the target voltage displayed, and it also computes two worse-case scenarios; namely what happens when R1 and R2 drift. If any of the three voltages are outside your range, those are highlighted in red.
It is tuned for the MAX882, but would probably work with LM319s and other parts too. You might need to tweak Vset though.
What is this telling me? This is telling me I really should not use 5% tolerance resistors. It also means I should not be using trim pots which have a 10% or worse tolerance.
I did find some resistors of the right value, but they are cheap 5% carbon film, whereas I should probably look for metal film ones for this job, even if reading the value on the damn things is made harder by the finer stripes and poorer contrast (due to the blue colouring).
As always, I spoke too soon. Not that the charger didn't work, it was doing the job nicely. I thought I'd up the ante a little bit though.
In place of my good multimeter, I grabbed a cheapie Digitor meter that I bought from the Grinning Glasses back when I was in high school. This cheaper meter had a fault; switch it to anything but voltage, and it'd turn off. I think it had a mishap with a battery and that fried that part of the meter. It still worked for voltage though.
At first though, it was reading high… figuring the battery was probably had it, I swapped the old 9V for a brand new one… and voilá, it was reading correct voltage. No problem.
Now, with my good one freed up, I switched it to current and put it in circuit to measure the current into the battery.
I also took my "current shunt" out of the circuit, so no 50ohm resistance limiting current now. Time to pull out all the stops. I wind the MAX882 up to 3.8V, and let 'er rip.
No problems at first, and I'm getting a slow trickle of about 2mA into the battery. Being so low, I thought I'd switch down a scale on the meter. I give the selector switch a tweak. Then find that the setting I chose was actually for measuring 4-20mA circuits, not straight current, so I tried to switch back … funny… the selector switch feel had changed, and the switch was no longer stopping at the usual points.
It kept going, right past off to the temp setting… and back… it was as if the knob shaft had sheared off the switch!
I now couldn't turn the meter off. I unplugged the probes and attacked it with a screw driver.
That there, is the back of the knob. That hexagonal piece engages with a socket on the switch assembly. The hexagon measures ~7mm point-to-point or ~6mm flat-to-flat.
There's the socket. As you can see, half of it is now broken. One piece got loose, the other two pieces are just hanging in there.
So much for a >$400 meter! Then again, as bad as this is, it looks repairable. Electrically, the meter is fine. The socket is about 2mm high. I'm thinking that if I clean up the remnants of the socket, this could be an entry into the Repairs You Can Print.
Interestingly, the meter looks hackable in other ways, up the top-right of the PCB is a 2×5 pin 2.54mm header, with one pin missing. (Looks all the world like a RS-232 header…). Just below that is this:
Yep, I spy, with my little eye, an ATMEGA32A. Definitely will have to look at this, then I can get rid of that annoying time-out that wore out the switch in the first place!
Recently I put an order in for some parts… in amongst them were some Maxim MAX882 LDOs. These are 200mA-capable LDOs which, if you tie the SET pin to 0V, you get a 3V3 fixed LDO, or if you hook it to a 10k pot, you get a variable voltage LDO, and they come in a nice hacker-friendly DIP8.
I also bought some Murata CRE1S0505S3C 5V-5V 1W isolated power supply modules. The idea is that three of these isolated PSUs will power four MAX882s set to ~4V with a current limiting resistor. Being isolated, the 0V reference on the output can be anywhere I like, including at the voltage potential of a cell's positive terminal.
That solves the battery balance problem: from the MAX882's perspective, it has a load, a single Li-ion cell, that it manages. The three power supplies' outputs are effectively in series, connected to the taps on the four cell battery.
If we consider the cells numbered 1 through 4. Cell 1 has its negative terminal connected to system 0V; and cell 4 has its positive terminal connected to system 12V.
The first cell just needs a MAX882; since any isolated supply would have its two negative pins shorted by the connections on the cell itself. It's easy.
Cell 2 has its negative end hooked to Cell 1's positive; this is the 0V reference for the regulator on Cell 2, thus an isolated supply is needed to allow cell 2 to drift up and down with Cell 1's voltage.
Likewise with cells 3 and 4; 4 is drifting up and down with the voltage of the other three cells, the negative terminal may be floating as high as 10V or 11V compared to system 0V.
All three isolated PSUs can be powered from the same 5V bus voltage; that is, inputs in parallel. That means I can tolerate a wide input voltage swing, from 5V right up to 16V. Regulating 16V down to 5V is easy.
For now, I'm giving one of the MAX882s a trial, charging a single cell.
The analogue meter isn't calibrated, I'm using it to give me a rough percentage of starting current measurement to tell me when it's time to adjust the voltage up. So far, all is going to plan.
Here, we have the console port adaptor module which will translate UART0 to RS-232 signal levels. I figure this is more practical than a USB TTL adaptor or leaving the bare TTL pins exposed. If I made it USB, there'd be two USB-B sockets, and confusion over which one to use. Or I'd have to embed a USB hub.
If I exposed the TTL serial lines, you'd then need to mess around with the pin-out, and then need to know the voltage, or else you'd fry the Pocket Beagle.
The circuit is simple, 5 capacitors and a SP2232EEP, and the connectors, on some scrap (and utterly shite) protoboard.
So at my last visit to HSBNE, I scavenged 4 Li-Ion cells from a scrapped battery pack which were configured in a 2S2P arrangement.
Today I'm giving these cells their first charge in probably months. I've modified the battery holders I bought, adding a centre-tap wire (orange).
I've been researching how to recharge these things, reading up on cell balancers. I haven't yet found a 4S charger PCB off-the-shelf from the usual suppliers (and I simply refuse to touch eBay/AliExpress), so it looks like DIY is going to be the answer.
For now, I have a 3V alkaline battery pack (which is quite drained… measured it at 2.8V) supplying current through a 100ohm resistor.
I'm going low and slow here… this page calls it the "aconditioning" stage. As can be seen, the slow trickle is doing the trick. I'm charging one cell at a time here, which also means I'll get an idea how well they hold a charge.
For the final charger design, I am half-tempted to use a combination of a 5V isolated DC-DC supply and an adjustable LDO regulator to supply the current. I've charged much bigger packs (10Ah+) with this exact method for years, without issue.
The only cells I've damaged was the 40Ah Thundersky cells I bought back around 2010… and what killed them is the fact that I left them unused for months then without checking cell voltages, hooked them up to my charger at full voltage. My first mistake there was letting them get this low, and to recover, I should have just carefully charged each cell at a low current.
I've learned that lesson now, and so my intent is to never let my batteries get that low.
The finishing voltage is a question mark… obviously for 100% capacity I should aim for the 4.2V. My larger packs though, I've always kept below 4V/cell, based on this guide. Admittedly, that discusses LiFePO₄, but the same concepts apply here. Even if it's 5% extra capacity, that's not really worth it when you consider the risks with old cells like this.
I'm looking at maybe 200mA of charging capacity, so the DC-DC converter will effectively operate constant-current (limited by its own capabilities), then the current will start to drop off as it nears full charge. By using four individual DC-DC supplies/LDOs, I effectively charge each cell individually.
That should prevent cell imbalance. Maybe not the most efficient, but perfection isn't the goal here.
Then there's a matter of monitoring voltages across the 4 cells for low-voltage protection. A LM324 configured as an instrumentation amplifier across each cell should let me see whether the cells are suitably charged by way of a LM339 and some diode-OR logic, and to disconnect load power if they aren't.
So… tonight I paid a visit to HSBNE, and dug around in their boxes of gutted battery packs. Out came 4 Panasonic CGR18650CGs.
They were configured in a 2P2S set-up… with one pair sitting at 2.5V and the other at 2.1V. A bit of nibbling with some end-cutters, and I had 4 liberated Li-Ion 18650 cells.
These, when new, deliver about 2.2Ah capacity with a nominal voltage of 3.6V. Even if they only do 1Ah, that's probably going to do better than a AA cell.
Given the age, it'd be wise to assume they won't have identical characteristics. I'm going to need a battery balancing circuit.
Previously for my LiFePO₄ packs, I've just used a basic LM2576 buck converter set to 14.6V. These things are internally limited (thermally) to 3A, and since my packs are 10Ah or more, this works fine. It's like a 3A constant-current followed by constant voltage. CC by default because the LM2576 won't push any harder.
This doesn't balance the cells though, and with this pack, that's going to be vital since they're mismatched already before I begin.
One thought I have of achieving this is to do round-robin charging. I have an isolated DC-DC supply, a 4.2V regulator, a low-side current-limiting resistor (doubles as current measurement), a comparator, an optocoupler, a number of solid-state relays (SSRs) and a decade counter.
The regulator and comparator are powered from the isolated supply. The comparator drives the optocoupler, and provides a signal when the battery is "charged", determined by measuring the drop across the current limiting resistor.
Each time the output of the optocoupler goes high, the decade counter advances. The output of the decade counter turns on a pair of SSRs to connect one cell up to the charger.
That would prevent over-charging of a cell and would balance all four cells.
For discharging, I'm thinking a quad op-amp could measure the voltage between each tap, and provide a ~0.5-4.5V output of the voltage for each cell. That could be fed into a quad comparator IC to compare each cell to a threshold voltage. If any cell is below threshold, the DC supply to the output is cut.
I'll think about this some more in the coming days. I think the first point of order though will be to put a maintenance charge on at least two of those cells… a 3V supply with a 47ohm 1W resistor in series ought to do the trick methinks!
(Update: Just saw this. Will have to think about this more.)
Having everything broken out, it was easy enough now for me to gain access to UART0 with my FTDI serial cable. Doing this, and turning on kernel messages revealed that while the FPGA board works, it's a little on the unstable side.
So unstable that the FPGA isn't always detected at boot. I added a line to /etc/rc.local to set up the FPGA with a LED blink configuration so I'd know if the board was alive. Frequently, this would fail.
The first culprit of course is the 5V rail itself. I had added a beefy capacitor to Vin, but we're not using that yet, so the next logical place was USB1 VBus.
To help stabalise things a bit, I've added a 100µF 16V electrolytic, and a 100nF ceramic to the VBus line. I've also added a 100nF ceramic across the previously added 220µF.
This has helped a lot, and while it still drops out, it's better than before. The drop-outs are particularly evident on the console:
U-Boot SPL 2017.09-00002-g0f3f1c7907 (Oct 09 2017 - 15:30:22) Trying to boot from MMC1 U-Boot 2017.09-00002-g0f3f1c7907 (Oct 09 2017 - 15:30:22 -0500), Build: jenkins-github_Bootloader-Builder-607 CPU : AM335X-GP rev 2.1 I2C: ready DRAM: 512 MiB No match for driver 'omap_hsmmc' No match for driver 'omap_hsmmc' Some drivers were not found Reset Source: Power-on reset has occurred. MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Model: BeagleBoard.org PocketBeagle not set. Validating first E-fuse MAC Net: No ethernet found. Press SPACE to abort autoboot in 2 seconds board_name=[A335PBGL] ... switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 ** Bad device 0:2 0x82000000 ** ** Bad device 0:2 0x82000000 ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... gpio: pin 56 (gpio 56) value is 0 gpio: pin 55 (gpio 55) value is 0 gpio: pin 54 (gpio 54) value is 0 gpio: pin 53 (gpio 53) value is 1 switch to partitions #0, OK mmc0 is current device gpio: pin 54 (gpio 54) value is 1 Checking for: /uEnv.txt ... Checking for: /boot.scr ... Checking for: /boot/boot.scr ... Checking for: /boot/uEnv.txt ... gpio: pin 55 (gpio 55) value is 1 2039 bytes read in 38 ms (51.8 KiB/s) Loaded environment from /boot/uEnv.txt Checking if uname_r is set in /boot/uEnv.txt... gpio: pin 56 (gpio 56) value is 1 Running uname_boot ... loading /boot/vmlinuz-4.4.91-ti-r133 ... 8886912 bytes read in 586 ms (14.5 MiB/s) loading /boot/dtbs/4.4.91-ti-r133/am335x-pocketbeagle.dtb ... 117513 bytes read in 101 ms (1.1 MiB/s) uboot_overlays: [fdt_buffer=0x60000] ... uboot_overlays: loading /lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo ... 2402 bytes read in 430 ms (4.9 KiB/s) loading /boot/initrd.img-4.4.91-ti-r133 ... 5865815 bytes read in 399 ms (14 MiB/s) debug: [console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0] ... debug: [bootz 0x82000000 0x88080000:598157 88000000] ... ## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 Loading Ramdisk to 8fa67000, end 8ffff157 ... OK reserving fdt memory region: addr=88000000 size=7d000 Loading Device Tree to 8f9e7000, end 8fa66fff ... OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 4.4.91-ti-r133 (root@b7-am57xx-beagle-x15-2gb) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Tue Oct 10 05:18:08 UTC 2017 [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache … [ 1.578201] usbcore: registered new interface driver usbfs [ 1.578292] usbcore: registered new interface driver hub [ 1.578404] usbcore: registered new device driver usb [ 3.450112] usbcore: registered new interface driver usb-storage [ 3.459159] 47401300.usb-phy supply vcc not found,...Read more »
So bar about four of them on P2… I've got most of the GPIOs exposed on both the PocketBeagle and the FPGA.
It was a tight squeeze… and yes, this board layout will fail EMC tests. But this is a proof of concept, and if it works out, I have the option of getting a PCB made with a nice big groundplane to avoid these nasty issues.
It is also tempting to forgo the PocketBeagle and the IceStick, and just slap a OSD3358 and a ICE40HX8K-CT256. Why such a big FPGA? Because it has a bigger pin spacing than all the others, and so would be the easiest to design a board for. I think the OSD3358 actually exposes a memory bus, so it's possible to link the two that way, although I think going via a PRU is "safer".
So tonight, I added the USB power switch IC and some headers for exposing the GPIOs. This involved some scratching around in my junk box, as I had neglected to get pin headers in my last order. Thankfully, a previous motherboard disassembly yielded the parts I needed.
Also on the 5V rail, I put a 220µF capacitor. If it looks familiar, it's because it came from the Digitech turntable I ripped apart.
So far, analogue inputs 0-4, the voltage references for those, plus I²C2 and UART0 now have headers:
There's also a space ready for a 5V DC input. Yes, some of those headers should have 0V pins along side them, and if this works out, I may get a board made up which has a proper 0V ground plane. Likely for now, I'll put some more pin headers on that 0V row so I can hook more signals into it.
Yes, that'll create some ground loops, but hopefully no worse than the ones I'd create doing jumpers on the veroboard anyway. I'll wait until I've done the other signals and see what I have left.
On the other side, I've exposed all the spare GPIOs on the FPGA board:
Since my last post, more parts have arrived and the project is taking shape.
In amongst them:
I'll have to figure out how to mount the USB power switch, it's a SOIC-8 package, but there wasn't room for an adaptor to mount it on. I should be able to dead-bug it. Sadly, I couldn't find a DIP USB power switch IC, and I wasn't sure what was needed to do it discretely.
The PocketBeagle didn't like the USB cable at first… I found there's a maximum length that it'll tolerate before it'll refuse to power up. Grabbed a shorter USB-A to B cable, and it was fine. This might improve once I have a local PSU built into the kit to power the PocketBeagle. Perhaps I can use the presence of a USB voltage to turn on the system +5V rail, which is then controlled by the PocketBeagle.
For the cell holders, I'll have to chase up some cells… there's a stack of gutted Li ion battery packs at HSBNE, so I'll probably locate four of those. Then the next step is to figure out a battery balance system.
I'll need to tack an extra wire onto the battery packs, which shouldn't be hard, then it should be possible to interface that to a battery management system.
So there's some solder smoke in my future this weekend.