<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi Michael,</div><div>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 :)</div><div><br></div><div>I've just ordered all pieces to get the adapter cable together, so I should be able to continue progress within a week.</div><div><br></div><div>Regards.<br>Patrick</div><div><br>Am 15.02.2013 um 13:24 schrieb Michael Balzer <<a href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>>:<br><br></div><blockquote type="cite"><div>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
Hi Patrick,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.02.2013 12:15, schrieb Patrick
Kapsch:<br>
</div>
<blockquote cite="mid:41D7F621-BFFD-4A72-A807-F9615DAE810A@mac.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
Hi Mark,
<div>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.</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div>There are two percentaged SOC-Values named LevAh and LevAhR.</div>
<div>LevAh basically just counts down the remaining Ah in the pack
and is set to 100% after a full charge.</div>
<div>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?</div>
<div>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 :)</div>
<div><br>
</div>
<div>Regards,</div>
<div>Patrick</div>
<div><br>
</div>
<div>
<div>Am 14.02.2013 um 01:59 schrieb Mark Webb-Johnson <<a moz-do-not-send="true" href="mailto:mark@webb-johnson.net">mark@webb-johnson.net</a>>:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space; ">
<div><br>
</div>
<div>Nikki: The reply below might be useful for you and the
NL support. Feasibility really comes down to just 3
parameters.</div>
<div><br>
</div>
Patrick,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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:</div>
<div>
<div><br>
</div>
<div>
<ol class="MailOutline">
<li>Constant stream - the native CAN mode where each
module streams out its status messages continually,
at preset intervals (e.g.; 10ms, 100ms, etc).</li>
<li>Request-Response - the OBDII style mode where the
tool requests a piece of information and the module
replies.</li>
</ol>
</div>
</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>
<ol class="MailOutline">
<li>SOC - battery state of charge - <i>car_SOC</i></li>
<li>Car On/Off (ignition switch, or Park/Drive gear
lever) - <i>car_doors1 [bit7]</i></li>
<li>Car Charging (true or false) - <i>car_doors1 [bit
4]</i></li>
</ol>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<blockquote class="webkit-indent-blockquote" style="margin:
0 0 0 40px; border: none; padding: 0px;">
<div><a moz-do-not-send="true" href="https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/docs/OVMS_Development.pdf?raw=true">https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/docs/OVMS_Development.pdf?raw=true</a></div>
<div>(page 35 and 36 on the version today, but that may
change)</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<blockquote class="webkit-indent-blockquote" style="margin:
0 0 0 40px; border: none; padding: 0px;"><a moz-do-not-send="true" href="https://github.com/markwj/Open-Vehicle-Monitoring-System/tree/master/vehicle/roadster_canlogs">https://github.com/markwj/Open-Vehicle-Monitoring-System/tree/master/vehicle/roadster_canlogs</a></blockquote>
<div><br>
</div>
<div>Please work in the 'open'. Let us know what you are
doing (and how you are getting on, via this mailing list).</div>
<div><br>
</div>
<div>Regards, Mark.</div>
<div><br>
<div>
<div>On 14 Feb, 2013, at 6:33 AM, Patrick Kapsch wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">Hi everyone,<br>
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.<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I'm absolutely amazed by this project and how far it
has come and I'm very happy to contribute to this.<br>
Please feel free to share your thoughts on this.<br>
<br>
Regards from Germany,<br>
Patrick Kapsch<br>
_______________________________________________<br>
OvmsDev mailing list<br>
<a moz-do-not-send="true" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
<a moz-do-not-send="true" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a moz-do-not-send="true" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
</blockquote>
</div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
</pre>
</div></blockquote><blockquote type="cite"><div><dexter.vcf></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>OvmsDev mailing list</span><br><span><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a></span><br><span><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a></span><br></div></blockquote></body></html>