Hi! avesome car!!!

before my actual mazda3 with f#k1ng diesel engine I was on '95 civic vtec and she was so good (yes SHE)...

I think that you dont have rpm lag, the truth is that your engine are so fast to increse rpm when vtec is engaged and the elm is not able to follow the rpm variation

ok, stop joking....

I think that main problem for your lag is due to old non CAN protocol used on your DC2.
How many pid/second is able to read your elm adapter from your ECU?

To have something that looks like realtime and smooth IMHO is needed to have something like 30-40 pid/second in average.

The problem for you is that maybe you cannot reaches these values also using the fastest obd adapters...

Hi!

You should be alright when getting 10 PIDs/sec upwards (that's 100ms per pid, so if you're only showing RPM, and that's the only sensor being requested, then thats RPM being refreshed 10 times per second)

To get the fastest read speed possible with your protocol and adapter, make sure you have 'Faster Communications' enabled in the OBD2 settings. All adapters support this and should work flawlessly with it enabled.

Also, make sure you're not logging too much data - the more sensors you log, the more requests to get that sensor data, which means the slower overall refresh rate of individual sensors. (Basically, the more PIDs you read, the longer it takes for the adapter to go through the list of PIDs and refresh, say the RPM as it has 10 others to refresh first)

Also, if you don't care about MPG and fuelling information, tick the 'disable MPG calculation' box in the OBD2 settings as well - this will disable some polling of sensors that are automatic.

Hi, thanks for the replies.

At first I thought the VTEC was just too much for the phone to handle..... just kidding lol

I never knew what the PID readout meant until now. On my ITR its reading at 5PID AVG, 5.3 max

I have a 2006 Corolla Canadian spec and its was averaging 3.3PID.

The protocol on the corolla says ISO9141-2 5 BAUD

0 on the error count

The adaptor is a V 1.5, 38400 baud, ELM 327 China, the one that has the Blue, orange and white sticker on it. Bluetooth mini version.

Phone is Galaxy S3 32GB

Is it the ECU's? the Adaptor? Bluetooth driver?

Thanks

Hi

It's the ECU protocol in this instance (not the ECU itself, but the way in which it talks to the diagnostic device(the bluetooth adapter))

ISO9141 is one of the slowest protocols - so this will be why. You will definitely want to make sure 'Faster Communication' is enabled in Torque's OBD2 adapter settings

Unfortunately other than the settings mentioned, there's not much that can be done to increase the speed of updates from the ECU

Quote from vDimitris on November 27, 2014
It seems that a value used for drawing of gauges’ needles is the avarage of incoming data. Just check youtube for videos where people test rpm. You may note that when you rev the engine & rpm rapidly increases the digital rpm indication can be much greater then the one at the gauge. It means that actual data has less lag. But drawing is based on avarage of few previous measurements. It makes the needle movement smooth but lagged.

I’ll test this on my Infiniti Fx later. I just ordered OBDLink MX WIFI. And I have CarPC based on x64 architecure with FTDI OBDII/CAN cable. This shows no lag at all. So I will test how can WIFI connection and a good adapter perform on Android/iOS/Win64. But for shure there is an avarage calculation in Torque for drawing.

Please check out this video
http://youtu.be/fJXr44YFD0A
FF to about 1:08 when driver rev the engine. Put to pause. Then frame by frame check that in some case when engine spins up digital rev shows about 3800 rpm while gauge needle is still at around 2400 rpm.

Screenshots of that video
Rpm is 3808. Gauge at 2400.
Throttle is released already. Compare value in digits & gauge.
Same for others

I’d like to ask Ian to make this avarege adjustable by user. So that user can set no avarage and drawing will be done as per current value.