Decoding data bus message

[kur4o]

If the switch is a momentary contact. One press will be on next press will be off.

The way I see the messages is
A8 3A 40 30 01 ED bcm send tow request on.
A8 3B 10 30 01 08 PCM answers that message is recieved.

A8 3A 40 30 00 ED bcm send tow request off.
A8 3B 10 30 00 08 PCM answers that message is recieved

LAST byte is checksum of message.
01 is on
00 is off

[PeteS]

If the switch is a momentary contact. One press will be on next press will be off.

The way I see the messages is
A8 3A 40 30 01 ED bcm send tow request on.
A8 3B 10 30 01 08 PCM answers that message is recieved.

A8 3A 40 30 00 ED bcm send tow request off.
A8 3B 10 30 00 08 PCM answers that message is recieved

LAST byte is checksum of message.
01 is on
00 is off

It is a momentary switch to ground, not a toggle on/off type of ground switch.

So do you have any thoughts on what/or how I should configure the Elm header to in order to simulate the send command? If the second line is in fact the On response I can get that part of this project rolling but with out being able to actually command it I'm still kind of dead in the water for the time being.

Thanks again......I'll check back for header settings in the meantime I'll go work on the On response from the pcm.

[kur4o]

Change the header to a8 3a 40.
Than send commands 30 01 - on, 30 00- off

[PeteS]

Change the header to a8 3a 40.
Than send commands 30 01 - on, 30 00- off

I was able to set the header and issue the command however the serial terminal I'm monitoring from goes haywire when I issue the command. It sends several lines of repeating capital A's and looks like it resets the data bus since it spits out a whole bunch of lines and they are the same lines it spits out on startup.

I was kind of able to get it to work by creating a repeater of the
E8 FF 10 03 B3E8 FF 40 03 ED
and then issuing the 3001 command but the line had to be inserted into the code after the 40 03 ED line to not reset the bus and the back and forth of the pcm/bcm chatter has to be perfectly timed. If the pcm send's it's line twice with out the bcm responding it spits of a bunch of stuff and looks to reset. The same happens if the bcm line is send twice before the pcm responds with it's line. This appears to be some type of timed send/receive message since the rate that it occurs isn't constant, I tried monitoring it with 2 different type of devices at the same time to see if it was an adapter issue and both windows stay in time with each other, it's the rate the messages are sent that changes. That makes it hard to be able to keep my fake bcm message in time with the pcm and still be able to send the pid ID, once it's sent it drastically alters the timing for a couple of seconds and my program falls out of time almost instantly. It's progress since it does send the response message back that should mean it's been turned on but I have no way of trying the off command since it resets so quickly after falling out of time.

Back to the drawing board for the time being on getting the timing to work and stay lined up. I'm sure someone that programs for a living could whip this out pretty quick but...that's not me lol.

Good information and thanks for the help, now I just need to work this out so I can move forward with the off command.

[kur4o]

The problem is how elm is configured. It doesn`t accept raw hex command easily. I think there was a translation between ascii characters and hex characters.

Search for elm237ds.pdf. You will find some very useful information there.