[Ovmsdev] Quick update on Tazzari CAN Logs

Sun Mar 3 21:09:30 HKT 2013

Mark,
thanks in advance. I'm ready to test any time.

Patrick

Am 03.03.2013 um 13:45 schrieb Mark Webb-Johnson <mark at webb-johnson.net>:

> Patrick,
> 
> I've done the basic implementation for this, but completely untested.
> 
> As we're transmitting on the bus, for the polling, I'd rather test this on my simulator first to ensure everything is as expected. I should be done with that in a few days and then will upload to github for you to try in the car.
> 
> Regards, Mark.
> 
> On 1 Mar, 2013, at 1:58 PM, Patrick Kapsch <patrick.kapsch at mac.com> wrote:
> 
>> Mark,
>> One can say that once it goes 00 every flip back to 63 is an interruption. It has to go all the way up to 04.
>> 00 -> 63 = interrupt
>> 01 -> 63 = interrupt
>> 03 -> 63 = interrupt
>> 04 -> 63 = okay, we were fully charged at this point (early abortion of the EQ phase)
>> 
>> Patrick
>> 
>> Am 01.03.2013 um 01:43 schrieb Mark Webb-Johnson <mark at webb-johnson.net>:
>> 
>>> Patrick,
>>> 
>>> Is there _any_ difference if the charge is interrupted vs completes normally.
>>> 
>>> For example, on a normal charge it goes ->00->01->02->03->04. On an interrupted charge, it goes ->00->01(interrupt)->??.
>>> 
>>> Regards, Mark.
>>> 
>>> On 28 Feb, 2013, at 10:56 PM, Patrick Kapsch wrote:
>>> 
>>>> Hi Mark,
>>>> there is no difference on charge interruption. It will show "reset" 63
>>>> 
>>>> Patrick
>>>> 
>>>> 
>>>> Am 28.02.2013 um 14:56 schrieb Mark Webb-Johnson <mark at webb-johnson.net>:
>>>> 
>>>>> 
>>>>> Patrick,
>>>>> 
>>>>> We actually support four charge states:
>>>>> 
>>>>> Preparing to charge
>>>>> Charging
>>>>> Charge Done
>>>>> Charge Stopped (interrupted)
>>>>> 
>>>>> If the charge is interrupted (say circuit breaker trips), is there any different state shown than if it completes normally? If so, that would be good. If not, on other cars we just say that if charge finished before SOC is 95% or above, then it is interrupted.
>>>>> 
>>>>> Regards, Mark.
>>>>> 
>>>>> On 28 Feb, 2013, at 9:27 PM, Patrick Kapsch <patrick.kapsch at mac.com> wrote:
>>>>> 
>>>>>> Mark,
>>>>>>> Damn, I'm good :-)
>>>>>> 
>>>>>> Yes - you are!
>>>>>> 
>>>>>>> You list SUV (last byte 00) as CHARGING and 'reset' (last byte 63) as not charging, but there are several others values 01, 02, 03 and 04 that would seem to also mean 'charging'. Can we say the 00 up to 04 is 'charging', and anything else is 'not charging'?
>>>>>> 
>>>>>> Exactly. When the charge comes to an end, the value goes to 1 up to 3. When it hits 4 (called SOV) it basically enters the EQ-Phase which means charging is complete.
>>>>>> So I'd suggest 00 - 03 is charging, and 63 as well as 04 is not charging.
>>>>>> 
>>>>>> Thanks :)
>>>>>> 
>>>>>> Patrick
>>>>>> 
>>>>>> 
>>>>>> Am 28.02.2013 um 14:19 schrieb Mark Webb-Johnson <mark at webb-johnson.net>:
>>>>>> 
>>>>>>> 
>>>>>>>> I can now confirm your guesses that 0x267 FF and 00 is indeed an indicator for the ignition.
>>>>>>>> And yes - your guess on the 0x165-167 is correct too - these are the voltages of the 24 cells, separated in 3 packs.
>>>>>>> 
>>>>>>> Damn, I'm good :-)
>>>>>>> 
>>>>>>>> I've attached a PDF with all important values on the bus. One thing I got problems with was the Current indicator. It jumps around so quickly that I didn't had the chance to read out one exact value and determine the exact value in Hex on the bus. That's why I've attached a logfile as well in which I was charging with the 400V charger at 63-64A.
>>>>>>>> I hope you can work that out as well and now have sufficient information to begin coding.
>>>>>>> 
>>>>>>> It seems ok, but one question on the charge status values. You list SUV (last byte 00) as CHARGING and 'reset' (last byte 63) as not charging, but there are several others values 01, 02, 03 and 04 that would seem to also mean 'charging'. Can we say the 00 up to 04 is 'charging', and anything else is 'not charging'?
>>>>>>> 
>>>>>>> I'll have a try at coding this up this weekend.
>>>>>>> 
>>>>>>> Regards, Mark.
>>>>>>> 
>>>>>>> On 28 Feb, 2013, at 6:10 AM, Patrick Kapsch <patrick.kapsch at mac.com> wrote:
>>>>>>> 
>>>>>>>> Mark,
>>>>>>>> I can now confirm your guesses that 0x267 FF and 00 is indeed an indicator for the ignition.
>>>>>>>> And yes - your guess on the 0x165-167 is correct too - these are the voltages of the 24 cells, separated in 3 packs.
>>>>>>>> I've attached a PDF with all important values on the bus. One thing I got problems with was the Current indicator. It jumps around so quickly that I didn't had the chance to read out one exact value and determine the exact value in Hex on the bus. That's why I've attached a logfile as well in which I was charging with the 400V charger at 63-64A. I hope you can work that out as well and now have sufficient information to begin coding.
>>>>>>>> 
>>>>>>>> Many thanks!
>>>>>>>> 
>>>>>>>> Patrick
>>>>>>>> 
>>>>>>>> <charging_at_around -63.00 to -64.00 A.CSV>
>>>>>>>> <Tazzari_CAN_Information.pdf>
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Am 22.02.2013 um 09:46 schrieb Mark Webb-Johnson <mark at webb-johnson.net>:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 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
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>> 
>>>>> _______________________________________________
>>>>> 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
> 
> _______________________________________________
> 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.teslaclub.hk/pipermail/ovmsdev/attachments/20130303/d2ba43d8/attachment-0001.html>