• buhmanb

    Hi Andy, 

    Both of your issues: No monitor on several mics & Problems setting the Name via the Inventory view

    Have the symptoms of something blocking the network traffic from the devices (QLXD4) to WWB.  My recommendation:

    1. Confirm the IP addresses and Subnet Mask are setup correctly on your computer and the devices.  
    They must be in the same network range.  (e.g. 192.168.1.X) 
    They must be using the same Subnet mask (e.g.

    2. Confirm that all firewalls have been turned OFF or have been configured to allow traffic into WWB6.
    Since you're on Mac - check out:

    3. I believe you are using WiFi?  The QLXD metering and responses use IP multicast.  I have seen some cases where WiFi access points are not configured to allow multicast traffic and/or in environments with high WiFi congestion that some access points drop the multicast traffic.  It can depend on the settings and/or manufacturer of the WiFi access point.  See the documentation for your particular WiFi access point.

    You could try choosing a less crowded WiFi channel, or connecting your computer to the network via wired Ethernet to compare results.

    Try those things and let us know.  It may be something else specific to your environment.  In any event we can get it working for you.

    Hope that helps! -Brian

  • buhmanb

    Right Click on the channel strip to display options.

    One of the options is "Channel Strip Size" and select from: Small, Medium, Large


  • buhmanb

    This has the symptoms of the Windows Firewall (or some other firewall software) blocking the status updates from the Shure device.

    You will need to configure the firewall to allow Wireless Workbench and a helper process called snetDameon.exe to communicate on all networks.  This is the fastest and easiest method I've found:

    1. Exit Wireless Workbench
    2. Open the Windows Firewall: Control Panel > All Control Panel Items > Windows Firewall.  
    3. Choose "Advanced Settings" -> This opens the "Windows Firewall with Advanced Security" dialog
    4. Select "Inbound Rules" and sort the inbound rules by name.
    5. Select and Delete the Inbound Rules: "snetDameon" and "Wireless Workbench 6"
    6. Restart Wireless Workbench
    7. Windows Firewall will prompt you with 2 "Windows Security Alert" 
    8. Check all 3 Check Boxes for "Domain Networks, Private Networks, and Public Networks" then "Allow Access"
    9. Now the RF, Audio, Battery, etc. values should update in the monitor tab and the Property Panel.

    Hope that helps

  • buhmanb

    Here are a few more notes that I hope will answer your questions:

    Regarding Analysis:

    • The pre-programmed Group/Channel maps are typically created (a) adhering to the Standard or More Frequencies compatibility profile and (b) assuming clean spectrum (i.e. assumes no other high power transmitters in the same spectrum). 
      • (a) If you use WWB and analyze the channels using the Robust compatibility profile, it is quite likely the Analysis will identify conflicts because the Robust spacing rules are wider.
      • (b) If the run time scan done by WWB identifies a "high power" transmitter (> -60 dBm), the Analysis will take the theoretical intermods created by those in addition to the theoretical itermods from the planned channels.  So those theoretical intermods may be the cause of the conflicts.
    • If you click the check-box next to the Analysis button that will create a detailed report which can be saved.  Sending a copy of that report, along with a copy of the Show File and Scan File would make it easier to specifically pinpoint why you're seeing conflicts.  You may see the reason by looking at the detailed report yourself.

    Regarding why you see a little noise with the WWB Scan/deploy vs clean after the ULXD Group Scan & deploy.  Here's my theory:

    • ULXD Group Scan:
      • I'm going to assume for example that the Group Scan was run on ULXD L50, and you chose Group 01, which has 67 "potential" channels, of which maybe 40 of them were deemed OPEN
      • When the Group Scan deploys, it pics the lowest RSSI from those 40 OPEN channels to send to your 16 physical channels.   
      • So those channels show up as very clean.
    • WWB Scan & Deploy:
      • I'm going to assume that the live scan was taken, using an Exclusion Threshold of -85, and that only 16 channels were requested for coordination  (i.e. no additional backups were requested)
      • The coordination found 16 channels that are compatible, and under the Exclusion Threshold.
      • When it comes time to Deploy, WWB has those 16 frequencies to pick from - some of which might see a little noise.  Essentially this deployment had fewer channels to pick from.
      • You could try requesting more backups, then when performing the Assign & Deploy there will be more channels to chose from.  By default the Assign and Deploy picks the lowest RSSI.
      • Note the Rank (stars) in the Assign & Deploy dialog.  Three stars means lowest RSSI, with one star you might see a little RF activity. 

    Hope that is helpful for you!  Best luck with your coordination!

  • buhmanb

    To best answer your question regarding your specific scenario I'd have a few questions to clarify with you first.

    Here is what I imagine happened:

    1. Your configuration consists of 4 ULXD4Q units from the L50 RF Band.  All networked together.
    2. Co-worker used the Group Scan feature on one of the ULXD4Q units and selected (for example) Group 02, then "Deployed" to the rest of the units.

    As a note - the Group/Channel maps are pre-coordinated such that all of the channels within a group are compatible with one another.

    The ULXD4 Group Scan measures the RF Level (RSSI) of ALL of the Group/Channel maps:
    If the RSSI < GroupScanThreshold (-85 dBm), the Channel is considered "OPEN" and can be deployed to a receiver.  (e.g. G:02 Ch:02 Freq:633.325 is at -97 dBm)
    If the RSSI >= GroupScanThreshold, the Channel is NOT_OPEN and will not be deployed to a receiver. (e.g. G:02 Ch:01 Freq:632.500 is at -72 dBm)

    Group Scan Deployment only sends out channels that are OPEN.

    1. At this point all of the ULXD4Q channels are operating on: (for example)

    G:02 Ch:02 Freq:633.325
    G:02 Ch:04 Freq:634.775
    G:02 Ch:07 Freq:637.700
    .... etc ...
    G:02 Ch:56 Freq:688.575

    1. Later, you connected WWB and the units showed up in the Inventory Tab.
    2. Changed to the Frequency Coordination Tab
    3. Used the "Select Frequencies From Inventory" and chose all of those ULXD channels
    4. Used the "Recent Scans" dialog to capture a scan from one of the ULXD4s.
    5. At this point you can see the overlay of the channels on the Scan.  The RED line is WWB's configurable Exclusion Threshold.
      1. From the attachment, it looks like you lowered the Exclusion Threshold to -99 dBm.
    6. Among several other factors - when WWB does Analysis it uses that Exclusion Threshold to identify which frequencies to avoid. Operating a channel on a frequency who's RSSI was measured over the Exclusion Threshold will trigger an Analysis warning. 

    So I suspect that your WWB analysis is using a threshold that is lower than the one used by the Group Scan.

    A more general note:
    Group Scan / Channel Scan - on the devices is simple and effective for most configurations and RF Environments.  The pre-programmed Group/Channel maps are pre-coordinated and assessed against a simple scan and fixed threshold.

    WWB's Frequency Coordination enables tailoring for more challenging configurations and RF Environments.  The output of coordination (CFL) is essentially a customized Group/Channel map specific to your run-time environment.

    WWB's Frequency Coordination also allows you to select the TV channels you wish to avoid via either a lookup, or you can manually check them.


  • buhmanb

    That is a very creative idea, but will not work as Apple's Internet Sharing creates a separate private network for "WiFi" and is performing Routing / Network Address Translation functionality.

    For example - The wired devices on your network may have IP addresses:
    ULXD4 :
    Mac (Wired interface):

    But the Mac's Internet Sharing over WiFi is acting as a router to a private network, and is assigning IP addresses to your "WiFi" devices - such as:

    That "routing / NAT" functionality is preventing the instance of ShurePlus Channels on the iPhone/iPad from being able to discover and connect to the ULXD4, QLXD4, etc..

    Even if you manually set the IP addresses of your ULXD4, etc to 192.168.2.x, the Routing / NAT functionality will block the necessary traffic.

    Maybe there is some 3rd party software that can make the Mac act more like an Access Point (without the routing / NAT) - but I'm not aware of any.

    When you use a Router / Access Point such as the Apple AirPort Extreme - the private network you are creating includes the devices (ULXD4, QLXD4, etc..) as well as the iPhones and iPads that are running ShurePlus Channels.

    Your best bet would be to get a Router / Access Point such as the Apple AirPort Extreme.

    Hope that helps!







  • buhmanb

    There is an Audio Overload Hold feature that was introduced in WWB  

    • Audio Overload Hold enables the user to hold an overload event on any audio meter of a networked Shure device.  Once enabled in Preferences, audio meters that experience an overload event will hold their clip indicator, and can be cleared by clicking anywhere on the audio meter.  Also, a right-click option in the Monitor tab can clear all audio overload holds.

    Look under the Preferences >  General > "Enable Audio Overload Hold for all audio meters"

    Is that what you're after?  Or are you looking for something more similar to the RF History Plot but for the audio meters?

    Thanks for the feedback!

  • buhmanb

    Some background that may help your investigation and/or resolve the problem.  

    UHF-R uses a different protocol suite for network discovery and device management than the newer products such as ULX-D, Axient, PSM1000, etc.   So it is most likely that something in this network configuration is blocking or not configured for the newer protocols to work.

    The biggest difference is the newer protocols utilize multicast messaging for discovery and device management.

    Firewalls, security software, and/or managed switch settings may be blocking the multicast traffic.

    • Make sure the switch is configured to allow multicast
    • Make sure the firewall and/or security software on the computer are not blocking multicast

    One thing to try is:
    Connect the computer directly to one of the ULXD4 units using unique static IP addresses.  
    If the ULXD4 now is discovered, then there are likely switch settings that need to be configured.
    If the ULXD4 is still not discovered, there are settings on the computer that need to be configured.

    Another point about the ULXD4D & ULXD4Q - are those have 2 network ports to enable some Dante features.  In troubleshooting scenarios I'd recommend eliminating variables first: get basic discovery / device manage working first, then configure for more advanced features.

    1. Set Configuration as Switched
    2. Connect Ethernet cable to the Primary port only (avoid daisy chaining for now)
    3. Make sure the "Shure Control" and "Dante" IP addresses are set appropriately to unique IP addresses

    You're probably aware of much of that already - but it is worth noting.

    Hope this helps!



  • buhmanb

    1. One thing that can cause those symptoms is a Firewall blocking the data transfer between the Spectrum Manager and WWB.

    If you are using WinXP - check Control Panel > Windows Firewall
    * You can temporarily turn OFF the Firewall then re-start WWB - to see if that is a factor in the problem.
    * And/Or look at the Firewall Tab: Exceptions and confirm that the following are allowed: Wireless Workbench 6, snetDameon, Shure Update Utility

    If you are using some other Firewall or Internet Security application - make sure they are allowing: Wireless Workbench 6, snetDameon, Shure Update Utility

    2. It could also be a subtle network settings difference causing the transfer to fail.  Verify the the network settings for the Spectrum Manager and Wireless Workbench:
    a) IP addresses on the same network.  (e.g. and, etc.)
    b) Subnet Masks are the same. (e.g.

    If the subnet masks are different this can cause some "one way" connections leading to odd application behavior.


    3. It could be something else - but those are the first 2 things I'd check.

    How large is the CFL in the Spectrum Manager right now?  
    From the AXT600 Menu press "CFL"
    The top row lists the number of frequencies.  Is that an extremely large (i.e. 200+) ?

    If you know you no longer want that list you could either:
    a) AXT600 Menu: CFL > More > Clear  : to clear out the list - then try starting WWB again.
    b) AXT600 Menu: Util > More > Reset All  : To factory default the AXT600, potentially cleaning up anything stale that could cause WWB to fail in loading.

    Best luck - hope that helps!


  • buhmanb

    That is shorthand for the intermodulation products (IMs) that occur when multiple transmitters are used.

    2T3O - 2 transmitter, 3rd order IM
    2T5O - 2 transmitter, 5th order IM
    3T3O - 3 transmitter, 3rd odder IM

    There is background on Intermodulation in the publication "Selection and Operation of Wireless Microphone Systems" starting on page 26


    Or on Wikipedia:

    WWB does the number crunching to identify where the IMs occur and warn you those conflict with your setup.

    Hope that helps!

© 2009-2014 Shure Incorporated All rights reserved.
  • Privacy
  • Powered by RightNow