-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
I have now verified all known codes using CAN bus-injection and summarized the result in the attached file as information to those who may be interested. The debug messages were largely known and contain less news, but I now got all the enduser messages and message color codes too. Since these alerts were all raised by can-bus injection on a part and were not observed in a car as they naturally occur, there is no guarantee that they all can actually be observed in a car. These results are for VDS firmware version 3.22 only. The previously published reults cover several firmware versions. If anyone wants the excel sheet of messages that was used to generate the pdf, feel free to pm me.
spaceballs
Member
Thanks so much for all your hard work! Will these error numbers be generated as error messages from the OVMS app or on the VDS screen?
These are the messages that appear on the VDS screen. I only used the OVMS as a tool to inject CAN bus messages that the VDS responds too. I could have used something else, but the OVMS is a very good tool for the task. You can think of my list as a verification and completion of the lists on this forum and on Gruber Motor Company's site that is valid for firmware version 3.22. Keep in mind that they were generated under artificial experimental conditions that may differ from the actual environment in the car in some cases. I did this in order to learn to know the car an eventually understand it better.
The error messages that are displayed in the OVMS app for the Roadster come from a file on the OVMS server. I will work with Mark to incorporate @einhalv's list. One question in my mind is whether to use the debug versions of the messages. For me personally I want the extra detail, but for some people the acronyms and text of the debug messages may be too cryptic. Perhaps a synthesis would be best.
My opinion... Always include the original manufacture's text as-is, but add to it for clarity or recommended action.
Bringing back an old issue. For the 2.x cars, in my opinion the most useful preventative alert can be #1144 and #1146, which are debug messages warning that the PEM Fan's power connections are failing. There have been reports of false positives, and for that reason (support load) the messages have been suppressed somewhere along the chain. But doing so also brings a risk, where an important warning could be ignored. If we have the ability to clarify that these messages *could* indicate a failing (and potentially very expensive to repair) connector, could we have those messages re-enabled? I really think that early detection of a failing connector is one of the best ways to prevent a fatally burned connector on the $10k PEM. OVMSv3 has the ability to improve on the car's original telematics; with care in wording, I think we should make use of that potential.
I think the debug version of the messages are usually to be preferred. First of all because many of them do not have enduser counterparts and it is frustrating receiving a push-notification without any idea about what is wrong. Second, for some ranges of IDs all enduser messages are equal while the debug messages are all different and, of course, more specific. For example, all enduser messages for IDs 2003-2099 are the same while the debug messages are different. Also I normally prefer the extra detail. However, sometimes the enduser message is much more clear, e.g. ID 951; "Power electronics too hot" in enduser versus "DMC FW: Ambient OverTemp fault" in debug mode, or ID 100: "Park Lock Problem Vehicle May be Free-Rolling" versus "CM: Hall Sensors both on". Judging which to use or attempt a synthesis therefore makes sense to me. The former approach would honour @gregd's principle of keeping manufacturer text as is, but considering that the manufacturer seems to have used different texts over time, check IDs in the range 1141-1153 at Gruber's site for example, I don't think we do much wrong with mild editing in some cases. How were the currently implemented messages in OVMS decided?
Einhalv, yes, it's really annoying when a bunch of detailed and different messages get rolled up into one more generic notification, usually something along the lines of "Problem exists, contact Service". The thing is, to an increasing degree, WE are "service" now, and need that information.
But you give some good examples where the original Manufacturer's text is from the development engineer's perspective, and only meaningful if one is looking at the car's schematics and source code. Since we have neither, a translation into "mortal human" terms can be substantially more valuable.
We really of need both...
But you give some good examples where the original Manufacturer's text is from the development engineer's perspective, and only meaningful if one is looking at the car's schematics and source code. Since we have neither, a translation into "mortal human" terms can be substantially more valuable.
We really of need both...
Yes, exactly. Apart from finding it interesting, it is the likelihood of becoming "service" myself that motivates me to dig into technical aspects of the roadster.
The current OVMS-implementation with the messages stored in a file on the server can only handle one message per ID. That is why Steve needs to make a choice. Expanding on that functionality is more job than adding text for the remaining 300+ IDs. Perhaps much more.
If we want to keep readily available both types of messages and also maintain interpretations and recommended actions, I think the best approach for now is to keep updating the post on the subject on this forum. I could update with my findings, but I don't want to type everything into the table. I would like to make a program that generates the table markup as I did for the pdf that I uploaded. Then someone else would have to modify the actual post. I don't have the rights.
The current OVMS-implementation with the messages stored in a file on the server can only handle one message per ID. That is why Steve needs to make a choice. Expanding on that functionality is more job than adding text for the remaining 300+ IDs. Perhaps much more.
If we want to keep readily available both types of messages and also maintain interpretations and recommended actions, I think the best approach for now is to keep updating the post on the subject on this forum. I could update with my findings, but I don't want to type everything into the table. I would like to make a program that generates the table markup as I did for the pdf that I uploaded. Then someone else would have to modify the actual post. I don't have the rights.
That was my thought. Also expand the module acronyms in the debug messages, e.g. DMC = Digital Motor Controller.
Two things have changed since the original VECE implementation (where the server converted the code to text): 1) we have now decoded the CAN bus messages in more detail and know exactly how a particular code is raised/cleared, and 2) we now have much more flash memory in the module than v1/v2 had. I think we can simply move all these text messages into the TR vehicle module and convert code->text there. That way we can also have a configurable debug/normal flag just like the VDS has. It would be helpful to compress these as much as possible (perhaps just code\0message\0code\0message\0\0 or something like that - not too worried about time, as there aren't that many and they aren't raised too frequently).
Rather than having to choose between normal and debug messages, I think it would be better to synthesize a message for each code that is easy to understand while providing useful details. So I'd say that allowing for a normal/debug selection isn't a strong motivation to move the error messages into the OVMS firmware. If you think it is important for the Roadster to work the same way as other vehicles, then OK, but otherwise I don't see a big problem with leaving the text on the server.
The original approach was to mimimic the VDS exactly. Same range calculation (rounding bugs and all), same messages, etc.
There is no real reason we couldn't simply send the debug/normal flag to the server, along with the code, or use a suffix on the code, so moving the messages to the car isn't really for that reason. More longer term (to be the same as the other vehicles, and to allow for moving to other server platforms such as MQTT).
I have extracted the firmware from the unit that I did the can-bus injection on and looked for differences, mostly without considering whitespace, between what I had in my list and strings found in the firmware. Based on that, I identified and corrected minor typos that I introduced for end-user messages 401, 402, 547, 975, 1105, 1093, 1152 and 3017, as well as debug messages 282, 409, 604, 909, 910, 918, 927, 928,929, 953, 954, 1075 and 1149.
More interesting is that several VDS screen-messages are truncated versions of strings found in the firmware. Comparing strings and screen, the explanation must be that the software introduces extra line shifts if text is too long to fit the screen width and that it does not render more than three lines. Hence some weird-looking messages are explained. These are the messages in question (e=end-user, d=debug):
e54, e1465, e1466
screen: "Coolant System Problem Charging restricted to"
firmware: "Coolant System Problem Charging restricted to 50%"
e965
screen: "WARNING: Shifter broken. Active gear is indicated on"
firmware: "WARNING: Shifter broken. Active gear is indicated on display."
d1010
screen: "DMC FW: Voltage on Charge Port Line2 during drive with"
firmware: "DMC FW: Voltage on Charge Port Line2 during drive with charge door open"
d1082
screen: "DMC FW: Line Voltage Lost Sync or UnderFrequency"
firmware: "DMC FW: Line Voltage Lost Sync or UnderFrequency warning"
e1093, e1131, e3004
screen: "WARNING: Gear Selection Problem Gear Selector May Not"
firmware: "WARNING: Gear Selection Problem Gear Selector May Not Work"
e1142
screen: "WARNING: Gear Indication Failure: Active Gear not"
firmware: "WARNING: Gear Indication Failure: Active Gear not Indicated"
e1169
screen: "Charge port open"
firmware: "Charge port open Remove key before charging."
e1905
screen: "Unable to enter Tow Mode Flatbed recovery"
firmware: "Unable to enter Tow Mode Flatbed recovery recommended."
In additon the following sentences are found at the location corresponding to message ID 1:
e: "Alert's end-user text not yet specified"
d: "ESS Bootp or Custom Alert"
This extra information has been added to the comments in the new version of the document.
More interesting is that several VDS screen-messages are truncated versions of strings found in the firmware. Comparing strings and screen, the explanation must be that the software introduces extra line shifts if text is too long to fit the screen width and that it does not render more than three lines. Hence some weird-looking messages are explained. These are the messages in question (e=end-user, d=debug):
e54, e1465, e1466
screen: "Coolant System Problem Charging restricted to"
firmware: "Coolant System Problem Charging restricted to 50%"
e965
screen: "WARNING: Shifter broken. Active gear is indicated on"
firmware: "WARNING: Shifter broken. Active gear is indicated on display."
d1010
screen: "DMC FW: Voltage on Charge Port Line2 during drive with"
firmware: "DMC FW: Voltage on Charge Port Line2 during drive with charge door open"
d1082
screen: "DMC FW: Line Voltage Lost Sync or UnderFrequency"
firmware: "DMC FW: Line Voltage Lost Sync or UnderFrequency warning"
e1093, e1131, e3004
screen: "WARNING: Gear Selection Problem Gear Selector May Not"
firmware: "WARNING: Gear Selection Problem Gear Selector May Not Work"
e1142
screen: "WARNING: Gear Indication Failure: Active Gear not"
firmware: "WARNING: Gear Indication Failure: Active Gear not Indicated"
e1169
screen: "Charge port open"
firmware: "Charge port open Remove key before charging."
e1905
screen: "Unable to enter Tow Mode Flatbed recovery"
firmware: "Unable to enter Tow Mode Flatbed recovery recommended."
In additon the following sentences are found at the location corresponding to message ID 1:
e: "Alert's end-user text not yet specified"
d: "ESS Bootp or Custom Alert"
This extra information has been added to the comments in the new version of the document.
Similar threads
