Software On ELM Street - OBD2 Software Development

[Tazzi]

Hopefully the next elm pops up soon. Getting restless not being able to attack the tech2.

Almost lost track what I need to update/check/change on the obd2 app now. Ahh.. Think it was the 115200 baud enable, the VIN function for CAN vehicles and also chuck out a test run for the engine data and faults logging.

If theres something else im missing let me know.

[VX L67 Getrag]

Trying to get it to work in XP?

[Tazzi]

Trying to get it to work in XP?

Will do, ill chuck it through a few virtual machines.

[Tazzi]

Second elm just rocked up.. let the games being.

[Witte]

Hi all,
36 pages, well it's really a lot, I fast scanned through it but I'm not sure if that was a good idea as I'm now with a lot of question instead. It seems this forum has gathered quite some knowledge through the years, great!

I can share the same ideas with you guys, some of the software you get with the ELM327 is just prehistorical. I don't want to offend anyone but that's the idea I have. The ELM327 is great to get to know OBD but you can also see that there are some mayor drawbacks. For real time data monitoring it is not fast enough (but what is?) and a lot of clones (of which some are really bad) make it not easy to support everyone out there. And there is off course the thing that this is a sort of niche market, I don't belief they're selling like a huge amounts of these units anyway. But compared to some other solution of OBD hacking (Arduino shields, Raspberry Pi shields) I find the ELM327 the best one to get me on the move without have to implement both desktop software and micro-controller firmware.

So, as far as progress goes, congratz so far, I found it actually funny to notice that I've started developing for ELM327 almost in the same period I don't have a lot of free time to work on it though, and sure reading through such long threads doesn't help much either. So for now I've only just implemented some basic command line functionality which allows to send some of the well know PIDs and allow the replies to be translated into human readable stuff. A GUI is implemented but its not showing anything useful at this moment. Unfortunately I'm developing on Linux using Java so in terms of code sharing we probable won't have a lot to share, but once I get my software to a decent level I hope to be able to report back some of my findings.

For now I can tell you that the running the AT01 command replies "OBDII to RS232 Interpreter", and requesting the version doesn't do anything. As for testing goes, I must always plug in the OBD tool in the car as otherwise it will not reply, not even on AT commans. I have no clue why firmware developers ever decided to do that, because it does pop up as a serial device under linux /dev directory...

Happy coding

[Tazzi]

Hi all,
36 pages, well it's really a lot, I fast scanned through it but I'm not sure if that was a good idea as I'm now with a lot of question instead. It seems this forum has gathered quite some knowledge through the years, great!

I can share the same ideas with you guys, some of the software you get with the ELM327 is just prehistorical. I don't want to offend anyone but that's the idea I have. The ELM327 is great to get to know OBD but you can also see that there are some mayor drawbacks. For real time data monitoring it is not fast enough (but what is?) and a lot of clones (of which some are really bad) make it not easy to support everyone out there. And there is off course the thing that this is a sort of niche market, I don't belief they're selling like a huge amounts of these units anyway. But compared to some other solution of OBD hacking (Arduino shields, Raspberry Pi shields) I find the ELM327 the best one to get me on the move without have to implement both desktop software and micro-controller firmware.

So, as far as progress goes, congratz so far, I found it actually funny to notice that I've started developing for ELM327 almost in the same period I don't have a lot of free time to work on it though, and sure reading through such long threads doesn't help much either. So for now I've only just implemented some basic command line functionality which allows to send some of the well know PIDs and allow the replies to be translated into human readable stuff. A GUI is implemented but its not showing anything useful at this moment. Unfortunately I'm developing on Linux using Java so in terms of code sharing we probable won't have a lot to share, but once I get my software to a decent level I hope to be able to report back some of my findings.

For now I can tell you that the running the AT01 command replies "OBDII to RS232 Interpreter", and requesting the version doesn't do anything. As for testing goes, I must always plug in the OBD tool in the car as otherwise it will not reply, not even on AT commans. I have no clue why firmware developers ever decided to do that, because it does pop up as a serial device under linux /dev directory...

Happy coding

Good to see others are working on similar things! Am happy to help work on anything or throw ideas around, just let me know!.
Progress has completely haulted, been a hectic few weeks with chrissy, and new years. Hopefully start playing around a bit more soon.

For anyone interested, a very good piece of software is "TouchScan", has worked on every OBD2 compliant car that Iv touched now! Including an i30 an Mercedes-bens. The app also has a "raw data" monitor. Will only provide generic fault codes but its enough to have an idea of whats going on.

[Tazzi]

Sooo I may or may not have gone ELM crazy... and now have 5 ELM327 cables hooked up to the Tech2.

I should be apply to happily dedicate one elm to Monitoring traffic and the other 4 can be triggered off when a reply is required. Shouldnt be a matter of if the cables can keep up now.

At the moment, Im having the thrilling task of completely re-writing the pcm mimicing app to continue reverse engineering those responses. At the moment Im looking into dedicating each cable to reply back to one single message from the tech2, that way I can have the headers all setup prior to sending the frames.

Im just gonna ramble a bit here to get ideas/issues out..) back to our original problem, a pcm sends alot of information with different headers to the tech2.. first off we have to setup the dynamic PIDs.. my main issues originally was the time wait between the elm switching from listening mode to then setting up the header and finally firing off frames, this is now completely resolved with the dedicated monitoring elm... and my preliminary testing shows that it takes about <10ms to change headers which isnt an issue. Next is then sending off the pid requests back to the tech2.. should be able to utilise 1-2 frames per elm comfortably...I think, And hopefully the tech2 accepts the responses this time.

If anyone else has a better idea let me know!

[Jayme]

yes use an avt.... its well fast enough and you can send it straight hex

then again 5 elm cables is still cheaper than one avt lol

[durahax]

Jayme you have 1337 posts The AVT is awesome, having a lot of fun with it. STN1100 is not bad because it can Tx around 1,364 bytes (from my testing, sometimes it allows a few more or less). It supports AT and ST command set, but it kinda blows for monitoring J1850 VPW. The ELM was actually more accurate when using ATMA than the STN1100. About to order my second AVT, this time a AVT-841 and I have some bluetooth chips waiting to try. Gonna try getting it to work with Android, I'm sure Windows/OSX will be easy enough. I want to monitor PIDs at 4x speed, on a Android. If that goes well I'm going to attempt a Android app to dump the PCM. Tazzi I'm down to help work on something, are you going open source with your project?

[antus]

if you can create something that logs vpw/can on android via avt that will be a world of win. ive tested aldldroid and that works well. will be funny strapping a tiny phone to a massive avt box, though