Originally Posted by rubberchicken
Originally Posted by RayCJ
Hope I'm not hijacking this thread but... Instead of scanners, is software for a laptop/notebook available instead? I've seen many wi-fi ODB readers that work with IOS and Android. Someone out there must have taken the next step and integrated full functionality into a PC software package.
Ray
Yes, this has been around way before Wifi and Bluetooth connected systems for iOS and Android. They seemed to have dropped off in popularity because users prefer the smaller footprint of a smartphone, or the purpose built scanners. The original GM dealer systems back in the late 90's were just ruggedized PC's with the OBD2 to (whatever) interface, with a lot of local logic and ability to store and forward data back to GM. Once you have the OBD2 to PC interface, and some API on your computer, then you could use literally any computer system to create your compute / presentation layer. A lot of these gadgets are cheap industrial controllers where the SDK (software development kit) runs on Linux, Mac or PC. I have not done this sort of work for a long time, but Java based systems running Vxworks used to be popular.
I checked out several software based packages yesterday and as you mention, they're out there but not as popular as the purpose-built, embedded devices. Cost of base software seemed reasonable though and if I upgrade my Foxwell NT301, I go with PC-based software next time. I see that ODBII looks like an interface spec for the COM port extending upward a little to reserve register IDs for common engine controls. After that, the software turns into the typical rats nest trying to keep-up with with proprietary register codes etc.
So, just curious... does each car manufacturer have their preferred diagnostic device and software? It would be really nice if one could obtain the "software module" from the manufacturer for a given line or model of vehicle. I have little to no faith in what people now call "Apps". Side note: In the old days, code was written, compiled, debugged/tested then released. Now, code doesn't need to be compiled and it seems most folks did-away with the debugging/testing part.
Originally Posted by RayCJ
Hope I'm not hijacking this thread but... Instead of scanners, is software for a laptop/notebook available instead? I've seen many wi-fi ODB readers that work with IOS and Android. Someone out there must have taken the next step and integrated full functionality into a PC software package.
Ray
Yes, this has been around way before Wifi and Bluetooth connected systems for iOS and Android. They seemed to have dropped off in popularity because users prefer the smaller footprint of a smartphone, or the purpose built scanners. The original GM dealer systems back in the late 90's were just ruggedized PC's with the OBD2 to (whatever) interface, with a lot of local logic and ability to store and forward data back to GM. Once you have the OBD2 to PC interface, and some API on your computer, then you could use literally any computer system to create your compute / presentation layer. A lot of these gadgets are cheap industrial controllers where the SDK (software development kit) runs on Linux, Mac or PC. I have not done this sort of work for a long time, but Java based systems running Vxworks used to be popular.
I checked out several software based packages yesterday and as you mention, they're out there but not as popular as the purpose-built, embedded devices. Cost of base software seemed reasonable though and if I upgrade my Foxwell NT301, I go with PC-based software next time. I see that ODBII looks like an interface spec for the COM port extending upward a little to reserve register IDs for common engine controls. After that, the software turns into the typical rats nest trying to keep-up with with proprietary register codes etc.
So, just curious... does each car manufacturer have their preferred diagnostic device and software? It would be really nice if one could obtain the "software module" from the manufacturer for a given line or model of vehicle. I have little to no faith in what people now call "Apps". Side note: In the old days, code was written, compiled, debugged/tested then released. Now, code doesn't need to be compiled and it seems most folks did-away with the debugging/testing part.