[pheno]

Originally Posted by _TB_

Yes, that works.

when I start TestO and select the right ecu - will it start to updte right away? or do I have to start it somehow?

On the right you see the list of jobs.. double-click for example the first in the list and it should open a graph window.

[TDIwyse]

Originally Posted by pheno

Santa Claus is still on holidays !

Yes, that would be nice of course but I was thinking that Torque with DWR's custom PID's is sufficient for you guys ?

EDIT: What do you think what would be the minimun features you'd expect to have in Android version ?

Yes, DWR's Torque PID's are great. The logging rate of Torque, however, is not.

Was wondering if by using the wired cable TestO uses might somehow be able to provide a faster interface than the bluetooth dongle? The notepad Windows 8 machine I'm using for TestO already requires a USB to micro USB adapter for its interface. Same thing could feed into the droid phone?

[_TB_]

Your android needs to support USB OTG, and a driver needs to be implemented.

[pheno]

Originally Posted by TDIwyse

Yes, DWR's Torque PID's are great. The logging rate of Torque, however, is not.

Was wondering if by using the wired cable TestO uses might somehow be able to provide a faster interface than the bluetooth dongle? The notepad Windows 8 machine I'm using for TestO already requires a USB to micro USB adapter for its interface. Same thing could feed into the droid phone?

I'm trying to get this... Ok, hmm.. so do you mean wired TestO would be used as a proxy the data to Android via BT on the notepad that Torque would use ??

Or.. best and easiest would be simply to use wired interface for Android. As said it needs OTG support. Data rate would be the same as with TestO

[DWR]

In this instance, sample rate in an android device, such as a phone, has more to do with the device than the connection method.

[TDIwyse]

Originally Posted by pheno

I'm trying to get this... Ok, hmm.. so do you mean wired TestO would be used as a proxy the data to Android via BT on the notepad that Torque would use ??

Or.. best and easiest would be simply to use wired interface for Android. As said it needs OTG support. Data rate would be the same as with TestO

I was asking about the direct wired connection to the Android device via the cable, thus avoiding the blue tooth dongle connection and its impact to sampling rate. So there'd be a "TestO" app installed on the Android that would read the data directly from the cable.

[TDIwyse]

Originally Posted by DWR

In this instance, sample rate in an android device, such as a phone, has more to do with the device than the connection method.

Curious as to this comment. I know the blue tooth dongles have slow response rate capabilities, but are you saying the Android processors are actually the bottle neck in the Torque sampling? I haven't looked into this to know the exact specifications, but I just expected the dongle to be the weak link based on its sub-optimum specifications.

[DWR]

Originally Posted by TDIwyse

Curious as to this comment. I know the blue tooth dongles have slow response rate capabilities, but are you saying the Android processors are actually the bottle neck in the Torque sampling? I haven't looked into this to know the exact specifications, but I just expected the dongle to be the weak link based on its sub-optimum specifications.

Ultimately, the bottle neck is the DDE. The limit is the updating speed of the OBD parameters. They are not a priority. Essentially, once you meet the sampling rate of the DDE there isn't much to be gained by faster requests and responses (the second sampling rate). Bluetooth appears to be more than fast enough. Of course, distance degrades speed. More so than with cable.

Like all computers the processor is only one part of the equation. The software is the other. With the same processor, different phones process background apps and other overhead with varying priority schemes. Torque doesn't necessarily win the battle for bandwidth (the third sampling cycle? I don't know what the correct term is). Bottom line it runs better on some phones than others, independent of the connection.

I probably should have written "can have" rather than "has". Absolutism will always get you in trouble

[_TB_]

I'm all in for an Android solution - if you need help coding the Android parts, let me know.

[pheno]

Originally Posted by _TB_

I'm all in for an Android solution - if you need help coding the Android parts, let me know.

Do you know if there are any free plotting libraries available for Android ? It should be fast and be able to reach at least 50fps without much cpu usage.

[pheno]

New version uploaded with an interesting addition for users who use custom jobs.

change testo.ini into:

[customjob]
clear_mw_block=1

(default value is 0)

I won't go into details but let me know if you find any improvements in logging speed. Thanks. At least MSV70 ecu seems to have much better logging speed with this setting.

Updated standalone version is here: http://phenoboy.kapsi.fi/testo/testo...andalone-1.zip

[DWR]

Thanks Pheno. I'll give it a try this week.

[DWR]

Hmm, I get no communication with the latest standalone version.

[pheno]

Originally Posted by DWR

Hmm, I get no communication with the latest standalone version.

Ok, that's interesting. Did you check the com port from ediabaslib.config ?

[DWR]

Originally Posted by pheno

Ok, that's interesting. Did you check the com port from ediabaslib.config ?

Nope, but that did the trick. Now to test the new version.

[DWR]

Well, I tested the newest version of TestO against an older version from July of this year, with a single parameter log of rpm.
Essentially, no speed change. However, the sampling rate has more variation in the new version. See a example of the time durations between samples below.

[pheno]

Originally Posted by DWR

Well, I tested the newest version of TestO against an older version from July of this year, with a single parameter log of rpm.
Essentially, no speed change. However, the sampling rate has more variation in the new version. See a example of the time durations between samples below.

Thanks for testing. Yes, I believe the situation won't change much with many parameters.

[_TB_]

Originally Posted by pheno

Thanks for testing. Yes, I believe the situation won't change much with many parameters.

I have the opposite problem - it seems it logs too fast - or maybe some of the parameters do not update fast enough?

I logged the following:

STAT_MOTORDREHZAHL_WERT
STAT_InjCtl_qCurr_WERT (Is this the actual injected amount?)
STAT_CoEng_trq_WERT (is this the torque the engine produces, or is it the torque before the gearbox limits it?)
STAT_LADEDRUCK_IST_WERT
STAT_LADEDRUCK_SOLL_WERT
STAT_RAILDRUCK_IST_WERT

I do get 4-5 lines with the same values in a row. (This is a WOT pull in 6th gear)

eg.:

time	STAT_MOTORDREHZAHL_WERT	STAT_InjCtl_qCurr_WERT	STAT_CoEng_trq_WERT	STAT_LADEDRUCK_IST_WERT	STAT_LADEDRUCK_SOLL_WERT	STAT_RAILDRUCK_IST_WERT
3776	1525,9	57,3469	460,862	1887,91	2125,91	1054,89
3807	1525,9	57,3469	460,862	1887,91	2125,91	1061,48
3947	1525,9	58,0275	465,897	1887,91	2125,91	1061,48
3978	1525,9	58,0275	465,897	1994,91	2125,91	1061,48

[pheno]

Originally Posted by _TB_

I have the opposite problem - it seems it logs too fast - or maybe some of the parameters do not update fast enough?

I logged the following:

STAT_MOTORDREHZAHL_WERT
STAT_InjCtl_qCurr_WERT (Is this the actual injected amount?)
STAT_CoEng_trq_WERT (is this the torque the engine produces, or is it the torque before the gearbox limits it?)
STAT_LADEDRUCK_IST_WERT
STAT_LADEDRUCK_SOLL_WERT
STAT_RAILDRUCK_IST_WERT

I do get 4-5 lines with the same values in a row. (This is a WOT pull in 6th gear)

eg.:

time	STAT_MOTORDREHZAHL_WERT	STAT_InjCtl_qCurr_WERT	STAT_CoEng_trq_WERT	STAT_LADEDRUCK_IST_WERT	STAT_LADEDRUCK_SOLL_WERT	STAT_RAILDRUCK_IST_WERT
3776	1525,9	57,3469	460,862	1887,91	2125,91	1054,89
3807	1525,9	57,3469	460,862	1887,91	2125,91	1061,48
3947	1525,9	58,0275	465,897	1887,91	2125,91	1061,48
3978	1525,9	58,0275	465,897	1994,91	2125,91	1061,48

Looks like you are running individual jobs ? You could try to create a custom job with the same parameters.

Individual jobs are run sequentially one after another so when logging only one value is new, others are previous / old values.

[_TB_]

Originally Posted by pheno

Looks like you are running individual jobs ? You could try to create a custom job with the same parameters.

Individual jobs are run sequentially one after another so when logging only one value is new, others are previous / old values.

That makes sense - so I need to make a custom job with the parameters I'd like to log.

..Need to find out how to make custom jobs

[pheno]

Originally Posted by _TB_

That makes sense - so I need to make a custom job with the parameters I'd like to log.

..Need to find out how to make custom jobs

Here's some help.

[_TB_]

Excellent, thank you. I'll make my custom jobs.

..But why am I not able to select the GS19.11 ecu when defining a custom job?