Data capture works well

I rebuilt the initial circuit I had used for the ALDL port on the car to a far more simpler design – this had solved the issue of Idle RPM showing up as several thousand. The data is spot on now!

Today, I got some information on how many questions I could ask in 1 second, this is needed so that I don’t overlap seconds of information – I read online that the OBD-II cars (ours is not one), are generally providing information in the area of 7 – 12 updates each second (this limits how many items you can query, 7 updates a second could be 7 speed updates, or 7 RPM requests, or 3 RPM, 3 Speed).

I found 100 requests takes 1618ms to complete, 1618ms divide 100 gives 16.1ms each request, and 1000 (ms = 1 second), divide by 16.1 = 62 requests each second. A lot of data.

My intention is to have function modes, e.g. we don’t want to ask for stored error codes every second, neither will I care what the air temperature is, but RPM, Injector pulses will matter.

So, if I break it up into different function modes – “error scanning mode”, “fuel monitoring”, “performance monitoring” – etc, these will mean the requests per second will likely be very few, we don’t want to be making excessive workload for the ECU either!

I couldn’t get the speed data from the ECU, I’ve seen reports a 1998 model or higher is where this is available from ECU, I could get it from the ABS ECU though.

Now, where did the relays for the ABS system go – our car doesn’t have them, and I didn’t take them out.

So, the next option to get speed information (the original idea here wasn’t ever fuel economy monitoring, merely, data logging of speed, brakes, and perhaps video). To get speed,  I can count the pulses that are output – this is available, nice and handy on pin 11 of the ALDL connector in my car.

Unfortunately, it’s now Sunday night, so I can’t test how many pulses make up one km, so that’ll have to be something I do another day – maybe tomorrow.

I’m still waiting on an LCD display for it too, taking it’s sweet time to get here, so the laptop has to come along for the ride.

The other idea to have was – I came across some RF transmitters some time ago for a Hot Water monitoring setup (still not completed, must be by winter!) – the RF transmitters can be used to send the collected data wirelessly to my server at home when we are at home (by using some sort of heartbeat method when stopped).

This would work good, but I need to get some more wireless transmitters. Unfortunately, one of the two I got found itself attached to 12V DC in the car when I first started this project – loose 12V pin caught the chip on the module.

I then considered where the LCD display for it could sit. Below the CD player would be pretty cramped, and not be easily visible for purposes of monitoring whilst moving. So, I could run the cable (I’ll have to make this too), from the ALDL port, using sticky clips to hold the cable out of the way, to just in front of the drivers speaker – this would make it easily visible, not distract, and the cable clips would ensure the cable stays out of the way.

I also need to think about what to enclose the lot in. Perspex maybe..

This entry was posted in Random. Bookmark the permalink.

2 Responses to Data capture works well

  1. criten says:

    I would of thought that data collection would be best operated under a schedule. You’re right in that you don’t need to check for errors every second… but what about checking every 10 minutes or so?

    Air temp perhaps monitored once every minute?

    Reason I suggest this is that ECU’s don’t have much memory and can often get overflowed with errors in the event of a fault.

  2. There shouldn’t be too many errors under normal conditions.

    The ECU has Active and Stored errors tho, so if need be, another mode of operation – error checking mode could allow errors to be displayed as they happen (I guess useful in service conditions when you aren’t actually moving).

    Too many possibilities.

Leave a Reply

Your email address will not be published. Required fields are marked *