User Tools

Site Tools


Navigation Menu

Flight-Control

  • StatusClosed
  • OP-ModePre-Launch
  • LocationN48 - E11
  • Localtime15:07
  • CountdownT-00D 00:00

Hot Projects

SEEDStack

SEEDStack - Open 3D printable seed/sprouting systemDIY Food Hacking

UCSSPM

UCSSPM - Unified Clear-Sky Solar Prediction ModelOpen Solar Power

picoReflow

picoReflow - DIY PID Reflow Oven Controller based on RaspberryPiDIY Reflow Soldering

PiGI

PiGI - DIY Geiger Counter based on RaspberryPiRasPi Geiger Counter

DIY ARA-2000

Active Wideband Receiver Antenna for SDR - ARA-2000Wideband Antenna

DSpace

DSPace - Map everythingMap everything!

Mission-Tags

FOSS Data-Logging for Junsi iCharger

Batteries in general and lithium based batteries in particular require special attention, when it comes to charging and balancing. For this reason, the lab has a Junsi iCharger 1010B+, which offers a complete battery management solution for virtually every battery technology out there and some non-battery related features as well (like DC-Motor burn-in and foam-cutting programs).

Junsi iCharger 1010B+

It has proved itself as reliable hardware for over a year, especially taking care of the custom made LiPo battery packs for the Orion HD Camera Rig. It even offers a USB port for software updates and data-logging. Unfortunetaly, until now, only LogView users could get the logging data, but that would require a closed-source non-free operating system to run, which isn't available here (see Apollo-NG's Code of Conduct). Additionally, while LogView itself may be free (as in free beer), it doesn't seem to be open-source, so another solution was due…

Luckily, the USB port is actually just a serial port based on the cp210x serial to USB converter. Remember to build and load the kernel module, it should look like this, when you plug-in the iCharger:

[2865177.518351] usb 1-6.2: new full-speed USB device number 60 using ehci_hcd
[2865177.604715] usb 1-6.2: New USB device found, idVendor=10c4, idProduct=ea60
[2865177.604720] usb 1-6.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2865177.604723] usb 1-6.2: Product: Junsi iCharger 1010B+
[2865177.604726] usb 1-6.2: Manufacturer: Silicon Labs
[2865177.604728] usb 1-6.2: SerialNumber: 0906102520
[2865177.605380] cp210x 1-6.2:1.0: cp210x converter detected
[2865177.668344] usb 1-6.2: reset full-speed USB device number 60 using ehci_hcd
[2865177.753915] usb 1-6.2: cp210x converter now attached to ttyUSB0

Python Code

The following code will read, translate and calculate all vital battery and voltage/current data. It was written in Python, since it's always inherently available on Gentoo systems, but should be easily adaptable into any other language. A node.js implementation with realtime web(socket) graphs would be interesting, to make it even possible to remote-monitor the process.

#!/usr/bin/env python
# -*- coding: utf-8 -*-
#
########################################################################
#
#   This program is free software: you can redistribute it and/or modify
#   it under the terms of the GNU General Public License as published by
#   the Free Software Foundation, either version 3 of the License, or
#   (at your option) any later version.
#
#   This program is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#   GNU General Public License for more details.
#
#   You should have received a copy of the GNU General Public License
#   along with this program. If not, see <http://www.gnu.org/licenses/>.
#
########################################################################

import os, sys
import time
import serial

# discharge end voltage (empty)

dchg_end = 3.2


# iCharger modes of operation
mop=[None]*13

mop[1]  = "Charging"
mop[2]  = "Discharging"
mop[3]  = "Monitor"
mop[4]  = "Waiting"
mop[5]  = "Motor burn-in"
mop[6]  = "Finished"
mop[7]  = "Error"
mop[8]  = "LIxx trickle"
mop[9]  = "NIxx trickle"
mop[10] = "Foam cut"
mop[11] = "Info"
mop[12] = "External-discharging"

# configure the serial connections 
# change according to the ttyUSB assigned to the iCharger (dmesg)

ser = serial.Serial(
    port='/dev/ttyUSB0',
)

ser.open()
ser.isOpen()

### MAIN #############################################################

while 1 :

	line 	= ser.readline	()
	raw 	= line.split	(';')

	v_bat 	= float			(raw[4])/1000
	v_c1  	= float			(raw[6])/1000
	v_c2  	= float			(raw[7])/1000
	v_c3  	= float			(raw[8])/1000
	v_in  	= float			(raw[3])/1000
	i_chg 	= int			(raw[5])*10
	i_sum 	= float			(raw[18])/1000
	t_int 	= float			(raw[16])/10
	t_ext 	= float			(raw[17])/10

	s_vc1 	= ((float		(raw[6])/1000)-dchg_end)*100
	s_vc2 	= ((float		(raw[7])/1000)-dchg_end)*100
	s_vc3 	= ((float		(raw[8])/1000)-dchg_end)*100
	s_bat 	= round			((((float(raw[4])/1000)
		    -   			(dchg_end*3))*100/3), 1)

	print "Mode:           " + mop[int(raw[1])]
	print "Batt:           " + str(v_bat) + " V (" + str(s_bat) + "%)"
	print "Cell 1:         " + str(v_c1) + " V (" + str(s_vc1) + "%)"
	print "Cell 2:         " + str(v_c2) + " V (" + str(s_vc2) + "%)"
	print "Cell 3:         " + str(v_c3) + " V (" + str(s_vc3) + "%)"
	print "Supply:         " + str(v_in) + " V"
	print "Charge Current: " + str(i_chg) + " mA"
	print "Charge Amount:  " + str(i_sum) + " A"
	print "Temp INT:       " + str(t_int) + " °C"
	print "Temp EXT:       " + str(t_ext) + " °C"
	print ">>" + line


It only requires the pyserial package, on gentoo you can just:

$ emerge -av pyserial

To run the application, make sure your user has permission to read the ttyUSB device and run:

$ python pycharger.py

There was not enough time to come up with a fancy pygtk or any other graphical implementation to show the data in real-time on a graph. Since the basic code, the data-mapping and the calculations are done and released under GPL3+ now, maybe someone else can step-in and extend the features to have realtime graphs :)

Examples

Monitoring Mode

The following example shows the data-log output of pycharger.py, with the iCharger in monitoring mode. The battery is one of Orion HD Camera Rig battery packs, after half a night of recording:

Mode:           Monitor
Batt:           12.199 V (86.6%)
Cell 1:         4.064 V (86.4%)
Cell 2:         4.072 V (87.2%)
Cell 3:         4.067 V (86.7%)
Supply:         12.315 V
Charge Current: 0 mA
Charge Amount:  0.0 A
Temp INT:       34.3 °C
Temp EXT:       22.3 °C
>>$1;3;;12315;12199;0;4064;4072;4067;0;0;0;0;0;0;0;343;223;0;46

Mode:           Monitor
Batt:           12.199 V (86.6%)
Cell 1:         4.065 V (86.5%)
Cell 2:         4.071 V (87.1%)
Cell 3:         4.068 V (86.8%)
Supply:         12.328 V
Charge Current: 0 mA
Charge Amount:  0.0 A
Temp INT:       33.8 °C
Temp EXT:       22.5 °C
>>$1;3;;12328;12199;0;4065;4071;4068;0;0;0;0;0;0;0;338;225;0;39

Mode:           Monitor
Batt:           12.199 V (86.6%)
Cell 1:         4.064 V (86.4%)
Cell 2:         4.071 V (87.1%)
Cell 3:         4.067 V (86.7%)
Supply:         12.315 V
Charge Current: 0 mA
Charge Amount:  0.0 A
Temp INT:       33.8 °C
Temp EXT:       22.2 °C
>>$1;3;;12315;12199;0;4064;4071;4067;0;0;0;0;0;0;0;338;222;0;32

Charging

The same battery pack, at the end of a charge cycle, in the final balancing phase:

Mode:           Charging
Batt:           12.618 V (100.6%)
Cell 1:         4.2 V (100.0%)
Cell 2:         4.205 V (100.5%)
Cell 3:         4.205 V (100.5%)
Supply:         12.362 V
Charge Current: 180 mA
Charge Amount:  0.725 A
Temp INT:       40.0 °C
Temp EXT:       26.7 °C
>>$1;1;;12362;12618;18;4200;4205;4205;0;0;0;0;0;0;0;400;267;725;31

Mode:           Charging
Batt:           12.599 V (100.0%)
Cell 1:         4.2 V (100.0%)
Cell 2:         4.205 V (100.5%)
Cell 3:         4.205 V (100.5%)
Supply:         12.315 V
Charge Current: 180 mA
Charge Amount:  0.725 A
Temp INT:       39.7 °C
Temp EXT:       26.6 °C
>>$1;1;;12315;12599;18;4200;4205;4205;0;0;0;0;0;0;0;397;266;725;29

Mode:           Charging
Batt:           12.579 V (99.3%)
Cell 1:         4.194 V (99.4%)
Cell 2:         4.205 V (100.5%)
Cell 3:         4.204 V (100.4%)
Supply:         12.315 V
Charge Current: 170 mA
Charge Amount:  0.725 A
Temp INT:       39.7 °C
Temp EXT:       26.6 °C
>>$1;1;;12315;12579;17;4194;4205;4204;0;0;0;0;0;0;0;397;266;725;19


Although the code could only be tested with the 1010B+ here, it is likely to be compatible to all sister models. If you have a different Junsi model and are able to test the code, please be so kind and leave some feedback for other people, who also look for free and open-source data logging alternatives.

If you're looking for a cheap grid power supply to drive the charger, any old PC AT or ATX power supply will do, since the charger itself is nothing else but a versatile buck/boost converter, regulated by a micro controller and assisted by a battery of balancing resistors. The 12V output of a 300W ATX supply is being used here.

Mission-Log entry created by chrono on 2012/10/06 20:13 UTC

Discussion

Tero
2015/06/05 21:17

Hi,

Already few years old post but anyway really informative article. I have heard that Junsi use some non-standard baud rate for serial connection. Did you have to do any “tricks” to get connection to work?

I tried your script but it won't print anything to screen. I guess it won't get any data. I have checked that my Raspberry Pi recognizes charger when I connect it (with dmesg), but still can't get any data from there. Any tips how to proceed?

Thanks, Tero

chrono
2015/08/24 11:06

Hey Tero, sorry for the late reply, currently internet access is very sparse. I really don't remember anymore, the code ran just like it is documented abov eand I don't think I used any “tricks” to change the baudrate.

When you attach the charger, do you get the /dev/ttyUSBx device? You should see the driver messages in dmesg.

You could also try a serial terminal like minicom or screen and access the serial device manually ,to see what's going on there.

And you can play with

ser = serial.Serial(
    port='/dev/ttyUSB0',
    baudrate=115200,
)

or many other options from http://pyserial.sourceforge.net/pyserial_api.html to see if that does anything.

John Clayton
2015/09/12 17:26

I'll be trying this with the 4010 Duo over the next week or so.

John Clayton
2015/09/12 17:27

When you say “make sure you have the drivers installed”, you simply mean USB kernel drivers or particularly the cp210x driver? Which one did you compile in?

chrono
2015/09/12 17:49
Device Drivers --->
  USB Support --->
    <M>   USB Serial Converter support  --->
      <M>   USB CP210x family of UART Bridge Controllers 

In dmesg you should get something like

cp210x converter now attached to ttyUSB0

when you plug it in. Most Linux distros should have these enabled by default in their kernels, I would reckon. It was just meant as a heads up for people who'd rather compile their own kernels and may run into unnecessary problems otherwise.

John Clayton
2015/09/14 10:06

I see it for a 306B, for the 4010 is appears that only a USB-HID device is seen - no ttyUSB0. I'll keep digging. Appears I need to investigate modbus over USB-HID.

For the 306B, while I see the device appear in /dev I don't get any information coming from readline().

chrono
2015/09/14 11:24

Ok then, try minicom or some other terminal for the 306B to see if there is anything coming there at all or if it needs some magic trigger to start putting out data.

We can also try to look if there is logview support for the 4010 and if so, see how they grab the data off the device. In the future I'd like to build these features into our new, flexible governing/monitoring software, where we have all system configuration, storage and logging already available (see picoReflow). It would be a great adition to the feature set and hopefully make this stuff more easily accessible for other people :)

John Clayton
2015/09/14 12:26

OK, minicom, not too familiar with it - but I'll have a look. I was wondering if the 306B has a specific baud rate/parity etc - my python code isn't using anything there.

I also don't know if there is a specific setting in the iCharger to do with log files that would trigger logging via USB or not.

I also had the idea of looking at LogView - another source is DataLogger (a java system for pulling data). I pulled the code for that too but haven't had time to figure out what protocol its using.

I'm more than happy to share the ideas / code by the way - having searched for about 3 hours now for info and seeing what's available… hmm… very little, so sharing more of this would be great.

I'll *potentially* build something commercial from this stuff, so I would be willing to share particular bits on a commerce friendly license.

John Clayton
2015/09/23 20:03

ok, so I got a basic USB-HID interface working, that speaks Junsi's MODBUS protocol. It's a C++ program using libusb. I can get quite a bit of data from the charger, can start/stop different modes too. Still a total prototype program in that there's nothing to tell you how to build it, nor how to set up a USB-HID interface etc etc.

But as proof of concept - yay. I'll keep working at it. I used A LOT of the demo app code (Visual Studio 2005) code.

chrono
2015/09/24 07:58

That's good, but when you're saying you want to build something *potentially* commercial we might have a potential conflict in interest :) Everything we do here is strictly kept non-commercial, since many people sacrifice a massive amount of their lifetime to share their knowledge, code and examples on the net for free, so that others may not be hindered by intellectual property issues and can start with what ever we have achieved up to now, no matter if we are rich or poor and may not be able to afford “commercial” solutions.

After all, it doesn't take much to observe the failings of our current non-sustainable system implementation and it doesn't seem to be wise to concentrate efforts and lifetime for personal monetary gains, when we're only able to create and build these things because other people were willing to give it away for free (even at the cost of their time).

Personally, I'd be happy to collaborate when it's kept open-source, don't worry too much about code sources or quality, everything starts out as a giant bug and progresses (or not) from there ;) If you could share your current implementation on github we'd have a place to start and I'd love to look at it anyways, since I've also got an LCR meter here that seems to have some sort of USB-HID interface, which I couldn't query successfully yet.

John Clayton
2015/09/24 13:24

I'm happy to share bits and pieces. I laughed out loud when you said everything starts as a giant bug! So true, so true.

I respect your choices with regards to open source and leveraging others work - at the same time I'll see what options exist for me commercially. In my particular case (the rc heli market), I rather doubt that there's enough people in the world to warrant mass production, marketing etc of the concept I'm building. After all, it's all about charging batteries and I am tickled with the idea of being able to monitor the charging from the comfort of my armchair.

I was discussing the idea of OS vs. commercial with my brother the other day too - we've both got plenty experience in coding and business, and agreed that in the initial stages the following ideas are more important (also from a business point of view): - release early, and make it open source you want to find out if theres any interest - once you've found interest, THEN ask if someone is willing to pay cash to have a really polished solution, e.g. buy it, plug it in, it works - instead of the more open source approach of buy it, assemble it, cross your fingers (and toes) and see if you can cobble something together that works. the latter option implies a non-trivial amount of will power and knowledge, which plenty of people have - my view is the commercial solution exists to serve the first crowd.

So, I'll keep you posted - my current goal is now take the “spike” solution I created which proves I can at least do comms i/o with the device and turn this into a server that publishes the charger status via ZeroMQ (using JSON), uses Bonjour for auto discovery and handles USB unplug/plug events.

After that, I can focus on a UI. I can't decide yet whether i'll cut my teeth on some HTML/JS stuff, or whether I'll go the Qt/QML route - the latter is appealing because it'll run EVERYWHERE and the tools to dev are far higher quality than that of the HTML/WEB world, not to mention I've already got years of C++/Qt experience so I'm massively biased anyway.

Time will tell.

Take care, – John

Mario
2015/11/22 20:34

Hi John, i read with very interest your posts. I am not su good in embedded software like you. Let's say so, I can read a little bit what you are telling us, but i am not really so expert to develop by myself. I have a duo4010. I was wondering if is possible to have a PC remote control. Let's say i habe a Labview or similar PC Logic Unit implemented and I can send (let's say every second) a current or voltage set point and the Junsi answer with a current/voltage stress on the battery, and give back on the modbus the measure current/voltage/temperature. Thanks in advance for your appreciated answer.

John Clayton
2015/11/22 21:45

Hey there - this is then worth a small progress update.

After about 6 days I managed to work out what the heck Modbus was, and used the example code (targeted for Visual Studio and the m/soft USB stack) to talk to the device - albeit on Linux running on a little Raspberry Pi/2.

It's not perfect - libusb reports that the device stops talking after some time, but I built a little USB reset into the calls and this appears to stabilize the comms quite well.

The code publishes the ports that are used for communication via Bonjour - making auto discovery and connection possible as long as the UI is running on the same subnet/network.

Speaking of UI. I tried using Qt/QML to mimic the 4010 DUO - it worked, but I wasted DAYS learning how to do it and I'm not at all happy with dev speed. I'll be investigating Ionic/AngularJS2 now as I'm curious as to whether this is, at the end of the day, easier. Goal is to deliver a monitoring UI to the charging process to all devices - so both Qt/QML and HTM5 work well as they cover all devices.

To answer your other questions - yes - you need a protocol to control the device, it requires Modbus knowledge - more than happy to push my code to github but right now it absolutely will not build for you unless you follow some pretty specific instructions (that I don't even have). What i mean by this is that I rely on some headers to be included on my dev box (Rasp Pi/2 and Mac), some installed by apt-get some installed by hand.

In other words - you'll need some level of patience getting it to work. I would like to release the back end parts that actually work as open source - but can't promise a documented, excellent smooth ride at this point in time.

Will post more when I have the chance.

Thanks!

chrono
2015/11/25 20:53

Sounds awesome. If you don't already know it, I can highly recommend: https://github.com/tmaximini/generator-ionic-gulp as a starting scaffold for a hybrid angular/ionic UI which is really easy to get going.

John Clayton
2015/11/22 21:47

Oh yes - I decided to use ZeroMQ as the comms channel NOT httpd - because it can provide pub/sub as well as req/resp patterns, this is far far better suited to the data stream requirements that a continuously polling HTTP request system.

Granted: my knowledge of web sockets is limited - still, to get that working the server needs a fully configured Apache or NGINX or equiv. back end - and ZeroMQ doesn't need any of that stuff, so code-wise it's a LOT easier to set up.

There you go - now you know why I chose that path :-)

chrono
2015/11/25 21:01

I've got plenty of nginx and zmq experience at $dayjob and I must say, in my experience, zmq does scale pretty well, yet it's simple and serverless +1. On the other hand most websocket based apps don't technically need an nginx in front of them. This is done mostly for either convenience or security measures. Using angular/ionic with websockets is actually a real breeze and a tightly integrated component for app/UI comms. I hope I can release some code for goveness by the end of the year for another project that might also serve as an example for this kind of approach.

John Clayton
2015/11/25 21:07

aha, cool - I have ZERO experience and of course this provides me a huge opportunity to bias things I know, like C++/C etc etc.

So if websockets and some simple low spec pub/sub style stuff is available via that, then it could well be a solution too. Zmq I know is utter overkill in the sense that we're talking kb/s over the wire with only a few messages per second not thousands.

I'm all ears - what kind of components would one plug together to get:

1. a pub/sub channel over which charger information would be continuously published.

2. a command channel over which a GUI asks “which chargers are there”? and “what topics/queues should I use to listen for their updates”?

Make sense?

mario
2015/11/23 13:13

Here the VERY simple commando that I would like to have: Set a Charge or discharge Current or Charge of discharge Voltage (say I=+/-10A or U_=10V) for a given time(say t_ch=1000s). In the meanwhile the Junsi provides on the bus as quick as possible the measurment of U,I,T. 100ms. Every 100ms the junsi verify that a new Current Value or the stop is given and so change the current value with the updated one.

With this i would be able to generate than a driver for a Labview VI system. It is possible? I would really appreciate. Bests & Thanks

chrono
2015/12/07 08:51

Which specific Junsi iCharger do you have?

John Clayton
2015/11/25 21:04

Check out https://github.com/johncclayton/charger

I think I understand your idea, and the code allows for it - at least I've written a test command line program that can start the charger, one would need to add code to specify the voltage amount.

Monitoring is also very possible.

Whats lacking is documentation about why I wrote the code the way I did. For example, the code to listen to updates from a charger can listen for updates from multiple chargers. My long term vision was to hook up more than just iChargers you see.

I'm at the brink of learning ionic/angular now - but my full time job takes a ton of my time, as do my family and other interests :-) so don't hold your breath please waiting for me. i'm MORE than happy to answer any questions though!

chrono
2015/12/07 08:50

Awesome, thanks for sharing. I'll have a look as soon as time permits (same thing with full-time job, rebuilding Apollo-NG'S basecamp etc. so there is little time left to dive into projects right now) but I probably can't test it anyways, since I've only got the 1010B+ so far, and IIRC this is not a modbus but a plain old serial device and I don't think that it's just a matter of firmware, it it?

If someone else has a modbus junsi device, please play with John's code, so that we can get more people involved.

John Clayton
2017/01/03 20:48

News: re-writing the project now, open-source, based on python - have got further than before :-) So far I've not tackled the idea of the 306B, I'm writing all this against a 4010Duo.

https://github.com/johncclayton/electric

chrono
2017/01/04 10:14

Awh, that's great, John. I've also been busy pushing https://github.com/apollo-ng/governess forward, it would also be a perfect system to integrate a multi-charger control & monitoring appliance. As of now, almost all wok has been put into the client (Multi-Platform Hybrid Web/Mobile/Desktop) to have a complete model/data driven setup. This way we can create any kind of appliance on the server with driver-plugins which give their input, control and output interfaces and settings to the client to build an interface that makes sense for the selected set of drivers for the users and leaves the server with an abstracted sense of the appliance it's supposed to be.

I'd love to have someone else onboard so that we don't waste time and resources building similar systems but I realize that it would require some sessions where I could show you more, so that you'd get the picture of the stuff that I haven't managed to finish yet.

I hope that I can finish the appliance editor toward the weekend in order to finally make a screencast that would give people a better idea of what's already been done since they can't just download, try it and start developing plugins for it.

Comment text

Please type the letters you see on the left into the box on the right:

   ____  ____    ___    ____   ____
  / __/ / __ \  / _ \  /  _/  / __/
 / _/  / /_/ / / // / _/ /   _\ \  
/_/    \___\_\/____/ /___/  /___/