Results for W10-22H2 to follow, but in the meantime I've been looking at what happens when it doesn't work - e.g. on my newer Laptop:
ES starts to send data to the ECU as a string of command bytes - The "Mode 1" command for getting ES type data is: Hex:F4,56,01,B5. As the ALDL interface has only 1 wire which has to contain data going in both directions (i.e. it uses Half-Duplex communication), this string is reflected back to ES (Which is where latency comes into things). ES then checks this "Echo" as an integrity check - If it doesn't see Hex:F4,56,01,B5 it reports "Bad Echo", and displays what ES received back.
Here's one I did last night:
IMG_0763.jpg
So it looks like we have some sort of data corruption going on, it could be related to baud rate, drivers, or maybe even something electrical.
With that in mind I started to look at the driver stacks and noticed a difference between the 2 machines - the newer one is USB3 capable, the older one is USB2. The upper layers of USB drivers are different between the machines!
Could those that are following this give an update on whether their machines work and which USB drivers are loaded please?
To find out, bring up Device Manager, then View - Devices by connection. If your ES cable isn't plugged in you'll have to choose View - Show hidden devices.
For my USB3 equipped machine:
If I expand the entry "PCI Express Root complex", I see the USB entry - "Intel(R) USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)"
Under that I have "USB Root Hub (USB 3.0), then "USB Serial Converter", then "USB Serial Port (Com3)"
For USB2:
If I expand the entry "PCI Bus", I see the USB entry - "Standard OpenHCD USB Host Controller"
Under that I have "USB Root Hub", then "USB Serial Converter", then "USB Serial Port (Com3)"
Inching nearer to a solution..... I think!
You do not have the required permissions to view the files attached to this post.