NeonDev

@bugbyte that is absolutely the way to go IMO. if people want to start a new FE just because no current FEs provide a certain feature nothing will ever come about but a collection of FEs with many different features but none that have even close to everything.

since the majority of FEs have plugin capability and are all OS X based there is little stopping somebody from writing the code that does all the work and "porting" it to all the different FEs. obviously there are likely some exceptions but I'll wager an OBD2 or GPS module could be ported fairly seamlessly across the board. If i end up being the one who writes it driven by donations then I have no problem with the code ending up in any of the other FEs at all.

just somebody needs to get the ball rolling. right now I am swamped at work and I am obligated to finish the XM module before moving on to the next thing.

@hanzov
I will gladly take up the offer if it still stands after I finish the XM module. I feel more comfortable taking the initiative on OBD2 then navigation since I have no idea where to even start with navigation.

couple of questions. how does the scantool interface with the mac? what drivers are needed to communicate with it? do you have or know where I can find good documentation on OBD2 communication?

If you end up sending it to me and I can't do anything with it I will send it back

__________________
check us out at: www.neonboombox.com

hanzov69

@NeonDev/BugByte

Well said both. This is exactly my frustration, picking through the forum is a virtual graveyard of fancy interfaces, interesting ideas, and a lot of vapor and abandoned code.

Hence my push for OSS/GPL type plugins/modules.



Of course. Let me know when you are ready to take it on, and I purchase it.


I don't specifically know what the USB/RS-232 cable offered by Scantool.net is based on. When I bought my elmscan/5, I opted for the straight bluetooth version.

However, connecting it to my mac was fairly painless, I used a USB/RS-232 adapter I had laying around (actually, I have several) based on the Prolific PL-2302 chipset, which is exceptionally well supported. I've been able to source these cables locally for about $10 USD.



Just the ones available at that link


That's a bit trickier. Reading off ODB-II is pretty straightforward, as I understand. (Warning: I may not be 100% correct with what I am about to say...don't hold it against me)
I found some pretty basic information on working specifically with the ElmScan here. As you can see, it's not terribly complicated to work with.

As for dealing with the data itself, it looks like the I/O is based around simple request/response, EG request a PID for a value you would like (Vehicle Speed), it returns an integer in a pre-determined range, which would then need to be parsed and applied to the GUI graph/control.

I believe this list on Wikipedia is quite comprehensive, and presumably accurate.

There are a number of quick-n-dirty OBD-II scripts that will do request/parse data, pyOBD might be worth looking at as well. It doesn't really tell you much info, it's more for sorting out the cause of MIL code, and it's also fairly old.


While I am confident this will be "low hanging fruit" for you, in the event that it proves to be a stumper, I would rather see it "paid forward" to another dev with the chops to take on the challenge

hanzov69

Guess I should look before I speak.

The cable available from Scantool.net is based on the Prolific PL-2303 chip, which has Mac drivers, so in the best laid plans it should be largely the same as the PL-2302

NeonDev

hey as long as there is an intel mac driver that can send and receive data I see no reason why I won't be able to do something for the community. wish I could start now ;-)

__________________
check us out at: www.neonboombox.com