Hard to say why the track recorder gets it right.

As far as the lag, I suffer from the same issue with my '96 Nissan 300 ZXTT. Ian looked at it at some point and reached a conclusion that the ECU is at fault. At the same time, regular mechanic tools work with the ECU without problems and see faults that Torque doesn't.

.a

Does the video show no lag? I have nothing to compare it to except at the stop sign where it shows a small amount of lag.

What does the "Adapter Status" PID speed show when you are having lag problems .... you may need to get someone to help read this while you drive.

Lag exists everywhere in the overall project ... the ECU will ensure highest priority to the vehicle system before considering providing data for diagnostics.

Limit the number of PID requests ... limit the number of programs running on Android ... have a reasonably fast phone to begin with and with good bluetooth ... reposition the phone so it has direct "line of sight" with the adapter ... if you can afford it upgrade to the fastest adapter which you can genuinely return if it doesn't work ... OBDLink MX offers a 90 day, no-hassle money-back guarantee!

The actual video output is unimportant to me. I only care about the four PID's shown at the top. Sorry for the confusion.

Perhaps you guys didn't understand my post. Let me simplify it:

When viewing my PID's in the realtime status window (on which I have absolutely nothing on any of the tabs besides the one containing speed, rpm, vacuum, and MAF), there is a delay, mostly because the PID's appear to only update about once per second. It can be confirmed by logs that they are only updating about 1 time per second.

When viewing the same PID's on an exported video from Track Recorder, there is no PID delay/lag in any part of the video, and the PID's update >5 times per second as far as I can tell.

What causes this discrepancy?

If the phone or adapter were at fault, it would simply not be able to capture four PID's at once at >5 points per second AND export video containing evidence that this is happening.

I have further narrowed down the problem.

The track recorder simply reads instantly faster than the realtime information app. The second I open track recorder, the PID's (speed, MAF, RPM, vacuum) are reading probably 10 times per second whereas when I open the realtime information tab there is a considerable delay, then eventually I can see it "attempt" to communicate faster and it'll read those same four PID's maybe a hair faster than 1 time per second.

It's weird because this is clearly a software problem specific to my car. I plugged my OBD reader into another car and the realtime information app updated just as fast as the track recorder app on that car.

Hi!

Go into the 'Adapter Status' screen, scroll down until you see the 'Adapter PID read speed'

This is the speed at which the adapter is able to retrieve data from your ECU. This is very ECU and protocol dependant. This is the actual read speed of sensors from the ECU itself. It will be different for different protocols (your ECU will only use one protocol). The fastest protocol is CANBUS, which really can retrieve PIDs at a fast rate (about 22-26PIDs/sec on a clone up to 50-65PIDs/sec on an OBDLink MX)

Make sure you have 'Faster Communication' enabled in the settings, and that the 'Error Count is 0 (if it's not 0 then you have a faulty adapter and this can be the cause of all kinds of strange behaviour/speed issues)

Also make sure that you're not logging an excessive amount of sensors - the more sensors you have enabled/logging/visible, the longer the refresh rate (as the app scans each sensor)

I noticed the same with the track recorder It was almost realtime.. I wish I could somehow get those read speeds over into the realtime part.

The protocol automatically detected right now is ISO 9141-2. It says it is reading 5 PID's per second which is just about consistent with what I see. Frankly I'm not surprised that the ECU can't read faster being such a basic car but at least now I know I'm not crazy.

Further analyzing what is going on, I believe that the track recorder is simply upsampling the PID's in the same way the "graph" function works onn the realtime status screen. It looks like they're really refreshing fast, but they simply aren't.

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.

try to reduce the number of devices on the screen

In my case 2 or more gage doesn't change anything

https://www.youtube.com/watch?v=pfsUIwOmRTY&list=UUzBelEJQi0u9xEPUaumALIQ

Quote from cintakc on November 27, 2014
try to reduce the number of devices on the screen

Doesn't matter how many devices you use. For drawing of gauges avarage value is used. Simple average gives good lag. There are more complicated avarages like Jurik Average which gives less lag. But better to include setting for number of steps used for average calculation so every user can set it as he likes