[Ovmsdev] Introduction - Tazzari Zero

Michael Balzer dexter at expeedo.de
Fri Feb 15 20:24:16 HKT 2013


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 at webb-johnson.net <mailto:mark at 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:
>>
>>  1. Constant stream - the native CAN mode where each module streams
>>     out its status messages continually, at preset intervals (e.g.;
>>     10ms, 100ms, etc).
>>  2. 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:
>>
>>  1. SOC - battery state of charge - /car_SOC/
>>  2. Car On/Off (ignition switch, or Park/Drive gear lever) -
>>     /car_doors1 [bit7]/
>>  3. 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/OVMS_Development.pdf?raw=true
>>     (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/roadster_canlogs
>>
>>
>> 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 at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20130215/9f16c435/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dexter.vcf
Type: text/x-vcard
Size: 206 bytes
Desc: not available
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20130215/9f16c435/attachment-0001.vcf>


More information about the OvmsDev mailing list