OBDX Development - Developer Tools and Suggestions

[hjtrbo]

If you need to buy some liquid to settle down that wizard brain of yours over Easter then I'm happy to provide the means. I'd love to get this piece of shit back together lol.

[Tazzi]

Well.. Iv got it sending messages to the scantool.. to the ECU.. ecu responds and then it tries to send the response back to T2win.. but.. appears tech2win then crashes.. so... we are close.. just not quite there,

[Tazzi]

We are no longer crashing.. but t2win does not seem to be accepting my event response frame.

Code: Select all

8:57:25 AM Friday, 15 April 2022  : PDUGetEventItem Called
hmod is: 50403020
hcll is: AABBCCDD
T_PDU_IT.PDU_IT_RESULT
hCop: 22334402
Timestamp: 1B15CB19 (454,413,081)
pCoPTag: 010D64E8
pData: 0F88E178	 
	RxFlag NumBytes : 4
	 RxFlag byte : 00 00 00 00 
	 UniqueRespIdentifier: FFFFFFFE
	 AcceptanceId: 00000001
	 Timestamp flag Numbytes: 4
	 Timestamp flag bytes: 00 00 00 00 
	 StartMsgTimestamp: 00000000
	 PDU_EXTRA_INFO num header bytes: 00000000
	 PDU_EXTRA_INFO num footer bytes: 00000000
	 PDU_EXTRA_INFO pheaderbytes: 00000000
	 PDU_EXTRA_INFO pfooterbytes: 00000000
	 Num DataBytes: 00000004
	 pDataBytes: 6C F1 10 60 
PDUGetEventItem Success

Looking at the MDI logs, after it sends back this request, t2win does its usual check for any more events, and then sends off the next frame.
For mine, the next frame it sends again is same as previous thus t2win is unhappy about something.

[Tazzi]

I can only think of two possible options here for why its not working:
1) Somehow Im running so fast that it is flagging the data as invalid...
2) Somehow my pointer to the data structure for the return data item for the "GetEventItem" is invalid/not written correct.

My only options left are to make a man in the middle to monitor the traffic directly and make sure I can understand/see every last pointer.. or to hire help

*edit
Actually, creating an interface to speak to the MDI DPDU DLL and maybe check if my coding is correct that way also??
This should be a fast way of verifying I have my data structures correct.

I would assume my event structure is working since tech2win is sending the “GetEvent” request after indicating a new event is present. And that function also passes the correct matching parameters from the event requested so it has recognised the event callback.

I have even gone to the extent to make sure all my “unique” IDs for everything match the MDI exactly to minimise problems.

If there was some sort of DPDU api tester application… this would be SO much easier!

[Tazzi]

Ok, we are on the hunt for software.

Apparently “softing” makes a software for testing DPDU apis. Should be able to use it with the MDI and also my own one and compare what it receives between commands.

[antus]

It sounds like a problem with sequence numbers or similar. Have you hard coded any counter that might stop t2w from realising communication has progressed to the next packet? Maybe it overwrites the first receive with the second and then replays the first transmission.

[Tazzi]

It sounds like a problem with sequence numbers or similar. Have you hard coded any counter that might stop t2w from realising communication has progressed to the next packet? Maybe it overwrites the first receive with the second and then replays the first transmission.

Right at the beginning of implementing DPDU, there are some parameters which support a “timestamp” such as the event callbacks.

I originally did not fill them in with an up to date time stamp which resulting in the app never progress past the first couple steps.

So timestamps were implemented into everything.

I will grab a fresh log of what MDI is doing, and what OBDX is doing for comparison. There’s a little bit of formatting left to do for the obdx error log so its easier to match against the mdi so I’ll do that first then pop them up. Maybe I am just I overlooking something simple.

[Tazzi]

Ok so.. comparing the logs.. side by side... with the exact same formatting.

And.... theres no difference

Honestly, at this point I would say I am being trolled by t2win.

It actually shows t2win is receiving frames from the 'vehicle' as the arrow is indicating it is receiving. If I never send anything back, the arrow back to the tech2win never moves indicating its received nothing.

At this point, I feel there is a timing issue. When monitoring MDI's timeframes, it shows it takes 16ms from when it sends the first "Executing" callback, to the "Received frame" callback.
In the OBDX, it is taking 10ms.

[Tazzi]

ah interesting....

So... if I DO NOT send the events of:
1) Executing frame send
2) Finish frame send

It appears to only send the frame once and does not try resend again, it just comes up with a "No Communication With Vehicle".

I also opened the filtering so it will pass the broadcast data, and I can see the arrow going to the "MDI symbol" indicating that I am sending the broadcast data TO t2win.. but it ignores it.

So... it appears we have a timing related problem. So.. we need to send these messages in the correct time placement otherwise it freaks out.

[Tazzi]

So Im not crazy.... its t2win blocking it.

I just made a quick app to send the exact same commands t2win does, and I send them to tech2win... and also OBDX.... and BOTH work.

Now.. why does t2win not work? Well.. I can only assume it has something to do with this message: "Tech2Win is operating with an invalidated vehicle communication device. In case of problems please contact manufacturer of the device and not the GM help desk."

What a funny message to receive... considering is trying to explicitly blame the scantool. Looks like its time to work out what produces that error exactly.