OBDX Development - Developer Tools and Suggestions

[Tazzi]

Awesome work. I need to buy an MDI or Mongoose but am holding off to get this instead. Would you happen to have a rough ETA for the 1st batch of production?

Pete and I are trying to get the first batch of either 30 or 50 on the way shortly, we are just waiting for the last stock to arrive at the manufacture to start production.

I still have to personally solder quite alot for each board which is a bit of a bummer with the GT. I did the logistics the other day, and it will be around 10min per cable to be fully soldered/assembled/programmed. So even on a same batch of 50cables, thats 500minutes... so 8.3 hours!

I can honestly only laugh at it.. otherwise I might cry

I do need to start testing canbus with J2534 though as I have yet to properly actually test if that works nicely yet since being distracted with getting DPDU working.
Basically main aim is to try have J2534 and DPDU working with the OBDX GT prior to its sale so that I can add in any additional requirements to need J2534/DPDU spec

[hjtrbo]

Put me down for a GT please

[Tazzi]

10 hours of coding later today, and we have a completely redesigned serial processing method.

Current method is designed as follows:
• Run serial received event in background thread so that it does not disturb main UI thread.
• When serial is received, it fires off a function to process incoming data which saves formatted frames into a queue
• Serial process function fires off any necessary callback functions for system or network received messages if a callback has been registered.

This method allows for all callbacks to occur instantly, and does not rely on any kind of request from tech2win to begin processing received OBDX tool messages.
Once a callback has been made, tech2win then sends off a "PDUGetEventItem" request which is where the actual data is then passed back to tech2win.

I have also made some progress understand the whole callback event system, we have three possible event types, but an event can use different callbacks depending on which are registered.
•If a Comlogical Event item is required, Use a comlogical callback if available, otherwise use Module callback, otherwise use system Callback (default).
•If Module event item is required, use a module callback if available, otherwise use Default Callback (system).
•If system event item is required, use system callback (default).

[Tazzi]

Next on the list is adding multiple software filters into D-PDU.

This is because the OBDX VT was never designed to have multiple filters on VPW, it was never assumed that it would need to grab multiple IDs at once.
It does support a filter plus mask, so this means all IDs can be allowed through by setting the mask to 0. Then received frames can be processed via a software filter in the D-PDU.

Its not a 'perfect' method, but since VPW is not too crazy, it can be managed.

Ontop of that, adding in all the sub commands for the PDUIoCtl will need to be done also. These two along will probably be my next 5+hours

I do not look forward to implement all the CANBus stuff for this, I feel like that is going to be 100x worse.

[Tazzi]

So theres one single kind of event I can see that is an issue for both J2534 and D-PDU, these both allow opening communication to more then 1 protocol at a time. Now, OBDX tools are not designed for this at all, and would require a pretty extreme makeover to make that work. I have yet to see any dealership software use this capability, but I believe this will simply have to be rejected for current line of tools until I can comeup with a solution to manage more then one protocol at a time in the processor.

[Tazzi]

This is just for my own sanity check to ensure I can look back at this if I get confused along the way.. so excuse my ramblings.

After a PDUconnect is performed by t2win. It then registers events. This means we do not send any system/module event updates since it is afterwards.

Code: Select all

6:56:42 PM Wednesday, 13 April 2022  : PDUModuleConnect Success

6:56:42 PM Wednesday, 13 April 2022  : PDURegisterEventCallback Called
6:56:42 PM Wednesday, 13 April 2022  : hmod is: FFFFFFFF
6:56:42 PM Wednesday, 13 April 2022  : hcll is: FFFFFFFF
6:56:42 PM Wednesday, 13 April 2022  : Registering Default/System Event Callback
6:56:42 PM Wednesday, 13 April 2022  : PDURegisterEventCallback Success

6:56:42 PM Wednesday, 13 April 2022  : PDURegisterEventCallback Called
6:56:42 PM Wednesday, 13 April 2022  : hmod is: 50403020
6:56:42 PM Wednesday, 13 April 2022  : hcll is: FFFFFFFF
6:56:42 PM Wednesday, 13 April 2022  : Registering Module Event Callback
6:56:57 PM Wednesday, 13 April 2022  : PDURegisterEventCallback Success

After its done that, it setups up all the ObjectIds which are used extensively throughout t2win, and just before it shows all available tools, it does a

Code: Select all

6:56:42 PM Wednesday, 13 April 2022  : PDUIoCtl Called
6:56:42 PM Wednesday, 13 April 2022  : _hMod is: 50403020
6:56:42 PM Wednesday, 13 April 2022  : _hcll is: FFFFFFFF
6:56:42 PM Wednesday, 13 April 2022  : Ioctlcommandid is: PDU_IOCTL_READ_VBATT

hMod is the tools unique handler, I have set it to 50403020 since its a very easy value to spot, rather then doing a simple 1 ect.

PDU_IOCTL_READ_VBATT is the subcommand request which is as the name suggests, read battery voltage. This gets returned in millivolts, so 13.120 volts will be 13120, or 0x3340.
Each sub command has its own custom structure which needs to be implemented, but the only two other commands to implement is a start filter and remove filter.

At this point, this is where we are at the main homescreen!

Everything after this point is setting the protocol, setting filters, sending data to write to the bus and receiving via callbacks.

[Tazzi]

Not sure how I missed this line of text:

Code: Select all

This IOCTL command starts filtering incoming messages for the specified ComLogicalLink. A minimum of
64 filters can be supported per ComLogicalLink

64 filters.... REALLY!?!?!?!?
And here I am.. using 1 on the OBDX VT

Anyways, it appears VPW does not use any filters.. seems tech2win wants to process it all via software.
When implementing the filter sub command, we get the following data from t2win:

Code: Select all

1:30:22 AM Thursday, 14 April 2022  : PDUIoCtl Called
1:30:22 AM Thursday, 14 April 2022  : _hMod is: 50403020
1:30:22 AM Thursday, 14 April 2022  : _hcll is: AABBCCDD
1:30:22 AM Thursday, 14 April 2022  : Ioctlcommandid is: PDU_IOCTL_START_MSG_FILTER
1:30:22 AM Thursday, 14 April 2022  : Set Filter has been requested
1:30:22 AM Thursday, 14 April 2022  : Item Type: PDU_IT_IO_FILTER
1:30:22 AM Thursday, 14 April 2022  : Number of filters: 1
1:30:22 AM Thursday, 14 April 2022  : Filter Type: PDU_FLT_PASS
1:30:22 AM Thursday, 14 April 2022  : Filter Number: 1
1:30:22 AM Thursday, 14 April 2022  : Filter Compare Size: 1
1:30:22 AM Thursday, 14 April 2022  : Filter Mask: 000000000000000000000000
1:30:22 AM Thursday, 14 April 2022  : Filter Pattern: 000000000000000000000000
1:30:22 AM Thursday, 14 April 2022  : PDUIoCtl Success

I thought I must have messed up with the Mask and Pattern being set as 00's, but.. nope.. that is correct. Because the Mask is 00, this means all received frames are allowed through.
I don't quite understand why it uses 12 bytes for the Mask and Pattern.. but Im sure it will pop up with CAN bus later.

Our next lovely call to process is PDUConnect, which is where we will set the OBDX cable's OBD status to enabled to allow receiving and writing data. Then finally it will be PDUStartComPrimitive to actually send VPW frames.

Anyways.. 1:39am.. Id say thats it for tonight!!

[Tazzi]

Yeah, this has to be either a "VERY" convenient timing, or the MDI is setting filters based on the data it writes to the VPW line.

So basically, t2win sets the mask and pattern to both 0. This means all received messages from the vehicle would be received.
Now, when watching the MDIs log, it does not receive ANY messages from the vehicle except the one from the ECU. Now.. it could be that its 'opening' the search when a PDUStartComPrimitive request is made, and its just timed right that it assumes the next received messaged from the vehicle will be the desired one from the ECU... but that seems kinda risky.
If any broadcast data from other modules send data before the ECU responds, it would be picked up since the filters are allowing everything through.

Im gonna have to see what happens if passing it incorrect data and see if it doesnt have a full blown melt down.

*Edit
Absolutely ridiculous.
Ok so our PDUConnect function is where we are 'suppose' to connect the VPW line to the scantool (Assuming isolated with relays) and setup with baud rate ect. Technically it has NOT been started yet, so it will not receive any data.. even if filter/mask are set to 0.

The PDUStartComPrimitive is the universal command to 'enable' communication to the car. At this point, we enable the TXD and RXD of messages to/from the vehicle.
The PDUStartComPrimitive parameters can indicate how many frames we are expecting to receive, which can then be used in our Serial Processing routine to find following bus messages and stop sending after hitting the counter.
once the PDUStartComPrimitive is exited, the 'comms' should be disabled again from the tool. Luckily enough, I did build this into OBDX tools but this method is overcomplicated.

Here goes another couple hours for this questionable setup!


*Edit2
Perfect example of what happens when a big task is delegated to one developer, and noone actually verified the coding is ok.
We have PDUStartComPrimitive called a couple times:
First time: Initiating communication to allow send/receive. Basically a pointless action.. but done to meet DPDU requirement.
Second time: To actually receive data, but it does not send any data, t2win then cancels this.
Third time: again to receive data... does not cancel it this time
fourth time: sends frame to ECU (6C 10 F1 20).

Then a background callback is fired off referencing the third ComPrimitive request with the response to the fourth Comprimitive write event. Response being 6C F1 10 60

Basically.. each Comprimitive is its own task. The "write" tasks just deal with sending sending the data, then fire off event updates when starting the writing and when finishing it.
The "read" tasks do the same, but it doesnt seem like the read task ever expires, since the same 'read handler' is referenced for future frames also.

Whats frustrating currently is no filters are set. None. Its a 'passthrough' setup. As the Read Task is never closed, it SHOULD receive the broadcast data from the PCM but it appears that the MDI has hard coded some sort of filter automatically which is... frustrating.. to say the least. Well... it can't be quite hard coded, since it gets two frames with two different IDs.. so maybe its hardblocking specific IDs.

Keeping track of all the handlers is a bit of a pain. So far.. it looks like its only every using 1 RXD and 1 TXD events. Realistically, the RXD is the only one I have to 'save' since the TXD one is finished as soon as the function ends as it can be completed in there directly.

[Tazzi]

cracking up over the 10+k of lines of coding for just the DPDU side, not including the scantool stuff at all.

The MDI must have some sort of internal filtering system. It has to.
It passes these two frames through with different headers:
Received: C8 3B 10 3C 04 48
Received: 6C F1 10 7C 08 05 7E 2F 18 79

But ignores this one:
Received: E8 FF 10 03 B3

The last one being a heartbeat message from the PCM. Yet no filters are applied.. so it should have been received.

I recon the MDI has it hard coded to ignore messages with a specific "to" address, and will only accept within a specific range when no filter is applied. Its the only thing that makes any possible sense.

[Tazzi]

Just keeps getting funnier.

So... I have intentional delays in setup routines for tech2win just so its easy to spot the time stamps in the log.

Remove 3/4 of them.. and tech2win boot so damn quick.. so it shows it is heavily reliant on the scantool responding. I then removed all of them.. and tech2win kept crashing. It appears that it is possible to actually send data back so far, that tech2win is actually not prepared and crashes!!!

We are finally on the back end of all this to get our first VPW data frames...

Code: Select all

Num Receive Cycles is: -1
Temp Param Update: 0
Num Tx Flag Bytes: 4
TX Flag Data: 00 00 00 00 
Num Possible Expected Responses: 1

The Rx receiver sets its number of rxd cycles to -1, this means it infinitely runs until requested to exit. So this matches what we see with the MDI.
Technically Im being a bit sneaky and not really caring what it puts there, at least for now.

After this.. and sending all required event notifications.. we FINALLY get to this golden request:

Code: Select all

CoP Type is: PDU_COPT_SENDRECV
DataSize is: 4
CoP Data is: 6C 10 F1 20 

This is the first VPW request. Next step is to actually pass to the tool and let it automatically pickup the response and parse it on through.