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:
(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@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________