openecu.org

I finaly got around to order a cable and want to get some logs from my car.
My car is a Subaru forester s-turbo -99 with a JECS ECU.
I can install windows on my laptop, but prefer not to go into extreme wrestling with that
So what options do I have?
What programs is crossplatform (java) and what can run thru wine?

oh, well, seems like Im the only one,..

I haven't finished the new version of EcuFlash yet, but it is written with Qt libraries, so porting to linux shouldn't be that difficult. You might consider setting up a dual boot laptop for the near future...

Colby

Jepp, ..install Windows and dual boot..
But, I will try wine and check USB support in Vmware

Its very cool that you are using Qt!
I have not tested my cable or any software yet, but will do that in the coming days.

Bump. I would much prefer a Linux data logger too.

HaHa... Free OS users using a Free software package for their cars... I didn't see that one comming...

In my experience, given enough time, free and open source code is always better, more powerful, more stable, and more efficient in general. I've noticed this strongly in operating systems and the applications that run in them. Soon I'll add engine management to that list.

Seriously though, is there any roadmap to a potential SDK for other developers to jump in on Linux, like me.

Yes, there is. After the coding is stabilized a bit, I will release the source to EcuFlash, which should be compilable to linux, as it uses Qt. Later down the road, I should be able to add logging as well.

fuzzydude wrote:Seriously though, is there any roadmap to a potential SDK for other developers to jump in on Linux, like me.

The first thing I need working under Linux is a logger.
My laptops run Linux, and my planned 'carputer' will run Linux.

I really hope a Linux logger will show up soon, if not, I will make something that suits my needs
I just have to finish off some other projects first..

So, how should a logger work?
As a diagnostic tool? (I just had a faulty MAF, the ECU seemed to have learned around it)
Does spamming the ECU with queries have any side effects?
Split logger in two: User interface(s) and a daemon?

I definitely want to add logging functionality to EcuFlash down the road. Some ideas I have are:

* Logging sources for different devices (ECU, WB02, dyno, GPS, accel) live in seperate modules which communicate via some platform independent method like sockets, SOAP, etc.

* A logging engine aggregates these sources, and supports various types of data acquisition from each source, including:
+ polled sampling
+ async "push" data with timestamps
+ sync "push" data with known intervals

* The engine can do per source latency correction, sample rate conversion, interpolation, extrapolation, buffering, etc.

* Other components (such as EcuFlash) can connect to the logging engine to control it and display or write to file the homogenized streams of data it produces.

Hi,

This last weekend I used pyOBD (http://www.cs.unm.edu/~donour/cars/pyobd/) a python ODBII toolkit/interface for ELM 32x devices to build a simple logging program and get data from my 1997 Subaru into a Thinkpad (debian 2.6.15) via USB. FWIW, I could not get the wx-based GUI for pyObd to run. The code is well commented and it was quite simple to use the classes that handle the actual interface to the OBD.

In my CST, I am writing an OSS cross-platform OBD logger in smalltalk (Squeak) to manage data and present analysis. It will do graphs and real time views, but I am mostly interested in applying machine and statistical learning techniques to automate log analysis and build models of normal/abnormal operation.

nyc97obw wrote:This last weekend I used pyOBD .. .. to build a simple logging program
and get data from my 1997 Subaru .

Does youre car have a standard ODBII port?

nyc97obw wrote: FWIW, I could not get the wx-based GUI for pyObd to run. The code is well commented and it was quite simple to use the classes that handle the actual interface to the OBD.

I have briefly looked at pyObd, but have not yet found time to look more into it :/
PyOdb is a bit dated and the wx stuff probably depend on an old version ..

nyc97obw wrote:In my CST, I am writing an OSS cross-platform OBD logger in smalltalk (Squeak) to manage data and present analysis. It will do graphs and real time views, but I am mostly interested in applying machine and statistical learning techniques to automate log analysis and build models of normal/abnormal operation.

Just what me and my old car need
I be first in line to test it out

Hi,

My 97 Outback has a standard OBDII port.

I'm not sure what you mean by 'dated'. The pyObd code is a couple of years old and there is a problem (probably in the pySerial module) with the serial port becoming blocked every now and then, forcing one to close and then reopen the port. I ran into this problem trying to intercept the datastream while doing a port forward to a tcpip socket. That said, the ECU is not a complicated device for OBD interfaces and pyOBD works fine for data acquisition. It is slow, though, and I'll try to optimize the data acqusition rate.

OTOH, pyObd does no downstream processing and analysis and there are (I gather) data logging programs that provide data managment, graphing and so on. So in that sense, pyObd is primitive. Still, with just a bit of programming experience, one can appropriate/extend the interface code and get any data the ECU is willing to give up via the OBDII interface. I am new to this domain, so pyObd and ELM has been a nice learning playground.

For my project, I am interested in getting access to real-world data logs that have been annotated by users in some way. The details are still unclear, but one idea is to ask for logs from 'routine' runs - e.g. cases where a person commutes on the same route - with comments about the car performance ('normal/abnormal'). Unfortunately, people who can/will data log are anal about their cars, so I expect few cases of abnormal performance (low mpg, hesitation, etc.). Not good for machine learning. Perhaps people can agree to convince non-anal friends with similar cars to log some data ..,

Bye for now,

Interesting. You see, I actually wrote pyOBD.

While old, the wxPython code should still work as 2.6 is supports the 2.4 API. However, when I wrote that code I didn't properly understand how wx events happen so sometimes the gui doesn't ... um... work. To make matters worse, the developement target was a very old Mac laptop which has terrible thread performance (really really bad), so I found that it really wasn't worth it to worry about races as everything executed so slowly. Whatever, I was lazy.

But that wasn't the point the project. I just wanted to have a nice OBD-II library that I could script around and I think it works well for that. I've been meaning to dig it up because I'm working on getting OBD-II support for the openport cable.

Before anybody gets too excited, remember that pyOBD speaks to Elm323 devices, not native OBD.

d