[Ovmsdev] Introduction - Tazzari Zero

Thu Feb 14 08:59:10 HKT 2013

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130214/4c7a0453/attachment.htm>