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
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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark,
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.
I'll check that as soon as I can.
So does that mean that after 3 minutes the 12V power is cut to that port? OVMS will lose power?
Yes - that's the case when parked and not charging. Regards, Patrick Am 22.02.2013 um 09:36 schrieb Mark Webb-Johnson <mark@webb-johnson.net>:
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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Let's see if I can confirm - Fingers crossed! Patrick Am 22.02.2013 um 09:46 schrieb Mark Webb-Johnson <mark@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Let's see if I can confirm - Fingers crossed! Patrick Am 22.02.2013 um 09:46 schrieb Mark Webb-Johnson <mark@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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 Am 22.02.2013 um 09:46 schrieb Mark Webb-Johnson <mark@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@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@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@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@lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@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@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@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@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@lists.teslaclub.hk >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@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@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@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@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@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@lists.teslaclub.hk >>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.teslaclub.hk >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@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@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@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@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@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@lists.teslaclub.hk >>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>> >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev@lists.teslaclub.hk >>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.teslaclub.hk >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@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@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@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@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@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@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@lists.teslaclub.hk >>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>>> >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev@lists.teslaclub.hk >>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>> >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev@lists.teslaclub.hk >>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.teslaclub.hk >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Perfect. Let's try it that way. We can always revise the logic later. Regards, Mark. On 1 Mar, 2013, at 1:58 PM, Patrick Kapsch 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@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@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@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@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@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@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@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@lists.teslaclub.hk >>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>>>> >>>>> _______________________________________________ >>>>> OvmsDev mailing list >>>>> OvmsDev@lists.teslaclub.hk >>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>>> >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev@lists.teslaclub.hk >>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>> >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev@lists.teslaclub.hk >>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.teslaclub.hk >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@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@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@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@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@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@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@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@lists.teslaclub.hk >>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>>>> >>>>> _______________________________________________ >>>>> OvmsDev mailing list >>>>> OvmsDev@lists.teslaclub.hk >>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>>> >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev@lists.teslaclub.hk >>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>> >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev@lists.teslaclub.hk >>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.teslaclub.hk >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark, thanks in advance. I'm ready to test any time. Patrick Am 03.03.2013 um 13:45 schrieb Mark Webb-Johnson <mark@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@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@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@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@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@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@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@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@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@lists.teslaclub.hk >>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>>>>> >>>>>> _______________________________________________ >>>>>> OvmsDev mailing list >>>>>> OvmsDev@lists.teslaclub.hk >>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>>>> >>>>> _______________________________________________ >>>>> OvmsDev mailing list >>>>> OvmsDev@lists.teslaclub.hk >>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>>> >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev@lists.teslaclub.hk >>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>> >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev@lists.teslaclub.hk >>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.teslaclub.hk >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark, Any news on the firmware testing? Patrick Am 22.02.2013 um 09:46 schrieb Mark Webb-Johnson <mark@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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (2)
-
Mark Webb-Johnson -
Patrick Kapsch