bperrybap
Contributor
Doug,
Just noticed that ACI/Oceanlog 2.x can select the incorrect com port when
locating the USB data cable com port.
This occurs because the s/w looks in the registry for
HKLM\HARDWARE\DEVICEMAP\SERIALCOMM\VCP0
While this method is nice in that the "VCP0" device will be created dynamically
when the USB data cable is plugged in, it is not guaranteed to always be VCP0 for
the Pelagic data cable.
If there is any other device in the system that creates a virtual comm port prior
to the Pelagic data cable being plugged in, the pelagic data cable will get assigned
something other than VCP0.
So say somebody has another USB serial device in their system it would be assigned
VCP0 and the Pelagic data cable would be assigned VCP1 when it is plugged in.
Virtual comm ports can also be created for certain types of other devices
or even debugging tools.
A better/foolproof method is to locate the com port by running
through all the enumerations of the FTDI devices and subinstances under the
HKLM\SYSTEM\CurrentCotrolSet\Enum\FTDIBUS hive and look for
"USB Download Interface" in the "Friendlyname" values of each sub instance.
This will indicate which device is a Pelagic USB data cable.
Then you can grab the "Portname" value from the "Device Parameters" hive
of that instance.
This gives you a comport name but only tells you that the device driver
has been installed and the cable has been plugged in but doesn't you if the
cable is currently plugged in.
To tell that, you must then go back to the ...\DEVICEMAP\SERIALCOMM hive
and check each virtual comport instance for a comport name that matches
the name you got from scanning the FTDIBUS instances.
If there is a match, you know that the Pelagic data cable is currently plugged in.
Not as simple as the current method used in OceanLog/ACI but it will always work, even when the PC has other virtual comports installed.
--- bill
Just noticed that ACI/Oceanlog 2.x can select the incorrect com port when
locating the USB data cable com port.
This occurs because the s/w looks in the registry for
HKLM\HARDWARE\DEVICEMAP\SERIALCOMM\VCP0
While this method is nice in that the "VCP0" device will be created dynamically
when the USB data cable is plugged in, it is not guaranteed to always be VCP0 for
the Pelagic data cable.
If there is any other device in the system that creates a virtual comm port prior
to the Pelagic data cable being plugged in, the pelagic data cable will get assigned
something other than VCP0.
So say somebody has another USB serial device in their system it would be assigned
VCP0 and the Pelagic data cable would be assigned VCP1 when it is plugged in.
Virtual comm ports can also be created for certain types of other devices
or even debugging tools.
A better/foolproof method is to locate the com port by running
through all the enumerations of the FTDI devices and subinstances under the
HKLM\SYSTEM\CurrentCotrolSet\Enum\FTDIBUS hive and look for
"USB Download Interface" in the "Friendlyname" values of each sub instance.
This will indicate which device is a Pelagic USB data cable.
Then you can grab the "Portname" value from the "Device Parameters" hive
of that instance.
This gives you a comport name but only tells you that the device driver
has been installed and the cable has been plugged in but doesn't you if the
cable is currently plugged in.
To tell that, you must then go back to the ...\DEVICEMAP\SERIALCOMM hive
and check each virtual comport instance for a comport name that matches
the name you got from scanning the FTDIBUS instances.
If there is a match, you know that the Pelagic data cable is currently plugged in.
Not as simple as the current method used in OceanLog/ACI but it will always work, even when the PC has other virtual comports installed.
--- bill