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

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.

Balance Tracking Data

Well, the pack has been in for a little over 3 weeks now and has been cycled to various depths from full to nearly empty.  It's been bottom balanced at 3.000V once, by hand with nothing more advanced than a test meter and a big light bulb.

I set the CellLog8s doing what it does... Logging data at 15 second intervals from all 8 cells plus the pack Voltage.  And here's the trace from the night of the 7th March to the night of 13th March.  Again, you can click on the graph to open a bigger view.

 

You'll notice that on the first night, the pack almost bottomed out before starting to charge on the 8th.  Just briefly it got down to about 3.1V.  Below you can see the zoomed in view of that discharge "spike".

The cells show good tracking with a spread that is just 15mV from the highest to the lowest cell in the pack.  This differential shrinks to about 7mV when under lower load.

The chart above shows the opposite end of state of charge at the 12th March.  Here you can see the pack reaching just shy of 27.80V and the spread of cell Voltages from 3.465V to 3.505V, some 40mV.

Remember that the pack is bottom balanced, so there will be more variation at the top of charge.  As long as we always undercharge the pack, this isn't a problem and requires no active balancing or Voltage limiting.  If we tried to do this, we'd be top balancing the pack and then would mess up the bottom balance.

As the charging current at the 28.00V target has been pretty massive (over 70A), I think the maximum regulation Voltage on the chargers was a bit too low.  They always seem to stop at 27.85V, measured on the CellLog8s and my DVM.  So I've tweaked the settings a bit.  The SSMPPT-15 and TSMPPT-60 have had their maximum regulation limit raised from 28.40V (3.55Vpc) to 28.80V (3.60Vpc).  Hopefully this will allow the terminal Voltage (at the charger end of the cables) to go high enough to raise the battery terminal Voltage to the desired 28.00V level.

I also tweaked the timer on the SSMPPT-15 so that it charges for 10 minutes (rather than 1 minute) before cutting out on the extended absorption timer.  You can see from the high charge chart that the SSMPPT-15 quit assisting the charge early and the TSMPPT-60 wasn't quite able to hold up the Voltage.  The big charger is still aiming to charge for 20 minutes, but now the small charger will support it for half the time.  Of course, the 10 minutes is not concurrent with the 20 minutes of the big charger, as the Voltage set point on the SSMPPT-15 is 0.1V lower at 27.90V.  It reaches this point while the TSMPPT-60 is still in bulk charge mode, trying to get to 28.00V.

Progress on the CellLog8s Front

Some general tuning and tinkering over the last couple of days.

After watching the battery pack charge and float, I noticed that it was starting to discharge a bit more than I'd like when floating.  So I increased the float level by 0.1V to 26.90V and then observed the next charge day.  This time, rather than discharging at 3 Amps, it settled into a discharge of around 1 Amp.

Meanwhile, things are moving forward with the CellLog8s problem and development of an interface to my inverter for low Voltage disconnect.

Junsi, on the OEM RC Groups thread, managed to replicate the unstable alarm port output problem in his lab and set about looking for a remedy for it.

Not 24 hours later, I received a PM on the forum and then a new beta firmware code to test!  Now that's FAST.

Uploaded the firmware (v2.09) to the Cellog8s, now connected to all the cells in the pack, and played about with the battery until 3am to see how it was now.

Much better, is the answer.  But still a ways off being useful without bodging some external electronics to fix the remaining problem...

At least now the alarm triggers reliably when some way above / below the set points.  But there's still a lot of instability at the set point.  The alarm trigger has no hysteresis in it.  With a big battery you get VERY slow changes in Voltage and then the battery can spend a long time transitioning across the set point (and I mean a few minutes spent dropping the pack Voltage by 1-2mV at a 150W load!).

Anticipating that they would fix the software, I built a follower relay module (that just follows the sense of the alarm output of the CellLog8s).  The relay itself came from an old broken mains timer switch and was convenient as it had a 24V DC coil.

The instability of the CellLog8s alarm output made the relay chatter noisily near the set point, with the transition instability.

If I used it "as is", it would probably do what Jack Rickard's VDR (voltage dependent relay) did to his test load and A123 battery pack.  The load and pack cycled on and off furiously at the switching set point, and then both of them exploded with the stress of a few hundred Amps being pulsed rapidly.

The addition of a programmable variable for alarm set point hysteresis would eliminate this problem.  If you have a low Voltage alarm trigger point at 24.00V and hysteresis of 0.5V, then the alarm will trigger ONCE at 23.99V, and then stay triggered in the alarm state until the pack Voltage rises to 24.51V.

With no hysteresis, your alarm triggers multiple times as the Voltage floats around the 23.895 to 23.995 zone, in exactly the same way you see a DVM last digit toggle randomly between two values when it is close to the threshold of the next digit. Fine for a DVM display (even desirable as you can interpret the toggling as meaning the value is very close the the transition point)... VERY BAD for a load controller.

Initial Tests & Programming the Morningstars

First day of solar charging the new Winston Battery pack.

Got the CellLog8s wired up into the individual cells during the night, ready to monitor them for any over charging.

It was quite simple in the end.  I'd thought about making lugs from copper strip.  I'd thought about soldering wires on to the cell terminal straps.

In the end, all I had to do was splice on thin stranded bell wire to the 9 way header cable (cutting off the other plug), and then insert the thin stranded wire into the laminated cell strap sandwiches. Each strap is made of several copper plates held together with heat shrink tube (and the terminal bolts of course). When bolted back down, the wires are securely held and aren't going anywhere.  Well, maybe at least until one of the cats decides the spaghetti is a toy and pulls it out or trips over it!  I wrapped the cable in some spare cable tidy spiral-wrap stuff.  I might shorten the leads later but was toying with the idea of having the monitor mounted somewhere above the battery pack.

Got the two Morningstar charge controllers re-programmed with very conservative settings to start to get a feel for how the pack would behave.  It was very sunny from the get-go, with the chargers putting out a combined 55 Amps into the battery.  No magic smoke ensued.  For that matter, nothing even got the slightest bit warm; none of the cables; the new "200" Amp battery disconnect breaker; any of the cells.

I checked the live data feeds from the two chargers with the MSView software to double check that they were adhering to the expected target Voltages and temperature compensation slopes.  Some months ago, I'd previously had an issue with one of the programming wizards that had a bug in the temperature compensation settings, but Morningstar were quick to provide a bug fix after I mailed their software support team.

Basic settings are as follows (per cell values in brackets):
Absorption Target Voltage: 28.00 (3.50)
Absorption (Constant Voltage) Cumulative Time : 10 mins
Absorption Time Extended: none
Float Target Voltage: 26.80 (3.35)
Float Exit Time: 12 hours
HVD (trigger): 29.00 (3.625)
HVD (release): 26.40 (3.30)
Max Regulation Voltage: 28.40 (3.55)
Temperature Compensation: Pack -60mV/C (25C to 80C)

The smaller SunSaver charger has the same settings with the exception that the absorption target Voltage is set to 27.90V, so that this charger quits before the main one and then the main one is in the driving seat to control the finishing charge.  This is especially important because the SunSaver charger does not have remote terminal Voltage sensing.

An overview of the programming wizard in the MSView software is included in the second video below.  Speaking of which, today's video is a monster.  It was so long (23 minutes) that I had to split it into two as YouTube complained it was too long. Soon I'll be making blog videos almost as long as episodes of EVTV :D

Get some popcorn...

Updated Monitoring Network

I finally got round to completing the Morningstar monitoring network.  The problems with the Toshiba laptop and Vista and the clunkiness of having to start up the machine and configure the logger and so on each day (to save wasting too much power at night) got to me.  Below is an example of the type of connection that can be made between Morningstar products.  I don't have a Relay Driver but it shows that you can connect a bunch of things to the EIA485 data bus.

The Morningstar SunSaver MPPT charge controller can talk to the TriStar controller if it has the right adapters.  I already had a RS232 adapter to connect the SunSaver to the laptop but you need an EIA485 converter to connect it to the same port on the TriStar. 

Although EIA485 isn't common in day to day PC networking, it is common in industrial telemetry as it can work over a four wire bus and transmit up to 1.2km without repeaters.  RS232 is only good for a few meters and even Ethernet runs out of steam at 100m.  It's a bit of a pfaff when you only want to connect two things together by a 30cm bit of string though...

The instructions suggest using Cat 5 Ethernet cable for the 4 wire bus.  Two are used for +12V and Ground power lines and the other two are the A and B serial data lines.  They suggested using Ethernet cables because they have twisted pairs to eliminate interference.  But I ignored that and just used 4 core flat telephone wire as it was such a short cable I was making.  They also say that you're supposed to terminate the A and B wires at each end of the bus with a 100 Ohm resistor between them.  I sort of did this by putting a 100 Ohm resistor at one end (inside the Tristar wiring box where it would be safe from being knocked).  I didn't have two 100 Ohm resistors in my spares box so I didn't bother with the one at the other end...  Seems to work ok without it.  I've been receiving data from the SunSaver without problem so again it's probably only important for long wire runs. 

With the SunSaver connected to the TriStar, you can use the MSView software to talk to any device on the EIA485 bus (up to 128 devices) using IP.  The TriStar can be set to bridge the Ethernet and EIA485 networks (it just forwards the MODBUS packets to the devices on the EIA485 network).  It's especially handy because with the exception of the TriStar MPPT-60, no other Morningstar products are IP enabled but now they can be.  It opens up the possibility of using cheap and commonly available networking products to move the data around.  For instance, I don't have Ethernet cable run around the house.  I have a wi-fi transmitter and the TriStar is actually connected to the computer upstairs via an Ethernet switch and a pair of Netgear Ethernet over AC power adapters.  This was more reliable than the wi-fi (which has a dead spot in that part of the house) and the CCTV data also travels over that switch and link.

So now my laptop upstairs can fetch performance data from the Tristar controller and also directly from the SunSaver controller.  The two controllers share the same IP address on the Ethernet but have different MODBUS IDs so each controller responds only to it's own commands.

You have to run the custom settings wizard for each controller to change the default MODBUS ID (all Morningstar devices are preset to "1").  So I changed the SunSaver controller to be ID "2" and left the TriStar on its default of "1".

The EIA485 network needs external power of 12V DC so I connected the two power pins on the EIA485 connector plug to the variable lab power supply that I use to run the AA battery charger and mobile phone chargers.  This converts the battery 24V to the needed 12V, although the EIA485 adapter isn't fussy and will work on any voltage between 8 and 16V, so you could just connect it to a 12V solar battery directly.  But I'm running a 24V system so I have to use a DC-DC converter.  The pair of adapters (RS232 and EIA485) together only consume about 20mA (or 0.5W power) so I can leave them running 24 hours (unlike the Toshiba laptop that consumed about 11W.