ECU Talk Pocket PC Edition

[X-Ray]

Correct! The values will still be written in the log, if the gauges are "freezed", just the gauges wont updated.

[NewKleer]

see what happens if you turn logging off - ie see if it ever freezes. or perhaps try set minimum refresh ms option to 0 (and have logging on).

[MichaS14a]

Hello again, under XP as Vista don't work with my modem at the moment.

Here are the logfiles made with V. 1.3.3 beta 3. http://www.200sx.name/forum/files/logs_ ... ip_115.jpg

I have test your new built in option to regulate the priority of ECUTalk. If I set it to "Below normal" I am able to run ECUTalk in background and have TomTom (a routing programm) in the foreground. On a distance of ca. 50 km there is a difference from ca. 2 km between ECUTalk and the original daily driven distance gauge in the car (what is the correct term for this?), so I think that ECUTalk will miss some updates from the ECU if it works in the background. I will try to run ECUTalk in the background and disable any gauges, only activating the logfile and show if ECUTalk miss fewer (lesser?) updates. The logs above are made in foreground with "normal"-priority and are very precise.

thanks for update

"If the gauges are "freezed" the actual sensor-values are written into the logfiles"

do you mean that when gauges are frozen, the log will still be written to with new values? (but these values arent being shown on gauges?) so the program is still reading data from ecu, just the gauges wont update?

Yes this is it: The gauges shown are frozen but the log in the background will be updated as expected. Only with the new version of ECUTalk wich shows the daily driven kms I am able to see this. If the gauges are frozen and you go to the main menue and tap "show gauges" again, after a half second all sensors show the actual values including the driven kms.

Now I will test your suggestions (turn logging off, setting refresh to 0 ms).

[NewKleer]

"odometer" is the KMs meter in car. "trip meter" is the resettable 0-999KM meter

can you see if ECUTalk is also off by 2km in 50km when at normal priority? as ecutalk works out distance based off speed, if tomtom takes up all CPU time, then distance calcs wont be right...

eg if its only updating once a second, then if u go from 0-30km/h and travel 50m, it might not see youre travelling 30km/h till a second later and miss that 50m. it could also operate the other way - if you brake from 50km/h to 0, then distance might still keep counting until the next sensor read (when it realises its no longer 50km/h and stops counting distance). overall this tends to even itself out

i would say 95% accuracy is good and is around the level ive got with ecutalk lcd display (and 2/50 is 96% so thats ok )

[MichaS14a]

"odometer" is the KMs meter in car. "trip meter" is the resettable 0-999KM meter

can you see if ECUTalk is also off by 2km in 50km when at normal priority? as ecutalk works out distance based off speed, if tomtom takes up all CPU time, then distance calcs wont be right...

No. When ECUTalk is the only software running at the PDA the values are very exact! I have a difference form only a few hundret meters compared to my trip meter.



If I turn logging of I don't be able to show the desired values as all needed sensors must be shown at once. The PDA Display ist to small to show all sensors at the same time in a size that I am able read the values.

If i set the refresh to 0 ms I have no "hanging" or "freezing" of the gauges but I am not sure if this behavior is stable. I must do more tests to verify this.

What about some new suggestions?
- Writing the last value of the driven km to the ini-file so at the next motor start (or ECUTalk start) the calculation starts at the last value and not at zero.
- Implementing a "Reset-Button" to delete the driven kms like the button at the original trip meter.

This can be extended to all values the relies on calculations (e.g. used fuel)

[NewKleer]

No. When ECUTalk is the only software running at the PDA the values are very exact! I have a difference form only a few hundret meters compared to my trip meter.

i guess thats pretty good then. yeh the longer between each packet (ie, if lower priority/cpu time ecutalk has), the more acceleration makes the distance calcs inaccurate.

s=ut+0.5at^2 (normal physics...distance = speedxtime + accel*time squared). since acceleration isnt factored into the calculations, whenever speed changes but there is a loss (or gain, if slowing down) of distance . acceleration cant be used in equation as it is not precise - ie acceleration will be 0 until the speed jumps each 2km/h, then acceleration is huge (ie speed is 20, 20, 20, 22 rather than 20.5, 21, 21.5, 22, etc).

this normally doesnt matter as the acceleration tends to cancel itself out, but the longer time between packets, the less accurate it will be. and because braking is usually quicker than acceleration, the kms will normally be less than actual.

in other words, there is nothing that can be done. even 95% with low priority is good! fuel/distance is all about relative values, ie comparing driving one way to another, or one place to another, or different speeds, etc.

If i set the refresh to 0 ms I have no "hanging" or "freezing" of the gauges but I am not sure if this behavior is stable. I must do more tests to verify this.

ok please test that a bit (it will just reduce amount of data logged by a bit as more time spent updating gauges), as if they never freeze with 0ms, then i think i know when problem is (but i might not be able to fix it )

- Writing the last value of the driven km to the ini-file so at the next motor start (or ECUTalk start) the calculation starts at the last value and not at zero.

already thought of - http://www.ecutalk.com/mantis/view.php?id=35

- Implementing a "Reset-Button" to delete the driven kms like the button at the original trip meter.

also already thought of - http://www.ecutalk.com/mantis/view.php?id=36

[MichaS14a]

s=ut+0.5at^2 (normal physics...distance = speedxtime + accel*time squared). since acceleration isnt factored into the calculations, whenever speed changes but there is a loss (or gain, if slowing down) of distance . acceleration cant be used in equation as it is not precise - ie acceleration will be 0 until the speed jumps each 2km/h, then acceleration is huge (ie speed is 20, 20, 20, 22 rather than 20.5, 21, 21.5, 22, etc).

this normally doesnt matter as the acceleration tends to cancel itself out, but the longer time between packets, the less accurate it will be. and because braking is usually quicker than acceleration, the kms will normally be less than actual.

in other words, there is nothing that can be done. even 95% with low priority is good! fuel/distance is all about relative values, ie comparing driving one way to another, or one place to another, or different speeds, etc.

Thank you for the explanation. I am very happy with the current accuracy of the values. :ja: [/quote]

ok please test that a bit (it will just reduce amount of data logged by a bit as more time spent updating gauges), as if they never freeze with 0ms, then i think i know when problem is (but i might not be able to fix it )

Ok!

- Writing the last value of the driven km to the ini-file so at the next motor start (or ECUTalk start) the calculation starts at the last value and not at zero.

already thought of - http://www.ecutalk.com/mantis/view.php?id=35

- Implementing a "Reset-Button" to delete the driven kms like the button at the original trip meter.

also already thought of - http://www.ecutalk.com/mantis/view.php?id=36

Ups, you have made a real bugtracker. So I have a to read all entries to see the current status.
Should I make an account at your bugtracker or post my test results here in the forum as before?

[NewKleer]

its easier if you sign up and post them there in general (as then its in a place i wont forget to check up on etc). particularly posting logs (i think there is an upload function) or screenshots etc of things not working.

eg you can enter a ticket about the freezing of the gauges (which no one else has mentioned yet)

im sure in these 18 pages there have been some feature suggestions/bugs mentioned that arent in the bug tracker because it is hard to keep track of everywhere people mention things about ecutalk. so hopefully even if other people dont put bugs/features in there, that i can do so whenever i come across one (in the past it was too much effort to update the feature requests page on the site).

[MichaS14a]

If I have the time I read through the 18 pages of this thread and compare it with your bugtracker. Then I post the issues that are not noticed at your page. But I think most of the issues are solved or already written at your bugtracker.

ECUTalk works very well at the current state.
All the last things to test are new features with exception of the freezing gauges. At the moment I don't miss an old unresolved issue. :gruebel:

From version to version ECUTalk becomes better and better! The best is that I am able to run ECUTalk not only at the PDA but also on my Notebook if I wish.

So if the abillities to define warning levels, make an ECU-ROM dump and have log-format that is compatible with the logviewer from the author of NissanDataScan is available I'm pretty happy :freude: (or are you able to write an own log-viewer for ECUTalk logs? Importing and formatting the values in Excel are very work intensive as Excel identifies number values seperated with a dot as text and not as numbers.)

[NewKleer]

nissan datascan log format - last time i talked to the author he said the problem is probably that nissan datascan cant read the logs because they have sensors in them that nissan datascan doesnt support (ie all my economy etc ones). but thats another ticket you could enter just so i dont forget to chase it up.

logs work with the "datalogviewer" program on blazt site, though (but it costs a bit more than its worth).

warning levels, rom dump, log viewer are all in there as tickets. log viewer isnt high priority (like warning levels and active tests) but i too need a better log viewer than excel so i want to do that

i will probably wait to see if i can do real-time graphs in ecutalk - if i do that ok then log viewer might be able to use similar graphing to whatever i write for real-time graphs.

maybe there is a generic graph drawing program for text files? i havent researched, but i would guess that there would be a need for other forms of data to be shown on a graph so there might be free programs out there that can do it?