[Ovmsdev] Quick update on Tazzari CAN Logs

Mark Webb-Johnson mark at webb-johnson.net
Fri Feb 22 16:46:45 HKT 2013 

Ok, answering myself (after re-reading [struggling] through that German PDF), I see there are 3 BMS, so probably:

0x165, 0x1E5 and 0x2E5 are from BMS1
0x166, 0x1E6 and 0x2E6 are from BMS2
0x167, 0x1E7 and 0x2E7 are from BMS3

And that leaves 0x267 sticking out as something special. Not a BMS but some other controller.

Regards, Mark.

On 22 Feb, 2013, at 4:36 PM, Mark Webb-Johnson wrote:

> 
> Patrick,
> 
>> I've uploaded the logs and a description of all available parameters on my dropbox. Please don't upload the parameter list anywhere else as this is confidential service information from Tazzari.
> 
> 
> Data looks very simple. Seems to be only 10 regular IDs on the CAN bus:
> 
> 0x165
> 0x166
> 0x167
> 0x1E5
> 0x1E6
> 0x1E7
> 0x267
> 0x2E5
> 0x2E6
> 0x2E7
> 
> Of those, nine are relatively boring (just decrementing numbers ?!?!!!?):
> 
> Blind guess is that 0x165, 0x166, 0x167, 0x1E5, 0x1E6 and 0x1E7 are battery voltages/current - 2 bytes per reading, 4 readings per message. That would be 24 readings total. How many sheets in the Tazzari battery pack?
> 0x2E5 and 0x2E6 are interesting in that they are unchanging for all logs except charging (where they count down).
> No idea what 0x2E7 is - that wiggles slightly on all the logs.
> 
> But 0x267 stands out:
> 
> charging.CSV
> 0x267	0,5875	00	00	00	00	FF	F6	00	00
> 0x267	0,7381	00	00	00	00	FF	F6	00	00
> 0x267	0,8887	00	00	00	00	FF	F6	00	00
> 0x267	1,0393	00	00	00	00	FF	F6	00	00
> 0x267	1,1899	00	00	00	00	FF	F6	00	00
> 0x267	1,3406	00	00	00	00	FF	F5	00	00
> 0x267	1,4912	00	00	00	00	FF	F5	00	00
> 0x267	1,6418	00	00	00	00	FF	F6	00	00
> 0x267	1,7924	00	00	00	00	FF	F6	00	00
> 0x267	1,9430	00	00	00	00	FF	F6	00	00
> 
> ignition_on_driving.CSV
> 0x267	******	00	00	00	00	00	8E	00	00
> 0x267	0,2245	00	00	00	00	00	8E	00	00
> 0x267	0,3751	00	00	00	00	00	8F	00	00
> 0x267	0,5257	00	00	00	00	00	8F	00	00
> 0x267	0,6764	00	00	00	00	00	8F	00	00
> 0x267	0,8270	00	00	00	00	00	8F	00	00
> 0x267	0,9776	00	00	00	00	00	8F	00	00
> 0x267	1,1282	00	00	00	00	00	8F	00	00
> 0x267	1,2788	00	00	00	00	00	90	00	00
> 0x267	1,4294	00	00	00	00	00	90	00	00
> 
> ignition_on_no_gear_selected.CSV
> 0x267	0,2458	00	00	00	00	00	8D	00	00
> 0x267	0,3963	00	00	00	00	00	8F	00	00
> 0x267	0,5469	00	00	00	00	00	8E	00	00
> 0x267	0,6977	00	00	00	00	00	8D	00	00
> 0x267	0,8481	00	00	00	00	00	8C	00	00
> 0x267	0,9989	00	00	00	00	00	8D	00	00
> 0x267	1,1495	00	00	00	00	00	8C	00	00
> 0x267	1,3000	00	00	00	00	00	8C	00	00
> 0x267	1,4508	00	00	00	00	00	8C	00	00
> 0x267	1,6012	00	00	00	00	00	8C	00	00
> 
> parked.CSV
> 0x267	0,1960	00	00	00	00	FF	F9	00	00
> 0x267	0,3466	00	00	00	00	FF	F8	00	00
> 0x267	0,4973	00	00	00	00	FF	F7	00	00
> 0x267	0,6479	00	00	00	00	FF	F6	00	00
> 0x267	0,7985	00	00	00	00	FF	F5	00	00
> 0x267	0,9491	00	00	00	00	FF	F4	00	00
> 0x267	1,0997	00	00	00	00	FF	F4	00	00
> 0x267	1,2503	00	00	00	00	FF	F5	00	00
> 0x267	1,4009	00	00	00	00	FF	F5	00	00
> 0x267	1,5516	00	00	00	00	FF	F5	00	00
> 
> Seems to be B5 is 00 when driving, or FF when not. But, then again this is just a few seconds of logs - but it might be worth checking into. Perhaps it is just SOC, and was different at the time the four logs were taken, or were they taken at very similar times? Can you check that 0x267 B5 theory? I guess you'd need to see more data, and in particular a log showing the transition from car off to ignition on to driving (in one log) would be helpful.
> 
>> Another important thing to mention is the power supply of the port. As the Tazzari has no 12V-Battery at all it's got everything powered via DCDC-Converters. There is a tiny one for the alarm and remote key and a big one for the rest of the power such as lights, radio, etc. AND *sadface* the BMS. The BMS Port is only active while driving, charging and about 3 mins after one shuts the car off.
> 
> 
> So does that mean that after 3 minutes the 12V power is cut to that port? OVMS will lose power?
> 
> Regards, Mark.
> 
> On 22 Feb, 2013, at 3:36 PM, Patrick Kapsch wrote:
> 
>> Mark,
>> thanks for the quick reply.
>> The Baud rate is 1.000.000. The problem with the driving-idicator value is that the Port just provides BMS information. There is only an indication of the selected drive mode which doesn't reset itself to a "no mode selected" value, but instead back to one particular drive mode.
>> Another important thing to mention is the power supply of the port. As the Tazzari has no 12V-Battery at all it's got everything powered via DCDC-Converters. There is a tiny one for the alarm and remote key and a big one for the rest of the power such as lights, radio, etc. AND *sadface* the BMS. The BMS Port is only active while driving, charging and about 3 mins after one shuts the car off. Thank god we have a server that caches the last values provided by the car. As a parked car with no charging will have no changes to the SOC or other important values, it's okay, but we have to keep that in mind.
>> 
>> I've uploaded the logs and a description of all available parameters on my dropbox. Please don't upload the parameter list anywhere else as this is confidential service information from Tazzari.
>> 
>> https://www.dropbox.com/l/lzz7mJyDjMW3A8rmVaNfHd
>> 
>> Regards,
>> Patrick Kapsch
>> 
>> 
>> Am 22.02.2013 um 03:10 schrieb Mark Webb-Johnson <mark at webb-johnson.net>:
>> 
>>> Patrick,
>>> 
>>>> I wasn't really able to dive deeply into the messages, but I found the SOC and a charge-status that indicates whether or not the car charges. 
>>> 
>>> This looks to be a variant of OBDII style communications. Very similar to what we are using for the Volt/Ampera and generic OBDII modules.
>>> 
>>>> Request:	0x78A	75 21 F6 E0
>>> 
>>> 
>>> I'm guessing 7521 is the request function, and F6E0 is the PID (item) being requested. The request is sent to the controller at 0x78A.
>>> 
>>>> Reply:	0x775	0A A1 F6 E0 00 00 00 63
>>> 
>>> 
>>> The controller replies from 0x775. In OBDII, an offset of 8 is used. It seems the Tazzari uses an offset of 21 - bizarre, but possible.
>>> 0AA1 is presumably the code for 'reply to your item request'.
>>> F6E0 is the PID being replied.
>>> The remaining four bytes (00000063) is the replied data.
>>> 
>>>> I'm still searching for a way to tell if the car is parked or not. As far as I know by now there is nothing on the Bus that indicates this. Is a GPS-Based determination generally possible? The OVMS would have to check the coordinates periodically and compare them. A charging process indicates a parked car as well, and could turn of the GPS comparison.
>>> 
>>> 
>>> Surprised: I would have thought this would have been the easier one to find.
>>> 
>>> I think GPS would not be suitable / ideal for this:
>>> - It would need quite a bit of logic to differentiate 'moving' vs just normal GPS slight position changes.
>>> - What if GPS lock was lost - do we assume parked or traveling under an overpass or in a tunnel?
>>> 
>>> I guess we could use ground-speed from the GPS - with a speed=0 for a prolonged time being interpreted as parked - but that is not ideal.
>>> 
>>> Have you managed to find 'vehicle speed' on the can bus? You just need some indication that the car is in 'drive' mode vs not driving. Speed, RPM, kWh usage, coolant pump, ignition status, gear selector, handbrake status, activity on the bus, etc - any one of such indicators would be fine. I am sure we can find something. If you can send us some textual logs of the vehicle driving vs parked vs charging, we may be able to find something (not necessarily something from the diagnostic tool you have, but something broadcast on the can bus periodically).
>>> 
>>> What is the baud rate of the can bus? If you can let me know that, I can quickly make you a proof-of-concept firmware that can read the soc and charging status (as well as the usual location, etc).
>>> 
>>> Regards, Mark.
>>> 
>>> On 21 Feb, 2013, at 11:39 PM, Patrick Kapsch wrote:
>>> 
>>>> Hi guys,
>>>> I just wanted to give you a quick update on my reverse engineering on the Tazzari Zero CAN-Bus. I've put together the Y-Cable-Adapter to attach the service-console as well as the USB-Interface to the Bus (see picture attached). As my dealer needs to get back his tools I borrowed, I wasn't really able to dive deeply into the messages, but I found the SOC and a charge-status that indicates whether or not the car charges. I will hopefully be able to write down all values that are provided by next week. 
>>>> 
>>>> 
>>>> LevAhR
>>>> This is the state of charge in percentage
>>>> 
>>>> Request:
>>>> 0x78A	75 21 F9 EF
>>>> 
>>>> Response:
>>>> 0x775	0A A1 F9 EF 00 00 03 E8
>>>> Value 100.0%
>>>> 03 E8 represent 1000 = 100.0 % SOC
>>>> -------------------------------------------------------------
>>>> 
>>>> Charge Status
>>>> Values to determine whether the car charges or not.
>>>> 
>>>> Request:
>>>> 0x78A	75 21 F6 E0
>>>> 
>>>> Response:
>>>> 0x775	0A A1 F6 E0 00 00 00 63
>>>> Value "reset" (not charging)
>>>> 
>>>> 0x775	0A A1 F6 E0 00 00 00 00
>>>> Value "SUV" (charging)
>>>> Note: there are more than these two values while the charging comes to an end. I'll know them soon. But for now !=reset should do the job for charging true.
>>>> 
>>>> I'm still searching for a way to tell if the car is parked or not. As far as I know by now there is nothing on the Bus that indicates this. Is a GPS-Based determination generally possible? The OVMS would have to check the coordinates periodically and compare them. A charging process indicates a parked car as well, and could turn of the GPS comparison.
>>>> 
>>>> Regards,
>>>> Patrick Kapsch
>>>> 
>>>> <IMG_2236.jpg>
>>>> 
>>>> _______________________________________________
>>>> 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
>> 
>> _______________________________________________
>> 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/20130222/757a28f3/attachment.htm>

More information about the OvmsDev mailing list