pcmhacking.net

Here are my logs with tuner cat winflash because the vpwexplorer will not work on windows xp 32 bit, it says it is not a win 32 app.
new_cable_old_program.txt this is the log with the problem seems like several baud rates are tried but no response seems to be present from the 853 cable, when run in the old program.

obd2_flash.exe IRP_MJ_WRITE COM4 SUCCESS Length: 2, Data: F1 A5 //avt reset
IOCTL_SERIAL_SET_WAIT_MASK COM4 SUCCESS Mask: RXCHAR TXEMPTY CTS DSR RLSD BREAK ERR RING
IOCTL_SERIAL_WAIT_ON_MASK COM4 SUCCESS
IOCTL_SERIAL_SET_WAIT_MASK COM4 SUCCESS Mask: RXCHAR TXEMPTY CTS DSR RLSD BREAK ERR RING
IOCTL_SERIAL_WAIT_ON_MASK COM4 SUCCESS
IOCTL_SERIAL_SET_WAIT_MASK COM4 SUCCESS Mask: RXCHAR TXEMPTY CTS DSR RLSD BREAK ERR RING
IOCTL_SERIAL_WAIT_ON_MASK COM4 SUCCESS
IRP_MJ_WRITE COM4 SUCCESS Length: 17, Data: D0 D0 D0 D0 D0 D0 D0 D0 D0 D0 D0 D0 D0 D0 D0 D0 D0 //not sure what this is
IOCTL_SERIAL_SET_WAIT_MASK COM4 SUCCESS Mask: RXCHAR TXEMPTY CTS DSR RLSD BREAK ERR RING
IOCTL_SERIAL_WAIT_ON_MASK COM4 SUCCESS
IRP_MJ_WRITE COM4 SUCCESS Length: 2, Data: F1 A5 //no response reset again
BREAK ERR RING

But in the new program the same command gets a response, idk why in both cases D0 is repeated 17 times it only needs to be sent ounce!!
new cable with new program: IOCTL_SERIAL_SET_HANDFLOW COM4 SUCCESS ControlHandShake: 0x0, FlowReplace: 0x40, XonLimit: 1280, XoffLimit: 1280 //FlowReplace is different on the old program seems to be 0x0 instead of 0x40 no idea what this does? All I see that is different?
IRP_MJ_WRITE COM4 SUCCESS Length: 2, Data: F1 A5
IOCTL_SERIAL_SET_WAIT_MASK COM4 SUCCESS Mask: RXCHAR TXEMPTY CTS DSR RLSD BREAK ERR RING
IOCTL_SERIAL_WAIT_ON_MASK COM4 SUCCESS
IOCTL_SERIAL_SET_WAIT_MASK COM4 SUCCESS Mask: RXCHAR TXEMPTY CTS DSR RLSD BREAK ERR RING
IOCTL_SERIAL_WAIT_ON_MASK COM4 SUCCESS
12IOCTL_SERIAL_SET_WAIT_MASK COM4 SUCCESS Mask: RXCHAR TXEMPTY CTS DSR RLSD BREAK ERR RING
IOCTL_SERIAL_WAIT_ON_MASK COM4 SUCCESS
IOCTL_SERIAL_SET_WAIT_MASK COM4 SUCCESS Mask: RXCHAR TXEMPTY CTS DSR RLSD BREAK ERR RING
IRP_MJ_READ COM4 SUCCESS Length: 5, Data: 91 27 92 04 48 //now with the new program and new cable we get data back!

Here is the old cable for comparison

Looks like old cable have old firmware 0415 vs new cable 0448.

Old cable stops working when it opens bus and program should get idle bus data[that not happens-complete silence]. All other seem good.

Not sure it is cable, firmware or program.
You will need to run some manual commands with avt hex terminal to confirm the cause.

http://www.avt-hq.com/download.htm#Hex_Term_SW

Looks like avt is closing business. It will be now the time to archive the site contents for future reference.

I am sure if you contact avt you will get much better support than we can guess here. Maybe some newer firmware.

https://help.electronic.us/support/solu ... low-method RTS (request to send) is a physical pin on the old school com ports for devices with a half-duplex connection. Its not normally used on "modern" full duplex com ports, but it can be depending on the implementation.
https://en.wikipedia.org/wiki/Flow_cont ... ow_control

So the D0 D0 D0 D0 is just noise on the bus, because the AVT and the serial chip are not ready to transmit yet. If hardware flow control was on, the AVT would come to life, or the serial port would wait until its ready (even if its just moments) and then the data would be there instead of that pattern. Its also possible the RTS line on the USB to serial chip is wired to some kind of solid state switch that turns off the connection to the ethernet device and on to the serial chip, rather than genuinely used for flow control.

So to do it properly you'll need to code that detects when the AVT fails to initialise and then tries again with RTS handshaking.

https://learn.microsoft.com/en-us/dotne ... at-ext-8.0
https://learn.microsoft.com/en-us/dotne ... at-ext-8.0

Except PCMHammer uses the Port class which doesnt appear to expose flow control settings. I just had a bit of a look and couldn't see how it'd be set in the current implementation. If it was exposed you'd set it around here somewhere.
https://github.com/LegacyNsfw/PcmHacks/ ... C13-L59C37

I am out of time for the moment, but it looks like it might require modifications to use a different serial class that is capable of it. I looked at Universal Patcher, which is heavily based on PCM Hammer's code and it appears to do the same thing, so I am not sure how it could work there. I could very easily be wrong, it was only a quick look and my C# isn't strong. It could also be that it is lost in the IPort layer here:

https://github.com/LegacyNsfw/PcmHacks/ ... s/IPort.cs

Maybe that just needs a getter and setter on Hardware, then it'd exposed at open time to be set? (edit: just gave that a bit of a shot, could not see how to get enum System.IO.Ports.Handshake in to scope. It might be a non-starter, or I might be out of my depth )

There is at least one difference between Universal Patcher and PCM hammer implementation: Universal Patcher uses serial port events for receiving data
https://github.com/joukoy/UniversalPatc ... rt.cs#L115
while hammer is polling port buffer.

Ok thanks, interesting I sent the cable back hopefully they can figure it out, at least for tuner cat related programs