Troubleshooting Miracast on the Surface Hub
The Surface Hub supports wireless projection through the Miracast protocol. Most wireless monitors and adapters available today use the original implementation of Miracast. The Surface Hub uses a slightly different version of Miracast known as Miracast AGO. A common troubleshooting step when wireless projection to the Surface Hub fails is to test protecting to another wireless monitor or adapter. In most cases these devices are not using Miracast AGO and do not handle wireless projection the same.
In traditional Miracast, the projecting device will connect the access point setup by the Miracast enabled monitor and then the monitor will send traffic back to the projecting device using the network channel of the projecting device. Miracast AGO is a two-step connection process. The first step is the is an initial connection using 2.4GHz. After that initial handshake, the projecting device sends traffic to the monitor using the wireless channel settings on the monitor. If the Surface Hub is connected to a WI-FI network, the access point, it will use the same channel as the connected network otherwise it will use the Miracast channel from settings.
There are generally two types of issues with Miracast to the Hub: connection and performance. In either case, it is a good idea to get a general picture of wireless network activity in the Hub’s location. Running a network scanning tool will show you the available networks and channel usage in the environment.
Start with the basics and ensure both WI-FI and Miracast are both enabled in settings on the Surface Hub. If you ran a network scan, you should see the Hub Miracast listed as an access point. If the Hub’s Miracast network shows up on the scan, but you cannot not see it as an available device, you can try to adjust the Miracast channel used by the Hub. When the Hub is connected to a WI-FI network it will use the same channel settings as the WI-FI access point for its Miracast access point. For troubleshooting purposes, disconnect the Hub from any WI-FI networks (but keep WI-FI enabled), so you can control the channel used for Miracast. You can manually select the Miracast channel in settings. You will need to restart the Hub after each change. Generally speaking, you will want to use channels that do not show heavy utilization from the network scan. Here is a list of supported channels for each region (search for “Miracast” on the page). Once you changed the channel on the Hub, you need to reboot the Hub before testing again, else the change will not be effective.
It is also possible that the connect issue can be the result of a problem on the connecting device. If the projecting device is running Windows, it should be Windows 8.1 or newer for full Miracast support. Again, for troubleshooting, disconnect the projecting device from any WI-FI networks. This will eliminate any channel switching between the access point channel and the Miracast channel set on the Surface Hub. Also, some group policy and firewall settings may be tied to a WI-FI network. It is also a good idea to ensure the latest drivers and updates are installed on the projecting device. This hotfix is highly recommended for Surface Pro 3 and Surface Pro 4 if they are on an older WI-FI driver. In device manager open the WI-FI adapter and video adapter and check for an updated driver version. Next, ensure Miracast is supported on the device. Press Windows Key + R and type dxdiag. Click on “Save all information”. Then open the saved dxdiag.txt and find “Miracast”. It should say “Available, with HDCP”. The windows firewall can block Miracast traffic. The simplest test is to disable the firewall and test projection. If Miracast works with the firewall disabled, add an exception for
Allow In/Out connections for TCP and UDP, Ports: All.
On domain joined machines, Group Policy can also block Miracast. Use the Windows Key + R and type “rsop.msc” to execute the “Resultant Set of Policy” MMC snap-in. This will show the current policies applied to the machine. Review Computer Configuration->Windows Settings->Security Settings->Wireless Network (IEEE 802.11) Policies. There should be a group policy object setting for wireless policies. Double click it and a dialog will appear. Open the Network Permissions tab and check the value of the “Allow everyone to create all user profiles” box
The last place to check is in the Event logs. Miracast events will be logged to Wlanautoconfig. This is true on both the Surface Hub and projecting device. If you export the Surface Hub logs, you can view the Hub’s Wlanautoconfig in the WindowsEventLog folder. Errors in the event log can provide some additional details on where the connection fails.
Once Wireless projection is connected, it is possible to see performance issues causing latency. This is generally a result of overall channel saturation or a situation that causes channel switching. For channel saturation, refer to the network scan and try to use channels with less traffic.
Channel switching is cause when the WI-FI adapter needs to send traffic to multiple channels. Certain channels support Dynamic Frequency Selection (DFS). DFS is used on channels 49 through 148. Some WI-FI drivers will show poor performance when connected to a DFS channel. If you are seeing poor Miracast performance while connected to a DFS channel, try the projection on a non-DFS channel. Both the Surface Hub and projecting device should use non-DFS channels.
If the Hub and the projecting device are both connected to WI-FI but using different access points with different channels, this will force the Hub and projecting device to channel switch while Miracast is connected. This will result in both poor wireless project and poor network performance over WI-FI. The channel switching will affect the performance of all wireless traffic, not just wireless projection. Channel switching will also occur if the projecting device is connected to an WI-FI network using a different channel than what the Surface Hub uses for Miracast. So, a best practice is the set the Surface Hub’s Miracast channel to the same channel as the most commonly used access point. If there are multiple WI-FI networks / access points in the environment, some channel switching is unavoidable. This is best addressed by ensuring all WI-FI drivers are up to date.