OSEPlugin for Tunerpro 5 v1.80

[Jayme]

yeah I gave up .... I run it in a vmware xp virtual machine hahaha. my drive is bitlockered and when that happens... you cant access the boot options to allow the unsigned driver to work ... :S cheap ass willem bastards, sign your driver already !@#!@$%@

[Holden202T]

now whos whinging

[festy]

what happen to win 9? hows it go from 8 to 10?

Typical Microsoft, they announced that Windows 9 would be a free upgrade for certain win8 customers (PR department in damage control mode over the widespread win8 hate) - then a short time later win9 quietly gets re-named to win10... so now they don't have to give anyone a free upgrade

[vlad01]

what happen to win 9? hows it go from 8 to 10?

Typical Microsoft, they announced that Windows 9 would be a free upgrade for certain win8 customers (PR department in damage control mode over the widespread win8 hate) - then a short time later win9 quietly gets re-named to win10... so now they don't have to give anyone a free upgrade

one word..."microshaft"

[antus]

ok, now while I agree with everything thats been said (and enjoy a good microsoft knocking session as much as the next person).. lets keep the oseplugin thread on topic.

[ejukated]

This plugin is fantastic for keeping all the editing, logging and RT stuff in the one program!

One question I had...

On tunerpro click the 'Initialize Emulation Hardware' button (A). Tunerpro should beep and name your hardware at the bottom of the screen eg "hardware: OSE12 Pro V1.1.1". Load the appropriate XDF (bin file definition) and ADX (Logging data stream definition) for your configuration. You should now be able to start logging (button B) and emulate (requires running from NVRAM, button C) as well as download from or upload to the complete tune (D). For logging bubble tracing hit E (shows on fuel/spark tables where the ecu is looking up data from - supported XDF/ADX only). The Dash, Data list, Data history and monitors views are labeled F

Is the 'Initialize Emulation Hardware' required by design prior to logging every time? I found that If I 'Initialize Emulation Hardware', Log, stop logging - I then have to 'Initialize Emulation Hardware' again before being able to log again or I just get corrupt data.

[antus]

The plugin is stateless so it does not fire off messages to keep the chatter disabled, and after you stop logging the chatter turns back on. Initializing again fires off a new disable chatter command which prevents the data errors. You only need to do this when you have configured the plugin to disable chatter on connect.

[ejukated]

that's interesting, I have a disable chatter command in the ADX so that should keep things quite without having to first initialise. Is there anything special in the way the plugin disables chatter?

[antus]

Yep, because the plugin is sharing the aldl bus between the logging and the emulating subsystems of tunerpro, the plugin ends up owning the data bus and tries to keep both parts of tunerpro happy without letting the aldl frames get mixed up/out of order or colliding. It attempts to pass through the silence and timeout stuff but the overhead of sitting in the middle can introduce enough variance that timing which works natively does not always work when its passing through.

The granularity is especially lost on the detect silence as the serial API requires you set a timeout and then try and read and if you fail to get a read the bus was silent for that amount time. The plugin tends to work in 10ms blocks from memory, and ADX files are looking for usually 50? ms. That in itself isnt a problem but it gets clumsy. Make the timing too tight and the ADX will never detect silence and so wont start logging or make it too loose and the disable chatter command collides. Logging might then start, but your back with the same problem that disable chatter didnt work.

Since it needs to work, ive gone the looser timing approach and as a work around for heartbeat detection and chatter disable problem it has the option to do the heartbeat detect and disable chatter itself. Takeing the tunerpro API out of the loop it can easily get it right. And thats what we have. It may be possible to play with the ADX timings and get it working from tunerpro, but it likely wont work on all laptops as they are different speeds with different amounts of lag in the USB drivers etc and it all affects the timing just a bit which makes it very hard to get it right for all. Essentially the windows comms and tunerpro APIs arnt really made for this. Tunerpro assumes you have an emulator and separate logger, and windows expects serial streams which are not millisecond timing critical, nor connected to a shared bus.

[ejukated]

thanks for the detailed reply. Makes sense, seems to be quite a well balanced solution given the constraints of the windows comms and tunerpro APIs