Anyone posting their modified maps?

[crispyduck]

it will be input from an external sensor (anything really) via a serial port.

thinking of doing it like this:
- external inputs defined in registry (configurable through ecuExplorer)
- dll initialized on startup (sensorInitialize)
- dll loaded on startup (function call to sensorStart)
- dll closed on shutdown (function call to sensorStop)
- dll polled when in realtime data view (function call to sensorGetData)

maybe have initialization return poll time, etc. still thinking about it. any recommendations?

calvin.

Quick note, that many modern laptops now do not come with serial ports. Will a simple serial->usb cable (plus driver) still work? In theory it still should as the application should still 'see' it as a serial port.
Just a thought.
-Steve.

[calvinc]

Will a simple serial->usb cable (plus driver) still work?

yes it will still work.

calvin.

[Kha0S]

calvin --

I'm very much looking forward to a DLL plugin interface. I have already written a partial driver to talk to the TechEdge for one of my own projects, and I'm eager to integrate it with ecuExplorer!

What is the potential for a "realtime output" architecture? That is, being able to write a DLL That would take the captured/processed data from ecuExplorer and display it graphically, display it on top of a ROM, send it over the network, or display it on some sort of remote device (like a Palm, PocketPC, etc.)?

This would allow ecuExplorer to become the core data acquisition engine behind a whole host of potentially groundbreaking tuning and monitoring tools... essentially, a car PC could just run ecuExplorer and the captured data could be routed to multiple applications at once, in realtime.

/Andrew

[calvinc]

its a great idea. can either use some command line parameters to tell it not to load gui or rewrite it into a specific project (dll), which might be better.

calvin.

[silverpike]

it will be input from an external sensor (anything really) via a serial port.

thinking of doing it like this:
- external inputs defined in registry (configurable through ecuExplorer)
- dll initialized on startup (sensorInitialize)
- dll loaded on startup (function call to sensorStart)
- dll closed on shutdown (function call to sensorStop)
- dll polled when in realtime data view (function call to sensorGetData)

maybe have initialization return poll time, etc. still thinking about it. any recommendations?

calvin.

My only concern is regarding the delays of the WB input vs. the ECU data.

This is a poorly addressed topic in auto tuning IMHO, but if the WB sampled values are off more than 1ms or so from the ECU data, correlating them is going to be a b!tch. Since they are both being sampled independantly of one another, they are subject to different processing delays. There is no way of knowing whether they are in sync by the time they arrive at the laptop.

I could just be paranoid though. It is possible that the sampling delays are small enough for all paths that any skew is irrelevant. However, I have yet to see any data on the subject, and thus my paranoia.

[silverpike]

What is the potential for a "realtime output" architecture? That is, being able to write a DLL That would take the captured/processed data from ecuExplorer and display it graphically, display it on top of a ROM, send it over the network, or display it on some sort of remote device (like a Palm, PocketPC, etc.)?
/Andrew

You could, but I suggest not getting ahead of ourselves. We don't have realtime map editing nor WB integration yet, and those are the foundation of effective tuning. Your ideas are nice, but that is icing on the cake (as I see it).

I'm very much looking forward to a DLL plugin interface. I have already written a partial driver to talk to the TechEdge for one of my own projects, and I'm eager to integrate it with ecuExplorer!

Wow, that is fantastic. I would love to see this code. I am also interested in working on this integration, and that would be a great starting point.

[Kha0S]

You could, but I suggest not getting ahead of ourselves. We don't have realtime map editing nor WB integration yet, and those are the foundation of effective tuning. Your ideas are nice, but that is icing on the cake (as I see it).

Actually, I've already written some proof of concept UDP streaming code that uses independent capture clients streaming to a single data aggregator program for display and logging. It's hugely useful, and allows us to offload the efforts of devloping digital dash interfaces, wideband, EGT, and ADC devices, and other input and output methods to the user base, instead of constantly requesting more features from Calvin and other logger developers.

ecuExplorer is a great datalogger, but I will never expect it to be a great digital dash, or a great telemetry transmitter. I'd rather write plugins to support those alternative output methods and have them plug right into Calvin's code.

I contend that we're not "getting ahead of ourselves" as "planning for expansion and scalability." Currently, anyone who wishes to develop a digital dash application for the SSM protocols is left to build a new/separate project, more or less in competition with systems like ecuExplorer. This is a waste of time and development effort in an open community. A good input/output plugin architecture in ecuExplorer gives us huge expansion opportunities while Calvin can concentrate on what he does best.

/Andrew