[Ovmsdev] Introduction - Tazzari Zero

Fri Feb 15 19:15:55 HKT 2013

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>:

> 
> 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/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
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130215/85a2e3b5/attachment.htm>