Win 10 and Microbit Setup Manager

[VO1HP]

Does anyone know if there is a problem with Win 10 and Microbit manager?....in my case I can never connect to the RRC Control and virtual com ports are never created.  I have reinstalled Setup Manager several times and also reinstalled Win 10...same result.

Yes I have the USB cable plugged in  and have removed Power Manageent from each USB Root hub. 

This is happening on my main shack PC where I want to run N1MM+ and DXLab  suite.

Frank VO1HP

[VO1HP]

This the error I get when trying to configure DX Commander

CIVComm.ReadPortText: Error reading comm device
30-Oct-2015 01:35:04 > program error 8020 in module
CIVComm.ReadPortText: Error reading comm device
30-Oct-2015 01:35:04 > program error 8020 in module

[VO1HP]

On this same Win 10 machine....I deleted all the USB Com ports and plugged in the RRC and suddenly the RRC virtual Com ports were created.
DX Commander only works one way DXCommander ---> K3..i.e. can change mode and freq manually. Does not work K3 ---> DXCommander....turning knob and changing mode on K3-0 does not change Commander.

N1MM+ on same machine is working FB reading Freq and Mode.   Go figure.  Something is preventing K3-0 from talking to DX Commander......possibly a setting in RRC Control?

[EI3KD]

Hi Frank,

FWIW - there's something strange with the virtual ports created by the setup manager on Windows 10. Like yourself, for me N1MM+ CAT (and, IIRC, OmniRig) works fine using the virtual port directly, but neither DxLog, WinTest, nor DxCommander do. That problem didn't exist on Windows 7, where everything worked fine.

I've pretty much tried everything I can think of to get it to work, or find a work-around, but have given up...

Regards, Mark EI3KD

[Jan (Microbit)]

It's annoying to read about this problem with the virtual com ports(USB<->COM) on Win 10 and still not being able to "catch it" so that we are able to find out what is going on. The Setup Manager does not actually install the ports, it merely adds four so called 'INF files' that describes the ports and their relationship to the RRC. So uninstalling Setup Manager does not remove the ports and their drivers. To remove them one has to use Device Manager. The actual installation takes place when connecting the RRC to the PC.

Windows 10 differs from both 7 and 8 in that an INF file for a COM Port is not mandatory. While 7/8 failed installing the Com Ports without an INF file, Win 10 installs them but with a generic name like 'USB Serial Device'. But to our knowledge if an INF file is provided it should not require a different content than for Win 7/8, so Setup Manager installs the same INF file for all version of Windows. It would be interesting to know it the COM Ports work without the INF file, though as I mentioned we are not able to reproduce the problem ourselves. Would it be possible for some of you having the problem to assist us in fixing this? If so you could start by attaching the 'ComportInstallerLog.txt' file which are created in the 'Documents\MicrobitLogs' folder when running the Setup Manager installation.

[EI3KD]

Jan, I can try to help - but first can we be clear about which problem it is that we're trying to track down?

If you're worried about correct installation, then I've had no problem with that on Windows 10 - i.e. I get the four ports installed and correctly named "RRC1258 COM0", etc. From that point of view, everything looks normal.

The problem I have is that the ports only work correctly with a few programs, and not with others. For example a port used for CAT, in my case, only works in N1MM+ and OmniRig, but not in DxLog, WinTest, DxCommander and others - all using the same settings. I guess there must be something different in the way those programs open/use the com port, but I can't figure out what it is. It certainly seems to be something specific to Windows 10, so it could well be out of our control...

Regards, Mark

[Jan (Microbit)]

Jan, I can try to help - but first can we be clear about which problem it is that we're trying to track down?

If you're worried about correct installation, then I've had no problem with that on Windows 10 - i.e. I get the four ports installed and correctly named "RRC1258 COM0", etc. From that point of view, everything looks normal.

Correct installation is not only about the ports getting the correct names and no error codes. The devil might lie in details not visible

The problem I have is that the ports only work correctly with a few programs, and not with others. For example a port used for CAT, in my case, only works in N1MM+ and OmniRig, but not in DxLog, WinTest, DxCommander and others - all using the same settings. I guess there must be something different in the way those programs open/use the com port, but I can't figure out what it is. It certainly seems to be something specific to Windows 10, so it could well be out of our control...

Regards, Mark

While looking for clues on the Internet I found this:

Developing a Cross-Platform app to work with an embedded device. App targets Windows Vista, 7, 8, 10, & Mac OSX. App works fine under all target OSes except Windows 10.

Updated to Windows 10 and communication over serial is very problematic. Communications from Xojo's Serial object appear to reach the device fine, but communications from device to Xojo are not. Communications from device seem to be buffered somehow, the initial communication always fails to arrive, but if I forcefully send a second it will reach Xojo just fine.

which, if I understand what VO1HP wrote correctly, is what he sees too. If so then W10 has some "odd behaviour" not seen in other OSes.

Btw, have you installed the "fall/autumn" update to W10?

[Jan (Microbit)]

The problem I have is that the ports only work correctly with a few programs, and not with others. For example a port used for CAT, in my case, only works in N1MM+ and OmniRig, but not in DxLog, WinTest, DxCommander and others - all using the same settings. I guess there must be something different in the way those programs open/use the com port, but I can't figure out what it is. It certainly seems to be something specific to Windows 10, so it could well be out of our control...

Regards, Mark

And maybe the programs that are "stubborn" and resends in a different way works while the others don't?