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

stevieg · 09-14-2004, 05:33 AM

I've got a number of functions from the API converted now, and it seems to be working very well in the Fake mode.

I've been testing the various PIDS and the first one I have come across a problem in is the MAF

When the function I've converted does it's work:

API_OBDII_GetValueForPacket = (0.01 * (pkt.m_Data(0) * 256 + pkt.m_Data(1)))

both parts equal the same thing - in the example above, pkt.m_Data(0) and pkt.m_Data(1) were equal to 205 in dubugging, and the calculation (Where API_OBDII_GetValueForPacket is long) overflows.

I'm now re-writing the application as a VB.NET console application, and certain things that didn't work earlier are starting to work in VB.NET, so I'll let you know how I get on.

Attached is the VB6 version that overflows, with the VB version of certain functions.

god_of_cpu · 09-14-2004, 08:41 AM

The overflow error is coming from pkt.m_Data(0) * 256 since m_Data(0) is a Byte it can only hold a number between 0 and 255. I'll have to go back and typecast all my code to ints

i.e.
In C++ the MAF function should have been
return 0.01f * (((int) pkt.m_Data[0])*256 + pkt.m_Data[1] );

You'll probably have to do something similar for your VB port, but I'm unsure of the syntax.

This is the code used in the faker plug-in to generate the real time values:
API_OBDII_CreateFakePacket(eOBDPID, 100, m_arMsgPackets[eOBDPID], FALSE);

It tries to covert a value of 100 into packet data for every PID set to be quieried. This means that in your code, if you are using the faker plug-in, your returned value from API_OBDII_GetValueForPacket should always be 100 regardless of which PID your querying for.

god_of_cpu · 09-14-2004, 08:49 AM

For the MAF PID, a value of 100 stored in the packet should result in data as follows:

m_Data(0) = 39
m_Data(1) = 16
m_iNumDataBytes = 2

If its not it probably indicates a problem on my end, I'll try and run your code later today and see if I can find out anything.

stevieg · 09-14-2004, 09:51 AM

Quote: Originally Posted by god_of_cpu

For the MAF PID, a value of 100 stored in the packet should result in data as follows:

m_Data(0) = 39
m_Data(1) = 16
m_iNumDataBytes = 2

If its not it probably indicates a problem on my end, I'll try and run your code later today and see if I can find out anything.

m_data(0 - 6) = 205
m_iNumdataBytes = 1
m_header(0 - 2) = 205
m_header(3) = 160

Something doesn't look right

I've just realised as well, that it's sending the same 205 value to the speed. It works fine in your demo application, it's just in the VB app I've made that's going wrong by the looks of it.

god_of_cpu · 09-14-2004, 10:36 AM

Thats interesing... The m_header member isn't even used in the plug-in other then to initialize it so it should always be 0. Maybe its the type declaration in VB?

Have you looked at the values for m_Data in the packet prior to calling API_OBDII_Mode1_GetPacket and seeing if they are actually changed by the function call to see if the 205s are getting set by the plug-in or just garbage values that are in your varible to begin with?

Also, this shouldn't make a difference, but try using this packet type and see if you get better results:

Code:

Type API_OBDII_MSGPACKET
    m_dwTimeRecieved As Long
    m_iNumDataBytes As Byte
    m_Header1 As Byte
    m_Header2 As Byte
    m_Header3 As Byte
    m_Data1 As Byte
    m_Data2 As Byte
    m_Data3 As Byte
    m_Data4 As Byte
    m_Data5 As Byte
    m_Data6 As Byte
    m_Data7 As Byte
End Type

stevieg · 09-14-2004, 10:54 AM

OK will try that.

A question about the conversion functions - do I actually need to convert them in the VB module? Just opened up the C++ solution in .NET and saw that the conversion functions are there (ie API_OBDII_GetPIDName etc)

god_of_cpu · 09-14-2004, 11:05 AM

I am exporting the functions in both plug-ins so yes you can call them from VB if you add declarations for them. This won't be an official part of the plug-in format though so they may not be available in future plug-ins for different hardware, but they will always be available for the ELM plugin and the faker plug-in.

stevieg · 09-14-2004, 11:12 AM

OK just had a look at the VB6 one - before it calls

API_OBDII_Mode1_GetPacket m_lpUser, eOBDPIDVehicleSpeed, lpMsgPacket

for the first time, everything set in pkt is set to 0 so at some point things are changing to 205. After changing the types as suggested so their not an array anymore, m_data1 becomes 160, with 2-7 becoming 205

god_of_cpu · 09-14-2004, 05:52 PM

Ok, I installed VB6 and got your code working.

The first change is that apparently VB declares arrays so you specify just the upper bound not the number of elements in the array as I thought. This means the API_OPDII_MSGPACKET type was incorrect it should be:

Code:

Type API_OBDII_MSGPACKET
    m_dwTimeRecieved As Long
    m_iNumDataBytes As Byte
    m_Header(0 To API_OBDII_NUMHEADERBYTES - 1) As Byte
    m_Data(0 To API_OBDII_NUMDATABYTES - 1) As Byte
End Type

The reason why there was 205 all over the place was because the data array was never initialized. API_OBDII_Mode1_ResetData m_lpUser should be called before calling any AddOBDPID calls. The reason why you weren't getting good values in the m_Data varibles that were filled during the GetPacket call was because the type was incorrect.

You also need to call GetPacket for every OBD packet you need to retrieve
i.e.

Code:

API_OBDII_Mode1_GetPacket m_lpUser, eOBDPIDTimingAdvance, lpMsgPacket

The last thing I found was that you declared the strings as follows:

Code:

Dim szPlugInName, szPluginComment, szVersion As String

Since you didn't specify a type for PluginName and comment it made them variants. You need to explicitly specify the type after every vaible like so:

Code:

Dim szPlugInName As String
Dim szPluginComment As String
Dim szVersion As String

You should be able to retrive the name and comment with that now.

I have attached the updated VB code.

stevieg · 09-14-2004, 05:54 PM

Aha...

I think I said "Doh" more than once there...

Thanks very much.. I will give that a go!

stevieg · 09-15-2004, 06:00 AM

Well, all seems to be fine when using the faker dll... Added the MPG code and appeared to work well.

Went into the car and problems started.

Using the configuration dialogue, it was not able to enumerate the COM ports. However on my dev PC I can enumerate the Com ports.

This is the error message:

god_of_cpu · 09-15-2004, 08:55 AM

That error is coming from your COM port being 0, it raises an assertion error in the debug build of it only. In the release version, which I haven't compiled yet, it will simply return FALSE and not show the assertion message box.

But as you mentioned, the real problem is with the port enumeration function. I enumerate the ports using the Enum ports API call and check to see if the port name looks something like COMx: where x is a number. Apparently not all com port names look like this. I will compile another version that will output all the names of the ports to a log file when it enumerates them. After I post that version If you could tell me what the contents of that log file are after you run the configuration dialog, I could figure out why its not working on it.

Code:

// Find out how much space is needed for pInfo
	EnumPorts(NULL, 2, (LPBYTE)pInfo, 0, &dwNeeded, &dwReturned);
	pInfo = (PPORT_INFO_2)new BYTE[dwNeeded];

	EnumPorts (NULL, 2, (LPBYTE)pInfo, dwNeeded, &dwNeeded, &dwReturned);

	iPortCount=0 ;

	for (iCount = 0; iCount<dwReturned; ++iCount)
	{
		CString strPortName = (pInfo+iCount)->pPortName;
		
		//Port names will look like COMx:
		if (strPortName.GetLength() >= 5)
		{
			if (strPortName.Left(3) == "COM" && strPortName.Right(1) == ":")
			{	
				//Get the COM port number
				INT iPort = atoi(strPortName.Right(strPortName.GetLength() - 3));
				if (iPort > 0)
				{			
					
					INT iIndex = m_cmbPort.AddString(strPortName);
					m_cmbPort.SetItemData(iIndex, iPort);

					if (iPort == m_iPort)
						m_cmbPort.SetCurSel(iIndex);
				}
			}

			++iPortCount;
		}
	}

In the mean time, to get the DLL to work you can simply call the connect function and specify the correct port number in the connect call, it will ignore the value found by the configuration dialog. In fact, the configuration dialog is completely optional so you don't even need to call it. Whatever COM port your connected to will be automatically saved to the registry when you release or disconnect the plugin and will be used next time you try to connect if you specify a 0 for the COM port.

i.e. API_OBDII_Connect m_lpUser, 1 would connect to port 1

stevieg · 09-15-2004, 09:13 AM

OK I will give it a go by specifying the COM port on the connect function.

I did try that this morning, but couldn't be sure - as sitting in a traffic jam using a touchscreen isn't the best place to edit VB code.

god_of_cpu · 09-15-2004, 01:16 PM

With the next update I'll post later today, I will also be adding a lot more functionaltity to the plugins. The faker plugin will now read values from a file and use them as the data values it generates rather then just random values. It will set a value of 10 if theres no data in the file. The format of the file it reads would just be comma delimited lines with the Pid as the first item on it followed by the values it should spit out. i.e. for speed from 0 to 60 it would be

Code:

13, 0, 1, 4, 10, 25, 40, 39, 50, 60

The values are generated every 300 milliseconds just like the ELM device normally does. values will repeat once it gets to the end of loaded values.

In conjunction with this, the debug build of the ELM plugin will automatically log all values its set to capture to a new log file named after the current time.

The interface for the plugin also changed slightly, I added a msg id parameter to the create function. This id will be sent to the handle to the window you specify for the hWnd parameter of the create function whenever events occur. Events are now generated every time a new value for a PID is recieved or whenever errors occur in the reading thread. i.e. whenever a packet is read from the COM port this line is called:

Code:

//Send a message to the registered window that a new message was recieved
			if (m_hWnd)
				PostMessage(m_hWnd, m_nMsgId, eOBDMsgRecievedValue, eOBDPID);

You'll just need to watch for the message id you used in the create call in your windows message loop (In VB I think you'll need the msghook control for this though). Reading the values in a timer will still work just the same too if you don't want to do it event driven.

Also besides MPG, are there any other things your planning on doing with the plugin? Like horsepower! I wanted to add MPG and horsepower to my own app, but between writing the dlls and the other stuff, I've just never had the time to figure out the equations.

Also if you have any other requests for functionality in the plugin format, I plan on freezing the interface format for this API version after the end of this weekend, so no more interface changes will happen after that without changing the API version number.

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

Quote: Originally Posted by god_of_cpu

With the next update I'll post later today, I will also be adding a lot more functionaltity to the plugins. The faker plugin will now read values from a file and use them as the data values it generates rather then just random values.Also besides MPG, are there any other things your planning on doing with the plugin? Like horsepower! I wanted to add MPG and horsepower to my own app, but between writing the dlls and the other stuff, I've just never had the time to figure out the equations.

Reading from a file will be great - That's the only way I got as far as I did with making sure the MPG equation was correct, even though I still haven't got it working on the road

The events sounds great to me - pretty much perfect the DLL.

Quote: Originally Posted by god_of_cpu

Also if you have any other requests for functionality in the plugin format, I plan on freezing the interface format for this API version after the end of this weekend, so no more interface changes will happen after that without changing the API version number.

The only other functionality I'm interested in is the ability to get so-called 'Mode 22' codes that are model-specific (I think I need this to get the fuel level and gear etc) - more information here: http://www.scantool.net/forum/index....y;threadid=580

I only just about understand the mode 1 codes (I've had the elm only a couple of weeks) so have no idea if I can use your plugin to get the rest.

I too will be looking to get the horsepower equation - Along with starting a database of car weights etc to make it easier for people to get it working. Once I've got the MPG meter part working my initial aim is to write a VB MediaCar app that displays various gauges in it's embedded window with MPG or other value in the always-on-top window at the top of mediacar.

Can I ask a question, as I still haven't got it working in my car - does the ELM version work in yours perfectly? I'm asking so I know for sure that there's something wrong at my end.

Cheers,

Steve