Anyone know where I can find the means to use my empeg to do datalogging on my OBDII 1998 Mitsubishi Eclipse?

The first problem with logging on the empeg is that you have to have somewhere to write the log, at least in order for it to be useful. There's not really any writable storage on the empeg while in the car.

Of course, that's not to say that something couldn't be implemented, but that's the first big problem, and no one's tackled it yet.

There have been *many* threads talking about interfacing OBD-2 to the empeg, and so far, *NO* completed projects. Just a lot of talk.

It's one of those projects where there are two groups of people: 1) Those who want the feature, but don't have the technical ability to implement it, and 2) Those who have the technical ability to implement it, but couldn't care less about the feature.

For a project to get done on the empeg, we need those two sets to intersect somehow.

Oh, and for those who might be interested, there's a lot of useful stuff at http://freediag.sourceforge.net/, some of it links to external sites. Also http://www.obd-2.com/.

Well, I'd be willing to do it, there's a small ODBII -> RS232 converter bot out there.
Problem is, the Empeg's running out of serial ports. I'm not finished with my VFD project yet, and may take this on, but it'll be a ways off. Unlike some people here on the board, I ain't the fastest.

Me.

obd-2.com sent me this email reply in reponse to my questions:
Q: Do you have any info that would help me be able to do datalogging with my EMPEG / Rio Car on my OBDII 1998 Mitsubishi Eclipse?

Re: Will use ISO protocol, do have a smart client chip system, that simplfies message format, would then need a coverter device for input to the Rio.
www.obd-2.com/chip.htm

The above link shows some kind of simple DOS program that utilizes their product. Any input on how you might impliment it into the Empeg via the Serial Port?

Theres no source code for the DOS program, so no, theres not much that can be done based on that. Someone would have to write a program to do it. It does give the communications protocol, so thats a plus. You do realize that these chips only sample @ 1 or 2 times per second, right? If its going faster than that then its "overclocking" your cars computer. Even if someone wrote a program to read the data off this board, like someone else said, that data can't be logged.

There was an article on the subject discussing OBD-2 specs in number 9/2002 of the swedish magazine "Allt on Elekronik" and a project for building a OBD-2 adapter -> RS232 in number 10/11 the same year.
If there is an interest in that I can look up the references for the article and some more info.

// Jonathan

"Allt om elektronik" is the same as the english magazine "Elektor Electronics" and the same articles appeared in october and november 2002, in case anyone has them...

Stig

The hardware in the project mainly consists of a preprogrammed microcontroller, ELM323, from Elm Electronics of Canada.

That one is suited for the majority of cars made in Europe and Asia (using the 10.4kHz ISO 9141 protocol). Most US manufactured cars use the VPW or PWM protocols. Elm has chips for those protocols also.

The software is opensource (though only 1.04 is available for download, while the binary downloads are 1.06) and available at www.scantool.net. They also have full kits as well as bits and pieces.

/Michael

I'd do something with OBDII but I don't have a car with the requisite port, yet...

OBD-II is something I've been thinking about for a while. I've not done anything about it, but eventually I'd like to. From all the threads discussing it so far, there's a number of obstacles that need to be overcome:

1) Only one serial port and many people want GPS, OBD-II, remote display, etc
2) Software to interpret the data
3) Disk space to log to.

Here's the approaches I've been considering:

1) I've been keeping my eye out (as opposed to actively searching) for a terminal server that we could use with the empeg. The problem is that most give binary drivers for major unix distros, not linux-arm, nor do they give source code to their drivers. In another thread, there was talk about a termserv that you could program in java (IIRC, it was called TINI). I don't have the skills to program drivers for it and finding someone with the skills, time and motivation hasn't happened yet.

2) Start with some of the OSS linked in this thread

3) The best approach I can think of is to re-partition your drive (1G should be overkill) and make the new partition ext3 so it can be more safely mounted read-write in the car.

If you're not using the serial port yet, there's enough pieces available to start putting the puzzle together. How much useful data you'll be able to extract is still in question though.

I thought the rocketport drivers are provided in source. I remember picking one apart for some constants a while back.

The Dallas Semi TINI module is programmed in Java but it's not actually a terminal server. Not unless you want to make it one anyway. It's a very small embedded board with a JVM. Can't remember how many serial ports it has by default but it's got an ethernet interface as well. The main problem is that they're quite expensive and have a huge lead time.

- Trevor

I found the RocketPort which says it supports Linux, but it only lists ISA and PCI interfaces, not ethernet.

Then there's the SerialHub which uses ethernet, but only works on WindowsNT.

And there's the SerialHub Si which is described similar to the regular serialhub, and says:

Designed for Intel-based computers...

...once the RocketPort Serial Hub Si is installed, the ports appear as standard (native) Windows COM ports, accessible by any application.

It does list Linux under supported operating systems, but in the context of the page, it almost seems like a typo. Do they have drivers for Linux, or can you just telnet to the termserv from a linux box and have it connect you to a serial port?

How a network device is designed for Intel computers is beyond me. But the specific mention of both Intel and Windows doesn't give me much hope that it will work with the empeg.

Ok, more info...

There's a Sourceforge project that has Linux drivers, but they're for the ISA and PCI cards (the ones that are supposed to already come with Linux drivers). So if people had to write their own Linux drivers for the ones that already supported Linux, I'm even less hopeful about the networked ones.

I just found the price for the 2 port Serial Hub Si: $635.
Or there's the Serial Hub ia2 which costs $679.

Both of those are way out of my price range for a 2-port term serv!

It does list Linux under supported operating systems, but in the context of the page, it almost seems like a typo. Do they have drivers for Linux, or can you just telnet to the termserv from a linux box and have it connect you to a serial port?

Looks like they do have drivers for Linux...

/Michael

And just after I posted, I found that too

That means it's no longer a technical problem, just a financial one

I don't know anything about lead times, but the TINI isn't expensive compared to the rocketport stuff.

The 512k versions are $50 qty. 1, and all you need is a 72pin Dimm socket. Details here, but in short there's 10Base-T and 2 serial ports, one with RS232 levels, one TTL. It also has a CAN interface, which may be handy for automotive applications, and a 1-wire interface if you want more sensors.

I'm no Java programmer, but from a hardware standpoint this seems nearly ideal, to be able to connect a bunch of IO to the ethernet port of the empeg.

I could see a board with a ELM32x OBD-II interface and a GPS module, with connectors for the 1-wire and CAN interfaces, all in a package about the size of a tuner (longer and narrower).

This would cover everything I can think of attaching to the empeg, and still leave the sled serial port open for the things I haven't though of.

$50 is quite reasonable. I'd buy one, but the problem is that it won't work out of the box. Someone's gotta write the Java code for it (probably not too bad, but still beyond me) and a matching device driver for the empeg.

As I noted above: I don't have the skills to program drivers for it and finding someone with the skills, time and motivation hasn't happened yet.

The approach I'm going to look at now is this one and I see you've found that thread too. A bit less exandable and may not work for everyone, but it's cheaper and (I think) I know how to do it.

Well, I have the motivation (now that I've started playing with GPSapp), and the hardware skills. I don't have the software skills to get it running on the TINI (though there's some sample code that looks promising, I've just never written a line of Java in my life).

On the empeg side, the usual m.o for terminal servers is just to use telnet, and I'm sure I can find code on the linux side to make a telnet session look like a serial port, or modify gpsapp to telnet to a commserver port. (Same with freediag)

Besides, this thing just looks too cool. I'll probably order one and start trying to make this stuff work.

In the meantime, am I inferring correctly that you're working getting OBDII running using the tuner serial port? Let me know if I can help in any way.

On the empeg side, the usual m.o for terminal servers is just to use telnet, and I'm sure I can find code on the linux side to make a telnet session look like a serial port, or modify gpsapp to telnet to a commserver port. (Same with freediag)

If you can get that to work, that'd be sweet! That's the solution I'd like to use.

In the meantime, am I inferring correctly that you're working getting OBDII running using the tuner serial port? Let me know if I can help in any way.

I don't know much about component electronics (I wish I did). The thread talking about the serial port on the tuner seemed to allude to needing to add some stuff (resistors?) and that's where I'd need some help.

Since I currently have neither a GPS, nor an OBD-II interface, I've not looked into it very deeply. What I will probably start with is OBD via the standard serial port. If you get the TINI working, then I'd get one of those and a GPS.

On the empeg side, the usual m.o for terminal servers is just to use telnet, and I'm sure I can find code on the linux side to make a telnet session look like a serial port, or modify gpsapp to telnet to a commserver port. (Same with freediag)

What does telnet look like "on the wire"? Are there control characters and such that need to be handled as part of the protocol or is it as simple as just listening on a port and passing the I/O onto another program? I have a TINI board around here somewhere and the java code to bind to a port and pass the I/O to a serial port would be pretty trivial for me to write...

-Mike

Telnet has a few special out-of-band signals. They are all preceded by 0xFF, and most consist of only one more byte (RFC764). There are some others, though.

A better summary, as it turns out, is here.

What does telnet look like "on the wire"?

Pretty close to raw characters in IP packets. There's a little more to it, described in RFC's 854 and 855.

There's also RFC 2217, which describes how to use the telnet protocol itself to do things like line rate and hardware setup for just this application. And finally, I found this post to the TINI mailing list with just the code I'm looking for. Though ultimately I'd like to extend it to both ports and the 1-wire interfaces, it's a good starting point.

So now I need to get the hardware and start hacking.

Nice to know there's someone with some TINI experience out there, though.

-Z

or modify gpsapp to telnet to a commserver port.

*cough*gpsd*cough*

*cough*gpsd*cough*

Too right. And, of course, it would only make sense to run gpsd on the TINI itself.

I was actually thinking that I'd want one of these at home to use as an NTP server, so porting ntpd should eventually happen.

OK, time to get off my butt and order some parts.

Nice to know there's someone with some TINI experience out there, though

Well, I am sure there is but it isn't me I ordered one for the geek factor, but I have never even gotten around to loading slush (the mini command interpreter) on mine yet and I have had it for at least a year. But, I do have one and a decent amount of java programming experience if you need any assistance.

-Mike

Anything new on this thread? I got an obd2-RS232 converter and would just need the software for the empeg...

I wouldn't even want to log anything, just visualize some data whenever I want/need to.

Also, check out this old thread:
http://empeg.comms.net/php/showflat.php?Cat=&Board=prodject&Number=140168&page=0&view=&sb=&o=&fpart=all&vc=1&PHPSESSID=

It's been 10 months now and the download page has the source for 1.06. I don't know what's new and haven't looked at the code.

Looks like the ElmScan might be a good cable/adaptor. Anyone used this with the empeg?

links I have found in the last 2 days:

1 Short discription of Class 2 network
2 Multiplex Engineering, serial to J1850. ~$85 interface. No software.
3 Card Labs, some J1850 related specs available here.
4 Adv. Vehicle Tech. listing of J1850 devices. Chips listed here. Complete products are very expensive $800-1500
5 ScanTool.net $85 serial to J1850 interface
6 ScanTool.net Free software & source code.
7 more links to specs and data sheets.

Serious prices, but snoops everything.
8 Vehicle Spy software. $1995
9 NeoVI vehicle interface for above. $1995

10 Freediag on sourceforge.

Hypertech power programmer for 97 Wrangler ODB ][

I'm thinking about springing for the scantool device and starting from there,

check this out:

99 dollar graphing log device for ODB ][

interesting.. reverse engineer this puppy