OBD MPGuino gauge

[Froggy]

I don't know what L line should do after INIT.

I read it is disabled, which would mean it could do as it liked...

There's something I could try... Just jumper the L line during init... unjumper once connection is made...

Anyway, I must use the L, and if a simple jumper is going to cause trouble, then I will need to go the route of ELM 323/7 just to get the L line. (I would prefer the 323 as I don't need the other protocols.)

There is a Freescale IC (for ISO 9141) that uses the L line, but it is no longer made...

[dcb]

Hmm, might jumper it high. If it is an output from the duino then the duino is sorta in charge of it's state, dunno for sure though. Also since it is just some bit banging code for intit another pin connected to the L line should not be too difficult (twiddle two pins in the bit banging section).

This is where I left it a few months ago:
http://ecomodder.com/forum/showthrea...html#post93434

[Froggy]

I disconnected the L line after connection was made, and the behaviour was not good. I noticed the LCD backlight was off and on, Trip data was being saved, and readings were incorrect. Reconnected the L line (which at this point was ONLY duplicating the K line data.)

As it is right now, the 33290 chip drives the K line to 12 volts. I take that, and split it to the L line. This seems to function fine.

If I created another pin to bit bang the init from the arduino, it would proceed at only 5 volts. Hmmm... actually I DO have another two 33290 chips. I could make one chip the K line, the other the L line. That might work... hmmmm

As for the turning off and on, I have not done a full test on this, but it looks like the OBDuino does not try to keep the communication active once the engine is off. Once the engine is ON again, the 9141 is not reinited, and thus, no RPM is read, thus OBDuino does not 'turn on' again... it stays in quiet mode... even if the car is running.

I tried version 131 and it did not succeed in connecting at all. The ISO changes in 138 are required for my car.

[electromike]

As a side note,, Once the obduino Has a successful init, it will never try again until it is reset. It just continuously polls for data. For the Honda, this works fine, when the car is turned back on again, the ECU responds happily, even though it is not re-initializing.

I havn't bothered to think of a way to make it detect when it is time to re-initialize, since it is unnecessary for my car. Maybe this is irrelevant for you too once you get the L line properly set up.

[Froggy]

Ok, I did some code changes and now on car restart, the OBDuino will resume communications. I simply watch the data size of RPM pid request, when I get no data back (not even a 0 RPM), I know the ECU if off. I then try to communicate (and try and try and try...) This works, but operation is less then ideal (some work is needed to make it useable in everyday use.)

According to ISO 9141 after 5 seconds of no communication, the ECU should require a new init process. Therefore, when a car is turned off and back on, we can not assume the ECU will pay attention to us at 10400 baud. If we don't get a response, we should say hello.

[dcb]

good job identifying the problem guys!

[Froggy]

I am glad it's working! (finally )

I will see if I can design and verify a working L line with a second 33290 chip. (I need more hardware first.)

I will also see if I can get a ISO 9141 re-init process going that I'm happy with.

[electromike]

Here is an idea to detect on when to go into re-init loop:

Set up a failed byte read count, reset on each successful read.
Once counter reaches say. 15 (about 5 seconds divided by about .3 seconds per read) send the device into re-init mode.

[Froggy]

I've set up a routine to ask the ECU the RPM. If I get no response back, I assume the ECU is off line. For the elm side of this routine it simply validates the response but will need to be tested on an ELM enabled device.

Once I feel the ECU is off line, I just poll for a new ECU response, or do the re-Init sequence.

[Froggy]

Using the OBDuino with a Toyota 2007 Matrix required a bit of work, but I got some further success today.

Still using the jumpered L line (Simply taking the K line feed and putting it onto the L line feed). This allows me to actually connect. (The car needs the L line.

The other problem was getting the unit to start up again when after I shut off the car and started it up again.

Using #define commands I added two modes for compilation. One mode will cause a replaces the init of ISO 9141 with an init process that can be interupted, and another mode will allow us to use ECU feedback as our 'engine on' model (instead of using RPM = 0).

When the ignition is turn from ON (or Accessory) to OFF, the OBDuino will save the trip data and go into a wait state. Here we discard the data screen and pop up a fake Car Alarm screen with a roaming * (back and forth). The asterisk moves fairly slowly as we are now waiting for an ECU connection before we go back to the data screen. On 9141 reinit mode, though the asterisk moves quicker (about 1/3 second per move as we don't actually poll for ECU connection, but are actually stepping though the long connection process in little steps, which allows us to move the asterisk faster.)

Once we get reconnected to the ECU we return to the data screen.

During the re-init process, the user can still use the buttons to configure the OBDuino. (This will cause the re-init to fail, but big deal).

Also, when the user uses the buttons when the OBDuino is off, the back light will turn on again (then off when they are done.)

I still have not done full testing on the changes yet, but I can now use it!