Odomoter trip data for tax records

Projects / Brainstorming
#1

Hi one and all,

My company has asked me to investigate a way to track business trips for tax purposes on our vehicle fleet rather than filling in log books and my research has led me here to AutoPi.

I would like to record trip data (non gps as there is currently a privacy issue with staff) so needs to be odometer based distance, not GPS distance. Is this possible with the AutoPi?

Regards,

Stephen

#2

Hi Stephen,

Welcome to the forum.

The AutoPi is limited to the information available the specific vehicle you are using. On some make/models, odometer information is available from the CAN bus of the vehichle. On others its not. So it depends on your fleet of vehicles.

If you need further clarification, you can always reach out to sales@autopi.io.

best
Peter

#3

Thanks Peter,

Have emailed sales. Probably my first step is to put OBD diagnostic tool on vehicles and see if odometer reading is available.

Most of these are late model vehicles but a mix of manufactures and models.

From the looks of the standard the odometer PID should be there under Service 01 so would be surprised if its not there, but I guess its all down to the manufacturer

1 Like
#4

What I have seen done in the past, which may or may not be compliant for “tax purposes” is that there could be an API call which records the current odometer setting at that single point in time.

Then, at the end of each trip, you could simply increment that value by the distance of the trip. I suspect the distance of the trip would be based on GPS data.

Essentially a virtual odometer by leveraging the GPS.

#5

One option might be to develop something utilising the OBD2 Mode 01 PID 31 “Distance traveled since codes cleared”.
This PID provides vehicle distance travelled since the OBD2 trouble codes were last cleared (you can clear them even if no codes are present).
If you clear the codes and note the odometer at that time as say, 50,000kms, you can then calculate the odometer in future as 50,000 + Distance since codes cleared.

You would need to account for the codes being cleared again in future, as this would skew the results. And also notice the PID delivers a value between 0 and 65,535kms - so you would need to clear the codes at least once every 65k kms.

#6

Hello everyone!
I got the 3rd gen unit - mainly because is cool and hoping to get the odometer readings for the same purposes - as Stephen mentioned. Here (RO) on the cars registered to companies you have to fill a document for each trip with the following content / format on every line:
START PLACE of trip (address) | END PLACE | Odometer reading | Purpose of trip.
Maybe the fiscal law changed in the last years, but as we have very few cars in company - we write the document by hand (boring…). The obvious solution is to automate this and the AutoPi seems to be the right choice for smaller companies.
Of course there are solutions on the market for a few euros per month to get this document done in electronic format - you get a device similar to AutoPi.Io (but not with Raspberry PI), but the problem with those solutions is that they are not opened. The companies offers also various services - fleet monitoring, geofencing, routes optimizations…
What I managed to get in a short time with a Volvo V40 D2 MY 2013:

  • easy setup, plug and play, the device works ok; it gets sometimes the audio message “Auto PI system network 4G offline” - but I guess it happens when the 4G coverage is not so good.
    The basic values (speed, rpm, temp…) - are correctly reported.
  • the request made by terminal to get the odometer value by requesting specified PID A6 / 166 (I got the info from Wikipedia page) does not get any answer, even with adding the force=True parameter.
    No surprise - as I understand that the auto manufacturers are not mandated to use a standard format for all ODBII PIDs, but only for the ones regarding emissions and basic car info - speed, air intake, RMP, etc. In return I can get by terminal readings for speed, RPM, etc. - as a confirmation that the terminal requests works Ok.
    I tried then - just to play around (!) some “reverse engineering”:
    I sniffed the CAN bus for 8, 5, 3, 2 and even 1 sec. at several indications of the odometer counter: 154690, 154697, … (one second means 1600-1800 PID’s ! That is a lot of data !)
    I converted the decimal value of the odometer to hex: 154690 -> 25C42, 154697 -> 25C49…
    When searching the output of the sniff file, surprise!
    The value 25C42 - appears in some PID’s with the ID 390: 360#01A45593CF025C42
    I repeated the tests, for 154747 km I get 360#01A47E9328025C7B (as an example today).
    154747 dec = 25C7B hex. Cool!
    I still have to figure out what triggers this PID, because when tested with the defaults loggers off (speed, rpm, battery voltage, air temp. etc) the 360# PID does not appear in the logs.
    And also what would represent the other data in the PID’s: 01A45593CF0, 01A47E93280 …
    The 360# PID appears more or less than 10 times per second in the CAN sniff recordings.
    Anyway this is my short experience with getting the odometer reading, maybe hopefully this method can be applied to other vehicles and I hope that will prove to be a stable method in order to get the odometer value and use it for various projects.
    Please excuse the eventual (technical) mistakes, I’m still very new to auto CAN bus and ODB II PID’s.
    Good luck to everyone!
    Regards,
    Radu T.
1 Like