Usage With SK Pang Teensy 4.0 CAN FD And LIN Bus Breakout Board

[AdamRJonesHPD]

Hi Ivor!

Great Project! I've had this one bookmarked for a while to use with some future projects, and here we are. Goal is to use this SK Pang board to take in CAN data from an ECU and output ISO 9141-2 on a K-line by implementing your OBD9141 sim classes.

https://copperhilltech.com/teensy-4-0-can-fd-and-lin-bus-breakout-board/

I thought an easy boiler plate test would be to adjust the tx/rx pins in simulator.ino to reflect the board's connections (pins 14/15, respectively) but I can't seem to connect with a commercial USB reader and software. I'm using an OBDLink SX and OBDWiz desktop software for my testing.

Wondering if you would be interested in looking over the board specs and architecture and let me know if I'm missing something glaringly obvious, or if there is still work to do be done on the simulator to get it to connect with a commercial scan tool.

Thanks for your time!

[AdamRJonesHPD]

Commenting on my own issue. Looking into this on my own and I see that the board and the MCP2004A transceiver needs a bit more coaxing than the SN65HVDA195-Q1 you've posted elsewhere. I'm digging into this and happy to share results with a fork. Still interested in your input!

[iwanders]

Hey!

Yeah probably best start is to compare that operational modes state diagram with the one of the SN65HVDA195, at first glance I'd expect you'll be able to get that chip working relatively quickly.

a K-line by implementing your OBD9141 sim classes.

Word of warning here, the simulator was really only implemented for me to be able to test things without having to walk to my car (where I didn't have a power outlet at the time). Especially the detection around the initialisation handshake is glitchy if I remember correctly. Other than that it's a fairly straightforward class that just reads replies from the answer list and replies accordingly.

I'm not too familiar with the CAN based OBD ports, but I presume the whole PID stuff is still the same, which means you can query which PID commands are supported; I recommend querying what commands the ECU supports at startup, then storing those somewhere. Given that 9141 is so much slower than can, I presume you can even avoid the whole setAnswer structure with the fixed list that exists in the simulator, and instead when a request comes in from the LIN side, immediately query it on the CAN side and just reply the answer you just got. Or set up something smart where you track which PIDs the OBD side is retrieving, and proactively cache those at high rate from the CAN side or something.

[AdamRJonesHPD]

Thanks.

I'm getting a 'Failed reading stuff' message now so I know that the connection is at least alive.

I may not need to worry about the init for my project. This is a similar goal for me to be able to work on some devices at the bench instead of at the car, but I also have a bench ecu with an open CAN protocol that I can manipulate at will to try some stuff out.

The aim for the sim would be for it to receive a K-line PID request, grab the current value off of CAN, convert and return as a PID - so quite similar to what you are describing but I will probably have to do some double-converting for some values.

[iwanders]

Be sure to enable extra prints by uncommenting this line, it may help debug what's going on.