Announcement

Collapse
No announcement yet.

MSS54 DS2 Tool: FREE - DME tune, program, flash counter, codes, adaptions, etc

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • karter16
    replied
    Originally posted by terra View Post

    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.

    Leave a comment:


  • terra
    replied
    Originally posted by karter16 View Post

    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?

    Leave a comment:


  • ac427
    replied
    Originally posted by karter16 View Post

    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 👍

    Leave a comment:


  • karter16
    replied
    Originally posted by ac427 View Post
    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 :-)

    Leave a comment:


  • ac427
    replied
    Originally posted by karter16 View Post

    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.

    Leave a comment:


  • karter16
    replied
    Originally posted by ac427 View Post
    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!

    Leave a comment:


  • ac427
    replied
    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.

    Leave a comment:


  • karter16
    replied
    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.
    ​

    Leave a comment:


  • heinzboehmer
    replied
    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.

    Leave a comment:


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

    Leave a comment:


  • karter16
    replied
    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:
    Click image for larger version

Name:	Screenshot 2026-05-22 at 10.03.01 AM.png
Views:	238
Size:	247.8 KB
ID:	356105
    Last edited by karter16; 05-21-2026, 02:03 PM.

    Leave a comment:


  • karter16
    replied
    Originally posted by terra View Post
    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.)

    Leave a comment:


  • karter16
    replied
    Originally posted by terra View Post

    Hmm, I haven't tested this app on ARM yet, but my own MSS6x flasher seems to work fine on ARM with any cable I throw at it (whether in CAN or K-line mode).

    Might be worth trying COM mode instead of FTDI or vice versa to see if that works better.
    I've done all my development on Win11 VM on an M1 MacBook Pro with a USB-C to A adapter and no issues there.

    Leave a comment:


  • karter16
    replied
    Originally posted by Slideways View Post

    I'll give that a try. It defaults to COM for this cable.
    And to confirm, have you set the COM latency time to 1ms in device manager? If you use FTDI driver then the software can do this automatically, if you use COM then you have to make sure it's set to 1ms (defaults to 16ms).

    Leave a comment:


  • ac427
    replied
    Tomba How does the INPA Vanos test compare to the original DIS Vanos test?
    Last edited by ac427; 05-25-2026, 08:59 AM.

    Leave a comment:

Working...
X