Torque

Forums

Forums

Guest  

Show or hide header
Welcome Guest, posting in this forum require registration.




Torque » Torque OBD ECU Scanner » Torque Discussion / Ideas » Active Sensor problem

Pages: [1]
Author Topic: Active Sensor problem
Enki
Member
Posts: 23
Post Active sensor and logging problem
on: August 22, 2011 (GMT)

So I’ll lay this out simply: There is too much stuff being accessed (according to the active sensor list) despite what I’m actually asking for; this cripples the refresh rate on both the screen and makes anything but half second or slower logging useless. When attempting to log at .1 second intervals, I normally get between 5 and 7 repeated values per PID.

In fact, having so many active sensors means the tablet (a modified Nook Color specifically flashed for use in my car) will actually lock up and reboot if I try to do anything other than view the one screen I have configured; trying to modify things ends horribly.

I have one screen active with the following sensors being monitored:

Engine coolant temp
DI PSI (custom pid)
Vacuum/boost
Actual AFR (custom pid)
Speed
RPM
Barometer

I have the following items set to log (logging has been disabled due to the issue at hand):

Engine coolant temp
DI PSI (custom pid)
Vacuum/boost
Actual AFR (custom pid)
Speed
RPM
Barometer
Throttle position (manifold)

I begrudgingly accept the fact that the accelerometers are forced to not only be active, but logged as well; they aren’t in the datastream pulled from the ECU so they “shouldn’t” be a part of the problem.

I really would like to know why the following are forced to poll on the active list when I’ve never configured them to be used before:

Air Fuel ratio (Commanded)
Air-Fuel ratio (Measured)
Ambient Air Temp
Catalyst temperature (bank 1, sensor 1)
Commanded Equivalence Ratio
EGR Commanded
Engine Load
Intake Air Temperature
Intake Manifold Pressure
Relative Throttle Position (Alternate)
Trip Distance (This has never actually updated anyways)
Voltage (Control Module)
Voltage (OBD Adapter)

I’m also kind of curious as to why the following are still listed as active, even though I no longer have them on any screen/logging:

Engine Load
Mass Air-Flow Rate
Timing Advance
LTFT (Custom PID)
STFT (Custom PID)

Not including accelerometer data, this totals up to 18 active sensors that shouldn’t be active.

Also, it would be nice if we could both turn off the accelerometer monitoring and logging (or at least reduce it to nearest hundredth.

I have a lot of time and a fair bit of money invested to using Torque as a platform for ECU monitoring, but I’m beginning to regret my choice.

If there is ANYTHING I can do to help with the resolution of the issues outlined in this post, please contact me; I am willing to do what it takes to make this work.

TLDR:
“OH GOD THE GOGGLES, THEY DO NOTHING!”

Enki
Member
Posts: 23
Post Re: Active Sensor problem
on: August 23, 2011 (GMT)

Attached is a zip file with screenshots of what I have shown (note that the screen shown is literally all the data I’m pulling at this time), as well as the active sensors and a log from Torque set to run at .1 second.

Hardware specs for the Nook are basically the same as a Droid X, and I’m using a class 10 card (which does work at full speed via the Nook, according to my tests).

http://dl.dropbox.com/u/21365631/ShootMe.zip

piemmm
Administrator
Posts: 6629
Post Re: Active Sensor problem
on: August 23, 2011 (GMT)

Hi

The screen corruption you have in the active sensors screen is something wrong with Android itself and should not ever happen on a properly functioning system (is this an original ROM that the manufacturer has supplied?). The active sensor screen is fluid on all other devices (even a lowly X10 mini pro and huawei low-end phones) so I highly suspect this is a problem with the version of android you are using

As to the refresh rate of sensors, there are several reasons for slow readings. Unfortunately you haven’t sent a comms debug whilst connected so I can’t offer any extra guidance.

Have you ‘ticked’ “Faster Communication” in the OBD2 settings and *UN*ticked “Disable ELM327 Auto Timing”?

ECU’s can also determine the speed at which sensors can be read. My Smart Roadster can only update at around 7 PIDs/sec, where as my newer Smart ForTwo(which uses the can protocol) updates at 31PID/sec – this is simply due to the way ECUs implement the protocol.

The adapters can also limit the speed at which sensors can be read. For example, the OBDKey can be quite slow at updating on some protocols, whereas the clone units from ebay are often faster, and the fastest adapter being the Scantool.net OBDLink

Also, make sure you are on the *latest* version of Torque from the Android Market. In an ancient version (ie: older than a month) there was a screen update issue with the sensor screen, it was a bit laggy, though it wouldn’t cause screen corruption like that (the screen corruption is a bug in android there and I suspect you’re not using the original firmware?)

Ian

Enki
Member
Posts: 23
Post Re: Active Sensor problem
on: August 23, 2011 (GMT)

Ian, thank you for your response.

Both the faster communication and the ELM auto-timing adjust are already as specified. As for the screen corruption, that appears only in the screenshots and I’m assuming because the tablet is overloaded with stuff to do; it only has issues when I go to do something with Torque other than monitor; it runs fine otherwise.

Yes, I am not running the stock OS (CM7 nightlies, same as on my phone) on this tablet, as you can’t actually use it for much other than reading books if left stock.

To reiterate, my biggest concern at this point is the fact that Torque shows so many extra PIDs being monitored when I’m only requesting a few. I should probably also note that the little green ping square which shows sensor update interval used to be damn near solid when I first started using it, but now only pings at a slow but steady rate.

I can confirm that I am on the latest version of Torque, and can also tell you that I have logs from another device which show 12 ECU PIDs logged at a rate of 12 samples per second, so I’m positive my ECU isn’t too slow.

Also, I’m using the PLX Kiwi module for CANBUS communication.

I’ll work on getting the debug information to you, and I’ll test torque on my phone (lesser hardware) to see if that makes any difference.

Thank you again for your time.

Enki
Member
Posts: 23
Post Re: Active Sensor problem
on: August 23, 2011 (GMT)

Debug data sent from both my phone and the tablet. Note that the phone has no memory card, so I did not migrate torque settings and just cleared all but the main screen; other settings should be identical.

piemmm
Administrator
Posts: 6629
Post Re: Active Sensor problem
on: August 23, 2011 (GMT)

Hi

Got the debug, thanks (haven’t seen the phone one, only the tablet) – you’ve got about 80ms between requests and responses which makes the read speed tally with what you are saying – about 12.5 pids/sec from that debug

It’s not a sensor refresh issue (you have about 4 sensors being refreshed when you sent the debug, which should result in updates of twice to 3 times/second for the displays visible on the screen.

However, the screen corruption on screenshots leads me to believe that the screen updates are lagging – this is likely where the issue is, the display driver isn’t accelerated enough to update the screen fast enough (or at least that is what suspect is happening as I can’t see any obvious issues from the debug)

In the settings->dash config settings, there’s an option to reduce the refresh rate on the screen – this might help if the display drivers are slow at writing to the screen. I don’t have a nook here to play with, but suspect that it’s using a very basic framebuffer driver for the screen output, which would cause this kind of speed issue

EDIT: This link (below) seems to confirm this suspicion
http://fineoils.blogspot.com/2011/08/graphicsvideo-hardware-acceleration-in.html

Enki
Member
Posts: 23
Post Re: Active Sensor problem
on: August 24, 2011 (GMT)

I tested the lower framerate setting and found it to leave the UI less responsive than with it off. I’ve also had it log again and found that it still repeats values for 5-7 rows.

I’ve tested bluetooth speed and can transfer files at about 100 KBPS, so a few PIDs should not be an issue. Maybe later tonight I’ll try an overclock and some settings tweaks to see if that helps at all.

Enki
Member
Posts: 23
Post Re: Active Sensor problem
on: August 24, 2011 (GMT)

No dice on the overclock. Sent another debug log “Enki tablet 3.”

Also, the screen corruption happened only in the screenshots and is ultimately a non-issue.

As a side note, you mention four PIDs being updated when the last log was sent; I have Torque configured to display 7 currently and 8 in the latest.

piemmm
Administrator
Posts: 6629
Post Re: Active Sensor problem
on: August 24, 2011 (GMT)

Hi

Some of the PIDs don’t require data to be sent over bluetooth (and are calculated from the 4/5 that are pulled over OBD, or are calculated from other sensors (GPS for instance if you have a GPS speed widget visible)

Logging is independent of PID read cycles, so if your reads only update slowly, then you will get duplicate lines.

Your ECU responds to PIDs at intervals of 80ms from requesting the data to getting a response, this is the limiting factor. You are limited to an approximate max of 12 PIDs /second – if you have 8 displays, then you would get a refresh rate of just over once per second. You are being limited by the rate the ECU supplies the data and/or the adapter.

Enki
Member
Posts: 23
Post Re: Active Sensor problem
on: August 24, 2011 (GMT)

It has to be the bluetooth adapter then; my ECU is capable of (and I have logs from another device to prove this) of recording twelve (maybe more) individual PIDs twelve times per second.

http://dl.dropbox.com/u/21365631/datalog1.csv

Do you know of anyone else having this sort of issue with the PLX Kiwi bluetooth adapter? I’ve tried looking up the data rate for the device and came up trump.

Thanks again.

Enki
Member
Posts: 23
Post Re: Active Sensor problem
on: August 25, 2011 (GMT)

Ian,

The PLX support people say that the Kiwi Bluetooth polls at a rate of 10ms; I’m trying to find out how many it can poll at once at that speed, but as of this moment, it doesn’t look like that is the issue.

There’s at least one other person on another forum I frequent who can’t get high speed logging to work properly either.

Do you have some sort of speed/latency test that can be run?

piemmm
Administrator
Posts: 6629
Post Re: Active Sensor problem
on: August 25, 2011 (GMT)

Right, I think I know what that is – it’s a change to how things are requested at the protocol level…. Is your vehicle using the CAN protocol?

If it is then it should be possible to double (or more) the throughput (so it could be possible to get a faster update, however it will require a code change in the app to do this. I will have a look at how this can be achieved – can’t promise anything right now, but hopefully you should be able to see something in a month or two.

Enki
Member
Posts: 23
Post Re: Active Sensor problem
on: August 25, 2011 (GMT)

Kickass, that would be awesome man.

Thanks again.

wnmgwarpp
Member
Posts: 1
Post Re: Active Sensor problem
on: November 23, 2018 (GMT)

Hello,
I’ve got a more general question about active sensors…what
determines WHETHER a sensor is active? I’ve seen green (active)
dark green (active but no data) and black (inactive).

I would assume most cars have sensors set to inactive by default.

Does Torque have any way to talk to the CANBUS and request a sensor be “turned on”?

Could some command using an OBD2 serial terminal be used to activate a sensor?

Basic “dabbles in everything” sort of scholar. Have recently developed an interest in OBD ii systems.

Pages: [1]
WP-Forum by: Fredrik Fahlstad, Version: 2.4
Page loaded in: 0.052 seconds.

  Follow me on twitter