Lithium battery BMS questions

[TurnNBurn]

Originally Posted by mechman600

Yes, TurnNBurn, you will need to solder. I picked up a 35W soldering gun at Princess Auto yesterday for $15. It even came with solder. Start practicing and do some YouTube tutorials. It's really not hard.

It's been a few years since I've soldered anything. I think I can handle it, though. I'm not an electrical guy and it's been about 10 years since I've programmed anything (I do BASH scripting, though) so I'd have no clue how to program an Arduino.

[P-hack]

Originally Posted by mechman600

Wow, those are indeed low cost. Unfortunately I am dumb if it's not Arduino.:

Well I can't seem to figure out what cpu is on what nucleo board or how many adc are available, or supported by the online compiler, or even what pins they would be on, the info is scattered and conflicting beyond the arduino pins. Looks like straight to the discovery series and gcc for me

Edit: yup, found the datasheet for the 64 pin mcu on the 32L100CDISCOVERY
board and determined the pin mappings for 22 ADC pins in short order. ADC_IN16 is dedicated to temperature and ADC_IN17 is internal voltage ref, so that leaves 20, i.e. 18 cells and a current shunt. I feel better now the legacy arduino stuff was a PITA for the capabilities of this cpu, will have to toy with gnu C.

edit 2: looks like coocox can make life simpler for windows users, yay! Eclipse/gcc based IDE
http://www.coocox.org/CooCox_CoIDE.htm

[TurnNBurn]

Would you guys say this would be a good weekend project once all the parts are compiled? Easy for a n00b to do with good instructions? I've soldered before. I'm okay with it. Just a bad experience once (toy robot fizzled and made magic smoke once I was done soldering the broken connections)

I'm already this far into the build.

[P-hack]

No way of knowing Anyway I've been pretty limited by the 8 bit stuff for to long so I am using this as an excuse to explore the options.


Thinking out loud...
internal voltage reference is 1.224V. Assuming pack voltage.
each analog pin tied to ground through a 10k resistor, and connected to the cell tap with a custom resistor. Going around the board clockwise, the pins appear in this order, so suggest mapping the ADCs that way too.
Then hookup is more logical.

cell	pin#	adc#
1	PB15	ADC_IN21
2	PB14	20
3	PB13	19
4	PB12	18
5	PB1	9
6	PB0	8
7	PC5	15
8	PC4	14
9	PA7	7
10	PA6	6
11	PA5	5
12	PA4	4
13	PA3	3
14	PA2	2
15	PA1	1
16	PA0	0
17	PC3	10
18	PC2	12

I took the liberty of mapping out the ADC on the discovery:

[P-hack]

(downloading coocox ide + prereqs)

Yah, I'm thinking that soldering and wiring are going to be challenging if you don't understand this stuff. And being all experimental when you are trying to protect your batteries could screw up something, do more harm than good.

You know how to measure voltage? That is the only skill needed for bottom balancing.

[mechman600]

I started figuring out I2C communication between Arduino boards. I soon learned that it is not a good solution for our purposes here:
1) It robs two analog pins per board
2) It can only send one byte at a time

I quickly set out to invent my own comm protocol. I set up two wires, one for Reader to send messages to Sender, and one for Sender to send messages to Reader. Using the analogWrite() function to send and pulseIn() to read, I successfully made a system that works.

Basically, the Reader sends a message at a specific duty cycle, waits a moment and then measures what the Sender has sent back. It then sends a different duty cycle and then reads again. The Sender responds to each duty cycle instruction and sends info back as a duty cycle that the Reader can measure.

I will attach code and maybe a video later. I'm excited that I figured this out.

[P-hack]

I considered duty cycle transmission, it is cool stuff, the only issue is that it is another analog link in the chain. There is a software serial library if you don't want to use rxtx. But it is byte oriented, and instead of the whole reading being converted to digital and back into an analog (and back into a digital) you pass the digital bytes directly, with a much "fancier type of pwm". The software serial can also be used to control a serial LCD on pretty much any pins.

So you can have two pins to talk to one board, two for the other, and 1 tx for a serial lcd (which can be remote from the board), you don't care about rx for the lcd because it isnt returning anything interesting. And the only detail you have to worry about is baud rate for these connections.

here is some stuff on the serial lcd, he is using pin 2 for tx, but any can be used: http://playground.arduino.cc/Learning/SparkFunSerLCD

once set up it is like:
pinMode(txPin, OUTPUT);
LCD.begin(9600);
clearLCD();
lcdPosition(0,0);
LCD.print("Hello world!");

and the other boards communicate similarly

and you can talk to other boards the same way, just have to figure out the protocol (i.e. when you send a certain byte or string, what does the response look like).



Of course I will mention that the discovery board (STM32) has 3 uarts , and uart hardware is nice because it can adjust to slightly different frequencies and uses majority vote on each bit to filter out noise. I don't think software serial does, and ev's can be electrically noisy.

[mechman600]

Originally Posted by P-hack

I considered duty cycle transmission, it is cool stuff, the only issue is that it is another analog link in the chain.

I do not agree. PWM is excellent because it can be seen as both digital (by the MCU and other digital devices) and analog (by a load such as a motor or light).

An analog signal at a specific voltage that receives interference/induced voltages can easily be skewed to a value that is incorrect. That is obviously why digital is superior.

Even if a PWM signal's voltage is skewed by interference, the timing will not change, and the timing is what the pulseIn() command reads to convert the pulse width to an integer value. However, interference will be nearly impossible because the signal will either be low (with a 10K resistor to ground to make sure) or high (+5V applied by MCU). There is no room for interference.

This is how I understand it....but I could be wrong.

I will add more multiplexed inputs tonight. I have 2 temp sensors and 2 5K pots. Maybe I can find more goodies to input.

[P-hack]

Time is analog

Reducing it to a 1 or a zero is the best way to eliminate rounding errors. The concept is as old as morse code, and serial communication is as old as two comupters talking to each other digitally. uart only uses it enough to determine if it is looking at a 1 or a zero, that is the basis of digital.

There is a lot of goofiness in the arduino implementation itself

you start with an analogread of 10 bits

you write it with analogwrite which drops it to 8 (resolution is now 1/4 the original)

you use pulsein to read it, which has a host of issues on the arduino.
Lets just say it isn't accurate, nor excellent for devices that can communicate digitally, easily.

And the boards themselves will have slightly different oscillator frequencies.
I2c builds on serial communication by adding another wire, a clock signal, to keep communication in synch.

Softwareserial makes it easy to use any pins, you write to it and read the responses from it, and you don't lose anything of the original voltage reading (the whole reason for doing this).

[mechman600]

I am still quite new to all of this, so some of the concepts you speak of are still beyond my brain. What I did find is that my POT voltage readings (having been read, ADC'ed, converted to PWM, sent down a wire, counted, converted to a float, and displayed on my LCD) seem to be quite stable and accurate.

I realize that PWM out is only 8 bits. However, since I am sending the values of smaller integers (the math to figure out individual voltages being done in the slave/reader Arduino), we are dealing with a value that does not require the same resolution. For example, we are measuring a bank of 8 lithiums with 10 bits @ 4.5V * 8 = 36V / 1024 = 0.035V resolution. We are then sending each cell voltage across comm with 8 bits @ 4.5V / 256 = 0.02V resolution. No resolution lost.

I do hear what you are saying about converting again and again, and that makes perfect sense. However, I see nothing erratic or inaccurate when I test. But, I shall test more, with more inputs and through an opto, because an opto will also be a necessary ingredient when coupling multiple boards at different locations on the pack's series string.