Avt 852 not working with vpwexplorer or older tuner cat programs help

[kur4o]

If you connect at 115000 baud with universal patcher, you`d better change it to that.
Post a debug log with universal patcher initial connection.
If you don`t have correct baud the cable is set to, you will get garbage data. 2 seconds are way more than avt should respond on reset.

[04colyZQ8]

I changed the the cable permanently to 527600 rate, and avt term only works with it at that baud rate.

The new cable is very slow even with the latest tuner cat update takes more than 2 seconds that’s for sure!

[antus]

You're on the right track, you can see the comments around the baud setting, some of the other devices need it, and that is where it is done. If its not on 57600 to add support in the public app you'll need to try more than once and try again after the first failure at a different baud rate for the cable you have, to keep support for the whole family of interfaces. More than 2 seconds is strange, I think that might be the whole init process, setting protocol, figuring out whats on the bus, not just the response to the init command which should be milliseconds. I agree with using a com port sniffer to see what the working tools, as well as pcmhammer where its not logging the init bytes are doing.

When I wrote the original implementation I used this old attached version sudt accessport which works nicely on a 32 bit operating system. I'd recommend win 7 32 bit in a VM. They added a 64bit version of the app later, but its not stable and causes system crashes (as it loads as a driver). So the old one in 32 bit is better. Else there is other similar software around.

[04colyZQ8]

You're on the right track, you can see the comments around the baud setting, some of the other devices need it, and that is where it is done. If its not on 57600 to add support in the public app you'll need to try more than once and try again after the first failure at a different baud rate for the cable you have, to keep support for the whole family of interfaces. More than 2 seconds is strange, I think that might be the whole init process, setting protocol, figuring out whats on the bus, not just the response to the init command which should be milliseconds. I agree with using a com port sniffer to see what the working tools, as well as pcmhammer where its not logging the init bytes are doing.

When I wrote the original implementation I used this old attached version sudt accessport which works nicely on a 32 bit operating system. I'd recommend win 7 32 bit in a VM. They added a 64bit version of the app later, but its not stable and causes system crashes (as it loads as a driver). So the old one in 32 bit is better. Else there is other similar software around.

Oh goodie that seems very interesting!!

So that sniffs what’s actually being sent to the com port that’s golden thanks

[antus]

yep and whats coming back. In this case I dont think you'll need it, but if the PC side receive is timing out because of short breaks between bytes or crashing because of unexpected or different data, you'll still see all the data you need it to read coming in the port, and you can update the code to suit.

[04colyZQ8]

You're on the right track, you can see the comments around the baud setting, some of the other devices need it, and that is where it is done. If its not on 57600 to add support in the public app you'll need to try more than once and try again after the first failure at a different baud rate for the cable you have, to keep support for the whole family of interfaces. More than 2 seconds is strange, I think that might be the whole init process, setting protocol, figuring out whats on the bus, not just the response to the init command which should be milliseconds. I agree with using a com port sniffer to see what the working tools, as well as pcmhammer where its not logging the init bytes are doing.

When I wrote the original implementation I used this old attached version sudt accessport which works nicely on a 32 bit operating system. I'd recommend win 7 32 bit in a VM. They added a 64bit version of the app later, but its not stable and causes system crashes (as it loads as a driver). So the old one in 32 bit is better. Else there is other similar software around.

How do you setup the tool? I imagine it must be on the vm all the ports im monitoring?

Because I only have a xp 32 bit vm and tuner cat is now installed on it but doesn’t connect to either cable old or new? What’s up with that I wonder installed the latest drivers from ftdi site

[antus]

Set it up something like this, and then start monitoring. I havn't used it for a while and don't have an interface on this pc, but from memory the order of when you start monitoring and start using the port matters. If it doesn't work monitoring before starting the other app, do it the other way around. You might have to try it a couple of ways. Its possible the latest FTDI drivers don't work on XP. It'd be general windows trouble shooting to see if the interface is working, and there might be something specific to whatever VM software you are using, if you are using a VM.

[04colyZQ8]

Set it up something like this, and then start monitoring. I havn't used it for a while and don't have an interface on this pc, but from memory the order of when you start monitoring and start using the port matters. If it doesn't work monitoring before starting the other app, do it the other way around. You might have to try it a couple of ways. Its possible the latest FTDI drivers don't work on XP. It'd be general windows trouble shooting to see if the interface is working, and there might be something specific to whatever VM software you are using, if you are using a VM.

Ok thanks do you press the green play button to monitor were do you select what port? Mine was saying cannot connect to that port as it is allready open

[antus]

Yes you do. the settings are under the cogs, or I think under tools menu item. Shouldn't be hard to find.

[04colyZQ8]

Got it working the new cable doesn’t seem to be sending any response messages back at times