OBDII / Elm MPG meter. Almost working but not quite! - Page 4

god_of_cpu · 09-15-2004, 03:40 PM

If you want to use the trouble code functionality, I also compiled a list of trouble codes and put them into XML format. Your on your own with reading and parsing the format though as the plugin just returns the raw codes and no descriptions for them.

The XML files can be found here, there is both an example file that contains every valid property allowed in the XML file and another file that is all generic OBD II codes. The format allows for manufacturer specific codes too, but I have not collected these:
http://filebox.vt.edu/users/cholbroo...oublecodes.zip

god_of_cpu · 09-15-2004, 03:49 PM

I actually wrote most of the ELM plug-in a couple months ago and only played with running it for a couple hours, but it did work then. I will eventually be getting out to my car later this week and making sure it's still working good, but I have no reason to believe its broken, but I certainly can't rule out the possibility of major bugs yet. I do have quite a few assertions in the plugin so if it is a bug in the plugin, it will hopefully show you an error message rather then just not working.

The plugin currently only supports mode 1-4 (I actually have never tried doing stuff with mode 2 yet though). I'll look into adding mode 22 stuff, doesn't look too different from mode 1 from glancing at the web page.

god_of_cpu · 09-15-2004, 11:13 PM

Ok, I uploaded the updated dll, you'll need to update your .bas file with the new definitions. Check the main readme.txt in the root of the zip file for the changes.

stevieg · 09-16-2004, 03:08 AM

Quote: Originally Posted by god_of_cpu

Ok, I uploaded the updated dll, you'll need to update your .bas file with the new definitions. Check the main readme.txt in the root of the zip file for the changes.

OK Thanks will do..

god_of_cpu · 09-16-2004, 08:40 AM

I didn't have time to explain it last night, but I also added a Mode1_Pause and Mode1_IsPaused functions that are actually redundant to the Mode1_Start and Mode1_Stop functions, however, the Mode1_Pause function simply pauses the thread so you can modify the PID list and not incur the penalty of killing and recreating the thread with start and stop. The only time it is useful is when you need to change the PIDs your monitoring. i.e. if you offered an option to graph any PID value, when the user wanted to see a different PID you would simply pause, remove the current and add the new PID then unpause it.

This is now demonstrated in the OBDII Tester program included with the SDK.

stevieg · 09-16-2004, 09:00 AM

Does it export those conversion functions yet?

god_of_cpu · 09-16-2004, 10:23 AM

Quote: Originally Posted by stevieg

Does it export those conversion functions yet?

yes its been exporting them for a while you should be able to call any of them.

If you want a list of everything that a plugin exports, just look at the exports.def in the source directory of the plugin your interested in it lists all the functions that the dll exported.

god_of_cpu · 09-16-2004, 03:30 PM

For extended manufacturer specific codes I'm planning on adding two very low level functions. One will be for one shot data like the fuel level and have the following prototype:

Code:

BOOL API_OBDII_CustomQuery(LPCTSTR lpszOBDIIString, API_OBDII_PACKET& pkt);

lpszOBDIIString will be the properly formatted string that will be sent to the OBDII device. It will accept strings just like the elm device requires. i.e. "01 01" to request all the trouble codes. The function will wait till it recieves a response from the OBDII device before it returns. The pkt parameter will be filled with the returned packet data from the OBDII device.

The other will be for things that change and continously poll like your current gear and will work just like the Mode1 calls and use Start, Stop, and Add functions to set the PIDs / data you want to continously monitor. An add function with the following prototype will be added:

Code:

 BOOL API_OBDII_Mode1_AddCustomQuery(INT iId, LPCTSTR lpszOBDIIString);

The lpszOBDIIString will work just like the API_OBDII_CustomQuery call except it will add the string to the polling list to be continuously queried by the polling thread just like API_OBDII_Mode1_AddPID adds a Mode1 PID to the polling thread. All custom queries will be made after all PIDs added by the Mode1_AddPID call are quired. The polling thread will repeat in this way until stop is called. All data queried through customQuery calls will be stored by the iId parameter. You can get the latest returned packet associated with an id through a call to another new function

Code:

void Mode1_GetCustomPacket(INT iId, API_OBDII_PACKET &pkt);

This function will work just like the Mode1_GetPacket except rather the returning a packet based on a PID it will return the packet associated with the specified id.

You will also recieve messages to your window when new data arrives or if there was an error sending your custom query just like happens for the Mode1 PIDs.

Construction of the lpszOBDIIString parameter as well as processing of the returned custom packets will be left up to the calling application, however, some helper functions might be eventually added for extended code data.

I will probably change the name of all Mode1 functions to replace Mode1 with RTD which will stand for "real time data" as it is more accurate since the mode1 functions will now work with more then just mode 1 things. i.e. API_OBDII_Mode1_Start will become API_OBDII_RTD_Start

I haven't implemented any of this yet and all is preliminary information at this time and subject to change. If you have any comments / problems with what I described, feel free to speak up now.

god_of_cpu · 09-16-2004, 06:57 PM

Finally got around to testing the ELM plugin in the car again and it definitly had some bugs. The thread dies immediatly since I didn't inialize a varible and I was sending codes in decimal not hex. DOH!

I'm gonna test it some more and make sure it's solid before I post another version up. I'll probably have a fully debugged version up this weekend

stevieg · 09-17-2004, 02:03 AM

Quote: Originally Posted by god_of_cpu

Finally got around to testing the ELM plugin in the car again and it definitly had some bugs. The thread dies immediatly since I didn't inialize a varible and I was sending codes in decimal not hex. DOH!

I'm gonna test it some more and make sure it's solid before I post another version up. I'll probably have a fully debugged version up this weekend

OK thanks for testing it... I assume it's fine for me to use the Faker to develop with though.

god_of_cpu · 09-17-2004, 08:31 AM

If there are any changes to the interface as a result of bug fixes, they will be minor and the ELM plugin should work just like the faker. So you should be fine developing with the faker for now.

stevieg · 09-17-2004, 02:47 PM

Quote: Originally Posted by god_of_cpu

If there are any changes to the interface as a result of bug fixes, they will be minor and the ELM plugin should work just like the faker. So you should be fine developing with the faker for now.

Great

god_of_cpu · 09-20-2004, 12:34 AM

The SDKs been updated, I fixed most of the bugs, the ELM plugin should work now. Try it out with the tester program first. There is still a Major bug existing in the conversion function that converts the OBDII packets to values so your values will be off. There were changes to the interface that you'll have to update your .bas with. Most were renames and return value changes and additional functions. I'm going to sleep now, I'll explain more in the morning, for now see the readme.txt for updates.

stevieg · 09-20-2004, 03:29 AM

OK Thanks!

I'm hoping to have something working properly before the end of the week - There's a national car pc meet in the UK this weekend and I'd like to show it off!

god_of_cpu · 09-20-2004, 11:10 AM

Ok, to step up to the new version of the SDK you'll have to change a few things to your BAS file as follows:

Do a global search and replace and rename Mode1_ to RTD_ then rename API_OBDII_RTD_IsPIDSupported back to API_OBDII_Mode1_IsPIDSupported
Remove IsPaused and add API_OBDII_GetState
Add API_OBDII_CustomQuery, API_OBDII_RawQuery, API_OBDII_RTD_AddCustomQuery, and API_OBDII_RTD_GetCustomPacket functions
Most of the types and enumerations had additions and name changes you'll probably want to look at them all and copy them over if they changed.

I also updated all the helper functions so they would be easier to use in visual basic all the helper functions that query string data, now return integers that specify the length of the returned string. i.e. API_OBDII_GetPIDFormatName now returns an int.

I added a new member to the API_OBDII_MSGPACKET structure. It's called m_Flags and right now it is mainly used to see if the last packet read in had an error. If it did, this value will be set to eOBDFlagError. You'll want to use this if your just using a timer to get your packets so you can see if there was an error retrieving it from the OBD II device. Don't do an equality operator to check for an error, make sure you do m_Flags & eOBDFlagError since m_Flags can contain a combination of ORed flags.

There are 2 bugs that I know about, still existing Mode1_IsPIDSupported always returns true and I was calculating values in API_OBDII_GetValueForPacket using the wrong bytes. The data bytes for the values actually start at index 2. Index 0 always has the mode for the requested PID + 64 and Index 1 always has the PID that generated the packet. I also don't currently extract header information from the ELM device so all indexes in the m_Headers member will always be 0.

I will release another update today that should have only internal changes to fix these bugs.

The ELM plugin now logs everything to a file called debug.log when it has warnings or errors. Check this file first if the plugin fails to work, it should tell you why.