SO2R config - USB COM port confusion

[vk4iu]

G'Day,

I am getting very frustrated with the allocation of real PC COM port numbers to the USB serial devices in the RemoteRig boxes.

I know this is a Windows issue, and are looking for advice on how to retain the COM PORT configuration after initial setup of the RemoteRig devices and system.

I have yet to understand the process, but if I have occasion to reboot the my PC, especially after the RemoteRig devices have been disconnected or powered off - Windows 7 seems to have a mind of its own, allocating new port numbers to the 4 devices in the USB connection - eight in my configuration.    Usually only four change, but the change can be to either RemoteRig USB connection.

I have an MicroHam MK2R+, Station Master SO2R configuration, with two Elecraft K3/100s driven remotely by two K3/0s, both RemoteRig sets are running in TWIN mode.  After correct configuration, the system works very well for hour after hour - all on a private local area network.  No "Internet" is involved.

But, if I do other things with the "control" PC, and ultimately reboot for example, Windows 7 may allocate a new set of com ports for one of the RemoteRig devices.  When the "re-config" is finished, I usually finish up with four new com ports, and the original ports are listed as "hidden devices" in Device manager.

I have experience setting up com ports.  So before initial setup, I moved all other devices - Bluetooth serial ports for my Nokia phone, other USB serial ports, to numbers higher than 8, that is  20 through 30.  Before I started with the RemoteRigs - all COM ports below 8 are free and unused - and any hidden devices below 8 uninstalled/deleted.

The PC is an i7 based Dell notebook with NO hardware serial ports.

When the Remote Rig Management software is installed, and the RemoteRig USB connection made, one at a time, the first device is usually allocated ports 5 to 8.  The second device usually gets ports around 8 to 13, which I then reconfigure to ports 1 to 4.   I then usually reboot the PC, turn the radios on/off and verify correct PC operation and configure the software in the control PC - N1MM, Logic, TRX Manager, OmniRig etc etc.

The complete system then functions correctly - the Microham gear follows along with the normal operation of the K3/0-K3, and any software I run on the control PC against the USB based com ports to the control RemoteRig device functions as I expect.  I can power the K3/0 off and on, and it all works as expected.

I understood that each USB device has some sort of identifying number to allow consistency of allocation.

What triggers a need to reallocate the COM ports in the Control PC when I later reboot the Dell notebook?

What procedure is recommended to minimise - perhaps eliminate - this problem?   See also another topic "Correct procedure - remote operation."

Peter VK4IU

[vk4iu]

... Windows 7 did it again.

WIN 7 reconfigured the coms ports, so I was prompted to write the first item in this topic.

After writing the topic, I then went back to my system, deleted the "hidden devices" Win 7 ignored, and reallocated the com ports as I wanted - that is used "Properities, Port Settings, Advanced" and changed the port number to "my" port selection.

I then rebooted the PC to ensure I would be consistent over time.  All devices remained powered.

On reboot, Win 7 reallocated the port numbers, of the second RemoteRig devices, turning my selections again into "hidden devices".

Why don't I just leave Windows set the port numbers?  Good question.

N1MM will not use ports above 8 - legacy software.  TRX Manager limits one to 1 to 16. OmniRig limits one to 1 to 20.  MMTTY allows 1 to 16 for FSK.

I want the RemoteRig ports to use 1 to 3, and 4 to 6, with FSK devices above 8.  That leaves some flexibility below 8 for other devices - a WinKey link, a link to the MK2R+ for N1MM.

Attached is a snap of the latest confusion - notice that Win 7 has allocated the FSK port to COM9 already allocated to the phone.

Peter VK4IU

[Jan (Microbit)]

Peter,

I did some tests on my Win 7 64-bits system:

1/
Attached one RRC and got four COM ports -> 12,13,14 and 15

2/
Attached another RRC and got the "installing drivers balloon". Four new ports appeared -> 21,23,24 and 25

3/
Rebooted the PC and the ports kept their allocated numbers.

4/
Reallocated COM13 to COM2

5/
Rebooted once again and still the numbers remained the same.

6/
Plugged out and in several times and still the numbers were ok.

So I am not able to see the behavior you describe and also I do not understand why Windows reinstalls/renumbers the ports in your case.

[dj0qn]

Peter,

As long as you:

a) Use the same USB ports for each device
b) The port was not already used previously

You will always get the same port upon reboot. The problem probably lies with the b) above:
at some point this serial port was used and is "blocked" within Windows. Clicking on "show all
devices" will NOT show all old devices no longer used. That is what is probably confusing you.

To solve that, do the following: make a batch file containing the following two lines, or else
enter then into a DOS box in order:

set devmgr_show_nonpresent_devices=1
\windows\system32\devmgmt.msc

Then when the Device Manager comes up, click on "show all devices". These older no longer
used ports will magically show-up. Then you can delete them. I hope this solves your problem.

If things really are nasty, one can easily completely delete all USB devices from the Device
Manager and reset Windows. In this case, you need to make-up a batch file containing
the following lines:

devcon.exe remove =USB
devcon.exe rescan =USB

Be very careful if you use this, since all devices will be reallocated new ports from scratch.

73,
Mitch DJ0QN / K7DX

[vk4iu]

Thank you Jan.

I notice your systems gives nice neat four sequential numbers for the ports - all high numbers.  It confirms for me the problem lies with Win 7, previous use of the com ports, and the "left overs" of the USB system as a whole.  But a method to get consistency is escaping me.

Thanks for your imput Mitch.

I have already set devmgr_show_nonpresent_devices=1 and made numerous attempts at removal, moving com ports and rebooting.  Sometimes it all works as one wants - but other times re-allocation occurs.

I note that one of the two RemoteRig devices seems to re-allocate more  often than the other., and the numbers follow odd sequences - rarely 4,5,6,7 more likely 4,9,6,7 and I never see numbers like 16,17,18,19.

So, as I search for a solution, my strategy will be to reset with "devcon remove=USB", avoid all the other USB devices, and work with the RemoteRig devices until I have a stable solution.  I will also try with a "clean-skin" Compaq Notebook I have to check the potential of the 64bit Win 7 Dell as a problem.

In Win7 I see no "show all devices", but there is "View, Show Hidden Devices", which with "devmgr_show_nonpresent_devices=1" does show what I expect.

I have a GPS attached to my Faros system - another Win XP system.  Windows was insisting that the GPS was a serial mouse.  I am familiar with the "re-enumeration" process that occurs on a Windows reboot count with Plug and Play devices.  I suspect that that process on my Win 7 64 bit system might be having some affect as well.

Peter VK4IU

[vk4iu]

G'Day,

After a long process I think I have some stability to my configuration.  Touch wood!

As I suspected, the problems seem to have been in the Windows 7 process of allocating COM ports to USB connections.

I proceeded as follows ...

I went to a "hopefully" clean Notebook and Windows Vista.  It was a mistake.  The Notebook had a "modem" that could not be "disabled" in the BIOS and was using COM3.  The issues I ran into were more complex than with the Dell notebook and Win 7.  But, it was a good exercise - the process improved my knowledge about removing, adding, reconfiguring USB devices and COM ports.

I returned to the Dell Win7 64 bit system.  I took Mitch's advice and purged the system of USB devices.  I then carefully rebooted again and again, rebuilding my system with everything apart from the RemoteRig devices.  It was not hard, just tedious, carefully adding USB devices and letting Win 7 re-install them.  Mainly the usual disks, webcams and keyboards and mice etc etc.

The one complication was the Bluetooth system - it adds a "standard Bluetooth modem" which I moved to COM31.

The system was checked extensively to make sure it functioned correctly.

I then made sure the RemoteRig systems were functional by themselves - stereo audio, VFO control, and that the backend to the MK2R+ functioned correctly.

I re-installed RemoteRig Manager with the COM port drivers.  The latest version - 1.17.

I then plugged in a USB 2 hub, directly into a USB 2 port on the Dell, and subsequently each RemoteRig link, one at a time.   The COM ports were allocated OK - 1,2 and 3, and 4,5, and 6, and I set the correct COM ports in my software and all functioned correctly. The FSK ports were moved to 11 and 12.  Everything functioned correctly.

But ... been there done that before.

I followed the same procedure for each of the subsequent reboots ...  unload the logging software, turn off the radios, and power down the PC.  The RemoteRig devices remained powered at all times, and connected via the USB cable at all times.  I used Logic and OmniRig for the tests.

I have two sets of Remote Rig, one set is H/W Rev 6, and the newer set H/W Rev 8.

When I rebooted, the control RemoteRig H/W 6 was re-configured by Win 7 to new COM ports - 13, 10, 9, and 7 for FSK.

I updated to the different ports in OmniRig, loaded Logic, and all tested OK.  PC control of the VFOs, radio control of the VFOs, band changes, stereo audio , and the backend to the MK2R+ for both radios.

I powered down again - all remained plugged in - the RemoteRigs powered at all times.

I started the system - the H/W Rev 6 box again reallocated COM ports - this time to 16,14,15, and 17.  OmnRig goes to port 16 so I simply reset the ports in OmniRig, and again the system tested OK.

This time I unloaded the software, reset the com ports to 4,5,6 and 12, and powered down again.

This time - no re-configuration - all ports remained the same and the system functions correctly.

I have since powered down, restarted the system many, many times.

The system is still functional - touch wood.

Re-configuration has never occurred with the H/W Rev 8 devices.  I find that a little odd.

Throughout, the RemoteRig devices by themselves have worked flawlessly - I have always been able to run the system with the K3/0 frontend radios, and listen to the audio coming across the network.  The only issue has been Win7 and the allocation of COM ports via the USB connection.

I shall add to this topic as necessary.   Please ... please! ... wish me luck.

Peter VK4IU

[Jan (Microbit)]

You are certainly doing your homework very well!  I send you tons of good luck which will prohibit Windows from messing up your COM ports again! 

[vk4iu]

The luck has worked - sort of.

The system has been operational for 24 hours.

I needed to reboot the system for reasons not related to the RemoteRig or USB.

As Windows 7 started, one of the RemoteRig devices was reconfigured. 

Suggestion:  a feature request - add a tag to the USB ports names to indicate which box the ports are from - s/n would be nice - or IP number perhaps.

So without touching anything, I started my radio software - Logic, using OmniRig for the com ports.  No changes have been made to any of the software or hardware - just a reboot.

The system is operational, but the radios have swapped places - the ports for the left rig are now in use on the right rig - and vice versa.

The USB ports for the RemoteRig USB devices have been completely swapped.

If think there may be something in the fact that I am using two systems, one H/W Ver 8, and the other H/W ver 6.

Peter VK4IU

[Jan (Microbit)]

Peter,

I have dug deeper into this and come to think that part of your problem might lie in the fact that the USB serial number is the same for both of your boxes. When we designed the USB interface we didn't use unique serial numbers assuming it would work anyway, but maybe it does not do that in all cases. Which fw version are you using in your RRCs? If you are using the latest 2.68 I could make a 2.69 with a different serial number for you to try. If it works then we have learned something new and you will get a system that works ok.

[Jan (Microbit)]

And for your feature suggestion: To my knowledge it is not possible to add such "dynamic" information to the names of the USB Com ports when using multiple devices of same kind.

[vk4iu]

G'Day,

Being an SO2R configuration, I call my systems "left" and "right" - but given what has just occured, I will name them by the IP address - 169 and 171.   I'm happy to do any testing you ask for.   The info panels follow.

A change to the USB names would be great.  Windows did not dream up the RRC1258 COMx (COM0/1/2/FSK).    I guess this may be embedded in the INF - Windows does the lot, with never a chance to dynamically change the name.

I did a search of the Registry for one of the names on my system.  What sets the - so called - FriendlyName value for the port?

Peter VK4IU

Address 169 Info Panel is:

Name   Value
Company   Microbit
Product   1258
PID   4
Version   5
HW   6
Software   2.66
Bootloader   1.10
Compiler   4.6.2
Build   Feb 5 2013 14:37:20
ROM/RAM   443952/56800
ETH-RAM   2944 (max 3kB!)
ResetSrc   0 [3]
Uptime   221593
    
Serial number   4217
MAC address   00:1e:fd:01:87:19
IP address   192.168.2.169
Netmask   255.255.255.0
Gateway   192.168.2.139
DNS   192.168.2.46
Wi-Fi network   module not present


Address 171 is:

Name   Value
Company   Microbit
Product   1258
PID   4
Version   7
HW   8
Software   2.66
Bootloader   1.10
Compiler   4.6.2
Build   Feb 5 2013 14:37:20
ROM/RAM   443952/56800
ETH-RAM   2944 (max 3kB!)
ResetSrc   0 [3]
Uptime   219474
    
Serial number   5948
MAC address   00:1e:fd:01:8d:dc
IP address   192.168.2.171
Netmask   255.255.255.0
Gateway   192.168.2.139
DNS   192.168.2.45
Wi-Fi network   module not present

[vk4iu]

... I have just had occasion to reboot my system again today.  Add Gif Construction Set software - that required a reboot.

USB ports for the H/W Ver 6 are missing - have NOT been configured - the ports are there, but as hidden/unconnected - and the H/W ver 8 system has assumed the ports for the H/W ver 6 system - that is, the ports have reverted back to those two reboots ago.

During the reboot, there is some sort of "race" going on between the two RemoteRig devices - wrt USB.

No changes have been made - just a simple restart of the system.

I will wait further advice before making any changes to the system.

Peter VK4IU

[vk4iu]

... I could not resist.

To show there is a race going on, I restarted again, but this time I removed the device HW REV 6, and when the system had completed the restart, I plugged it back into the same port.

No re-configuration occured, that Win 7 told me about.

When I plugged the device with H/W Rev 6 in both devices have the original ports I configured.  Left(.169) is left and right(.171) is right.

The set of ports configured when the devices swapped places are now listed as hidden/unconnected devices.

I made no configuration changes, to hardware or software - simple restart only, with delayed plugging of the RemoteRig device with H/W Rev 6.

Peter VK4IU

[Jan (Microbit)]

Peter,

Of course Windows does not "dream up" the names of the COM ports, they are, like you say, taken from the INF files used for the four ports. But the problem is that no matter how many RRCs you connect to the system they all will fetch the names of their ports from the same INF files and so the names will be them same. The reason they will use the same INF files is because they have the same USB vendor and product ids. So in order to get different names one would have to provide a different set of INF files for every RRC connected to the system and also change the product id so Windows sees them as different devices. At least that is my understanding of how it works.

As for the "race" I have a strong feeling it is cause by what I mentioned before, the RRCs having the same USB serial numbers. That serial number is there to help Windows distinguish between devices having the same USB vendor and product id, though as I said we did not think it was that important as it very well might show being.

I will make a version for you which has a different USB serial number and then we will see what happens.

[Jan (Microbit)]

Peter, I have sent you an email