pcmhacking.net

Tazzi wrote:Passthrough basically removes the "send 1 receive 1" nature of the ELM protocol.

It allows all messages that meet the filter requirements to be sent to the computer instantly. You can still also send messages to the bus.

So i played with this tonight and it doesn't seem to work quite as I expect.

I
1) reset part
2) set protocol
3) set mask to 000000
4)turn off echo

I get packets passes through as long as there is no unaubmittes text in the terminal. For example, if I am typing the send message command out (but it's not being echoed back), i do not receive any messages until I press enter.

On top of that, it appears that all messages from first character entered to enter key are lost.

In reality, it's a low chance to lose a message with a program typing things out, but delays could cause issues here.

jlvaldez wrote:

Tazzi wrote:Passthrough basically removes the "send 1 receive 1" nature of the ELM protocol.

It allows all messages that meet the filter requirements to be sent to the computer instantly. You can still also send messages to the bus.

So i played with this tonight and it doesn't seem to work quite as I expect.

I
1) reset part
2) set protocol
3) set mask to 000000
4)turn off echo

I get packets passes through as long as there is no unaubmittes text in the terminal. For example, if I am typing the send message command out (but it's not being echoed back), i do not receive any messages until I press enter.

On top of that, it appears that all messages from first character entered to enter key are lost.

In reality, it's a low chance to lose a message with a program typing things out, but delays could cause issues here.

The 'echo' is the tool sending back each character as you send it. Depending on the terminal you are using, some send each character while you type, others only send it when you click a big button saying send.

For using terminal based stuff, you need echo on.

I get it. I was using the terminal to test functionality as I wrote the code for software to do it.

While software would likely not spend much time sending the characters, it's possible that the OS puts the thread to sleep for a while to service other things. In this example, it looks like any incoming messages would be dropped, even with echo off?

I agree with Echo on, it makes sense to hold sending messages to the terminal until a command had been sent, but with echo off, I'd think it could happen at any point, no?

Doing some more work... I built a bench harness for ECU flashing, and also added an ABS plug to it, so I have an ECU and an ABS module connected. Allows me to do some testing on my desktop instead of going into the car.

Made a few minor updates to my python script, it's still pretty alpha-level, but it works enough.

I was testing modes and functional messages on the ABS module trying to figure out which modes it supports with physical node to node modes...


Apparently it supports:
Mode $14: Clears DTCs
Mode $19: Reads DTCs
Mode $20: Return to normal
Mode $25: Stop transmitting
Mode $28: STFU mode
Mode $29: Return normal?
Mode $2A: This is the ONLY PID retrieval mode supports.
Mode $34: Data download


I figured out that to retrieve a single PID with mode $2A, you send 2A 01 <PID>

Have to do it that way because it doesn't support modes 21-23...

Good news: I took mine further apart
Bad news: the CPU chip has a cover glued to it, so there's no much new information

I had hoped to find a chip with a visible ID that would lead to a data sheet, but no such luck.

And the whole thing is encased in a clear goo that is almost liquid. I poked in with a pick and tried to pry the cover off with no luck. I suspect that the black stuff around the edges is epoxy.

Well that is interesting... Now I'm wondering how hard it would be to actuate those valves then... Is the only option for us to design a new board that controls that actuator board? Those look like bond wires suspended in the potting material? I'm not sure what those would be. Very interesting.

I hate modules that have that bullshit wire bond stuff. The T42 TCMs and E55 ECUs also use them, I could never identify what the chips were.

2nd that potting is good for waterproofing but that's it.

Ah, the days of soldering on new wires on the vt commodore modules.

Would those be toroid's for signal conditioning? The other side of the board is very similar to the insides of the MEFI controllers with the goo and the tiny wires from board to pins.