Com0com ports not showing up in SDR Console

[Frank O]

I just installed the latest version of com0com x64 on a new HP laptop running Windows 10 Pro, then renamed CNCA0 and CNCB0 to COM20 and COM21. They show up in Windows' Device Manager. However, they don't appear as selectable options in SDR Console v3.0.25 under Tools > Options > Controllers, even after hitting Refresh on that menu, rebooting the PC, restarting SDRC, etc. I tried renumbering them as COM7 and COM8, but this didn't help. Any possible suggestions on how to resolve this? See screen shots here:

https://postimg.cc/gallery/hGXVWZc

[Simon G4ELI]

Hi,

• Images can be (should be) added as attachments so we have them for posterity.

• Look at the Device manager - there's a warning symbol, fix it. I've attachment the output from Device Manager on my system which runs well.

[Frank O]

Thanks for the reply.

I just uninstalled com0com, reinstalled it, and then ran the setup to create a com port pair in the GUI tool. See the file attachments for how this looks in the com0com GUI tool and in Windows' Device Manager. These ports are still not appearing in SDR Console.

I also noticed the warning symbols that appear in Device Manager. When I click on any of these, a menu appears for that com0com bus. The only thing that does not appear to be normal is the following for Device Status:

"Windows cannot verify the digital signature required for this device. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source. (Code 52)"

I also note differences in the organization of the Device Manager listing on your system and on mine. On yours, the com0com ports appear along with regular COM ports under a heading "Ports (COM & LPT)". On my system, there is no such heading under Device Manager, and the com0com ports appear under a free-standing heading for com0com.

I did the com0com setup and port pair creation based on what I could find in the way of docs on the Sourceforge page for com0com. About all I can think to do at this point is to look around to see if there are online videos or blog entries going through the creation of com0com port pairs to see if there's anything slightly different I can try. If any other thoughts come to mind I'd be very interested.

[Simon G4ELI]

I just looked at my code, I require the device to be correctly preset on the system, I can only assume that setupapi.dll doesn't consider the device to be properly present.

I just installed com0com, that's it!

SetupDiGetClassDevsW

[Frank O]

I've looked at some videos of com0com install, and it's obvious that what I see on my PC is different from what you and the others see. In all of your cases, com0com appears to create by default a numeric port pair (COM8 and COM9, or similar) in addition to the CNCA0/CNCB0 pair when setup runs. In those cases the numeric pair is apparently ready to use, with no further config needed. However, in my case the setup screen shows this numeric pair as "COM# and COM#". There is also the warning message about Windows not being able to validate the software. I'm following exactly the same download and install steps I'm seeing in the example videos, with a new HP laptop running a freshly downloaded install of Windows 10 Pro. I don't know what's causing the issue -- a recent Windows update?

As for other options, I downloaded and installed VSPE. On the positive side, a pair of COM ports that I defined in its control panel do show up correctly in SDR Console. They charge about $25 for a 64-bit license, which doesn't seem excessive. The only downside for me is that, as far as I can tell, the control panel must be opened to launch the com port pair each time they are used. Not a complete show-stopper, but it adds another step to getting software going during an operating session.

I also sent an email to K5FR requesting a copy of VSP Manager, which apparently is free to hams with a callsign. Waiting to hear back.

I looked at the website for Eltima Software's Virtual Serial Port Driver, but the ~$140 license price seems excessive for a utility of this scope.

[Frank O]

Just an update on this.

After trying several virtual serial port utilities, I've ended up using VSP Manager by K5FR. It's working very well for me with SDR Console, and is free. The only hitch is that it's only available to licensed hams with a callsign. There are some other alternatives that non-hams might consider.

[jdow]

I wrestled with this awhile in a brief offline conversation with Simon. Your image if the Com0Com configuration panel provides the necessary clue to make Com0Com work for you. In all your definitions you do NOT have "use Port class" ticked. That must be set so that the port is identified to the system as a serial com port. So your ports were there but not really there. They showed up in device manager as com0com devices but not as serial ports.

At the programming level I bet something like CreateFile on "\\.\COM9" would open one of the ports despite normal enumeration techniques not finding it. The "COM#" pair should be jettisoned. Changing the COM9<->COM10 to "use Port class" will probably make it work.

{^_^}

[Frank O]

Thanks very much for taking the time to determine that issue with the com0com configuration panel. It's odd, I got the impression from all of the other examples of com0com setup I've seen that no adjustment was required to any settings, the numerically named port pair was usable right out of the box. Good to know though that the issue you raised could fix it.

Today I did an operating session with SDR Console, WSJT-X and a virtual com port pair created by K5FR's VSP Manager. Everything worked great. Thus I'm inclined not to tweak the virtual com ports any further, and instead just use the K5FR software. I've saved a copy of your note, though, so if for any reason in the future there's a strong reason to reconsider com0com I'll have it to work with. Thanks again --