Old BMS Hardware Thread

[steiner]

I just want to let everyone know that there are 3 tabs on the bottom of the spreadsheet. The first tab is the component list for two of the 12 channel slave boards that I built for my setup. They utilize the same basic design as Greg's 16 channel slave board but some of the components will be different as I have a higher bypass current.

The second tab is for the remote display that Peter designed.

The third tab is for Peter's version 2.0 of the Master.

[martinwinlow]

Peter,

I gather the best place to get PIC/PICAXE stuff is http://www.rev-ed.co.uk/picaxe/ but what do you recommend I need in a basic 'toolbox' to program the 3 MCUs used in the digital master and slave and install the programs on the chips? I have no prior PIC/PICAXE experience.

Regards, Martin.

[retepsnikrep]

Depends on which way you want to go.

If you are going to go all picaxe chips for master and slaves then you only need the free picaxe program editor, the usb download cable and a simple adapter to fit the slave 3 pin sil setup. You can make the adapter by studying the picaxe manual

http://81.134.141.187/epages/Store.stor ... cts/AXE027

http://www.rev-ed.co.uk/picaxe/

If you are going to have non picaxe cheaper slaves then you also need a USB pic programmer.

I recommend one of these e-bay item number 270556584954 Damn good and work well. You can load the hex files I upload direct to the pics.

I'm also making progress in converting the other picaxe programs into the pic variant, and have just finished the watchdog chip which can now be a plain pic saving a few pence. I hope to finish the remote display picaxe to pic conversion as well soon. That only leaves the main master CPU 28X1 as a picaxe but again if time permits i may eventually change that to a simple pic variant.

[martinwinlow]

Peter,

Thanks for that.

However, AXE027 is the PICAXE USB download cable... which manuals do you recommend for both PIC and PICAXE programming?

Martin.

[retepsnikrep]

Peter,

Thanks for that.

However, AXE027 is the PICAXE USB download cable... which manuals do you recommend for both PIC and PICAXE programming?

Martin.

You need the usb cable AXE027 as above.

Just download the 3 big manuals for the picaxe interpreter basic and read them that's what i did.

For the pic i use picbasic pro which is a compilied language and again i just read the manual. I can't find my copy at the moment though and unless you are going to buy the pbp compiler it's a bit redundant. i will supply the hex files which the
pic programmer can use to burn the slaves.

Can we see all the VB6 stuff you have been doing please.

[martinwinlow]

Peter (and anyone else that's interested),

You ask for details of my VB6-based BMMS monitoring program I use on my EV - a Daihatsu HiJet micro-van which has a Netgain Impulse 9" motor, Belktronix controller and 38 x Thundersky LFP160 LiFePO4 cells giving a nominal pack voltage of 120V - see www.evalbum.com/2092 for more details. The program(s) run on a carputer running XP.

There are 2 separate applications. The main one - EVMonitor - displays and records the BMMS (battery monitoring and management system) data. The secondary one - EVPlotter - allows the playing back of the data in the same format as the main program and can be speeded up or slowed down as required.

You can see 2 basic videos of EVPlotter running here... http://qik.com/martinwinlow/videos ... one recorded whilst the EV was charging and the other recorded whilst the EV was on the move.

Both aps are very much works in progress and have lots of bugs but it still works well enough most of the time.

The main sensing hardware is currently 5 x Paktrakr Remotes and one Paktrakr display which also puts out a very wordy serial string of data containing all the cell voltages etc - in all around 150 separate bits of data. Unfortunately, the PakTrakr uses the first 3 cells of each sub-pack (I have 5 sub-packs in my EV - 3 x 8 cells and 2 x 7 cells) to power itself and this unbalances the pack - albeit only by an additional 10mA or so draw. But, after a few days without charging it is enough to cause the charger to stay on unnecessarily long whilst it balances the pack. More seriously, I have never managed to get the current sensing to work reliably due to electrical noise issues I believe. Consequently, I intend to replace the PakTrakr system with Peters digital Master and Slave BMS which I hope will stop unbalancing the pack and give reliable and much simpler data for EVMonitor to use.

EVMonitor displays the following information updated every 2 seconds (hope to reduce to every second or less):-

All 38 traction pack cell voltages to a resolution of around .01 of a volt
Traction pack current - the Hall Effect transducer is on the negative pack lead so measures battery amps (rather than motor amps)
Speed - obtained via a USB GPS
Power in and out in kWh calculated from pack current and voltage
Each sub-pack temperature - but the sensors are in the PakTrakr remotes on top of the cells so not accurate
Motor RPM (not yet implemented)

EVMonitor also records the above parameters every 2 sec unless stationary when it saves the data every minute. Data is saved to a file on the hard disk of the carputer. Apart from the displayed info above, the system also records location in northings and eastings, speed and direction. A new file is created each day at midnight.

EVMonitor uses an RS232 to USB converter to get the data from the PakTrakr and a USB GPS receiver for speed and location. This is shared using xPort with the navigation software included in the main carputer 'front end', Centrafuse.

The carputer has wifi so I can access EVMonitor via a LAN.

There is a GSM USB modem attached to the carputer to allow it to send status reports both at a pre-configured time of the day as well as on demand by texting the carputer a code word. Eventually, it will also interface with a smoke alarm and anti-theft alarm. The Evmonitor program also monitors the state of charge of the pack and can send alerts via text for under/over pack voltage and under/over individual cell voltages. Obviously, just about anything can be done in terms of monitoring or even controlling the EV systems using a combination of text and/or wifi (or even internet) connection. Cripes, if you put a USB WebCan in the front, you could drive it remotely (OK - you'd have to do something about the accelerator, brakes and steering etc).

If anyone wants the source code, exe files or has any questions, let me know.

[retepsnikrep]

Martin

That's very good. I especially like the timpe lapse display of the stored data and the various signalling options inc text messages etc.

My BMS polls the cells once a second so you should get second by second data, hopefully it will be accurate enough for you.

Please can we have a look at your source and the exe files. May be an idea to start another thread on here so others could contribute to it as an ongoing project.

Thanks

Peter

[hardym]

Great work on this open source project, this seems like a nice solution

I read thru the last year or so of messages, and didn’t find a succinct description of how the communications works, so I would like to summarize how I think the slaves talk to the master and then offer a concern, based on similar projects.

- The slaves are monitoring each battery and can individually add a load to each battery.

- The Slaves can all talk via a shared, isolated Master Data serial bus (9600 bps) to the master; The serial line is pulled up by the master and each slave can take turns pulling down on the line to make serial communications.

- The Master communicates a serial one-byte command to the first slave, over a separate, isolated Slave Bus. The first slave receives and processes the command and then forwards the one-byte command to the next slave, in a daisy-chain.

Commentary: (Once again, great work, don’t take this as criticism)

1. Software Serial Reception on the Slave port. Serial output from PIC can easily be done with a software routine and timing loops or with a built-in UART.
However, A serial receiver into a PIC is a bit more tenuous without a hardware UART. The pic12F683 does not have a serial receiver, So I’m assuming a software UART is used from PicBasic. This means that the PIC is looking for a start bit as an interrupt, and then will use a software routine to receive the serial bits, starting with the remainder of the start bit. I’ve tried this using the CCS compiler software UART library and it is unreliable at 9.6k bps (but more reliable at 2400 bps, with a 8MHz PIC clock). The problem with this approach is that the interrupt that starts the bit reception will start in the middle of the start bit, and depending on what else is going on, may miss the first bit transition, or the bit transitions may be off. In the daisy chain, if one of the PICs misses the message, the rest don’t see it either, so this needs to be pretty reliable. (It looks like the master could be the last recipient of the daisy chain slave, but not sure what the master does when a command byte doesn’t come back, or a different/unexpected byte comes back).

A suggested fix is to use a 14 pin PIC16F688 which is the currently smallest thru-hole package PIC with a serial UART receiver. This will add cost each slave (1$). Note that when using the built-in serial receiver, the receiver will shut down if 3 characters are received into the input buffer. Need to watch for this and clear.

There are new 8 pin, 8 bit processors coming out of Microchip that would be ideal, like the 12F1822/1823/1824, with UART and self-write. Wouldn’t it be nice to be able to re-program all the slaves at one time via the serial link?

2. Number of wires: Rats nesting. This is a problem for most all BMS. This solution requires a pair between each slave, and another pair to the master, total of 6 data wires in/out, and a + and – battery connections. I’m thinking that a good connector solution is to use a pair of RJ-11 (popular here in the US) and daisy chain each board together (both master bus and slave bus on same wires). RJ-11 connectors and wire is super cheap, and pretty reliable for low speed comms.

3. Load Resistor Flyback. The R2 load resistor will have some inductance, especially if wirewound. When the load is turned off, a flyback pulse is generated, that may damage components. Suggest a 400V max v diode across the R2 to catch this.

4. Load Switch. The load switch Q1 is a NPN a t0-92 case. You could use a SOT3 surface mount n-FET, could switch up to 2A, would be cheaper, less real estate. I can get you a part number.

Mark.

[retepsnikrep]

Mark

Thanks for your comments we appreciate them.

In answer to some of your points. The BMS sytem has been a group effort with myself as the lead with no electronic/programming qualifications whatsoever. It does work though which is something and is slowly evolving.

1) The slaves actually use a varying pulse length as the command system not serial commands. The master sends out an interupt pulse followed by a timed length pulse which the the slave measures and decodes to decide which command is being requested.

' Command 01 = Send Cell Voltage on Master Bus (0.1ms pulse)
' Command 02 = Turn Off Slave Load (0.2ms pulse)
' Command 03 = Turn On Slave Loads as Required (0.3ms pulse)
' Command 04 = Increase Load CutIn Voltage by 10mv (0.4ms pulse)
' Command 05 = Decrease Load CutIn Voltage by 10mv (0.5ms pulse)
' Command 06 = Increase Load CutOut Voltage by 10mv (0.6ms pulse)
' Command 07 = Decrease Load CutOut Voltage by 10mv (0.7ms pulse)
' Command 08 = Set Slave Load CutIn/CutOut Voltage Defaults (0.8ms pulse)
' Command 09 = Turn On Slave Load for 0.5 seconds (Flashes Led) (0.9ms pulse)
' Command 10 = Set Baud rate to 9600bps (1.0ms pulse)
' Command 11 = Set Baud rate to 2400bps (1.1ms pulse)

These command pulses avoid the slave getting stuck in a serial reception routine and seem quite rugged. Commands 4-11 are echoed back on the master bus and the master therefore knows if the slaves have all received the correct commands.

2) I agree the RJ11 connector may be useful for the boards. We also now have a 16cell multislave board available which negates this issue quite a bit and we are working on a 26 cell slave board for my own battery install. Do you have any suppliers, part numbers and prices for these? The short tail wires with connectors at each end would be good.

3) We use anything from a 100R to 10R load resistor, all are carbon not wire wound. never had any issue with flyback voltages. Is that really a problem with very low speed switching of such a small voltage and relatively small current on a non inductive load?

4) I agree if we go SMD then a fet would be sensible. But the system is designed so anyone can build it with basic soldering skills. I have never used SMD, perhaps soon we will have to move to SMD.

Keep any comments comming. Thanks peter

[RichardC]

Great work on this open source project, this seems like a nice solution
- The slaves are monitoring each battery and can individually add a load to each battery.

- The Slaves can all talk via a shared, isolated Master Data serial bus (9600 bps) to the master; The serial line is pulled up by the master and each slave can take turns pulling down on the line to make serial communications.

- The Master communicates a serial one-byte command to the first slave, over a separate, isolated Slave Bus. The first slave receives and processes the command and then forwards the one-byte command to the next slave, in a daisy-chain.

I am trying to design a data serial bus myself, however I am having some issues. I have been trying to use an I2C bus, with the master micro on the main BMS unit and the PICs on each cell are slaves with their own address. I have got a small scale system with only a few cells working, but I have been doing some reading before I expand it to my entire pack and came up with the following issues:

- I am concerned about having a multi-board I2C bus, as each PIC is at different potentials and ground, no? How can i achieve a data bus that is like I2C (few wires)? Is I2C the right choice?
- I have read that there is a 400pF limit for any of the bus lines for I2C, I believe that due to the number of nodes that I will have connected, and due to the length of the wire, that this will be exceeded. Is there some way to mitigate this or would a different data bus be more suitable?