Fuelly
Showing posts with label BMS. Show all posts
Showing posts with label BMS. Show all posts

Thursday, March 29, 2012

CellLog8s Hardware Mods

In researching the firmware issues with the CellLog8s, I discovered on the RC Groups forum that there are a couple of hardware modifications that can be done to the device to make it work properly when using more than 6 cells.

The OEM, Junsi, posted an item in the thread here (links to the post) describing how the CellLog8s only draws power for the CPU and LCD from the first 6 cells connected.  This will cause a 7 or 8 cell pack attached to have a charge imbalance over time as cells 7 and 8 are not loaded.  It's only a few dozen mAh per day but for a solar pack connected 24 hours a day, it all adds up.

I've copied the photo from the forum, so you can see it here more easily.  Click on it to see it bigger or follow the link I gave above to see the whole article posted by Junsi.

The red line denotes where the link wire has to go and the resistor is circled in pink.
The cure (for users who only want to use more than 6 cells all the time, like me) is to add a wire link and replace one microscopic surface mounted device (SMD) resistor.  The resistor is an optional modification for those with excellent soldering skills (or the right tools) :D. 

Changing the resistor from the "202" (2k2) value to a "103" (10k) value reduces the CellLog8 power consumption when used with more than 6 cells.

Note that the modifications make the CellLog8 unable to function on just 2 cells, so it's not a full fix for the issue.

Of course, applying this "fix" may well invalidate your warranty from the supplier (especially if you muck it up and fry the thing).  But given that the device has a known hardware "bug" out of the box, you could always argue for a refund on the basis that the device was "not fit for purpose" in the first place.  So anything you do to remedy this has no bearing on the initial situation.  Either that, or you could ask the supplier to make the modification for you, again citing that the device was not fit for purpose (if your purpose was to monitor 7 or 8 cells).

On the plus side, at about 28 Euros, they're cheap if you fry one :D

Wednesday, March 28, 2012

Getting CellLog8 Data Out

I've been helping a contact with getting the CellLog8s to transmit data to a PC and thought that the info might be useful to anyone else trying to get the slightly quirky data transfer to the slightly quirky German LogView software to work.

First thing to note about the CellLog8s and PC connections is that the USB port on the logger is not isolated from the PC and is not isolated from the battery pack being monitored.

The CellLog8s should have opto-isolated data lines to USB.  But they also wanted to be able to power the thingy from USB so that means a connection to the PC...  The later product (PowerLog) comes with a cludge of a solution in that it has a USB cable with the power pins not connected!  Rubbish solution, as immediately you'll loose the original "isolated" cable and use a normal one and BOOM!

I know about the issue and have from my own experience blown up a hand-held oscilloscope by running it from the DC-DC converter on the solar system instead of the internal batteries only.

I get away with plugging the CellLog8s USB into my little laptop because I make damn sure that I only run the laptop on batteries and not plugged into ANYTHING else (even use wi-fi for network connection).  It's all good if the PC is running on internal power and is not connected to anything where the solar battery power can escape back to itself in a loop and... BOOM!

That's why all the data interfaces on the Morningstar charge controllers are opto-isolated.

Next is that you need to install the Junsi serial port driver that came with the device on a mini CD.  Do not just plug the CellLog8s into the PC as Windows 7 will find the device and install a built-in USB serial port driver that does not work.  Install the Junsi one first and then plug the device into the USB port and check that the Windows USB notification says it has found and successfully configured the Junsi driver.

Also note that you must be using a non-64 bit version of Windows.  Windows 7 comes in 32 and 64 bit flavours and the Junsi drivers do not work with 64 bit Windows.  This is not because they don't work but because Windows 7 64 bit enforces a "no install" security policy for unsigned 3rd party drivers.  The 32 bit editions do not enforce this.  They'll complain that the driver is unsigned but allow you to install it anyway.

I've managed to get the LogView thing to work without problem.  I don't log continuously but have managed to download the CellLog8 on-board log file with no trouble.  I'm using v2.7.3.481 (which came on the CD with the CellLog8).  You don't need to mess about with the device file.  Go to the Device> Choose Devices and Ports menu.  In there, use the drop down lists to choose Junsi and CellLog8.  It even shows a picture of the device when you select it.

Then all I did was tick the "Automatic start recording" option and select the COM port to talk to it over in the "RS232 Seriel" drop down list.  The CellLog8 driver you installed earlier (you did install the supplied driver, not rely on the Windows one?) will be listed as "Junsi something or other COM x".  You have to have the CellLog8 connected to the PC via the USB cable before starting LogView for it to find the Com port that gets discovered and enabled by Windows as soon as you plug the CellLog8 in.  If you don't plug the logger into the USB before starting LogView, it won't find the serial port.

The "Automatic start recording" option means that whenever you start LogView, it tries to connect to the port used last time for the CellLog8 and it opens the recorder session in LogView (ready to receive any data).  If CellLog8 is in logging mode it will transmit individual data every 2 seconds (or whatever you set in CellLog8).  If you are not logging, it will still open the channel but have nothing to receive.  When you then go to the logfiles menu on the CellLog8 and select "transmit", the file will be broadcast on the serial port and LogView will be listening for it and will save it in the PC memory (which you can then save to disk).

If you do not put the "Automatic start recording" option on then you have to press the record button on the LogView panel BEFORE hitting "Transmit" on the CellLog8 (otherwise LogView won't be listening for the broadcast).

Transmission of a big log file (say 30,000 entries) can take a few minutes!  You will see NOTHING on LogView while this is happening (apart from the green communication lights on LogView flashing).  You WILL see CellLog8 counting though the log entries to show progress of the BROADCAST.

When the transmission is completed, the CellLog8s will beep and then LogView will draw the graph of the data received.  At this point the data is only in memory and you should save the data from the File > Save As menu option in LogView before messing about with the data.

Monday, February 27, 2012

The "5 Minute Warning" Alarm

The CellLog8s LVD is fine and works well at protecting the battery bank from over discharge but it doesn't give you any warning that the lights are about to go out.

So I started thinking about some kind of pre-alarm that would give me a few minutes warning (under heavy load) that the battery was nearly depleted.  I could then turn off some big loads and buy some time.
The old SmartGauge Voltmeter has a programmable relay in it too.  But it only works on pack Voltage.  I've been using it as an obvious visual reminder of pack Voltage (it's no good at reading SoC for non lead acid batteries).

Then I started looking around the house for something to use as a buzzer or alarm sounder that the relay could activate so that you'd get the message...
I found a small toy sound effect thingy that you press the top and it makes a cool police car sound.  I actually found another one that my wife had that made steam train noises and in fact a whole load of similar sound chip enabled things, like a Dr Who Darlek bottle opener that says "EXTERMINATE!" when you close a circuit (with the bottle top) and a Christmas card that plays George Michael's "Last Christmas"...

But I decided to go with the police car :D

Taking it to bits was very easy and then all I had to do was solder wires on to the existing switch contact and run these out to the alarm relay on the SmartGauge and program the chosen low Voltage alarm.
The toy still uses the same two 1.5V button cells to make the noise.  The SmartGauge does not provide any power to the relay contacts so external power for the alarm or whatever is needed.  If the batteries in the alarm go dead, it does not affect the safety of the battery bank as this alarm is just for information.

When the relay contacts close, the police siren only goes off once for a few seconds and then stops.  This is a good thing!  Saves the batteries in the alarm and prevents bricks being thrown at the thing for sounding too much once the message has gotten through to whoever is within ear-shot of it :D

Sunday, February 26, 2012

CellLog8s "One-Shot" LVD

With little prospect of the firmware being fully fixed, I decided to implement a work around to make the CellLog8s at least work as a "one shot" Low Voltage Disconnect (LVD) for the inverter.

The problem was that without proper hysteresis in the CellLog8s firmware, the alarm output would flip-flop in an unstable way near the alarm set point value.  So I had to devise a way to iron out this transition behaviour and make it trigger once only.

I found a little DPDT latching relay in Maplins that does the trick, but I had to rebuild the interface board that I'd made previously.  In the video you can see the new circuit.


In this new version, the inverter receives an "Enable" signal from the interface.  This just connects to the common pin on the Remote/Off/On select switch on the inverter front panel.  The new relay is stable in both positions of its double throw output and has two coils, one to select each output mode.  It only needs a single short pulse to cause the state change and then further pulses have no effect (as you have to energise the opposite coil to change the state).

So, you press a button to "Enable" the inverter (or reset it, if it had tripped).  This just flips the relay "on".
The 680 Ohm resistors in series are because the relay has 12V coils with a measured DC resistance of about 700 Ohms.  They weren't quite equal though and (by luck more than judgement) I happened to pick the coils in such a way that the alarm state coil is the "stronger" one, so that when the alarm state is "true", the "reset" button does not work... Useful that.  You can't force the inverter to start up when something is wrong.

The second pole on the relay is just used for the LED indicator.

The output of the CellLog8s alarm port (now set to Normally Open) sits and does nothing until the set point is reached, at which point it will trigger.  The alarm port goes to closed state and triggers the "Disable" coil on the relay.  The LED goes out and the inverter is forced to shut down.  It cannot restart until the alarm condition has cleared and the reset button is pressed on the CellLog8s interface (and of course after you've investigated why it tripped!).

As programmed in the CellLog8s now, either a pack LVD or a cell imbalance alarm can cause it.

Next, all I had to do was hack the inverter to accept the Enable signal...
Here's another video of me "hacking" the inverter to get at the switch on the front panel and wiring in the connection to the new interface.  A bit of testing, too.
Now the battery is fully protected from any low Voltage drain from the inverter (the main load).

The advantage the new system has is that the relay consumes no power to hold the inverter in the enabled state.  Just a pulse of current from the reset button and then nothing.

In the alarm state, the other coil consumes 20mA for as long as the alarm is triggered. In practice, the load from the inverter is usually such that the pack or cell Voltage sags to the limit and triggers the alarm.  Instantly, the load is disconnected and the pack/cell Voltage recovers enough to rise above the alarm set point, which cancels the alarm.  Now the relay consumes no power again but is latched in the "Off" state.

In theory, the charge controllers, the SmartGauge, and even the CellLog8s itself could cause the pack to drain down and be damaged. But as I've set the cut-off Voltages quite high (24.0V pack and 3.00V per cell), it would probably take several days with no solar charge (the PV disconnect breaker thrown) to drain the last few Ampere.hours from the pack and damage it.

Wednesday, February 15, 2012

Still Testing the CellLog8s

After the previous experiments with the CellLog8s alarm output, I posted a query on the RC Groups forum where the manufacturer provides support for the range of Junsi chargers and cell monitors.

They looked at my video and blog entry and suggested that the problem might have been a grounding problem in my wiring of the LED to the alarm port.  The alarm port negative needs to be referenced to the cell negative.

So here's my update on the situation.  I wired the LED +ve into the cell +ve terminal.  The negative of the LED goes to the +ve alarm port and the -ve alarm port goes to the cell -ve terminal.  The chargers are all connected to the same points too.
You can see the LED and its connection points in the photo above.

In the photo below you can see the problem.
 The alarm was set to trigger when the pack Voltage exceeded 3.65V.  It's now 3.95V as shown on the charger and the logger display is showing 3.973V, alternating with the alarm status "over".  But at the same time, it's not beeping an alarm and the LED connected to the normally closed alarm output is ON (indicating no alarm condition).

Here's today's video showing the erratic behaviour of the alarm port and beeper.

Monday, February 13, 2012

Flakey CellLog8s alarm

Today's episode:
Still charging up the cells one at a time...

When no.4 got to be full, I decided to play with the CellLog8s and its alarm output.  I'd noticed that when it gets to (and beyond) the set point of the over Voltage alarm, it would flash "over" on the display but not always beep.  It goes though random phases of beeping every 4 seconds (like it should) and then not beeping for a while.

So I set it up with the provided alarm output cable (with a tiny plug and tiny thin wires...) to a 12V LED.  This  has the current limiting built in for use as a panel lamp in cars. You can see the alarm port on the device and the external LED circled in green in the photo.
The plan is that the CellLog8s will be my low Voltage monitor, both for the pack as a whole and individual cells (as any cell that goes below 2.0V will be permanently damaged).

The 3kW inverter is my only load and has a LVD cut-off built in, but there are two problems with this.  The first is that it has a fixed cut-off Voltage of 21.0V, which is too low.  It's 2.62V per cell.  For high drain applications (0.5C / 200A discharge) 2.8V is the recommended cut-off.  For lower currents, the cut-off Voltage is actually higher.  The cell can be considered "empty" when it gets to 3.0V.  This means that for the many hours of a day where the inverter is drawing a mere 3-4A while doing not a lot, the worst case applies and I need to shut the thing down when it gets to 24.0V pack Voltage.

Then it's also possible for the pack to be out of balance and one cell get below 3.0V before the others as the pack nears "empty".  If I accurately bottom balance the cells, this shouldn't happen but I want to catch it if it does.

The CellLog8s does both of these things.  It monitors each cell Voltage, and it monitors the pack Voltage.  And the alarm output can be triggered at any programmable level.

Now, back to the test...  Because I'm charging the cells, I set the over Voltage alarm to 3.65V so that as the cell gets near to the end, it would alarm so that I could watch it finish and shut the charger down.  Just to see the alarm work.

Ideally, the alarm output would trigger and latch.  That way, if the threshold is crossed, the load will be disabled and then require manual reset before it could be enabled again.

Anyway, for the test, I had the alarm set to "Normally Closed" output.  This means that the LED comes ON when there is NO alarm condition.  This would mean the CellLog8 has power (to drive the output transistor) and the wiring is working.  This would provide a fail-safe "inhibit" signal to the inverter remote port.  When there is no alarm, it's safe for the load to run.

When the alarm is triggered (by low Voltage), the LED should turn OFF.  This would signal to the inverter that there was either a low Voltage alarm or that there was a fault in the CellLog8 (open circuit wiring or no power to the device).  In either event, the inverter should be disabled or shut down.

Well, as you can see in the video, it sort of worked.  The alarm was triggered at the appointed Voltage and the LCD display started flashing "Over" to tell me what kind of alarm it was.  The CellLog8 started beeping (as it should) and the LED turned off.  But... It then came back on and randomly turned on and off.

At first I thought it was a hysteresis problem (with the alarm threshold being crossed multiple times as the Voltage crept up) but with the cell well over the limit, the LED continued to randomly turn on and off.  No good.

Time to post a bug report on the RC Groups forum where the manufacturer hangs out.  They've been quite good at listening and producing bug fixes and new features for the device firmware but this is a pretty basic problem that should have been ironed out by now.

Failing that, I could work around the problem with an externally latching switch / relay, but if the software on the logger worked properly in the first place, it would reduce the interface complexity and so the number of points of failure.

Saturday, February 11, 2012

Faster Initial Charging and CellLog8

Episode 02 of my video blog:


While charging the first cell, it quickly became clear that the 5A output of the bench power supply wasn't enough to get charging done in a sensible amount of time.  The cells appear to be delivered with 50% charge and so I have to put another 200Ah into them.  At 5A, this would take 40 hours at least.

I'd also had some concern expressed by Jack Rickard about such a slow charge rate being effectively a trickle charge that might not even be able to push the cells to the top and could even overcharge them in some way by trying for too long.

There was some conflict in advice, in that Jack has been using these cells for a couple of years and has never done an initial charge on them and never charges them to 4.00V.  His method is to stop charging at 3.60-3.65V (but often charging the cells in series), safely under charging them, with no active BMS present (or required).  I take his advice seriously, as he's tested lots of cells in his lab and blown up a few when over charging them on the bench!

However, the Winston Battery operator's manual is quite clear (and insistent) that this initial charge to the full 4.00V is done before the first discharge.  GWL echoed this in their user FAQs.  So I contacted the Technical Manager at GWL for advice on whether I should do the initial full charge, whether the 5A bench PSUs are suitable and whether any harm comes of doing the initial charge too slowly.  The Winston Battery manual recommends a charge rate of between 0.1CA and 0.5CA, but this is out of my reach as it means a PSU that can deliver between 40A and 200A!

The response from GWL was go with the full 4.00V CC-CV cycle and it's ok to do it slowly, so long as you terminate the cycle properly when the current has reduced in the CV phase.  They have posted a technical paper (PDF) warning about using shunt BMS systems that hold cells for too long at the terminal Voltage (4.00V). However, this was in the context of holding cells at that Voltage for long (cumulative) periods after the charge acceptance current of that cell has effectively reached nothing.  Not the same case as doing a very slow charge and terminating at the end of charge acceptance of the cell.

So, on balance, I'm going with the advice of the manufacturer and the supplier of the cells on this.  At least that way, if it turns out to be bad advice, they are on the hook for giving it to me - if it comes to a warranty claim.
I'm using these new 80W constant power SMPS PSUs from Maplins.  They can run in parallel with a master/slave link and they also have a remote sense input so that the constant Voltage dialed in is measured at the cell terminals and can compensate for the Voltage drop in the heavy current power leads.  This way you dial in 3.97V and you know the charger will hit the mark.

The unit is small, light and efficient.  Doesn't get hot in use, has no need of a fan and is power factor corrected.  At £100 each, they're not cheap but also checking RS, Farnell and Rapid didn't turn up anything better value.

After the initial charge, the manual advises that it's ok to subsequently charge within any part of the cells safe operating range from 2.50V to 4.00V.  So I'll adopt Jack's strategy of making sure all the cells are bottom balanced (at 2.75V when "empty") and then never fully charging them, to avoid the problems and need for active top balancing and current shunting and all that expensive and failure prone junk.

The CellLog8 should be all I need to prevent over discharge of the pack or individual cells in the pack.  It can monitor each cell individually and I can set an alarm for any cell that goes below 3.00V or the whole pack goes below 24.0V.  It can also alarm if any cell differential Voltage (the difference between individual cells) exceeds a limit.  This will tell you if the pack is out of balance -even before it gets to being near full or empty.  The CellLog8 has a beeper and an open collector transistor output that can be used to provide an "inhibit" signal to my inverter to shut it down until the solar array can recharge the pack.

Of course, the required 9 pin header cable for the CellLog8 didn't come with the thing, so I had to source that from a radio control models shop (Electriflyer).  They also sell the Junsi lithium battery chargers that use the same JST-HX balance lead (model BW-9-11).  Just under £5 delivered.
The cable is actually meant to connect a Junsi iCharger 208b charger to a balance board (hence the 11 way header on the other end) but you can either cut off the big plug or use it.  The CellLog8 doesn't have a proper JST socket so a plug with more than 9 pins will fit;  the spare ones will stick out over the end of the 9 pin header on the device.  I might cut the lead in the middle and then have two usable plugs for the gadget.
Another thing I had to order was some terminal lugs.  These are also a bit harder to track down because they are M14 stud holes.  I found some on eBay from Clarik Engineering Supplies.  They take up to 120mm2 cable (too big for my 35mm2 cable).  I might have to use a blow torch or my pipemaster plumbing soldering iron to attach cable to them.  These alone were another £7 delivered... Everything is expensive when you have such massive terminals on a battery!