MSS54 DS2 Tool: FREE TOOL for programming DME - Tune, full binary, flash counter, etc

[Shonky]

Honestly, this is probably the most exciting thing about the tool for swapped cars. AFAIK the only way to run the Vanos test and see the data is with ISTA, and you can't access the test without an M3 EWS. Having this in your tool is going to be fantastic for any swapped car with a stock DME.

It is possible to run DIS in a VM and get VANOslS results. A bit painful and tricky to get working though so I'm all for an easy to use app.

[ac427]

Not a test but being able to manipulate the 3 parts (SAP, fuel enrichment and (i think timing)) of the 'cold start routine' would be a great addition to the tool.

[ac427]

Honestly, this is probably the most exciting thing about the tool for swapped cars. AFAIK the only way to run the Vanos test and see the data is with ISTA, and you can't access the test without an M3 EWS. Having this in your tool is going to be fantastic for any swapped car with a stock DME.

Can you run the "Throttle set point" calibration on a swapped car?

[George Hill]

So the app will do the same thing and return and display the results :-)

Honestly, this is probably the most exciting thing about the tool for swapped cars. AFAIK the only way to run the Vanos test and see the data is with ISTA, and you can't access the test without an M3 EWS. Having this in your tool is going to be fantastic for any swapped car with a stock DME.

[karter16]

Oh nice. Have you figured out how those script files work or are you replicating from logs and dme disassembly?

Working backwards from the disassembly and some trial and error In this case I'd previously identified the DS2 handlers, as well as the functions that set the VANOS positions. From that was able to work out that there's a series of functions that are called back to back in one of the tasks on the slave (I think 100ms task from memory) that each check for a different value in a vanos status variable and then process various actions (set fully advanced, set fully retarded, etc.). There's a corresponding set of DS2 functions that set that status variable, and from there it doesn't take much to put it together and work out which is which, given we know the names and purposes of the individual tests that can be called from Tool32, etc.

[terra]

Yep, so the way the DIS Vanos test works is it just calls a sequence of individual tests over DS2. Once that sequence of tests is complete another function in the DME pushes all of the test results into a structure in memory that is then read by another DS2 call to get the result. So the app will do the same thing and return and display the results :-)

Oh nice. Have you figured out how those script files work or are you replicating from logs and dme disassembly?

[ac427]

Yep, so the way the DIS Vanos test works is it just calls a sequence of individual tests over DS2. Once that sequence of tests is complete another function in the DME pushes all of the test results into a structure in memory that is then read by another DS2 call to get the result. So the app will do the same thing and return and display the results :-)

That's great news. I thought it might be a tough job to extract the test details or there may have been some custom code involved.

That would certainly make it easier to export the Component Activation stuff in DIS.

There is a throttle set point calibration option in there somewhere too. Top work mate 👍

[karter16]

Have you had a look at the DIS Vanos test?

Yep, so the way the DIS Vanos test works is it just calls a sequence of individual tests over DS2. Once that sequence of tests is complete another function in the DME pushes all of the test results into a structure in memory that is then read by another DS2 call to get the result. So the app will do the same thing and return and display the results :-)

[ac427]

Ha!

Diagnostics tests are what I'm working on at the moment! Currently have the following:

Vanos Test
Electric Radiator Fan Actuation
Fuel Pump Actuation
Throttle Actuation
CSL Flap Test

Will add the E-box fan test as well and see how it goes!

Everyone: If you have any tests you'd like to see added to the list please shout out!

Excellent, I was going to ask for the electric radiator fan but i didn't want to be too greedy.

Have you had a look at the DIS Vanos test?

The throttle actuator would be great 👍

Thank you.

[karter16]

Just an idea but would it be possible to test the E-Box fan from the DS2 Tool?

I only ask because the option doesn't appear in INPA if you are running the CSL 0401 firmware.

Ha!

Diagnostics tests are what I'm working on at the moment! Currently have the following:

Idle Speed Control
Vanos Test
Electric Radiator Fan Actuation
Fuel Pump Actuation
Throttle Actuation
CSL Flap Test

Will add the E-box fan test as well and see how it goes!

Everyone: If you have any tests you'd like to see added to the list please shout out!

[ac427]

Just an idea but would it be possible to test the E-Box fan from the DS2 Tool?

I only ask because the option doesn't appear in INPA if you are running the CSL 0401 firmware.

[karter16]

I think option 2 because it lends itself more to accurately synchronised log comparison, which is essential.

I like (2) as well.

Thanks both - I've gone with this approach.

v1.1.0 now available: https://github.com/karter16/MSS54-DS...ublic/releases

• View live values in app
• Choose values to log to CSV for import into log viewers, etc.
• Save log sets in app so you can easily log the same data points over multiple runs.

[heinzboehmer]

I like (2) as well.

Just a thought: maybe add the option to toggle between outputting multiple log files (one per request) or one coalesced one like you showed?

I genuinely can't decide if that makes it more or less confusing, so feel free to ignore.

[ac427]

I think option 2 because it lends itself more to accurately synchronised log comparison, which is essential.

[karter16]

Question for the group when it comes to logging live values.

Because of the way the DS2 live values queries work, there are a number of "blocks" that are queried. These must be done sequentially over the DS2 interface. If a user wants to log values from multiple of these blocks then the app needs to make multiple queries to get the relevant values from each block. Because these are done serially, it means that the exact time block 1 was snapshotted, is different to block 2. etc. How much this matters varies on what is being logged. If you're trying to track ignition timing against other variables for example, or do the CSL fuelling tuning process it's a bigger deal, for other things like logging temps etc. it doesn't really matter.


There are two ways I can think of to approach this:

1: Query each block in sequence and when you have all the data from that sweep then write a line to the logs with the current timestamp. At 3-4Hz that means some values might have been capture quarter of a second earlier/later than other values.

2: Log the values from each block as it comes in on its own log line. This means you get the exact time that those values were snapshotted. Any values not in that block are blank for that row.


My personal preference is option 2 as it is more exact/correct. However it means then that the user has to understand that is how it works and setup their log viewer accordingly (e.g. in MegaLogViewerHD you have to select the "use last value for NaN" option, etc.). Want to make sure this doesn't end up being too complicated for people to easily use.


Thoughts?


Example of option 2 for those of us who are visual: