Old BMS Software Thread

[retepsnikrep]

OK Greg if you can set the controller to 9600baud, 8,n,1 then we can do what you need. I'll leave that though until you get it all in and running. I'm doing the eeprom stuff now.

Don't forget max 64kbyte eeprom for time being.

[retepsnikrep]

I2C Master and Remote code done but untested until i find my eeprom chips I bought some and can't bl**dy find them!

I've added a new sub menu function as well as it was getting a bit untidy.

The master already transmits data via the rf link continously whilst it is switched on. And you can already use that to gather live data on the fly into a spreadsheet.

The new dump eeprom command allows the stored eeprom data to be sent over the link to a connected PC and into a spreadsheet.

If the eeprom is full it could take upto 4 minutes to transfer the 64kb of data. The rf link is only 2400 baud

I'm starting with cell voltages only for the moment until i get all the code right.

Might have a problem if I vist Greg and both our BMS are operating with cars near each other, not sure if they will interfere with each other Txd to remote display etc.

[retepsnikrep]

OK some new software for V2 Master board, remote display unit and non picaxe updateable slaves.

Quite lot of new stuff in the Master which has the eeprom logging commands, it works ok without the eeprom chips fitted just doesn't store the data Note just logs cell voltages at present every time through main loop (1 second intervals)

www.solarvan.co.uk/bms/MASTER_8mhz_0101 ... UD_I2C.txt

The new remote display software is for the use with Master V2 software 1.93 and above as it allows the eeprom data to be dumped via the rf link and usb cable to a PC.

www.solarvan.co.uk/bms/RemoteDisplay301209_v24.txt

Should be OK but might need to tweek the delimiters for excel etc.

Finally the last and newest version of the super non picaxe slave software. This is now my final version for the time being and I am starting to program my 48 chips with it. Works fine on bench with above Master software.

www.solarvan.co.uk/bms/SerSla15.pbp
www.solarvan.co.uk/bms/SERSLA15.HEX

Command pulses have now been shortenend < 1ms for improved speed.

Seven commands available.

Command 1 = Send Cell Voltage on Master Bus (0.1ms pulse)
Command 2 = Increase Load Operation Voltage by 10mv (0.2ms pulse)
Command 3 = Decrease Load Operation Voltage by 10mv (0.3ms pulse)
Command 4 = Set Slave Load Defaults (0.4ms pulse)
Command 5 = Turn On Slave Load for one second (Flashes Led) (0.5ms pulse)
Command 6 = Set Baud rate to 9600bps (0.6ms pulse)
Command 7 = Set Baud rate to 2400bps (0.7ms pulse)

Slaves now confirm on Master bus what command they have received and implemented. Master checks this data to confirm updates accepted OK.

Also added some very short pulse rejection in case of spikes on slave bus.

[retepsnikrep]

Still tweaking and tidying the Master V1.95 i'll post it tomorrow.

It now logs the same data to the eeprom as is sent over the rf link (plus all the individual cell voltages)

For my newest Insight lithium conversion that would be 56 bytes a second. 20 minutes worth of data into a 64k byte eeprom.

48 bytes for the individual cell voltages and 8 bytes for the misc data.

Might have to chop it down to once every 10 seconds.
Giving 200 minutes of data.

Is it worth making the data recording conditional?

I.E. it only records data if any current is flowing?

At present if you get back home and are sat on drive with BMS on it will continue saving data every second. Overwriting your trip data quite quickly.

Hmm? Ideas welcome

[GregsGarage]

Code: Select all

`Constants
symbol BatAmpsLim        = 240      ;Controller cutback limit. Initial value will be 240 - 40= 200 amps
symbol BatAmpStep        = 40      ;Amount to reduce battey current in controller on each low cell alarm

;**************************************************************************************************************

ControllerCutback:
   
   if BatAmpsLim > BatAmpStep then      ;Check that BatAmpsLim > BatAmpStep
   BatAmpsLim = BatAmpsLim - BatAmpStep   ;Reduce BatAmpsLim by BatAmpStep
   else
   BatAmpsLim = 1            ;BatAmpsLim lowest allowed value is 1
   endif   
      
   serout Controller,BaudT9600,("bat-amps-lim",BatAmpsLim,<cr>)   ;Send cut back command to controller
   
   return


I was going to wait till I had the controller to post this, but there has been some other interest in this idea, so here it is. This is just pseudo code, it is not yet ready to be added to the bms software. Rather it is a place to start. The current reduction is very simple, it just sends a value when you get a low cell warning, and keeps sending lower values on further alarms until it gets to 1 amp. The initial value sent will be BatAmpsLim - BatAmpStep. These 2 values will need to be set for a particular vehicles needs, a bit of trail and error to find what works best for you. The routine could be made more complecated, for example taking into account battery current that set the alarm and/or SOC of the pack to premptively start reducing current, but I think this method would be a good place to start. It should work well enough and only requires a few lines of code.

[retepsnikrep]

Greg

That's looks like a good start. Can you send me the relevant documentation for the controller.

I quite like the idea of a bit of pre-emptive current reduction when SOC gets to say <10%. From my experience with the cells a drop to 50% current would be a good move at Soc <10% then 25% current at Soc <5%. In my application I can really exhaust the cells as I can keep discharging at lower and lower current without any effect on the vehicle performance, so I can keep going if required until they can't even supply 1 amp without going below minimum cell voltage. (I don't do that though!)

You can't go quite so mad in a pure EV as you won't be moving below about 10% normal current


Here is Master V1.95

www.solarvan.co.uk/bms/MASTER_8mhz_0101 ... UD_I2C.txt

Note the 'SocUnit' variable is set for 8ah cells in this version onwards. (My new pack is 48 x 8ah Lifebatt cells)

[GregsGarage]

That's looks like a good start. Can you send me the relevant documentation for the controller.

Best I can do is, http://www.paulandsabrinasevstuff.com/HelpFileMcontrollers.html As with our project most of the documentation is buried in the forum thread.

Note the 'SocUnit' variable is set for 8ah cells in this version onwards. (My new pack is 48 x 8ah Lifebatt cells)

Is this for another Insight PHEV or something else?

EDIT; This program can connect to the controller, log data and set parameters in the controller.
http://www.evvette.com/EVVette.com/RTD_Explorer.html

[retepsnikrep]

Is this for another Insight PHEV or something else?

Yes my spare 235,000 mile car!

Battery is knackered so I'm experimenting!

[GregsGarage]

Is it worth making the data recording conditional?

I.E. it only records data if any current is flowing?

At present if you get back home and are sat on drive with BMS on it will continue saving data every second. Overwriting your trip data quite quickly.

Hmm? Ideas welcome

Am I correct in thinking that when it gets to the last memory location of the eeprom that it starts back at the begining, overwriting data? And when you dump data then it starts at location 0 and dumps data until it gets to the current location stored in variable "I2CAddress". If that is the case, if you do a dump after it has rolled over, you won't get the full 64k of data, only the data from 0 to I2CAddress. You could be disappointed if it had only just rolled over.

Do you need to store pack voltage to the eeprom? I know its only 1 byte, but we don't have many. The only time I can think that you might want to record cell voltages with no current is directly after charging, LiFePo4 cell voltage tends to drop off, but even then I can't think that this would be all that useful. Maybe you could set recording threshold to say 5 amps? Probably the biggest problem is knowing what information is useful to all of us. Some people might want to know about voltage drop at high C rates so they may want to capture data every second and stop when eeprom is full. Others may want to keep an eye on charging profiles, they may be happy to log only every 30 seconds. So I don't know what the answer is other than have these parameters well documented in the program comments so it can be adapted as others see fit.

[retepsnikrep]

Am I correct in thinking that when it gets to the last memory location of the eeprom that it starts back at the begining, overwriting data? And when you dump data then it starts at location 0 and dumps data until it gets to the current location stored in variable "I2CAddress". If that is the case, if you do a dump after it has rolled over, you won't get the full 64k of data, only the data from 0 to I2CAddress. You could be disappointed if it had only just rolled over.

Good point I need to adjust that so it sends data from the current I2CAddress point until it catches up with itself. So it sends the full 64k data on every dump. I'll think about that a bit more.

Do you need to store pack voltage to the eeprom? I know its only 1 byte, but we don't have many.

Your on a roll! I meant to omit that as the spreadsheet can calculate it from the cell voltages.

Maybe you could set recording threshold to say 5 amps? Probably the biggest problem is knowing what information is useful to all of us. Some people might want to know about voltage drop at high C rates so they may want to capture data every second and stop when eeprom is full. Others may want to keep an eye on charging profiles, they may be happy to log only every 30 seconds. So I don't know what the answer is other than have these parameters well documented in the program comments so it can be adapted as others see fit.

Agreed, dont know is the answer.

It's already possible to log a complete charge cycle data in real time using the remote unit and a laptop/excel as the bms is transmitting data all the time it is operating.