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

[karter16]

The latter is how I do it in mss6x flasher (minus restoring adaptions etc), but that's also partly because on those DMEs writing a program wipes the tune so it's pretty much necessary. I do like the idea of having a 'one click' solution to accomplishing what is essentially a complete restore from a different backup (minus ISN I guess). Could be useful for those scenarios where one needs to swap back to a stock tune not want to go through the hassle of setting the drive cycles again etc.

Another thought I had was adding a RAM dumping functionality, though again probably mostly useful for us tinkerers out there.

Yeah okay - I've been thinking about this and it seems like it could be the more streamlined way to do it for sure. also means where the user wants to write multiple blocks the app can just execute that as a set of sequential actions. Thanks heaps for this, I will look to implement this in a future version.

Ah RAM dumping is a great idea - I hadn't thought of that one. as you say, less people who will use it, but that doesn't matter, the point is to try to make all these activities as easy as possible (and accessible on modern hardware, Win10/11, ARM, etc.)

[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:

[ac427]

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

[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.

[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.

[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]

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]

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]

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]

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 👍

[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?

[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.

[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.

[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?

[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.