OBD MPGuino gauge

[Magister]

thanks I'll take a look, with the "#define debug" enabled I didn't see a prob, I'll double check.

[m3ph]

I edited my last post a little about the refresh rate i talked about earlier, don't know if you saw that...

[m3ph]

Weird... I reflashed the software again (missed the line that shows the version during startup) and the l/100 character was fine again...

One of those things I guess...

[m3ph]

Sorry about spamming the topic.

I'm still having problems with the reinit. The device doesn't start the reinit process when restarting the car, for some reason. Is there a good way to debug this?

I'm going to try my obduino on someone else's car just to be sure that the problem is my car, not my bad soldering skills...

[Magister]

I do not have an ISO car so I don't know why the re-init does not work

About the refresh rate, when your screen displays fuel consumption, cost, etc, it does not ask for any particular PID, only the internal accu_trip() asks for rpm/speed/throttle/maf/fuel_status and what you display does not involve asking for PID, so the system asks 5 PIDs per "cycle".
When you want to display information like speed, rpm, or any others PIDs, the system has to ask for it, and on a ISO system it's slow... so if you display 4"real" PIDs instead of 4 "fake" PIDs (like fuel consumption, distance, etc), the system has to ask the 5 regular PIDs + your 4, so 9 PIDs in a cycle, hence the slowness...

One work around would be to "cache" the values read by accu_trip() like rpm or speed so when you want to display them, the system would not re-ask the ECU the value but use the one in cache. But if you display others PIDs you will have the same slow refresh rate.

[eimix]

yes, ISO is slow But acceptable

6bytes request (3header, 2payload, 1crc) = 4.6ms (10400speed limit)

10ms delay after each byte in Obduino32K code (function iso_write_byte). 6x10 = 60ms

ECU responds after 25ms

response is 7-10 bytes (avg 8bytes) = 6.2ms

Mandatory delay before next request 55ms

so we have 151ms in total, or 6.6pids/sec physical limit.
+ Obduino32K code is also working + LCD commands are also not so fast.

edit:
Tested PID_SEC pid in my car - and i get 7, so calculations looks good

edit:
according to
http://www.koch-engineering.com/file...ISO14230-2.pdf page 7
there should be at least 5ms delay before each byte. it would be no big increase, but still - increase 6.6p/s -> 8.2p/s

[Magister]

What could be done to make the display faster, is to disable the DCFO detection. Anyway if you never see 0.00L/100 or 999MPG when you coast and your car does not support DFCO, each cycle you could save the 2 PIDs for fuel status and throttle position. With this you could have almost 2 refresh per second instead of 1.

[m3ph]

Originally Posted by Magister

What could be done to make the display faster, is to disable the DCFO detection. Anyway if you never see 0.00L/100 or 999MPG when you coast and your car does not support DFCO, each cycle you could save the 2 PIDs for fuel status and throttle position. With this you could have almost 2 refresh per second instead of 1.

Caching the pids seems like a good idea. The refresh rate, when not showing actual pids is almost okay atm... around half a second. The other interesting pids I'd like to watch sometimes, are the same that are used in fuel calculations anyways. Throttle position, rpm and speed.
As my car supports DFCO, I'd like to keep that. Altho a setting in the config to disable it would probably be nice.

Regarding DFCO... My car does support it, but when the rpm drops so low that the car starts injecting fuel again to keep the engine running, the display still shows 0,00L/100. A bug in the software or an anomaly with my car?

[eimix]

I tested my proposed way - and i got an increased refresh rate (25%), and everything works fine (for VW jetta at least).

In define section add (after //#define ISO_14230_slow)

// Define delay between ISO request bytes (min 5ms, max 20ms) slower is faster refresh rate. By default 10ms.
// 5ms gives 8.2pids/s, 10ms gives 6.6pids/s
// On VW MK4 5ms works fine
#define ISORequestByteDelay 5

Replace delay(10); with delay(ISORequestByteDelay);

void iso_write_byte(byte b)
{
  serial_rx_off();
  Serial.print(b);
  delay(ISORequestByteDelay);  // ISO requires 5-20 ms delay between bytes.
  serial_rx_on();
}

If lowest allowed value does not work - you should increase it

[Magister]

Originally Posted by m3ph

Regarding DFCO... My car does support it, but when the rpm drops so low that the car starts injecting fuel again to keep the engine running, the display still shows 0,00L/100. A bug in the software or an anomaly with my car?

It does the same thing with my 07 Elantra, when I coast to a stop, it displays 0.00L/100 but I can feel at a certain time that fuel restarted to flow but it takes a few seconds for the ECU to change the fuel status.
It's not a software bug nor an anomaly with the car, it works like this... It could be detected I think by checking the O2 sensor voltage but it would make one more PID to check every cycle.