Hi Michael, Thanks for your advice. I've just talked to my dealer and it turns out that my car (and every other one he has ever serviced) has a problem with the current sensor getting wet. Over time the plastic cover of the sensor gets tiny cracks in which water gets into the sensor and annoys it. I took a look at the current readout and can confirm that it varies from nonsense values of 7000 Amps to correct ones randomly. LevAhR will work and be the best SOC value as soon as this is fixed. I will heat it up and seal it. That should do the job. And you are right - this is also the value for the car to decide when to block the high power mode, light up the warning indicator and finally slow down. It comprises various values from the pack to do the math. These are all available on the Bus separately. I will be getting complete information on the meaning of every value available on the bus from my dealer - that'll help a lot :) I've just ordered all pieces to get the adapter cable together, so I should be able to continue progress within a week. Regards. Patrick Am 15.02.2013 um 13:24 schrieb Michael Balzer <dexter@expeedo.de>:
Hi Patrick,
a warm welcome from me as well. Although driving the Twizy now I still consider the Tazzari, it's a great LEM. Great to hear it's got a CAN bus as well.
Regarding Ah and SOC, that's really a bit complicated. You're right, the capacity (Ah usable) depends on a bunch of parameters including temperature, chemistry, age, .... Simple Ah counting is only sufficient if you know your battery characteristics quite well. Basically all sophisticated SOC readings provided by cars are based on some kind of virtual battery model that incorporates at least temperature, Ah counts, voltages and cycle age of the battery pack and of course the knowledge about how the battery ages.
I suppose your LevAhR is that SOC model value of the Tazzari BMS. Normally this will also be used by the car to decide when to throttle power (e.g. Twizy throttles at 6%, switches off at 0% -- although the battery pack is far from empty at 0% SOC). So even if it's not reliable, you may need to use that, as another reading on the OVMS would be useless then.
If the Tazzari does no battery protection based on the LevAhR, you (or "your" OVMS developer ;-)) may try to create a battery model yourself. You know the chemistry (LiFePO4) and maybe there are some spec sheets available. Parameters needed besides LevAh would include at least battery temperature (maybe available on CAN?) and age (in full cycles). It will still be an approximation though -- as is every SOC reading.
It seems strange though the Tazzari has no reliable SOC display, IMO that's essential for an EV. How does the driver know when he/she's going to run out of juice?
Regards, Michael
Am 15.02.2013 12:15, schrieb Patrick Kapsch:
Hi Mark, thanks for the warm welcome. I've asked the Tazzari driver community for support and there are some people willing to help with firmware testing. I told them about the project and to stand by until it is absolutely sure that I can log and decode the messages from the bus. In my first log I did several dumps including one while driving, one while charging and so on. I found that they are all the same. All parameters must be asked for. I looked at the values provided by the service console and there are a number of parameters that could be used to identify the various stages of the car. I've just contacted my dealer to ask for further documentation on the service console and a detailed explanation of every value provided, as they are all named with acronyms on the display.
As I was driving with the service console attached to my car and looking at the values I came across the first major question with regard to the SOC. There are two percentaged SOC-Values named LevAh and LevAhR. LevAh basically just counts down the remaining Ah in the pack and is set to 100% after a full charge. LevAhR is represented in the dashboard by ten segments that indicate the SOC for the driver. Many cars have problems with this, especially in the cold days. Sometimes this stays at 100%, sometimes it shows nothing and so on. I'm not sure what this value is supposed to mean. There is obviously some other value involved to calculate this SOC value. As this LevAhR is not very reliable I wouldn't use it for OVMS. But a simple countdown from the nominal value of Ah in the pack (which is 160Ah in a Tazzari) isn't the right value either, or is it? I'm no expert on this but what I thought was happening in cold conditions is that one can't pull as much Ah from the pack as in warmer conditions. So what that would mean is the car would stop working much earlier in cold conditions than the LevAh-Value would imply. If let's say the Ah that can be provided from the pack is 20% lower than the full possible Ah in warm conditions, then LevAh would still be at 20% charge when the car already ran out of juice. If that's true, then we will have to calculate our own SOC from the other provided values of the BMS. But that's quite a hard thing to do, isn't it? Please tell me that I'm wrong and the simple counting down of Ah taken from the pack is a reasonable way to calculate a SOC value :)
Regards, Patrick
Am 14.02.2013 um 01:59 schrieb Mark Webb-Johnson <mark@webb-johnson.net>:
Nikki: The reply below might be useful for you and the NL support. Feasibility really comes down to just 3 parameters.
Patrick,
Thanks for the help, and I'm sure we can find someone to help with the coding. Once we've identified the feasibility and basic messages are available, I'll create the stub (car type TZ, I guess) and initial support.
Is there an owner's forum for the Tazzari Zero? If so, if might be worth getting on that and seeing if anyone else is willing to help.
Your suggestion of using a Y-adapter-cable to look at the handheld unit seems sensible. Some of the Volt/Ampera work was done the same way. We typically see two sorts of data on CAN buses:
Constant stream - the native CAN mode where each module streams out its status messages continually, at preset intervals (e.g.; 10ms, 100ms, etc). Request-Response - the OBDII style mode where the tool requests a piece of information and the module replies.
From a feasibility point of view, you first need to identify and document the CAN bus specs (which I see you've started). Make sure that everything that is needed is on 1 can bus, and find the baud rate and physical connection feasibility. Once you have that, there are just three messages that are key to feasibility:
SOC - battery state of charge - car_SOC Car On/Off (ignition switch, or Park/Drive gear lever) - car_doors1 [bit7] Car Charging (true or false) - car_doors1 [bit 4]
If those three are available, and readable by the OVMS hardware, then the project is most likely feasible. There are lots of other parameters (range, temperature, odometer, speed, vin, tpms, etc) that are nice to have, but are either optional (nice-to-have) or can generally be derived from these three key messages - so long as they can be found. For example, on the Volt/Ampera we don't know the detailed charge messages, but do know whether the car is charging or not - we can assume charge interrupted if the charge finishes before 95% complete. Similarly, if the range of the car is XXkm, we can estimate the current range based on XX * SOC%. If the car has no GPS details on the CAN bus, then we can use the GPS in the OVMS module itself.
Once you have your Y-adapter-cable and CAN logger, the best is to look at the development checklists in the OVMS developer's guide:
https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/docs/OV... (page 35 and 36 on the version today, but that may change)
Those checklists show all the parameters we can support, and can be considered a 'target'. 100% is hard, but not necessary to have something still useful. Initially, I suggest you concentrate on the three key messages.
To help the people writing the code, you need to find the CAN bus messages (or request-response sequence) that gets you the information required, and fill that in under the "Vehicle Support Notes" column. It would be really helpful if you could also include one or more sample CAN bus dumps, with equivalent real-world values, to demonstrate each of the items supported. Three overall can bus dump for perhaps 1 minute while charging, 1 minute while parked still, and 1 minute while driving, would also be useful to provide background reference. All the CAN bus dumps should just be CSV (or tab or space separated) format, hexadecimal - keep it simple. You can see some examples for the Tesla Roadster at:
https://github.com/markwj/Open-Vehicle-Monitoring-System/tree/master/vehicle...
Please work in the 'open'. Let us know what you are doing (and how you are getting on, via this mailing list).
Regards, Mark.
On 14 Feb, 2013, at 6:33 AM, Patrick Kapsch wrote:
Hi everyone, My name is Patrick and I've been a silent reader of this list for some time now. A few weeks ago I bought three OVMS modules: one for my Ampera, one for the Twizy and a third one for my third Car - A Tazzari Zero. Most of the europeans should have heard of it. It's a smaller EV from italy. As the OVMS now works well in the Ampera and the Twizy, I started the reverse engineering of the Tazzari CAN messages today. There are two ports on the car: one for the controller data, and the other one for the BMS. The last one is of interest for the module, so I managed to log my first data from the Bus. I should mention that the ports are no OBDII connectors but instead the so called AMP Superseal. I borrowed the maintenance Kit from my car dealer and checked the cable wiring for future replication of the connection cable - no big deal.
I'm no coder and so I have to rely on you guys for the coding work that needs to be done in order to get this to work. I heard mark saying on Transport Evolved that the implementation of a new car is just 20% of the work, so I hope someone is willing to go that last bit for me as I will do my very best to document the CAN messages.
In my first log I just found a hand full of counters or some kind of timer data that counts upwards or downwards periodically, as well as three very stable but not static values. I have the proprietary maintenance handheld device in hand with which one can read out all the data provided on this port. What I now plan to do is build some sort of Y-Adapter-Cable to attach both devices - the handheld and the CAN logger to the port. This way I should be able to log the messages from the device as well as the answers from the BMS as it requests these. I feel pretty confident that I'll be decoding almost every value provided.
I'm absolutely amazed by this project and how far it has come and I'm very happy to contribute to this. Please feel free to share your thoughts on this.
Regards from Germany, Patrick Kapsch _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev