Guides & Troubleshooting

How to Print out System Information W2K

This document provides guidance on configuring SNMP traps for Datapath systems (VSN, VSN Micro and iolite) to monitor Datapath software (Wall Monitor, Wall Control, Wall Monitor Server).

Installing the SNMP Trap Provider

The SNMP Trap Provider is the service that generates traps. It is not installed by default by a Windows installation. To install the provider the following steps must be followed:

1. From the Control Panel, select Programs.

2. Under Programs and Features, select Turn Windows features on or off.

3. In the Windows features list, scroll down to Simple Network Management Protocol (SNMP) and expand the list so that you can see WMI SNMP Provider.

4. Select the check box for WMI SNMP Provider. The check box for SNMP feature is selected automatically because the provider requires SNMP.

5. Click OK.

Registering a Remote Workstation

Having installed the trap provider, you must now register the machine to which it is going to send any traps. To register a remote machine you must use the Services configuration program, which is available in the Administrative Tools on the Control Panel.

1. Open the Services control program from the Control Panel (or type services.msc in the Start Menu).

2. Select SNMP Service from the list of services and double click on it.

3. On the resulting Dialog box go to the Traps tab.

4. Go to Community name edit box and insert a name to describe the connection. E.g. public.

5. Press Add to List button.

6. The Add button is now enabled. Press this button. An SNMP configuration dialog will appear.

7. Enter the Host Name or IP Address of the trap destination. Click Add.

Setting Up the Event Traps

The final step is the setup the Events logged by our applications that are translated to Traps. We can do this through the program evntwin.exe which is a Windows component.

1. From a command prompt or the Start menu, type in and run evntwin.exe.

2. This will display a list of currently configured traps. Select the Custom configuration type, and the Edit >> button will become active. Select this.

3. The Application drop down contains a list of applications that are registered with the Event Viewer to provide events. This will include Datapath software (e.g. Wall Control, Wall Monitor)

4. Select an application and the Events List will be populated with the events that can be generated by the application.

5. Select an event from the Events List that you would like to translate to a trap. Click the Add button, and a dialog box will be displayed describing the Trap. If you are happy with its configuration click Ok to add it to the translation list.

6. To complete the changes click Apply changes on the translator dialog.

Adding the event in the dialog box above would trigger a trap if Wall Monitor were ever to generate a Red Alert and shut the system down. This might occur if the fans failed and the temperature rose to a critical level.

Trap MIB

The SNMP TRAPS will all be generated using the Microsoft's private enterprise MIB branch. This MIB uses the prefix 1.3.6.1.4.1.311 (RFC1155-SMI).

Traps will be generated to the specified hosts configured using the SNMP services. An application (MIB Browser/trap receiver) will be required which is capable of receiving traps.

Windows uses the Application Name as the OID. All OID's for Microsoft, begins with 1.3.6.1.4.1.311. After that, 13.1 shows the evntwin definition traps (i.e. 1.3.6.1.4.1.311.13.1).

After that, the application definition begins. The next digit defines the number of characters in the application name. 1.3.6.1.4.1.311.13.1.XX., followed by the Application Name using ASCII characters. So, if we are talking about the application (source) WMONSVC, the number of characters would be 7 and thus we would have:

1.3.6.1.4.1.311.13.1.7.87.77.79.78.83.86.67

W M O N S V C

Testing SNMP Traps

There are a number of SNMP utilities on the market. Any utility that has a built in trap receiver can be used. For the purposes of development and testing, we recommend using the Trap Receiver program that forms part of the MIB Browser suite from iREASONING.

Once traps have been configured on the Wall Controller, the Trap Receiver should be run on the remote machine to log any received traps. For testing purposes, it is useful to enable a few ‘informational’ traps such as the traps for ‘application started’ and ‘application terminated’ as these are easy to trigger (by closing and opening the relevant program) and verify in the Trap Receiver.

Once traps have been fully tested, they can be rolled into any existing enterprise wide monitoring system such as Solarwinds, Nagios or any other SNMP monitoring tool. To widen the scope of monitoring, SNMP traps can also be created for other software and tools installed on the machine, or from error logs generated by the operating system itself.

06/11/2017

The EDID configuration (Extended Display Identification Data) defines the exact video timings that a video source should output once connected. It also advertises support for a number of other implementation specific features, such as 4K60 4:2:0 support on HDMI 1.4.

This tutorial describes how to set custom EDID on any of the Fx4 inputs. EDID data can affect how a connected video source responds when the FX4 is connected to it.

To access the EDID configuration feature you will need your Fx4 to be running firmware version 2.3.2 or later (Fx4-SDI firmware version 1.3.2).

Note: Your FX4 device may require a firmware upgrade before running this tutorial. To do so please make sure your device is connected to the network and follow the firmware upgrade prompt when instructed.

Steps for Programming EDID

1. Setup your Fx4, using Wall Designer Software in the usual way.

2. After using the ‘Auto-config Fx4’ option on the Devices page right click on an input port.
‘EDID > Create Custom appears’.

3. Click on Create Custom

Note: Within the EDID menu, Import and Export of EDID binary files is also supported. This can be useful for example to import a known EDID from a monitor, or to configure multiple devices with an identical custom EDID

4. The ‘Source Capability’ window is now displayed. Select the appropriate CEA extension block for your input signal type.

For HDMI 4k60 fps select ‘HDMI (CEA-861 Extension)’

5. Click Next

6. You are then presented with the ‘Mode’ window. Here you can either select a predefined EDID, or create your own.

7. Click Finish.

8. A warning may pop up if the defined input canvas does not match the new EDID settings. Click yes to accept or no to revert.

9. The input EDID has now been programmed with your selected pre-defined EDID. Video sources will now automatically output this mode where they are capable.

Note: Programming an EDID using this method will override settings in the INPUT tab of Wall Designer software i.e. a custom defined EDID will always take priority. Once custom EDID is created, you will notice the resolution and frame rate settings in the INPUT tab are updated to reflect the preferred mode that has now been defined.

Note: It is not necessary to configure the EDID in order to achieve 4K60 operation on HDMI. The simplest way to do this is to use the INPUT tab in Wall Designer. Select a resolution of 3840x2160 @ 60 refresh rate on the HDMI input. This will automatically program an EDID that advertises support for 4:2:0 subsampling as defined in the HDMI1.4 specification.

Steps for Creating a Custom EDID

1. Follow steps 1-5 above

Note: If an EDID has already been defined for this input, you will need to select ‘Clear Custom’ before proceeding.

2. You are then presented with the ‘Mode’ window

3. Select Custom

4. Click Next

5. You are then presented with the ‘Custom Support’ window.

Here you can select the ‘Colour sub-sampling’ and ‘Colour bit-depth’ (10-bit option is available only on FX4-SDI).

Note: These tick boxes are not selectable on the Displayport inputs. Colour sub-sampling options are available only on HDMI inputs.

Also 10-bit support is only available on the DisplayPort input of the FX4-SDI varient.

6. Click Next

7. You are then presented with the ‘Preferred Timings’ window, here you can set your custom EDID.

8. Click Finish

9. The selected input on the Fx4 has now been programmed with your custom timings. Video source will automatically respond to the changes.

Note: Some video sources require the video cable to be unplugged and reconnected after updating the EDID memory in order to read the EDID again.

Note: For 4K60 fps support, some video sources (such as the Playstation4), also require the option enabled in their display menu in order to output the mode.

Datapath FX4 Custom EDID Support

Custom EDID functionality adds even more flexibility to the Datapath FX4, giving the user more control and easing integration with a wider range of video sources.

For further information on EDID definitions and CEA extensions please refer to the HDMI1.4 specification https://www.hdmi.org/

1 Contents

2 Introduction

3 Common issues

3.1 Networking connection issues

3.1.1 Connection Failed

3.1.2 DNS Error

3.1.3 Invalid path

3.1.4 Not Authorized

3.1.5 Stream stopped

3.1.6 Connection Terminated

3.1.7 End of stream

3.1.8 Invalid Connection

3.2 Decoding issues

3.2.1 Unsupported Stream

3.2.2 Invalid Stream

3.3 Stuttering and video corruption

4 Advanced troubleshooting

4.1 Enabling logging

4.2 Retrieving logs

4.3 Detecting packet loss and jitter

4.4 IGMP Multicast issues

5 Appendices

5.1 Logging types

5.1.1 SQX Logging

5.1.2 GStreamer logging

5.1.3 Pipeline logging

5.1.4 Packet logging

2 Introduction

This document describes the support-oriented functionality that has been implemented within the ActiveSXQ card and the process that Datapath will follow, using these features, to swiftly investigate and remedy any problems that may be found when deploying the ActiveSQX.

The document describes the steps that should be taken when an IP stream source does not work with the ActiveSQX card. An IP stream may pass through a diverse set of hardware and software components and there are an equally large number of reasons why the stream may fail to work. The document covers the potential issues in order from most common to least common. The common issues could be diagnosed by the end-user or fist-line support without too much trouble however some of the less common issues will need to be escalated to Datapath for further investigation and the processes involved in that are also described.

3 Common issues

When a window is first opened to display an IP stream, “Connecting” will appear in the window. This indicates that the ActiveSQX card is attempting to establish a connection to the IP stream source. This may take anywhere from a fraction of a second to half a minute depending on the quality of the network and source.

In case of networking issues an error maybe displayed in the window immediately or the software may time out after approximatively 30 seconds and then display an error message in the window.

The different types of networking issues are described in section 3.1. Assuming the network connection can be established correctly, various issues with decoding such as trying to decode a stream which uses an encoding format or specific feature of that format which the ActiveSQX does not support may be encountered. These are described in section 3.2.

3.1 Networking connection issues

If there are issues with the network one of the following errors may appear:

3.1.1 Connection Failed

This means the ActiveSQX was not able to establish a connection with the source IP address and port. In some cases it may be that the source has rejected the connection due to invalid username and password (refer to section 3.1.4) or that the source IP has reached its maximum number of supported connections.

3.1.1.1 Check physical connection

Make sure that an Ethernet cable is connected to the ActiveSQX and is on a network which has physical access to the source’s IP address.

3.1.1.2 Check IP address

If DHCP is being used make sure that the ActiveSQX has obtained an IP address, check this by opening device manager and double clicking on the ActiveSQX card under “Sound, video and game controllers”. Go to the “Configuration” tab and look for an IP address in the greyed out IP address field as shown in Figure 1. If the “Configuration” tab is not present then the ActiveSQX has failed to establish a connection with the host machine. If this is the case try to shut down and power back on, if the tab still does not appear then either the card is faulty or has been placed in an unsupported host machine.

Figure 1 ActiveSQX device manager configuration

The IP address field will only update when the dialog is first opened, so if an Ethernet cable is subsequently plugged into the ActiveSQX the dialog must be closed and re-opened for it to refresh. If an IP address does not show up in the dialog then verify that the DHCP server is running correctly. If necessary use a packet sniffer such as Wireshark on another machine connected to the same network to verify the DHCP packets are being transmitted. If the DHCP server is not functioning correctly then try assigning a static IP address instead. However if a static IP address is assigned make sure not to pick an address within the range reserved for DHCP to avoid IP address conflicts.

3.1.1.3 Ping IP addresses

Once the ActiveSQX has an IP address verify that it responds to ping requests from another machine on the network by typing “ping x.x.x.x” using a Command Prompt, replacing x.x.x.x with the IP address of the ActiveSQX. Also verify that the source responds to ping requests to its IP address. Provided the ping requests succeed verify that the port number entered for the source address is correct. Also verify that the stream is accessible from another machine in the same network using a software media player such as VLC.

3.1.2 DNS Error

If a domain name, rather than an IP address, is entered for the IP source and it has failed to resolve then this error will be displayed. Check that the domain name is correct and that it can be accessed using the ping command. Otherwise it may be because the ActiveSQX is unable to connect to the domain name server. The address of 1 or 2 DNS servers may be explicitly specified through the ActiveSQX properties page in device manager if the DNS cannot be established automatically through DHCP.

3.1.3 Invalid path

This error occurs when connection to the IP source was established but the source rejected the path given. Check the path in Wall Control by opening the “IP-Camera Configuration” dialog and selecting the “Camera Models” tab. Select the relevant camera, click on “Modify...” and verify the path is correct.

3.1.4 Not Authorized

This error indicates that the IP source has rejected the connection. This may be due to an invalid username or password. Check the username and password in Wall Control by opening the “IP-Camera Configuration” dialog and selecting the “Cameras” tab. Select the relevant camera, click on “Modify...”, select the “UserName” radio button and enter the login credentials.

3.1.5 Stream stopped

This error indicates that no video frames have been decoded in the last second. This may be due to a temporary network glitch such as a cable being unplugged and may recover provided the network connection is re-established before the connection times out. This may also occur if the maximum decoding capacity of the ActiveSQX is exceeded, please refer to the datasheet for the limits.

3.1.6 Connection Terminated

This error will occur in situations where the connection is lost for an extended period of time (i.e. about 30 seconds). This may be due to a number of different reasons:

• A cable being disconnected somewhere between the source and the ActiveSQX
• The source may have stopped streaming if it was powered off for example
• If the source was multicast it may be due to a misconfiguration in the IGMP network settings on
  the switches (see section 4.3 for more details)

3.1.7 End of stream

This is not actually an error, it simply indicates that the source IP stream has ended. Typically this message will only be displayed if the source was a video file which had a fixed length rather than a never-ending live stream.

3.1.8 Invalid Connection

This error indicates a generic network error has occurred. Further investigation is required as described in section 4.

3.2 Decoding issues

If there are issues decoding the source IP stream then one of the following errors may be displayed:

3.2.1 Unsupported Stream

This error usually indicates that the source IP stream encoding format is not supported or it may also indicate an unsupported transport protocol. Please refer to the ActiveSQX datasheet for a list of supported formats. In some cases it may be possible to address the issue by configuring the source IP stream to a compatible format. If the source’s encoding format is unknown it can be checked using a software media player such as VLC.

3.2.2 Invalid Stream

This error indicates that a generic stream error has occurred. Further investigation is required as described in section 4.

3.3 Stuttering and video corruption

In some cases a number of green tinted frames may be seen when first connecting which will then correct itself after some time. In the case of H264 encoded video this is due to not having received an I- Frame from the IP source when the connection was first made. The IP source should send an I-Frame on connection but not all IP sources do so. Unfortunately there is nothing that the ActiveSQX can do about this.

Another common issue with IP streams is to see video stutter and/or decoding artefacts. Since the decoding of frames often relies on having successfully decoded the frames before it, IP streams are very sensitive to any disruption and this often manifests itself in video corruption.

Decoding artefacts are usually caused by network packet loss, to confirm this is the case it is best to try and make the route from the source to the ActiveSQX as short as possible. If physical access to the network is available try to connect the source and the ActiveSQX directly into the same switch and disconnect all other unnecessary ports to see if the problems persist. The switch or cabling may also be faulty, try using several different switches and cables if possible. If that still fails the source could be faulty, try using different IP sources. If physical access to the network is not available then try measuring packet loss using the logging techniques described in section 4.

Stuttering video may also be caused by network packet loss but is usually also associated with decoding artefacts. If video stutter is present without artefacts then it may be due to packets taking different amounts of time to be transmitted from the source IP stream to the ActiveSQX. The ActiveSQX will by default cache packets for 200 milliseconds before decoding them, this will enable smooth playback even though packets are not received at a smooth rate, provided the difference in transit time between the slowest and fastest packet does not exceed 200 ms. This value is configurable in Wall Control by opening the “IP-Camera Configuration” dialog, selecting the camera, clicking “Modify...”, then “Advanced” and changing the Caching value. Try increasing the value until the stuttering is eliminated. However be aware that increasing this value will add a delay between the live source and the displayed video. If the problem cannot be solved by changing the Caching value then the problem may lie with the IP source. Try decoding the same source with a software media player such as VLC to see if the same problem is exhibited or not.

4 Advanced troubleshooting

In cases where the problem cannot be identified from section 3 it will be necessary to make use of the built-in logging functionality of the ActiveSQX. By default logging is disabled for performance, durability and security reasons but is invaluable for debugging complicated issues.

Logging should be enabled and then the issue should be reproduced by opening the problematic IP stream (or performing whatever steps are necessary). The log files can then be analyzed to determine the cause of the problem or sent back to Datapath for further analysis if necessary.

4.1 Enabling logging

Logging can be enabled using the cmd183.exe command line tool from a Command Prompt. As a starting point SQX logging warnings and errors with GStreamer INFO level logging and pipeline dump should be enabled using the following command line:

cmd183.exe setlog file –s 2 –g 4 –p

These logs will not contain any sensitive information and are fairly light. For more details on the different logging types and how to use the cmd183 tool see section 5.1.

4.2 Retrieving logs

Logs are retrieved using the cmd183.exe command line tool as well. First create a folder on the host machine where the logs should be stored. Then run “cmd183.exe getlogs ” where is substituted for the location of the folder created. Once the logs are successfully retrieved they will be cleared off the ActiveSQX card(s). All log files have a date and time appended to the filename as well as an ID such that each client window has its own unique log file. The contents of the folder can then be zipped and sent back to Datapath for further analysis. Depending on the outcome Datapath may request further logging with different options to be done in order to narrow-down the problem.

4.3 Detecting packet loss and jitter

If the network appears to be suffering from packet loss and/or jitter because the video is displaying decoding artefacts then enable the following logging:

cmd183.exe setlog file –g rtpsource:5

Open the IP stream and leave it running for a minute or so then retrieve the logs using the getlogs command. In sqx-client-child_xxx.log look for lines that look like this:

rtp_source_get_new_rb: fraction 0, lost 1, extseq 120132, jitter 98

fraction indicates the number of packets lost in the range of 0 to 256, to convert to a percentage divide by 2.56. lost indicates the number of packets lost since the last report. Unfortunately even small amounts of packet loss can result in large decoding artefacts. Take for example an H264 encoded video transmitted using RTP packets at a bit rate of 8 Mbit/s at 30 frames per second with a GOP size of 30. Many IP sources will encode entire frames into a single H264 NAL unit, so each frame will thus be on average roughly 34 KB. The maximum transmission size of a packet is typically around 1.5 KB, so a frame must be split into around 23 RTP packets. Due to the way the RTP protocol works, if any one of those 23 packets goes missing all of them must be discarded. So a single packet lost can in fact result in 23 packets being discarded in this example. As soon as one frame goes missing, all subsequent frames will suffer from decoding artefacts until the next I-frame arrives which could be as much as 29 frames in this example. A mere 0.1% packet loss could result in up to 66% frames being corrupt (0.1 * 23 * 29). So in order to achieve smooth and artefact-free video playback it is important to minimize packet loss as much as possible, ideally eliminate it completely.

jitter is the variation in the delay of received packets in the stream in clock rate units. It is measured by comparing the interval when RTP packets were sent to the interval at which they were received. For instance, if packet #1 and packet #2 leave 50 milliseconds apart and arrive 60 milliseconds apart, then the jitter is 10 milliseconds. The lower the jitter value the better, high jitter values indicate packets are not arriving at regular intervals and more caching is needed to achieve smooth playback. Jitter is generally less of a problem compared to packet loss since it can be compensated for by the ActiveSQX by increasing the caching.

4.4 IGMP Multicast issues

If a multicast IP stream cuts out after a certain amount of time, anywhere from a few minutes to hours or even days, then it may be due to a configuration issue with the switches being used to transmit the multicast packets. If that is the case a “Connection Terminated” error will appear in the window, we can verify that the RTP packets are no longer being received by enabling the following logging:

cmd183.exe setlog file –s 2 –g rtpsource:5 –n igmp

Open the IP stream and leave it running until the stream drops out, then retrieve the logs using the getlogs command. In sqx-client-child_xxx.log look for the lines “No frames transferred for more than 1 second” and “Treating end of stream as timeout”, in between those the number of RTP packets being received can be seen. If that number has not increased in between the last frame being decoded and the timeout then it means that no new RTP packets are coming in and could point to a switch filtering the packets out.

Assuming the packets have stopped, we can look at the IGMP packets to see if it is behaving as expected. Open sqx-client_xxx.pcap with Wireshark and look for “Membership Query, general” packets coming from the switch. Make sure that every query is responded by a “Membership Report” within the Max Resp Time indicated by the Query packet for the multicast address connected to. If another device responds with a report before the ActiveSQX then the ActiveSQX will not send a response as well (this is part of the IGMP protocol standard). In some cases the ActiveSQX may receive a report from another device that it shouldn’t, this indicates in issue with the network configuration.

5 Appendices

5.1 Logging types

Log files can either be stored on the ActiveSQX or sent live to the host machine as they are generated and viewed using DebugView or a kernel debugger. Writing to files on the ActiveSQX tends to be faster and doesn’t interfere as much with the decoding process but the ActiveSQX has limited space for logging (about 1.4 GB). Conversely viewing the logs in DebugView isn’t limited by the ActiveSQX’s disk space but can severely impact performance if very verbose logging is enabled.

There are various different types of logging that can be enabled:

• SQX: log messages originating from Datapath’s proprietary code.
• GStreamer: log messages originating from open source GStreamer code.
• GStreamer pipeline: graphical representation of the GStreamer pipeline.
• Network packet capture: raw network packet captures that can be viewed in Wireshark.

Depending on the nature of the problem any number of these logs can be enabled at once bearing in mind the limitations of disk space and performance impact. The best approach is to start with a fairly light level of logging and look for errors and warnings within them. Then as the source of the problem becomes more apparent increased logging levels can be activated.

5.1.1 SQX Logging

SQX logging comes in 4 levels: 0 to 3. 0 represents no logging, 1 is errors only, 2 is errors and warnings and 3 is all logging. Log level 2 is a good level to start with as it should not fill the disk too quickly. Example: cmd183.exe setlog file –s 2

5.1.2 GStreamer logging

GStreamer logging is more complicated, it includes 10 log levels 0 to 9. In addition to the log level, GStreamer has a number of different debug categories for different components within the GStreamer architecture. It is possible for example to enable debug level 9 specifically for the rtpsource category while leaving all other categories disabled. For more information refer to the GST_DEBUG variable under http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gst-running.html. Level 4 across all categories is generally a good starting point as it strikes a balance between giving enough information and not filling up the disk space too quickly. Example: cmd183.exe setlog file –g 4 or cmd183.exe setlog file –g rtpsource:5

5.1.3 Pipeline logging

GStreamer also has the ability to output the pipeline to a .dot file which once processed by graphviz gives a graphical representation of the pipeline which gives a good indication of what encoding formats and transport protocols are being used by a given IP source. Example: cmd183.exe setlog file -p

5.1.4 Packetlogging

If the problem cannot be diagnosed with the log files alone then it may be necessary to capture raw network packets and analyze them in Wireshark. For intermittent problems it may also give a convenient way to reproduce rarely occurring issues. However it should be noted that if all packets are captured it may fill up the disk space very quickly. To help alleviate this issue and provide a level of privacy to customers it is possible to filter packets captured based on given criteria. Tcpdump is used for the packet capture and the filter syntax is described in detail here http://www.tcpdump.org/manpages/pcap-filter.7.html. Example: cmd183.exe setlog file –n “src 10.20.0.1” or cmd183.exe setlog file –n “ ” for no filtering.

Promiscuous mode is disabled to avoid capturing general network traffic not destined to the ActiveSQX. However since the packet capture operates at a low level it may capture potentially sensitive information depending on what information is being sent across the network if not explicitly filtered out. It is also possible to replay video from the packet captures and customers should be made aware of this before asking them to send packet captures back to Datapath. For these reasons packet capture should generally be used as a last resort for debugging issues.

To verify the RAID set up on your wall controller simply follow these instructions:

1. Restart the wall controller and press the keyboard delete button when the Boot-Up splash screen is displayed. This will direct you to the BIOS Setup Utility (Fig.1)

2. Use the keyboard arrows to navigate across to the Advanced Tab and the following screen is displayed:

Fig.1

Confirm that Configure SATA#1 as is set to RAID.

3. Press F10 to save and exit the BIOS Utility.

4. When the wall controller restarts press CTRL + i at the BIOS splash screen to enter the RAID BIOS Utility (Fig.2)

Degraded RAID Array

5. If a RAID array degrade this does not necessarily mean that the hard drive or any other hardware within the system is faulty. What it does mean is that there is an inconsistency in DATA across the array. This could be caused by many different factors including a BSOD, the system hanging, an application conflict or power outage.

As stated above, the degrade of a RAID array does not necessarily mean hardware failure but should the problem occur on a regular basis then further diagnostics should be performed/ undertaken. It is recommended, as with any system, that regular backups are made to safeguard information.

Fig.2

6. If a RAID Array is degraded take note of the physical port number and the drive serial number of the degraded disk, which in Fig. 2 is highlighted with an error in red. The working drive is set to Member Disk (o) and is highlighted in green.

7. Use the keyboard arrow key s and navigate to Option 3 on the Main Menu (Reset disks to non-RAID) and press Enter.

8. Use the keyboard arrow keys to select the degraded disk (highlighted in red) and press the keyboard spacebar to assign it for Reset.

WARNING! Ensure the correct disk is selected before continuing.

9. Once the disk has been reset the BIOS RAID Utillity will detect the disk as a new one an a prompt will appear asking if you want to use the selected disk to repair the RAID. Accept and continue.

10. Both disks should now be displayed as Member Disk (x) with the status highlighted in yellow as Rebuild (Fig.2).

11. Exit the Utility by clicking Esc and RAID will commence the rebuild process once the operating system has loaded.

You may be asked by our support staff to run the Datapath Diagnostic Tool to assist in solving a problem you may have encountered with our products.

The Datapath Diagnostic Tool is a diagnostic progam for Windows® which gathers information on the configuration of the system components. The information is sorted, gathered and compressed into a zip file for onward transmission to to the Datapath support team.

To run the Datapath Diagnostic Tool you must first download it from the Datapath website, click here to download the diagtool.zip.

Once downloaded unzip the the contents of the zip file into a folder and double-click the DIAGTOOL.exe file. This starts the diagnostic tool wizard and displays the following dialog:

Click Next> to continue and the following dialog is displayed:

Licence Agreement

To enable the diagnostic tool to run, the licence agreement must be accepted by clicking in the box as indicated above. Please read the terms of the licence agreement carefully. Once you have read and accepted the terms click Next> and the following dialog is displayed. Memory dump should only be checked is specifically requested by the Support staff.

Components

This dialog allows individual selection of the various diagnostic components that will be collected. Unless requested by a member of the Support Team, please use the default selections as shown above. Click Next> to display the Summary dialog:

Summary

This dialog displays a summary of the options chosen in the previous Components dialog. To change the Component options, click on the Back button.

If the dialog displays the options you require click Next> and a progress dialog is displayed as the diagnostic tool collects the required information.

Once all the data has been gathered and successfully written to a file, the following dialog is displayed:

Finished

The Finished dialog confirms the diagnostic tool has gathered all the required information and written it to a zip file, the location of the zip file is also displayed. The zip file should be located and attached to an email and forwarded to the Datapath Support Team.

You may be asked by a member of our support staff to complete the Firmware Golden Image procedure. To carry out this process, complete the following:

"LINK" = LK1 VisionRGB-E2, VisionRGB-X2, VisionSD4+1, VisionSDI2, VisionDVI-DL and VisionHD4

"LINK" = LK4 for VisionRGB-E1 and VisionSD8

"LINK" = J8 for VisionAV-HD and VisionAV-SDI

"LINK" = J11 for VisionAV

"LINK" = J1 for VisionHD4

• Power down your machine including and attached expansion chassis
• Remove link "LINK" found on the Vision capture card PCB board
• Power on the machine into the Windows desktop
• Replace "LINK" back onto the Vision capture card
• Execute the required Vision/Driver installation program
• Confirm that Flash133 executes successfully
• Power down your machine including and attached expansion chassis
• Power on the machine into the Windows desktop
• Confirm that you have a working Vision capture card / application

Open GraphEdit and select "Connect to a remote graph" from the File Menu

If you do not have GraphEdit installed on your machine you can download this file from our support pages for multi-screen utility drivers.

The "Select a remote filter graph to view" dialog is displayed:

If an entry exists in the dialog, select the entry and click OK.

You may be asked by a member of our support staff to forward a filter graph. To carry out this function follow these few simple steps:

1. Open the GraphEdit application and select Graph/ Insert Filters.

If you do not have GraphEdit installed on your machine you can download this file from our support pages for multi-screen utility drivers.

2. The following dialog is displayed

3. Expand the WDM streaming capture devices and select the capture device. The source filter is then displayed in the GraphEdit application window.

4. Right click on the first source filter capture pin and select Pin Properties, the Pin Properties dialog will be displayed.

5. Select the colour space, do not change the buffer size or capture rate. Close the pin properties dialog, right click on the first source filter capture pin again and select Render Pin.

6. The GraphEdit application will now display the system filter graph for the colour space in use.