Hacker News Reader

Comment by emeraldd | Hacker News Reader

The problem is going to be getting enough information out of the machine to actually diagnose what the underlying problem is. With the belt story, there was nothing wrong with the belt but the computer thought there was. He could have thrown a new belt on it (i.e. throwing money at the problem and try again) but that wouldn't have fixed the problem. Heck, that might have been the first thing he tried. Diagnosing an issue by replacing part after part along the problem chain takes time and gets expensive fast making it impractical for anything really serious.

View on HN

But it's not like the farmer is trying to retune the internal tables of his engine controller or override some kind of operation mode. He just wants to get the fault code out of the system.

It seems like there's plenty of room for a middle ground here. Deere certainly could have opened up some kind of way for owners to get fault codes out of the system, at least for things that are user-replaceable. Hell, the UI should at least put up that message ("CHECK ENGINE OIL", "BELT BROKEN", etc). But then the owner might not buy the replacement part from Deere, right? Perhaps that's the real motivation here.

But the replacement part and send out the field service technician. Deere wants to own the service contract.

As another example, I had a check engine light on my car. It was ~$500 to check the code fault and replace a sensor. If I had my own access to those codes, I could have done the work myself for a fraction of the cost, but the car manufacturer knows that I'm limited in my options. If I want to renew my car tabs, I'll have to pay them and their service technician to do the work. It's a racket.

> As another example, I had a check engine light on my car. It was ~$500 to check the code fault and replace a sensor.

You can get OBD2 readers for not very much money (<$20), which would have let you read the code.

That's the reason for the openness of the basic ODB-II protocol. You can buy a sub-$100 code reader that can read all the basic powertrain codes and can reset the MIL.

That and 2 minutes of Googling will point you in the right direction generally.

My cars haven't seen the inside of a dealer's service bay in over 10 years, other than for warranty or recall work.

But OBD-II only has to (by law) provide certain information to the reader, mostly to do with emissions control.

If you own a BMW, for example, the detailed diagnostic information for the rest of the car is sitting on their MODBUS, which is only readable with a very expensive tool and software sold only to BMW dealers.

I think you mean CANBus. You can purchase very inexpensive CAN transceivers, but you're on your own figuring out the messages. MODBUS is an industrial automation relic (but like all things in ind. automation, still very popular), and not limited to a particular physical layer.

Actually I meant MODIC and not MODBUS. MODIC is a variant of Siemens' D-BUS protocol (not to be confused with the Linux IPC system)

Yes, but those systems are not involved in the grandparent post's problem of a MIL ("check engine light") preventing the car from passing inspection.

Whether or not you can service the rest of the car in a DIY or third-party fashion is a commercial concern, not a regulatory concern. I think BMW makes fine cars, but their anti-DIY stance is why I won't own one. (Porsche, Mercedes, and the VW group are more DIY friendly, though still not totally.)

A customer with a fancy new $2M machine couldn't easily diagnose problems in the field because the LCD on the machine would only show fault numbers or classes of faults. So they paid me to make an additional display which tied into the machine and showed detailed plain-English status and error messages. Very tedious work, and only slightly difficult to ensure false messages are not posted. I always wonder if the original programmers get lazy at implementing such details ("the user can always read the manual") or they run out of time due to shipping deadlines. Would a company like JD really keep things cryptic on purpose?

Having worked with a company similar to Deere in the construction/Ag sector they pretty much run like any other automotive company. Very long schedules to engineer and deploy electronics, sometimes on the order of 4-5 years for a next generation system. If something like this was left out, it was left out by specification (or lack thereof) and not a last-minute-rush omission.

>or they run out of time due to shipping deadlines.

It's this, or else it was never in the scope of work to begin with.

>Would a company like JD really keep things cryptic on purpose?

Yes. It serves their interests well.

My 1990 (if I recall the year correctly) Honda CRX had a little LED readout with the fault code. "Prosumer" and bonafide professionals should be insisting on this sort of capability -- we should "own" the operating data in our stuff, even if we don't have the software license. We should insist that access be available, for no extra cost and refuse to buy otherwise.

Reply on news.ycombinator.com