Page 2 of 7

Re: PCM Hammer Release 015 (Preview)

Posted: Sun Dec 27, 2020 6:50 am
by kur4o
NSFW wrote: On the other hand, I also think that I could almost double the data rate if I (or someone) can figure out how to command the PCM to send data continuously rather than querying for each batch of data... but I haven't been able to get that to work reliably yet. I works for a while but it randomly stops. I'm pretty sure it's possible with some more experimentation though.
I think there is a need to send some periodic message each x seconds to keep the bus quiet.
A 3f message each 2 or 5 seconds will do the trick.

There is also some low priority data that can be requested on demand by the tool, that also keeps bus quiet.

Re: PCM Hammer Release 015 (Preview)

Posted: Sun Dec 27, 2020 8:48 pm
by antus
The ADX Jayme wrote here (requires AVT Cable) works perfectly with DPID, can use it to learn. viewtopic.php?f=10&t=2314

Re: PCM Hammer Release 015 (Preview)

Posted: Sun Dec 27, 2020 9:44 pm
by antus
I just noticed malware reported in another thread. It seems ls1flash-free from 2014 has suddenly been flagged by google as malware, and so now every download on the site is flagged in firefox and chrome. I've checked, and thats the real false positive. Ive asked google to check, we'll see what happens now. Quite a big impact for a sudden flag of 6 year old software. But I think they like screwing the little guys so here we are. Hopefully its fixed soon. There is nothing wrong with the files in this thread, or on this site.

Re: PCM Hammer Release 015 (Preview)

Posted: Mon Dec 28, 2020 7:28 am
by NSFW
aaronc7 wrote:Is this just Mode $22 and $23 for now? Or have you got $2C / dynamic working? EFI also has some mode they call 'stream-fast' which allows 24 bytes to be logged at 10 hz. I'm definitely not knowledgeable enough at the programming level to make this work, just curious!
It uses 2C, but there is more than one way to use 2C. You can either ask the PCM to send a batch of dynamic PIDs once (which is what it's doing now), or ask it to stream the DPIDs (which is where I had the reliability problem). The "send DPIDs once" method is far faster than using mode 22 to request each PID individually, but the streaming approach would be faster still.

EFI Live probably uses the streaming approach. Or they might be using high-speed (4X) bus mode. Or both. I haven't experimented with 4X at all yet.
kur4o wrote:I think there is a need to send some periodic message each x seconds to keep the bus quiet.
A 3f message each 2 or 5 seconds will do the trick.

There is also some low priority data that can be requested on demand by the tool, that also keeps bus quiet.
I tried sending 3F message every 2 seconds, but that wasn't sufficient.

I don't think I've tried sending "suppress chatter" messages though. That's worth a try.

Re: PCM Hammer Release 015 (Preview)

Posted: Mon Dec 28, 2020 10:04 am
by NSFW
antus wrote:The ADX Jayme wrote here (requires AVT Cable) works perfectly with DPID, can use it to learn. viewtopic.php?f=10&t=2314
I think that was where I learned most of what's in the code now. :)

I've improved on that very slightly, by requesting up to 3 DPIDs at a time. The tricky thing is getting the ECU to send data continuously.

Re: PCM Hammer Release 015 (Preview)

Posted: Mon Dec 28, 2020 4:53 pm
by jlvaldez
NSFW wrote:
jlvaldez wrote:I'm interested in the datalogging. Particularly if you can do the VPW raw logging ;)
If you mean passively recording everything on the VPW line, that was on my "some day maybe" list, but now that you're making such good progress on that front... :)

This release is totally focused on logging batches of parameters from the PCM, just for standard tuning purposes ("under what conditions is the engine knocking?"). But if we can find some good parameters to log from other modules, that could happen in a future release. I have a hunch we could get brake pressure from the EBCM for example. I haven't tried yet though. And I'm a little concerned that the data rate would be too slow to be useful. I get about 6 rows of data per second just logging from the PCM, which IMO is just barely enough, and pulling just one parameter from another module might cut that down to 3 or 4 rows per second.

On the other hand, I also think that I could almost double the data rate if I (or someone) can figure out how to command the PCM to send data continuously rather than querying for each batch of data... but I haven't been able to get that to work reliably yet. I works for a while but it randomly stops. I'm pretty sure it's possible with some more experimentation though.
I've actually already found the PID to get brake pressure.

Send: 6C 28 F1 2A 03 41

You will get a response:
6C F1 28 6A 41 00 00 05 00 00 1D
The 1D is the raw voltage value. If you poll this and then press and release your brake pedal, you'll see this value change :)

I found this while sniffing traffic from my Tech 2 and found this PID. I believe the hex value is a 0V to 5V scale of the signal. Assuming 0x00 = 0V and 0xFF = 5V, then 0x1D = 0.56V, which is what I read from my tech 2 with the pedal completely released with engine off.

While my sniffer python script seems to work ok, it has some issues (particularly that python is slow as hell).

Re: PCM Hammer Release 015 (Preview)

Posted: Mon Dec 28, 2020 5:01 pm
by jlvaldez
kur4o wrote:
NSFW wrote: On the other hand, I also think that I could almost double the data rate if I (or someone) can figure out how to command the PCM to send data continuously rather than querying for each batch of data... but I haven't been able to get that to work reliably yet. I works for a while but it randomly stops. I'm pretty sure it's possible with some more experimentation though.
I think there is a need to send some periodic message each x seconds to keep the bus quiet.
A 3f message each 2 or 5 seconds will do the trick.

There is also some low priority data that can be requested on demand by the tool, that also keeps bus quiet.

Is that the point of the 3f message? Looking at some of my datalogs where my tech 2 continuously polls the bus, I see a 3f message transmitted periodically but the module sends updates automatically. However, when i send the exact same message request, I only get 1 response, where the tech 2 gets a repeated stream... No idea why i get different behavior unless a 3F message being sent does something about that.

Here's a text stream of a Tech 2 polling the ABS module for PIDs 20, 21, 40, and 41.
You see that the module responds immediately and sends multiple updates, then the other modules seem to send a 03 (module heartbeat) to the bus. I'm genuinely confused by why the ABS module sends multiple updates... I'm almost thinking that my OBDX VT Pro is dropping some messages... The first 3F message isn't sent by the tech 2 until many messages after the ABS sends messages.

Code: Select all

6C 28 F1 2A 03 20 21 40 41 A6
6C F1 28 6A 20 00 00 00 00 00 FF 42
6C F1 28 6A 21 9B 00 A5 00 82 01 4F
6C F1 28 6A 40 83 05 7F 00 00 00 11
6C F1 28 6A 41 00 00 05 00 00 00 B9
6C F1 28 6A 20 00 00 00 00 00 FF 42
6C F1 28 6A 21 9B 00 A5 00 82 00 52
6C F1 28 6A 40 83 05 7F 00 00 00 11
6C F1 28 6A 41 00 00 05 00 00 00 B9
E8 FF A0 03 BB
E8 FF B0 03 0F
E8 FF 10 03 B3
6C F1 28 6A 20 00 00 00 00 00 FF 42
6C F1 28 6A 21 9B 00 A5 00 82 00 52
6C F1 28 6A 40 83 05 7F 00 00 00 11
6C F1 28 6A 41 00 00 05 00 00 00 B9
E8 FF 60 03 98
E8 FF 28 03 28
6C F1 28 6A 20 00 00 00 00 00 FF 42
6C F1 28 6A 21 9B 00 A5 00 82 00 52
E8 FF 40 03 ED
6C F1 28 6A 40 83 05 7F 00 00 00 11
6C F1 28 6A 41 00 00 05 00 00 00 B9
E8 FF A1 03 F7
6C F1 28 6A 20 00 00 00 00 00 FF 42
6C F1 28 6A 21 9B 00 A5 00 82 01 4F
6C F1 28 6A 40 83 05 7F 00 00 00 11
6C F1 28 6A 41 00 00 05 00 00 00 B9
E8 FF 99 03 6C
6C F1 28 6A 20 00 00 00 00 00 FF 42
6C F1 28 6A 21 9B 00 A5 00 82 01 4F
6C F1 28 6A 40 83 05 7F 00 00 00 11
6C F1 28 6A 41 00 00 05 00 00 00 B9
E8 FF 58 03 03
6C F1 28 6A 20 00 00 00 00 00 FF 42
6C F1 28 6A 21 9B 00 A5 00 82 00 52
6C F1 28 6A 40 83 05 7F 00 00 00 11
6C F1 28 6A 41 00 00 05 00 00 00 B9
6C F1 28 6A 20 00 00 00 00 00 FF 42
6C FE F1 3F 8B
6C F1 28 6A 21 9B 00 A5 00 82 00 52
6C F1 28 6A 40 83 05 7F 00 00 00 11
6C F1 28 6A 41 00 00 05 00 00 00 B9
E8 FF A0 03 BB
6C F1 28 6A 20 00 00 00 00 00 FF 42
6C F1 28 6A 21 9B 00 A5 00 82 00 52
6C F1 28 6A 40 83 05 7F 00 00 00 11
6C F1 28 6A 41 00 00 05 00 00 00 B9
E8 FF B0 03 0F
E8 FF 10 03 B3
6C F1 28 6A 20 00 00 00 00 00 FF 42
6C F1 28 6A 21 9B 00 A5 00 82 01 4F
6C F1 28 6A 40 83 05 7F 00 00 00 11
6C F1 28 6A 41 00 00 05 00 00 00 B9
E8 FF 60 03 98
E8 FF 28 03 28
E8 FF 40 03 ED
6C F1 28 6A 20 00 00 00 00 00 FF 42
6C F1 28 6A 21 9B 00 A5 00 82 00 52
6C F1 28 6A 40 83 05 7F 00 00 00 11
6C F1 28 6A 41 00 00 05 00 00 00 B9
E8 FF A1 03 F7

Re: PCM Hammer Release 015 (Preview)

Posted: Mon Dec 28, 2020 10:40 pm
by Tazzi
This looks like DPID data?

The Tech2 setups a bunch of PIDs in a DPID, then requests the module (ABS) to start spamming the messages.

The tech2 needs to keep sending a "tester present" message which is the 3F message you are describing to keep the data polling :)

Re: PCM Hammer Release 015 (Preview)

Posted: Tue Dec 29, 2020 12:01 am
by kur4o
Here is some logs and a file with some commands to control pcm. It can give you a better understanding about how to set ip up.

Setting up is the channels is the trickiest part. You need a list of all the pids the pcm supports, if you request non-supported pid the pcm gives an error.
And than there is some priority byte that is not fully understood. Mimic the commands set from the logs can prove it works reliable.

Re: PCM Hammer Release 015 (Preview)

Posted: Tue Dec 29, 2020 7:08 am
by NSFW
kur4o wrote:Here is some logs and a file with some commands to control pcm. It can give you a better understanding about how to set ip up.

Setting up is the channels is the trickiest part. You need a list of all the pids the pcm supports, if you request non-supported pid the pcm gives an error.
And than there is some priority byte that is not fully understood. Mimic the commands set from the logs can prove it works reliable.
Thanks, that looks very helpful! The logs show a mode $10 message at the start of the logging session, which might be the key thing I've been missing. I'm going to try that plus some different DPID IDs and see if streaming will work.