PCM Hammer Suite development

They go by many names, P01, P59, VPW, '0411 etc . Circa 1999 to 2006. All VPW OBD2 PCMs.
User avatar
Posts: 894
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Suite development

Postby Gampy » Fri Jan 15, 2021 2:14 am

I have pushed a PR (#218) to squash the Select Device and Cancel issue. (See: Re: PCM Hammer Release 015 (Preview))
The issue is due to vehicle being disposed before it's time.

It would be appreciated if this could get merged (or rejected) as soon as possible.

Thank you.
Windows 10 is like an off idle flat spot ... It stumbles when it's time to go!

User avatar
Posts: 479
Joined: Fri Feb 02, 2018 3:13 pm

Re: PCM Hammer Suite development

Postby NSFW » Fri Jan 15, 2021 3:26 pm

Merged. Thanks!
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!

User avatar
Posts: 894
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Suite development

Postby Gampy » Sat Jan 16, 2021 5:23 am

Thank ya, Thank ya very much!

Pushed a persistent device life Enable4x up.
Windows 10 is like an off idle flat spot ... It stumbles when it's time to go!

User avatar
Posts: 479
Joined: Fri Feb 02, 2018 3:13 pm

Re: PCM Hammer Suite development

Postby NSFW » Fri Jan 29, 2021 4:39 pm

Gampy wrote:Thank ya, Thank ya very much!

Pushed a persistent device life Enable4x up.


Do you have any more changes coming soon, or should I publish a release of what we have right now?
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!

User avatar
Posts: 894
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Suite development

Postby Gampy » Fri Jan 29, 2021 5:38 pm

Thank you for asking ...

We should resolve this first IMO, a proposed resolution is here.

[edit]
Antus made a valid point, the choice was made, a PR for this is up!
Windows 10 is like an off idle flat spot ... It stumbles when it's time to go!

Site Admin
User avatar
Posts: 6521
Joined: Sat Feb 28, 2009 8:34 pm

Re: PCM Hammer Suite development

Postby antus » Fri Jan 29, 2021 8:38 pm

merged, thanks for the PR
Have you read the FAQ? For lots of information and links to significant threads see here: viewtopic.php?f=7&t=1396

User avatar
Posts: 894
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Suite development

Postby Gampy » Fri Jan 29, 2021 10:34 pm

Sorry, I forgot to add a simple cleanup to PR#225 ... I just pushed another stupid simple PR, removing a stray comma.

I have been limiting myself to bug fixes and things that won't cause issues ... And that's it for them at the moment!
Windows 10 is like an off idle flat spot ... It stumbles when it's time to go!

User avatar
Posts: 894
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Suite development

Postby Gampy » Tue Feb 02, 2021 11:08 pm

In Device.GetVpwTimeoutMilliseconds(...), there is an int,
Code: Select all
            int bitsPerByte = 9; // 8N1 serial
is there a reason it's 9 ??

8N1 is 10 bits per 8 bit byte.
Windows 10 is like an off idle flat spot ... It stumbles when it's time to go!

Site Admin
User avatar
Posts: 6521
Joined: Sat Feb 28, 2009 8:34 pm

Re: PCM Hammer Suite development

Postby antus » Wed Feb 03, 2021 7:46 am

Neither look correct to me in the context of the code. Its trying to time the data packet on the VPW bus which is 8N0 without a start bit, so it should be 8 bits per VPW byte. The payload, after the start of frame bit, and not counting the checksum or interframe, is 8 bits per byte on the VPW bus. But I would also think that there are too many variables to calculate this exactly correct. The add 10% probably covers the SOF and IFS in most cases, but its a bit rough. Could probably attempt to do better reading timing off of a logic capture, similar to whats here viewtopic.php?f=3&t=4761&hilit=sigrok#p67134 though they dont show the IFS at the end, to which the spec is a minimum length, from memory. Its also worth noting, that because VPW is variable length, the byte length will change depending on the payload. That is 01010101 or 10101010 will be the shortest and the longest bytes.

So you probably want to calculate SOF + (payload length + (8*long bit time)) + 8*long bit time (for checksum) + EOF. Then divide it by 4 if bus is at 4x. But even then, thats assuming a silent bus, and no re transmission and no wait for another packet to get in front.

As for 8N1 being 10 bits, that would be correct is we were talking RS232 serial. 1 start bit + 8 data bits + (no parity) + 1 stop bit

The other issue is how to time the data from the interface back to the pc. If its an older interface at serial 38400 then its going to take as long as the 4x speed packet on the VPW bus. If its a newer interface running usb 1 at 2mbit, its barely noticable. All in all, I dont think its worth attempting. What we have is probably close enough but we could probably document it better and not use 9 bits per byte in the code as thats completely meaningless in the context.
Have you read the FAQ? For lots of information and links to significant threads see here: viewtopic.php?f=7&t=1396

User avatar
Posts: 894
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Suite development

Postby Gampy » Wed Feb 03, 2021 8:26 am

A compromise between the two ??

Pc to Tool is 8N1
Tool to PCM is 8N0 ?
Windows 10 is like an off idle flat spot ... It stumbles when it's time to go!

PreviousNext

Return to GM LS1 512Kbyte and 1Mbyte

Who is online

Users browsing this forum: No registered users and 2 guests