[Ovmsdev] Quick update on Tazzari CAN Logs

[Patrick Kapsch]

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