@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.
Quote: Originally Posted by
NeonDev 
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.
Of course. Let me know when you are ready to take it on, and I purchase it.
Quote: Originally Posted by
NeonDev 
couple of questions. how does the scantool interface with the mac?
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.
Quote: Originally Posted by
NeonDev 
what drivers are needed to communicate with it?
Just the ones available at that link
Quote: Originally Posted by
NeonDev 
do you have or know where I can find good documentation on OBD2 communication?
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.
Quote: Originally Posted by
NeonDev 
If you end up sending it to me and I can't do anything with it I will send it back
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