When I bought my current car, it came with an owners manual--for free!!
I can grab any data I want from the OBD port. The hardware was cheap, the software to use it is, again, free.
I'm not excited about this brave new world where you have to pay a subscription fee to plug a cable into a device you own and interact with it, and even less excited there are people here defending the idea.
You may not be aware but there are a lot of proprietary PIDs on your OBD2 bus you can't interpret without specialized software - you can get like oil pressure and temperature, but not say, shift points or anything the manufacturer doesn't think you should see. True right to repair would mean all of the PIDs get documented and there is a marketplace where I can purchase software or documentation without having to be a certified brand X mechanic.
I’m not sticking up for car manufacturers, but at what size or capacity should you be required to document and publish these things? It requires employer time and effort and has a cost associated with it.
As a counter argument: I was just looking at a small open source utility. As I was going through the code I found cases where certain arguments could be set to magic values that cause useful, but undocumented behavior. Should the developers be forced to document these options?
I don’t think a manufacturer should be able to lock you out of reading diagnostics on your own devices, or that anyone should be prevented from reverse engineering what those values mean. But I also don’t think there should be any requirement that they are forced to do additional work. That seems just as immoral.
I was just looking at a small open source utility. As I was going through the code I found cases where certain arguments could be set to magic values that cause useful, but undocumented behavior. Should the developers be forced to document these options?
You were able to do that because it was open source. If a car mfr was willing to do that, it would be plenty enough for me. They shouldn't be forced to do any additional work beyond the 5 seconds it takes to type `git remote add origin github.com/honda/civic`. Then the community would have everything it needs to carry things forward.
Failing that, yes, I do think everything should be documented.
Certain PID values are bit-packed in non-obvious ways (like the tens digit is in one byte, ones in another, decimal in another) and units of measure are 'known' but might not be obvious. Publishing that information (which already exists! How do you think they write software?) would be a nice step in the right direction
There are a ton of dbc files floating around like this. Almost any car with a turbo has a kit to flash the ecu for more boost, so even the proprietary signals have been reversed.
Between reading basic diagnostics and documenting every signal and field is routine or recurring write operations that will need to happen in the field.
Resetting the oil/maintenance light, recoding key fobs, resetting the battery stats upon replacement, etc.
I want independent mechanics to be able to do that. I also want to be able to do that myself, if I’m so inclined.
Let’s invert the car analogy: if someone writes an app with a backend service or library, should they be required to document the API for people to build their own tools on top of? Where between software and car does this requirement or regulation change and why?
I’m absolutely in favor of being able to repair my own stuff and voiding any warranty or liability in the process. I absolutely support reverse engineering and preventing companies from issuing copyright strikes on uncopyrightable facts about their products. I’m mostly OK with the idea that unqualified people can make potentially life threatening changes to their 2-ton vehicle barreling down the road at 80mph.
Would I like documentation for all these things? Absolutely! Should it be enforced by law? I don’t think so.
if someone writes an app with a backend service or library, should they be required to document the API for people to build their own tools on top of?
Yes. Network services and client software should be considered two separate products/markets, and tying between them should be seen as anti-competitive behavior worthy of anti-trust enforcement.
That the software industry has been able to develop some brazenly anti-competitive pratices does not constitute an argument that it should be allowed to continue.
I don’t think a manufacturer should be able to lock you out of reading diagnostics on your own devices, or that anyone should be prevented from reverse engineering what those values mean.
But they do do that. Also what’s the difference between a lot of obfuscation and prevention and how will you enforce that without lawsuits and discovery?
Also, what is those values have the ability to do damage and cause safety issues? Like losing your own software onto a control by wire car? Then you can rent a car and install your own software surreptitiously.
the issue is not that this information is undocumented, it's that an "authorized service center" gets information that an "owner" does not. Also cars are not "small open source utilities" with undocumented arguments; do you think that an auto manufacturer has hidden, untested diagnostics that only the dealer uses?
> don’t think there should be any requirement that they are forced to do additional work
At one time seatbelts, airbags, emission controls, etc were all viewed in this category. Now we have regulations enforcing aspects of all of these. Why would diagnostics be different?
That’s why I said, at what level should this disclosure be required? Obviously a small open source utility shouldn’t have to document everything. What about a $20 electric screwdriver with an unpopulated JTAG header? a $200 door buster TV? A $2,0000 OLED TV? A Kickstarter device that unexpectedly takes off? A small ICE engine? A house?
If you’re starting up a small business, selling at-a-loss widgets to gain market share do you want to be forced to publish a diagnostic manual that not only increases your work, but may also increase your liability?
Seatbelts and airbags are safety, but if you talk to anyone at a body shop, they will tell you there are significant regulation changes in the past decade that have made cars more expensive to fix while not necessarily safer.
I just don’t think it’s as cut and dry as everything must be forced to be documented. What is everything, at what size or industry is this documentation required, why this industry and not that one, is it just OBD or _everything_ including all CAN bus communication, etc. Minimally the end result is increased cost for everyone.
If it’s already published, perhaps libraries should start collecting the service manuals.
How about; if it's already documented, make it available to the end user.
The right to repair cases that bother me most is where the company goes out of their way to prevent end-user repair (cryptographic pairing of modules!?), or where service manuals/information exist but are only available to dealers.
I’m not sticking up for car manufacturers, but at what size or capacity should you be required to document and publish these things? It requires employer time and effort and has a cost associated with it.
You're talking about things that by definition have to be documented and internally published in order to design and build the powertrain in the first place. You can't design a computer-controlled automatic transmission without documenting the shift points.
The cost is therefore essentially nothing, because the information already exists. Just copy paste it into a PDF and put it on your website.
at what size or capacity should you be required to document and publish these things?
The reason there is an opaque number in that open source utility is precisely because of a lack of open documentation for that register definition. Independent black box analysis of the messages only got as far as "write this value to do effect X". Whomever developed that utility would have loved to spell that bitfield out, but not at the cost of more days reverse engineering.
But manufacturers aren't reverse engineering register definitions, they're working off of vendor datasheets or protocol definitions they themselves created. All of this documentation has already been produced, as it was used to develop the tractor from its various subsystems. It just needs to be published!
I’ve worked on enough internal and third-party SOA to know that documentation could be in an email, a slack chat, or a hallway conversation. The public docs go through writers and reviews. How many software teams could make their service or library docs public based only on internal documentation and produce anything useful?
Documentation for hardware subassemblies produced by different manufacturers isn't getting conveyed through hallway conversations. Pure software can indeed be quite sloppy, but for vehicles we're talking about large scale cross-stakeholder projects where these things do get formally documented.
At any rate, for things a manufacturer doesn't consider important enough to document themselves then there can be a clear alternative requirement - release whatever upstream documentation they did use to create it, plus the software source code they developed on top of it. If it's not important enough to have been documented as its own product, then it also isn't a significant part of the value they're actually selling, right?
Yes and I'm just pushing back against GP who seems to think gatekeeping that access is a good thing. And it's still way better than John Deere who (according to TFA), when the tractor detects that some wires are disconnected, wants you to pay $195 to find out which ones.
I'd love to move towards a world where owners can access everything, flash the firmware in the headlamps, etc. But all I can do as an individual is vote with my wallet and avoid the 2020s computers-on-wheels.
What you want is the service manual. Owner manual should be implicit.
OBD port can work for some cars, for some of the data. But other cars do have specialized gear they require to either access either reset some stuff in some of the car's computers.
Yeah the owners and service manuals are two very very different things. You won't be performing much maintenance with the owners manual besides the absolute basics, like checking your oil.
The cheap OBD2 readers lack the vast majority of data and tools you would want to use for service as well.
There are aftermarket options but most manufacturers want you to subscribe to their service tools - often charged per monthly plus an additional a fee per VIN it touches. These cost in the hundreds to thousands. It can be pretty frustrating as a shadetree mechanic.
Notably, some vehicles like the Toyota Highlander you can’t even figure out when you need to change the spark plugs, let alone what kind of spark plugs you need from the owners manual.
Theoretically, they are to be replaced at 120k miles (!!) but they won’t even tell you that in the owners manual.
It is, yeah. The owners manual for my current vehicle seems to mostly contain walkthroughs about the infotainment and other tech features. The section related to maintenance is tiny in comparison.
You're probably aware of this already but luckily a lot of service manuals can be found online in PDF form.
Somewhat related but I was going through an older relatives belongings not too long ago to help cleanup and found a bunch of old manuals for various household things. The detail included in them was beautiful to see - full wiring diagrams, mechanical diagrams, etc.
The change interval is in the Warranty and Maintenance Guide, not in the main owner’s manual. (This is still part of the in-glovebox manuals, not a service-center manual.)
Reading codes is only part of it. For the last quarter century or so (some manufacturers more than others) if you replace certain components (radio, any computer module) you need to update the ECU to recognize the new component. This requires proprietary software and in many cases proprietary hardware as well. These "features" are marketed as an "anti-theft" mechanism. This renders some repairs basically impossible for the end user to perform.
The fact that they've been allowed to build systems like that is appalling.
Comments
When I bought my current car, it came with an owners manual--for free!!
I can grab any data I want from the OBD port. The hardware was cheap, the software to use it is, again, free.
I'm not excited about this brave new world where you have to pay a subscription fee to plug a cable into a device you own and interact with it, and even less excited there are people here defending the idea.
You may not be aware but there are a lot of proprietary PIDs on your OBD2 bus you can't interpret without specialized software - you can get like oil pressure and temperature, but not say, shift points or anything the manufacturer doesn't think you should see. True right to repair would mean all of the PIDs get documented and there is a marketplace where I can purchase software or documentation without having to be a certified brand X mechanic.
I’m not sticking up for car manufacturers, but at what size or capacity should you be required to document and publish these things? It requires employer time and effort and has a cost associated with it.
As a counter argument: I was just looking at a small open source utility. As I was going through the code I found cases where certain arguments could be set to magic values that cause useful, but undocumented behavior. Should the developers be forced to document these options?
I don’t think a manufacturer should be able to lock you out of reading diagnostics on your own devices, or that anyone should be prevented from reverse engineering what those values mean. But I also don’t think there should be any requirement that they are forced to do additional work. That seems just as immoral.
You were able to do that because it was open source. If a car mfr was willing to do that, it would be plenty enough for me. They shouldn't be forced to do any additional work beyond the 5 seconds it takes to type `git remote add origin github.com/honda/civic`. Then the community would have everything it needs to carry things forward.
Failing that, yes, I do think everything should be documented.
I can poke at OBD and try to interpret values. CAN bus sniffers exist.
You want to force companies to publish and maintain repositories using your preferred toolset?
Certain PID values are bit-packed in non-obvious ways (like the tens digit is in one byte, ones in another, decimal in another) and units of measure are 'known' but might not be obvious. Publishing that information (which already exists! How do you think they write software?) would be a nice step in the right direction
J1939 is really all most consumers need to care about when it comes to their personal car CAN data.
https://github.com/Konik-ai/j1939_dbc/blob/main/dbc/j1939.db...
There are a ton of dbc files floating around like this. Almost any car with a turbo has a kit to flash the ecu for more boost, so even the proprietary signals have been reversed.
Ghidra exists. That doesn't mean all software is open source.
Nope. Anywhere will do, whatever is easiest for them, as long as device owners can access it.
Between reading basic diagnostics and documenting every signal and field is routine or recurring write operations that will need to happen in the field.
Resetting the oil/maintenance light, recoding key fobs, resetting the battery stats upon replacement, etc.
I want independent mechanics to be able to do that. I also want to be able to do that myself, if I’m so inclined.
Let’s invert the car analogy: if someone writes an app with a backend service or library, should they be required to document the API for people to build their own tools on top of? Where between software and car does this requirement or regulation change and why?
I’m absolutely in favor of being able to repair my own stuff and voiding any warranty or liability in the process. I absolutely support reverse engineering and preventing companies from issuing copyright strikes on uncopyrightable facts about their products. I’m mostly OK with the idea that unqualified people can make potentially life threatening changes to their 2-ton vehicle barreling down the road at 80mph.
Would I like documentation for all these things? Absolutely! Should it be enforced by law? I don’t think so.
Yes. Network services and client software should be considered two separate products/markets, and tying between them should be seen as anti-competitive behavior worthy of anti-trust enforcement.
That the software industry has been able to develop some brazenly anti-competitive pratices does not constitute an argument that it should be allowed to continue.
But they do do that. Also what’s the difference between a lot of obfuscation and prevention and how will you enforce that without lawsuits and discovery?
Also, what is those values have the ability to do damage and cause safety issues? Like losing your own software onto a control by wire car? Then you can rent a car and install your own software surreptitiously.
the issue is not that this information is undocumented, it's that an "authorized service center" gets information that an "owner" does not. Also cars are not "small open source utilities" with undocumented arguments; do you think that an auto manufacturer has hidden, untested diagnostics that only the dealer uses?
At one time seatbelts, airbags, emission controls, etc were all viewed in this category. Now we have regulations enforcing aspects of all of these. Why would diagnostics be different?
That’s why I said, at what level should this disclosure be required? Obviously a small open source utility shouldn’t have to document everything. What about a $20 electric screwdriver with an unpopulated JTAG header? a $200 door buster TV? A $2,0000 OLED TV? A Kickstarter device that unexpectedly takes off? A small ICE engine? A house?
If you’re starting up a small business, selling at-a-loss widgets to gain market share do you want to be forced to publish a diagnostic manual that not only increases your work, but may also increase your liability?
Seatbelts and airbags are safety, but if you talk to anyone at a body shop, they will tell you there are significant regulation changes in the past decade that have made cars more expensive to fix while not necessarily safer.
I just don’t think it’s as cut and dry as everything must be forced to be documented. What is everything, at what size or industry is this documentation required, why this industry and not that one, is it just OBD or _everything_ including all CAN bus communication, etc. Minimally the end result is increased cost for everyone.
If it’s already published, perhaps libraries should start collecting the service manuals.
How about; if it's already documented, make it available to the end user.
The right to repair cases that bother me most is where the company goes out of their way to prevent end-user repair (cryptographic pairing of modules!?), or where service manuals/information exist but are only available to dealers.
You're talking about things that by definition have to be documented and internally published in order to design and build the powertrain in the first place. You can't design a computer-controlled automatic transmission without documenting the shift points.
The cost is therefore essentially nothing, because the information already exists. Just copy paste it into a PDF and put it on your website.
The reason there is an opaque number in that open source utility is precisely because of a lack of open documentation for that register definition. Independent black box analysis of the messages only got as far as "write this value to do effect X". Whomever developed that utility would have loved to spell that bitfield out, but not at the cost of more days reverse engineering.
But manufacturers aren't reverse engineering register definitions, they're working off of vendor datasheets or protocol definitions they themselves created. All of this documentation has already been produced, as it was used to develop the tractor from its various subsystems. It just needs to be published!
I’ve worked on enough internal and third-party SOA to know that documentation could be in an email, a slack chat, or a hallway conversation. The public docs go through writers and reviews. How many software teams could make their service or library docs public based only on internal documentation and produce anything useful?
Documentation for hardware subassemblies produced by different manufacturers isn't getting conveyed through hallway conversations. Pure software can indeed be quite sloppy, but for vehicles we're talking about large scale cross-stakeholder projects where these things do get formally documented.
At any rate, for things a manufacturer doesn't consider important enough to document themselves then there can be a clear alternative requirement - release whatever upstream documentation they did use to create it, plus the software source code they developed on top of it. If it's not important enough to have been documented as its own product, then it also isn't a significant part of the value they're actually selling, right?
Yes and I'm just pushing back against GP who seems to think gatekeeping that access is a good thing. And it's still way better than John Deere who (according to TFA), when the tractor detects that some wires are disconnected, wants you to pay $195 to find out which ones.
I'd love to move towards a world where owners can access everything, flash the firmware in the headlamps, etc. But all I can do as an individual is vote with my wallet and avoid the 2020s computers-on-wheels.
What you want is the service manual. Owner manual should be implicit. OBD port can work for some cars, for some of the data. But other cars do have specialized gear they require to either access either reset some stuff in some of the car's computers.
Yeah the owners and service manuals are two very very different things. You won't be performing much maintenance with the owners manual besides the absolute basics, like checking your oil.
The cheap OBD2 readers lack the vast majority of data and tools you would want to use for service as well.
There are aftermarket options but most manufacturers want you to subscribe to their service tools - often charged per monthly plus an additional a fee per VIN it touches. These cost in the hundreds to thousands. It can be pretty frustrating as a shadetree mechanic.
Notably, some vehicles like the Toyota Highlander you can’t even figure out when you need to change the spark plugs, let alone what kind of spark plugs you need from the owners manual.
Theoretically, they are to be replaced at 120k miles (!!) but they won’t even tell you that in the owners manual.
Insane.
It is, yeah. The owners manual for my current vehicle seems to mostly contain walkthroughs about the infotainment and other tech features. The section related to maintenance is tiny in comparison.
You're probably aware of this already but luckily a lot of service manuals can be found online in PDF form.
Somewhat related but I was going through an older relatives belongings not too long ago to help cleanup and found a bunch of old manuals for various household things. The detail included in them was beautiful to see - full wiring diagrams, mechanical diagrams, etc.
Not official ones for John Deere tractors unless they were leaked from authorized service agents!
And those get taken down when JD finds them.
The change interval is in the Warranty and Maintenance Guide, not in the main owner’s manual. (This is still part of the in-glovebox manuals, not a service-center manual.)
One example: https://assets.sia.toyota.com/publications/en/omms-s/T-MMS-1...
Sadly service manuals aren’t commonly sold anymore and you need a subscription to a website to access factory service manuals.
It’s a shame, I use to buy the service manual when I bought the car.
Reading codes is only part of it. For the last quarter century or so (some manufacturers more than others) if you replace certain components (radio, any computer module) you need to update the ECU to recognize the new component. This requires proprietary software and in many cases proprietary hardware as well. These "features" are marketed as an "anti-theft" mechanism. This renders some repairs basically impossible for the end user to perform.
The fact that they've been allowed to build systems like that is appalling.