# About J1939 and Communication Structure



## iruraz (Sep 4, 2012)

Dear All,

I work with 4-5 different vendors for my vehicle canbus structure (BMS, Charger, DC-DC Converter, VMU -vehicle management unit-). And I have to specify canbus properties (bus speed, ids..etc.) for communication between devices which work on vehicle bus. Which system do you recommend? Because CAN protocol has wide application proporties and conditions. Different car makers can use different communication standards. J1939 bundles seem appropriate for us but how do I define vehicle canbus requirements? For example should we use J1939-73 application layers standards for instrument cluster? And is j1939-11 physical layer standard enough for specfying? etc.

In attachment file you can see my basic system structure. MCU canbus proporties are defined by VMU vendor.

Regards.


----------



## iruraz (Sep 4, 2012)

Is there anyone who knows anything about J1939?


----------



## peterguy (Jun 18, 2012)

If you tell a bit more about the background of your project, I'm sure somebody can help.

Following questions came to my mind while reading your thread:
Do you need to specify the CAN communication for all ECUs, or are some of the ECUs out of the box and have already an implemented CAN configuration?
Are you a big OEM or just a small company?Why do you want to use the J1939? Is it a requirement of your project or just a proposal. 


If you there is no regulation forcing you to use J1939, I would try to keep the CAN communcation as simple as possible.
500kbit, all messages cyclic, no special protocol on top of the CAN bus.


regards,
Peter


----------



## iruraz (Sep 4, 2012)

@peterguy thanks for your response. we are small company and we try to build a prototype. 

Every components that you see in the diagram are provided different vendors. Every components support CANbus. But I am confused about how they communicate between VMU (Vehicle Management Unit) and instrument cluster (for example instrument cluster is able to read data from BMS to show battery informations). I don't have any CAN configuration and specification. In fact I don't know how I specify CAN for vehicle bus.

There is no regulation forcing us to use J1939. But it is specified every rules for CANbus. For example it has 250 kbit/s speed and it has PGN (Parameter Group Number). Shortly it has exact rules for CANbus specs. I don't need to specify anything (if i am wrong correct me please).

I want to use simple protocol specs but I don't know how I set it. Specifying baud rates is no enough for CANbus. I need to specify components ID number and their priorities.

If you have any idea about specifying CANbus specs, I would like to know. Thanks in advance.

Here is the instrument cluster and infotainment screen (I mean MimodHP monitoring systems) which we intend to use in our electric car.

http://www.mimodhp.com/Default.aspx

Regards.


----------



## peterguy (Jun 18, 2012)

Ok, very good, so you have all the freedom to design the system as you want.  

To answer your question about J1939: Maybe you do not need to specify anything ( I do not know the protocol, but I really doubt that its that easy), but: If you stick to it you need to find components that support this protocol or you convince the vendor that he implements J1939 on his components.


First of all, if your are not experienced with the CAN bus in general, you should get more knowledge in that topic (training, wiki, pratice). 
The CAN Bus is the backbone of your system, and a good configuration is essential for a quick development and a reliable system.


To set up the CAN, we usually create a CANdb file using the follwoing tool: http://www.vector.com/vi_candb_en.html
In that file the complete CAN communication is configured (who sends what on which id). Some of the information is coming from the component's specification (Charger, DC/DC) and some information are defined by ourselfs (VMU to Cluster, BMS to VMU).
The VMU developer takes the candb file and implements the CAN communication and the control logic behind on the VMU .

Who develops the VMU for your Car?

Maybe it also helps if I describe how we are building our EVs:
1) We buy a charger with CAN interface. For example an Eltek Valere Charger (just an example: http://www.eltek.com/wip4/detail_products.epl?k1=25508&close=1&id=1207367)
This charger has a CAN interface which is already configured to 500kbit speed. So, all the other components connected to this CAN bus must have the same speed.
The charger is already configured to send and receive some CAN messages. The charger CAN configuration is defined in the charger specification. The VMU Software developer has to program the VMU to communicate with the charger.

2) same story for the DC/DC

3) same story for the Inverter/motor

4) For the BMS the approach depends a lot on your purpose. Do you develop your own BMS? Do you buy a generic one on the market? Or does your Battery have a build-in BMS?

5) The instrument cluster: Here we chose either a freely configurable Display with CAN interface (example: http://www.gems.co.uk/?content=pages&id=lds4-driver-display), or we develop one on our own. Here for example a display that I developed at home, with CAN interface: http://www.diyelectriccar.com/forums/showthread.php?t=80571
I tried to get the datasheet of your instrument cluster, but somehow there is none on the link that you posted.

Maybe, if some of your components are not compatible to each other (because of the CAN speed for example, or because they send data with the same ids), you need to add a separate CAN bus.

I hope those information help you a bit.I know for the start its a big topic with a lot of question marks!

Regards,
Peter


----------



## iruraz (Sep 4, 2012)

@peterguy thanks for your interest. 



> To answer your question about J1939: Maybe you do not need to specify anything ( I do not know the protocol, but I really doubt that its that easy), but: If you stick to it you need to find components that support this protocol or you convince the vendor that he implements J1939 on his components.


For using J1939 do we need to purchase J1939 specification from SAE? I have only theoretical knowledge about J1939 and it seems easy to use because it is plug&play system. I keep touch with my VMU vendor about CANbus and they are waiting me for specifying CANbus specs. 



> To set up the CAN, we usually create a CANdb file using the follwoing tool: http://www.vector.com/vi_candb_en.html
> In that file the complete CAN communication is configured (who sends what on which id). Some of the information is coming from the component's specification (Charger, DC/DC) and some information are defined by ourselfs (VMU to Cluster, BMS to VMU).
> The VMU developer takes the candb file and implements the CAN communication and the control logic behind on the VMU .


Thanks for tool advice. But we have a lot of datasheet about components which components use which ID. But in the integration process I will need a can analyzer for monitoring and checking CANbus traffic. Which one do you recommend? I would like to know.



> Who develops the VMU for your Car?


We purchased motor+controller+VMU from TM4.



> Maybe it also helps if I describe how we are building our EVs:
> 1) We buy a charger with CAN interface. For example an Eltek Valere Charger (just an example: http://www.eltek.com/wip4/detail_pro...e=1&id=1207367)
> This charger has a CAN interface which is already configured to 500kbit speed. So, all the other components connected to this CAN bus must have the same speed.
> The charger is already configured to send and receive some CAN messages. The charger CAN configuration is defined in the charger specification. The VMU Software developer has to program the VMU to communicate with the charger.


We purchased Elcon 5kW charger and it has CANbus interface. But there is not any detailed technical documents about it is CAN interface.



> 4) For the BMS the approach depends a lot on your purpose. Do you develop your own BMS? Do you buy a generic one on the market? Or does your Battery have a build-in BMS?


No I don't develop BMS or anything else. We purchased from Orion. As far as I understand you develop software for BMS.



> 5) The instrument cluster: Here we chose either a freely configurable Display with CAN interface (example: http://www.gems.co.uk/?content=pages...driver-display), or we develop one on our own. Here for example a display that I developed at home, with CAN interface: http://www.diyelectriccar.com/forums...ad.php?t=80571


I looked to GEMS screen but it is small for us. We need 7 or 8 inch screen for displaying data. We intend to use digital cluster (like Tesla ModelS). Your gauge design is impressive. Can you develop a digital instrument cluster for us? 



> I tried to get the datasheet of your instrument cluster, but somehow there is none on the link that you posted.


Yes they don't have any datasheets in their website. But if you want to see their designs you can look their facebook page. We need impressive digital design like that :

https://www.facebook.com/MiModHP/photos



> Maybe, if some of your components are not compatible to each other (because of the CAN speed for example, or because they send data with the same ids), you need to add a separate CAN bus.


They are compatible because all of them can support same baud rates. 

My other question: Should VMU's vendor adjust to VMU according to other device's ID? 

As I mentioned before I don't develop anything I purchased most of components from different vendors. Here is the list of the components which work in vehicle bus you can see below :

- Elcon Charger 5kW
- Orion BMS
- Delphi Universal DC/DC Converter 2.2kW (for supplying 12V accessories)
- VMU (TM4 - Neuro)
- Instrument Cluster and Infotainment Screen (intend to MimodHP)

If we divide a few step building vehicle bus specs:

1- Specify baud rate of the bus?
2- Make list of components IDs which work on vehicle bus.
3- Specify which one of these IDs numbers for VMU or Instrument Cluster.
4- Inform the VMU vendor about IDs and vehicle bus
5- Inform the Cluster vendor about IDs and vehicle bus



> I hope those information help you a bit.I know for the start its a big topic with a lot of question marks!


Yes they are very helpful. Thanks again.

Best regards.


----------



## peterguy (Jun 18, 2012)

iruraz said:


> For using J1939 do we need to purchase J1939 specification from SAE? I have only theoretical knowledge about J1939 and it seems easy to use because it is plug&play system. I keep touch with my VMU vendor about CANbus and they are waiting me for specifying CANbus specs.


I have no clue if you need to buy the spec. I also have only theoretical knowledge of it  
Have you already asked the vendors if they can support the J1939?




> Thanks for tool advice. But we have a lot of datasheet about components which components use which ID. But in the integration process I will need a can analyzer for monitoring and checking CANbus traffic. Which one do you recommend? I would like to know.


Very good that you already have most of the datasheets.
What we do is to enter the CAN Ids and Signals from all the datasheets into one CANdb file, using the tool I proposed to you. Then we add the Ids and signals we need for our purpose, in your case this would mailny be the data exchanged between cluster and VMU.

In the development process we program the CAN module of the VMU and BMS and cluster according to this CANdb file. As I understood, in your case the vendors do this job.

In the integration process we take the CANdb file and put it into CANoe for monitoring the CAN bus. The big advantage of using the CANdb file is that you now can see the physical signals on the CAN bus, so instead of raw data like Id 0x123 Data: 7F 7F 31 2E 30 AC 12 9C you see it like:
Message BMS_Info_Frame_to_VMU
SOC = 96%
CellVoltMin = 3,771 V
Current = 120,4A
... and so on
BTW, CANalyser is the lightwight version of CANoe.
You will need one of both tools for the integration, and of course also a compatible CAN bus interface for your PC (e.g. the VN1611 or VN1630 or CANcase XL)
Of course there are many other vendors for CAN bus tools, especially cheaper ones  , but we have good experience with those tools from Vector.



> We purchased motor+controller+VMU from TM4.


Very good choice, we also prefer the TM4 inverters and motors.





> We purchased Elcon 5kW charger and it has CANbus interface. But there is not any detailed technical documents about it is CAN interface.
> 
> No I don't develop BMS or anything else. We purchased from Orion. As far as I understand you develop software for BMS.


Have you checked out this Application note: http://www.orionbms.com/charger-integration/interfacing-elcon/




> I looked to GEMS screen but it is small for us. We need 7 or 8 inch screen for displaying data. We intend to use digital cluster (like Tesla ModelS). Your gauge design is impressive. Can you develop a digital instrument cluster for us?
> 
> Yes they don't have any datasheets in their website. But if you want to see their designs you can look their facebook page. We need impressive digital design like that :
> 
> https://www.facebook.com/MiModHP/photos


Whow thats really impressive. Me personally I prefer analog or LED driven instruments rather than full TFT ones, but this one is great.






> They are compatible because all of them can support same baud rates.


Ok, if they all support 500kbit I would set the baud rate to that value. Its a good compromise between data throughput and robustness



> My other question: Should VMU's vendor adjust to VMU according to other device's ID?


Yes, exactly. The VMU vendor needs to know all the CAN Ids on the bus so that he can develop his VMU software.




> If we divide a few step building vehicle bus specs:
> 
> 1- Specify baud rate of the bus? yes, if possible set to 500kbit
> 2- Make list of components IDs which work on vehicle bus. yes, e.g. using the CANdb++ editor
> ...


Regards,
Peter


----------



## iruraz (Sep 4, 2012)

@peterguy thanks for your interest and helps. Before start, I should tell that we purchased most of the components but we haven't received them yet.

Maybe I give up using J1939 for communication in vehicle bus. Because our components supports 500kbit/s as you mentioned before.



> What we do is to enter the CAN Ids and Signals from all the datasheets into one CANdb file, using the tool I proposed to you. Then we add the Ids and signals we need for our purpose, in your case this would mailny be the data exchanged between cluster and VMU.
> 
> In the development process we program the CAN module of the VMU and BMS and cluster according to this CANdb file. As I understood, in your case the vendors do this job.


Charger IDs, BMS IDs and DC-DC converter IDs are defined by vendor in their datasheets. As I mentioned before we won't able to configure VMU. But as far as I understand I should use CANdb++ with CANanalyzer or CANoe. By the way, do I have to use CANdb++ with CANanalyzer or CANoe? Because CANdb++ is a software tool and CANoe or CANanalyzer is hardware to connect CANbus. I read Vector's application note and to my understanding I should use it CANanalyzer or CANoe. Here is the application note link below :

http://www.vector.com/portal/medien...orship/EcoCar/AN-AND-1-116_CANdb_Tutorial.pdf

They are Vector's product. I posted them a mail to find out their price. I guess they are expensive tools. Is there any different tool which you recommend? (especially fair price)



> Very good choice, we also prefer the TM4 inverters and motors.


I am glad to hear this  Do you have any recommendation about BMS, DC-DC converter and Charger? For my understanding (I looked your gauges posts) you develop software for BMS and your firm products electric vehicle. 



> Have you checked out this Application note: http://www.orionbms.com/charger-inte...rfacing-elcon/


Yes I checked application note and it is ok.



> Me personally I prefer analog or LED driven instruments rather than full TFT ones, but this one is great.


Is there any analog gauge for electric cars (plug&play system)? I searched and analyzed many products but nearly all of them is not adequete for our project (some of them is insufficient and others have poor design)



> Ok, if they all support 500kbit I would set the baud rate to that value. Its a good compromise between data throughput and robustness





> Yes, exactly. The VMU vendor needs to know all the CAN Ids on the bus so that he can develop his VMU software.


I started working by your advices. Thanks again.

And I would like to know your thoughts about ISISPower products. Here is the link below. There is 3-Cell kit for controlling front and rear electrical harness. It seems nice plug&play solution for us.

http://www.isispower.com/products/multiplexing/3-cell-starter-kit.html

Best regards.


----------



## peterguy (Jun 18, 2012)

Sounds like your project is progressing 




iruraz said:


> Charger IDs, BMS IDs and DC-DC converter IDs are defined by vendor in their datasheets. As I mentioned before we won't able to configure VMU. But as far as I understand I should use CANdb++ with CANanalyzer or CANoe.


when I understood your posts before correct, your VMU vendor need the information about the CAN Id and speed to be able to adjust the VMU?
In that case you theoretically could give him just the datasheets (They'll need them anyway to understand the components). 
Yes the greatest advantage of the CANdb file is that it can be imported in CANoe or CANanlyser. And probably the VMU vendor will also appreciat to have it. Have you asked them which format of CAN spec they expect?




iruraz said:


> By the way, do I have to use CANdb++ with CANanalyzer or CANoe?


You do not need it, but I would strongly recommend it. Otherwise you just see the raw CAN data which is hardly readable.



iruraz said:


> Because CANdb++ is a software tool and CANoe or CANanalyzer is hardware to connect CANbus.


All three tools are software tools. 
CANdb++ is just for editing the CAN description.
CANoe and CANalyser is for displaying the live data on the CAN bus.
CANoe and CANalyser require CAN bus hardware like the VN16xx or CANcase that I mentioned before.



iruraz said:


> I guess they are expensive tools. Is there any different tool which you recommend? (especially fair price)


Yes, vector tools are expensive, compared to the competitors.
Some time ago I have also worked with the tools from PEAK. http://www.peak-system.com/
For just reading the CAN Bus I think those tools will be sufficient, too.



iruraz said:


> I am glad to hear this  Do you have any recommendation about BMS, DC-DC converter and Charger?


Hmm hard to give additional recommendations since I have no practical experience with the components/vendors that you have ordered. 
Most important is that the components have a well documented interface, and this seems to be the case since they have CAN and you have the specifications.



> For my understanding (I looked your gauges posts) you develop software for BMS and your firm products electric vehicle.


We are a small team that mainly convert combustion engine vehicles into electric vehicles. We also develop charger infrastructure, means battery buffered chargers for EVs. I mainly write the software for these chargers, but also parts of the VMU or BMS for the cars. As you probably know, in a small team everybody does everything 




iruraz said:


> Is there any analog gauge for electric cars (plug&play system)? I searched and analyzed many products but nearly all of them is not adequete for our project (some of them is insufficient and others have poor design)


This is also a problem for us.
There seems to be absolutely no ready-to-use dash/display/gauge that is worth the money it costs.
That's why we use either the GEMS or develop our own Dashs.
One reason why there is no plug'n'play product maybe that each vendor has its own proprietary interface so that its very hard to develop a generic gauge.



iruraz said:


> And I would like to know your thoughts about ISISPower products. Here is the link below. There is 3-Cell kit for controlling front and rear electrical harness. It seems nice plug&play solution for us.
> 
> http://www.isispower.com/products/multiplexing/3-cell-starter-kit.html


I'm not sure if I can give you good hints about that product.
Is it somehow the body controller for the car? So responsible for switching the lights, pumps, and so on?
In our pojects this is done by the BMS or VMU, which both are our own inhouse developments and therefore can not really be compared to this product.

Regards,
Peter


----------



## iruraz (Sep 4, 2012)

@peterguy,



> Sounds like your project is progressing


Yes you are right 



> when I understood your posts before correct, your VMU vendor need the information about the CAN Id and speed to be able to adjust the VMU?


Yes VMU and instrument cluster vendors need CAN IDs and datasheets to adjust VMU and instrument cluster.



> CANdb++ is just for editing the CAN description.
> CANoe and CANalyser is for displaying the live data on the CAN bus.
> CANoe and CANalyser require CAN bus hardware like the VN16xx or CANcase that I mentioned before.


If I only use CANdb++, don't I need to bus hadware (VN16xx,CANcase)? And Can't I watch the live data traffic on CANbus with CANdb++ ?



> Some time ago I have also worked with the tools from PEAK. http://www.peak-system.com/
> For just reading the CAN Bus I think those tools will be sufficient, too.


Thanks for your advice. I wanted price information from Vector this morning. According to price I may seek different products.



> We are a small team that mainly convert combustion engine vehicles into electric vehicles. We also develop charger infrastructure, means battery buffered chargers for EVs. I mainly write the software for these chargers, but also parts of the VMU or BMS for the cars. As you probably know, in a small team everybody does everything


Yes we are small company too. "Small company" meaning is divided 100 pieces 



> I'm not sure if I can give you good hints about that product.
> Is it somehow the body controller for the car? So responsible for switching the lights, pumps, and so on?
> In our pojects this is done by the BMS or VMU, which both are our own inhouse developments and therefore can not really be compared to this product.


Yes, it is body controller. As I mentioned before front and rear electrical harness. For example, high-low beam, turn signals, fog lights etc.

It is interesting what do you control with BMS? If we have configurable VMU I would control body components with VMU. But it is not possible for now (only vendor can configure I/O and it is hard to configure for every changes). Is your VMU programmable? ISIS product seems so powerful for controlling. 

Before next step, I mean after completion of prototypes, I intend to design new controllers with powerful MCUs. 

I am thankful for your helps. 

Best regards.


----------



## peterguy (Jun 18, 2012)

iruraz said:


> If I only use CANdb++, don't I need to bus hadware (VN16xx,CANcase)? And Can't I watch the live data traffic on CANbus with CANdb++ ?


Yes exactly. The CANdb++ tool just creates a CANdb file, nothing else.
btw, CANdb++ is shipped with CANoe (and maybe also with CANalyser).
So if you buy one of these software tools for bus analysis, you will have CANdb++.





iruraz said:


> Yes, it is body controller. As I mentioned before front and rear electrical harness. For example, high-low beam, turn signals, fog lights etc.


Ah ok understood. Just from reading it the product description sounds good, but who knows if its also good in reality  Maybe if you are
unsure about it you can ask them to visit you for a live demonstration.



iruraz said:


> It is interesting what do you control with BMS? If we have configurable VMU I would control body components with VMU. But it is not possible for now (only vendor can configure I/O and it is hard to configure for every changes). Is your VMU programmable? ISIS product seems so powerful for controlling.


Ok so, in case we convert a car to EV, we try to keep as much of the body control as it is already. So usually we do not need to touch the beams and lights and stuff like ABS.

We have two different types of BMS, the ones that are sitting directly on the batteries for reading the cell information and then a supervisor BMS that collects all the data, handles charging, power contactor switching, DC/DC, limits and error checking, Insulation check, and a lot of minor auxiliary I/O stuff.
Our VMU (as well as our BMS) is freely programable for us, and handles the drive train (torque vectoring, traction control, inverter control).





iruraz said:


> Before next step, I mean after completion of prototypes, I intend to design new controllers with powerful MCUs.


If you plan to have more projects like your current one, this might be a good idea. But keep in mind that developing the hardware and software and testing is a job that will keep a some people busy in full time 

Best regards,
Peter


----------



## iruraz (Sep 4, 2012)

@peterguy thanks again 



> So usually we do not need to touch the beams and lights and stuff like ABS.


ABS and ESP is critical for us. We try to find solution for ABS. 2-3 firm product ABS in the world.

I wonder your thoughts about BMS. Do you have any expreince with Orion or Elithion? I chose Orion first but I have some worried about cable harness because it is central connection (for 100 battery cells there is 101 cable connection). I will make decision between Elithion and Orion, which one do you recommend?

Regards.


----------



## peterguy (Jun 18, 2012)

iruraz said:


> ABS and ESP is critical for us. We try to find solution for ABS. 2-3 firm product ABS in the world.


Are you building a EV from the scratch or converting a combustion engine car to EV?
I think its possible to integrate an ABS in an EV build from scratch, but ESP I would say is nearly impossible without driving a huge effort.



iruraz said:


> I wonder your thoughts about BMS. Do you have any expreince with Orion or Elithion? I chose Orion first but I have some worried about cable harness because it is central connection (for 100 battery cells there is 101 cable connection). I will make decision between Elithion and Orion, which one do you recommend?


I have no experience with both, sorry. Our BMS is more like the Orion, so one PCB for 48 cells with a lot of wires to the cells.
But I also like the idea of the decentral solution of Elithion. 
Have you already chosen a battery?
If possible I would search for one with a BMS already included.

Regards,
Peter


----------



## iruraz (Sep 4, 2012)

@peterguy;



> Are you building a EV from the scratch or converting a combustion engine car to EV?


We are building EV from the scratch  It is really difficult build something new. We have strong mechanical team to design.



> I think its possible to integrate an ABS in an EV build from scratch, but ESP I would say is nearly impossible without driving a huge effort.


I wonder that how it is possible to integrate ABS. Should I integrate available car's ABS? Car which features are like our design. 

But for ESP it is impossible because there are alot of parameters for ESP.



> I have no experience with both, sorry. Our BMS is more like the Orion, so one PCB for 48 cells with a lot of wires to the cells.
> But I also like the idea of the decentral solution of Elithion.


Yes, you are right. Elithion's solution is great but they have high prices. I should decide between "cable troubles" and high price 



> Have you already chosen a battery?
> If possible I would search for one with a BMS already included.


Yes, we chose Winston's battery. If you have recommendation about battery. I would like to know it.

By the way, do you have any website? If it is possible, I would like to look your projects.

Thanks again for your helps.

Regards.


----------



## peterguy (Jun 18, 2012)

iruraz said:


> We are building EV from the scratch  It is really difficult build something new. We have strong mechanical team to design.


Sounds interesting. Can you tell some more details? What type of EV is it, for "normal" road use, racing, farming, ...




> I wonder that how it is possible to integrate ABS. Should I integrate available car's ABS? Car which features are like our design.


Yes, I would check either an available car's ABS, or maybe check also the motorsports market. I mean all the racing teams might have the same problem to find an ABS...



> Yes, we chose Winston's battery. If you have recommendation about battery. I would like to know it.


We work with Li-Ion Batteries rather than the LiFePO4 Batteries, so I will not be of much help here. Just a general advise (you will probably already know): For a long battery lifetime its good to not fully discharge the batteries each time. So if possible add some capacity reserves, e.g if you want to achieve a range of 100mls, plan the pack for 130mls.



> By the way, do you have any website? If it is possible, I would like to look your projects.


We usually do not publish our projects, since they are for internal purpose only.
But you could google for pikes peak 2012, one of our cars has made 1st place in the EV class 

Regards,
Peter


----------



## iruraz (Sep 4, 2012)

@peterguy,



> Sounds interesting. Can you tell some more details? What type of EV is it, for "normal" road use, racing, farming, ...


It is sport car for road use. 



> Yes, I would check either an available car's ABS, or maybe check also the motorsports market.


Thanks for advice.



> We work with Li-Ion Batteries rather than the LiFePO4 Batteries, so I will not be of much help here. Just a general advise (you will probably already know): For a long battery lifetime its good to not fully discharge the batteries each time. So if possible add some capacity reserves


As far as I know LiFePO4 is kind of Li-Ion. Correct me please if I am false. And about lifetime of battery, you are right. I read alot of technical data about them.



> We usually do not publish our projects, since they are for internal purpose only.
> But you could google for pikes peak 2012, one of our cars has made 1st place in the EV class


Rules for confidentiality  

I think you have small and powerful team  I looked for "pikes peak 2012". Is it the car in the links below?

http://www.driven-imagery.com/2012_ppihc_electric_cars/h3D2F6871#h3d2f6871
http://www.driven-imagery.com/2012_ppihc_electric_cars/h261A5F4F#h261a5f4f

Regards.


----------



## peterguy (Jun 18, 2012)

iruraz said:


> As far as I know LiFePO4 is kind of Li-Ion. Correct me please if I am false. And about lifetime of battery, you are right. I read alot of technical data about them.


You're right, LiFePO4 is some kind of Li-Ion.
But, the (lets say "classic") Li-Ion has a different characteristic than the LiFePO4.
For example the OCV vs SOC graph looks like this:









The blue line is similar to the graphs of the Li-Ion Batteries we use, and the red line is for the LiFePO4.





> I think you have small and powerful team  I looked for "pikes peak 2012". Is it the car in the links below?
> 
> http://www.driven-imagery.com/2012_ppihc_electric_cars/h3D2F6871#h3d2f6871
> http://www.driven-imagery.com/2012_ppihc_electric_cars/h261A5F4F#h261a5f4f


Yeap, exactly 

Regards,
Peter


----------



## iruraz (Sep 4, 2012)

@peterguy,

I should analyze different Li-Ion batteries. I am newbie about batteries. It is very important and critical topic.

I hope that our project would be successful.

As far as I understand you have much BMS experience and knowledges. Is there any books or other sources which you recommend for improving my BMS skills? (without Elithion  by the way I try to improve my C language skills for programming cpu)

Regards.


----------



## peterguy (Jun 18, 2012)

I can give you two links that helped me a lot to get started in the BMS topic some time ago.
This page really give you all information and crosslinks you need, enough stuff to read for weeks 
http://www.mpoweruk.com/bms.htm

This link maybe quite helpfull for understanding all the abbreviations:
http://mit.edu/evt/summary_battery_specifications.pdf

Good luck for your project!

Best regards,
Peter


----------



## iruraz (Sep 4, 2012)

@peterguy,



> This page really give you all information and crosslinks you need, enough stuff to read for weeks


You are right, these pages are very helpful.



> Good luck for your project!


Thank you too much for your helps. Keep in touch 

Regards.


----------

