Old BMS Hardware Thread

[GregsGarage]

It can be configured for 9600, 8,n,1. I don't yet know how but have been told it is fairly simple software change.

Greg

[retepsnikrep]

Greg

You could use J12 on the master V2 board as your input from your serial connection.

Omit C8 from the master pcb.

Use an opto output across J12 driving the led input side from your controller serial output.
The opto might invert the signal but that doesnt matter.

This ensures isolation as well

We need a lot more info on how the serial signal is sent etc, how often etc? to make the master software work.

[GregsGarage]

The controller can spit out a data stream.

When the controller is started up, you send the command rtd-period #, where # is an interval setting in milliseconds.

The output string is a fixed format and it looks like :

TR=000 CR=000 CF=000 PW=000 HS=000 RT=0000 FB=00 BA=000 AH=000.0

Where you have:

TR = Controllers calculated throttle position. 0-511
CR = Controllers current reference based on throttle and other factors. 0-511
CF = Current feedback from LEM current sensor 0-511
PW = PWM duty cycle of controller 0-511
HS = Heat-sink Temp in raw ADC counts 0-1023
RT = Raw Throttle counts from the ADC 0-1023
FB = Fault Bits. Hex output with each fault and status code. Normal 00
BA = Calculated Battery amps 0-511
AH = Calculated Amp Hours consumed 0-999.9

The default output is through the serial port. 19200,8,N,1.

To adjust battery amps limit you send the command "bat-amps-lim #" where # is the battery amp limit between 0 and 511 amps, zero setting disables battery amp limit. I would want the bms to listen for battery amp data from the controller and be able to adjust the battery amp limit down when I start getting low cell warnings, or maybe even before I get low cell warnings.

I will find out if it is possible to just get the battery amp value on its own without all the rest of the info.

You may have noticed that the battery amps is a calculated value. On the controller the current sensor measures motor amps and then calculates battery amps based on the pwm duty cycle. Actual measurements have found the calculation to be quite accurate, around 0.5 amp difference between measured and calculated values at 100 amps.

[steiner]

Peter,

I remember sometime ago you mentioned possibly re-writing the master code to port to a standard PIC chip vs the PicAxe. The only reason I mention this is according to the PicBasic Pro manual is the "Serin2" command can operate up to 38,400 baud. I haven't ever communicated at this speed so I am not sure what all is involved other than the oscillator must be faster than 4 Mhz.

I started re-writing the code for a standard PIC sometime ago but never finished it as there were many more important things I needed to get done.

[GregsGarage]

Looks like I have 3 options for getting the bms master and the controller to talk to each other. Just to recap what I want to do. Pass the battery amp info from the controller to the master along with a small current sensor on the master for auxillary loads and battery charging. Adjust the battery amp limit in the controller down when a low cell warning is reached. The bms will keep reducing the battery amp limit until the low cell warning stops, or shutdown the car completly when we get to say 10 amp limit.

1. recompile controller firmware for 9600 baud. An easy task, but this will prevent me from using the RTD Explorer program for setting up and diagnosing problems with the controller. The program is hard coded to work at the controllers 19200 baud rate. I can still use a normal terminal program though, its just not as friendly as RTD Explorer.

2. Get the master comunicating at 19200 baud. This would require porting the picaxe software to pic basic pro. I don't think this is very likely at the moment, lots of work and no guarantee of success.

3. Use something else between the master and controller to pass along commands. Might be possible to use a arduino for this. I have one lying around and it looks like there are some libraries for serial comms that can handle different baud rates, so might have a go with this option first, then try option 1 next if this doesn't work out, unless a pic basic pro version of the master software comes along first.

Greg

[retepsnikrep]

Gents I have been looking at the master code with a view to rewriting it for the picbasic pro compiler but have such a lot on at the moment i don't see that happening for six months or more. It works as is in both my applications and could work for Greg with minimal modifications if he goes for 9600 baud in his controller.

We could use an intermediate pic 12F683 for instance which just sits between master and controller adjusting the baud rates as reqd and passing messages back and forth. I think that would be a lot more reasonable to code. Greg if you want to have a go with the arudino by all means have a go and post your code so i can see what is needed by the controller etc. Rick if you could post whatever you managed to do with the master i can have a look at it.

The stumbling blocks for me at the moment are

1) I'm halfway through an A123 20ah Insight lithium install, have to get that finished.

2) I'm on with a couple of other big insight projects.

3) Work is very busy and i'm too knackered to get in the garage.

[GregsGarage]

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, ...
...A suggested fix is to use a 14 pin PIC16F688 which is the currently smallest thru-hole package PIC with a serial UART receiver. 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?

Don't know if you remember hardym's comments earlier this month, but maybe one of the pics he suggests might be better suited, having a hardware uart connected to the controller might be more reliable.

EDIT: Or this one that has 2 uart modules,http://uk.farnell.com/microchip/pic24f08ka101-i-p/mcu-16bit-1k-ram-nanowatt-20dip/dp/1707617

Greg

[retepsnikrep]

I think we should try it with the 12f683 first. I am aware of those notes. But feel free to have a go with the arudino it will be a while before i get to look at it.

[GregsGarage]

I will try the arduino first, as I have one ready to go. Here is what I am thinking of doing. Get the arduino to collect the data stream from the controller. Then pass on the battery amp and amp hour data to the master. Thinking of using the pulse led (J9 pin 3) to tell the arduino to send the data to the master. So when the master is ready for amp and amp hour data it will toggle the watchdog, which will tell the arduino to send the data. I think it would be good to use the controllers ah data and just have the master calculate ah for charging and auxiliary loads, then total the 2 figures together. For this I will get one of the allegro sensors that Peter is using, but maybe a 50 amp version. I like the idea of being able to see separate ah data for motor and auxiliary loads. For the controller cutback I can connect J7 (controller cutback) to the arduino. The arduino will then send the appropriate commands back to the controller to limit battery current when J7 is activated. I will start a new thread for this once I have made some progress.

Greg

[retepsnikrep]

Assuming the arudino responds to either a high or low for a data request using the watchodg led you will get one set of data every two seconds.

The watchdog is high for one second then low for one second add infinitum.

We can insert a serin command immediately after the watchdog to wait for the controller data.