VehicleDatabases

Vehicle Databases

About the vehicle databases

Vehicle database information comes from many sources, often vehicle owners who piece together what is needed to get the values they want from the car they own using whatever OBD-II tool they have. So there may be pieces of the puzzle taking the form of C source code (as in the contribution from the ECROS Technology MiniScanner firmware), spreadsheets or tables of XGauge commands for the ScanGauge, Python source from people using pyOBD, etc.

To assemble coherent databases from such a variety of sources, we need a [VehicleDatabaseFormat] that various source formats can be easily converted into, and that makes it easy to merge and compare entries from several sources. Once a merged vehicle database is created, further work on checking, correcting, and adding to the database will ideally be done in just one place, by contributors who were formerly working in several different formats. That has to be worth their while, which means:

• the format should be easy to read and work with, and
• it should be able to preserve all information that was in contributed sources, so that
• the original contributed formats can be exported from the database at any time.

That way, contributors do not give up having the data in the format they originally wanted, while the repository here becomes the preferred single place to correct and add to the database. The most up-to-date version of a database here can be used with a ScanGauge, for example, just by running the exporter that generates XGauge codes from the database.

Tiny vs. full-featured platforms

Vehicle data can be used by tiny devices (such as the ScanGauge) or by apps running on less limited platforms like laptops or smartphones. Using the database with a tiny platform will generally mean using an exporter to transform the database into whatever specialized form (e.g. hexadecimal XGauge codes) the platform needs. Tiny platforms with tiny displays or limited math may need carefully hand-chosen abbreviated labels and math conversions for the values to be displayed. Those platform-specific details can all be kept in the central database here and automatically used when exporting the specialized form for that platform.

New apps for less-limited platforms with XML support can simply slurp in the database directly, and use the generic labels and [UnitsOfMeasurement] information in it to produce reasonable displays without hand-tuning of math conversions and labels.

More information in [VehicleDatabaseFormat].

Available vehicle databases

• Toyota
  • NHW11 (2001-2003 Prius)

Available exporters

• XGauge for the Linear-Logic ScanGaugeII
  • generate vBulletin-style tables of XGauge codes from a vehicle database (format used by vincent1449p on PriusChat). So far only tested with the Toyota NHW11 database, which uses ISO14230 protocol, probably won't work right with anything else yet.
• Torque for the popular closed-source Torque app
  • generate CSV files that the Torque app can use to define extended PIDs. Very preliminary - I don't have Torque installed to test with. Please see the commit comments for things known incomplete or in question, and report how well it does or doesn't work.