Dropped Frames with GigE Vision and USB3 Vision Cameras — Locating the Cause and the Windows Settings to Review

An inspection machine occasionally misses images from its industrial camera, and in the SDK’s viewer the counts of “incomplete images” and “resend requests” keep creeping up. This article covers dropped frames when you use GigE Vision or USB3 Vision cameras on Windows: how to tell where they happened, and which Windows settings to review.

Dropped images (frame drops) happen somewhere on the path from the camera to the app. You can tell where by cross-checking the SDK’s stream statistics, Windows’ adapter statistics and the image numbers the app received. Each location has different settings that help, so count first to narrow down the location, then change settings one at a time and compare.

This article covers setups in which a GigE Vision or USB3 Vision camera is connected to a Windows 10/11 PC and images are received through the maker’s SDK (one that complies with GenICam). The procedures and settings are based on camera makers’ and Microsoft’s documentation; they are not results measured on a particular model. Setting names and recommended values differ by maker, model and driver, so read this alongside the documentation for your product.

The Path an Image Takes to Reach the App

An image the camera captures reaches the app after passing through the camera itself, the transmission path, the PC’s receive side and the SDK’s buffers. With GigE Vision, the transmission path is LAN cables and switches, and the NIC receives on the PC. With USB3 Vision, the transmission path is USB cables and hubs, and the host controller receives on the PC.

flowchart TB
        accTitle: The path of an image from camera to app
        accDescr: Shows how a camera image travels through a switch and NIC with GigE Vision, or through a hub and USB host controller with USB3 Vision, then through the driver and the SDK's buffers to the app.
        CAM["Camera (capture and send)"]
        CAM --> G1["LAN cable / switch"]
        CAM --> U1["USB cable / hub"]
        G1 --> G2["NIC"]
        U1 --> U2["USB host controller"]
        G2 --> DRV["Driver"]
        U2 --> DRV
        DRV --> BUF["SDK receive buffers"]
        BUF --> APP["App image processing"]

Figure 1: An image reaches the app through the camera, the transmission path, the NIC or host controller, the driver and the SDK’s buffers.

At each location, dropped frames show up differently.

• An image the camera failed to capture cannot be recovered however you change the PC’s settings. For example, if the trigger interval is shorter than the time needed for exposure and transmission, some images may not be captured. Some models count dropped frames on the camera side, so check the camera’s manual.
• If data is lost on the transmission path, GigE Vision can sometimes fill the gap by resending packets. If it cannot, that image is treated as an incomplete image.
• At the NIC, arriving packets are discarded when the receive buffers fill up. Microsoft explains that small receive buffers cause packets to be dropped and performance to fall¹.
• If the app is holding all of the SDK’s buffers, there is nowhere to put the next image.
• If the app is set to “receive only the latest image,” older images are discarded by design.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (13 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

Using Statistics to Tell Where Data Was Lost

Before changing settings, count where the loss is happening. If you change settings without looking at the numbers, you cannot tell whether a change helped or merely moved the problem somewhere else.

The SDK’s Stream Statistics

Camera makers’ SDKs keep receive statistics as counters. In Basler’s pylon Viewer, you can see them by selecting the camera and opening “Statistics” in the stream parameters². The pylon API has counters such as Statistic_Resend_Request_Count, which holds the number of resend requests sent³.

The names differ between SDKs, but most keep counts like these:

• The number of images received
• The number of incomplete images, which arrived with packets missing
• The number of packets for which a resend was requested
• The number of images discarded because there were not enough buffers

Check in the documentation for your SDK which counter counts what.

Gaps in Image Numbers

GigE Vision image data carries a number called the block ID⁴. The SDK passes this number, or the frame number the camera assigned, to the app. If the numbers the app receives skip, an image was lost somewhere before it reached the app. The width of the number and how it resets when acquisition is restarted depend on the SDK and the model, so check the documentation.

Windows’ Adapter Statistics

With GigE Vision, you can also see from the Windows side how many packets the NIC discarded. Get-NetAdapterStatistics returns broadcast, multicast, discard and error counts⁵. Specify the name of the NIC used for the camera and show all properties.

Get-NetAdapterStatistics -Name "Camera1" | Format-List -Property *

If the counts discarded on receive (such as ReceivedDiscardedPackets) rise during the same period as the dropped frames, the NIC is discarding them.

flowchart TB
        accTitle: Steps to locate where frames are dropped
        accDescr: Shows how to use gaps in the image numbers the app received, the SDK's statistics and Windows' adapter statistics to tell whether frames were dropped on the transmission path, on the PC's receive side, in the app or in the camera.
        A["Do the image numbers skip?"]
        A -->|"They skip"| B["Which SDK count went up?"]
        A -->|"They do not skip"| F["Check the camera's capture conditions"]
        B -->|"Resend requests / incomplete images"| C["Did the NIC discard count also go up?"]
        B -->|"Discarded for lack of buffers"| E["Review app processing and buffer count"]
        B -->|"None went up"| L["Check for a latest-only setting"]
        C -->|"It went up"| D1["Review the NIC settings"]
        C -->|"It did not"| D2["Review the link (bandwidth, switch)"]

Figure 2: Look at the image numbers, the SDK’s statistics and the NIC’s discard count in turn to narrow down where frames are dropped.

If the numbers do not skip but there are fewer images than triggers, the camera may not have captured those images. If the numbers skip but none of the SDK’s statistics increased, check whether the SDK is set to hand over only the latest image (see “Number of SDK Buffers and How Images Are Received” below).

Even when the NIC’s discard count does not increase, packets may be discarded inside the switch. The breakdown in Figure 2 is a rough guide, so when deciding on the location, also use the bandwidth calculation in the next section.

GigE Vision Bandwidth and Resends

How Much Is Sent and the Available Bandwidth

On paper, a 1 Gbps link carries 125 MB per second (1,000,000,000 ÷ 8 bytes). In practice, Ethernet, IP, UDP and GigE Vision headers are added to every packet, so less than that is available for images.

The amount a camera sends can be calculated as width × height × bytes per pixel × frame rate. For example, at 1920 × 1200 pixels, Mono8 (1 byte per pixel) and 50 fps, that is 1920 × 1200 × 1 × 50 = 115,200,000 bytes, or about 115 MB per second. On paper this fits on a 1 Gbps link, but once the headers are taken into account there is almost no headroom.

If you connect two of these cameras to a switch and link the switch to the PC with a single link, the two cameras push about 230 MB per second through that one link. That does not fit on a 1 Gbps link, so no NIC setting will stop the dropped frames. Basler explains that giving each camera its own NIC port lets each camera use a link’s bandwidth, whereas with a switch the cameras share the single link to the PC⁶.

flowchart TB
        accTitle: A setup in which two cameras share bandwidth through a switch
        accDescr: Shows two cameras each sending about 115 MB per second, totaling about 230 MB on the single link from the switch to the PC's NIC, which does not fit on a 1 Gbps link.
        C1["Camera 1 (about 115 MB/s)"] --> SW["Switch"]
        C2["Camera 2 (about 115 MB/s)"] --> SW
        SW -->|"Total about 230 MB/s"| NIC["PC NIC (1 Gbps)"]
        NIC -.-> NOTE["Exceeds 125 MB, so settings cannot fix it"]

Figure 3: There is only one link from the switch to the PC, so the combined output of both cameras must fit on that link.

When it does not fit, change either how much is sent or how much can be carried: lower the frame rate, narrow the ROI (the region of the image that is cropped and sent), give each camera its own NIC port, or switch to a faster link such as 10GigE.

Packet Spacing and Transmission Start Times

If you feed the same trigger to several cameras, every camera starts sending at once. If the buffers in the switch or NIC cannot absorb this overlap, packets are discarded. For this case Basler lists widening the spacing between packets (Inter-Packet Delay) and using a setting that delays the start of frame transmission (Frame Transmission Delay)².

flowchart TB
        accTitle: Packet overlap when several cameras send at the same time
        accDescr: Shows that when two cameras send at the same time on the same trigger, the buffers in the switch or NIC overflow and packets are discarded, and that widening the packet spacing or staggering the transmission start reduces the overlap but lowers the maximum frame rate.
        A["Two cameras send at once on the same trigger"] --> B["Transmissions overlap at the switch"]
        B --> C["Switch or NIC buffers overflow"]
        C --> D["Packets are discarded"]
        A -.-> E["Widen packet spacing / stagger start"]
        E -.-> F["Less overlap"]
        F -.-> G["Lower maximum frame rate"]

Figure 4: When packets from cameras that start sending together overlap, the buffers overflow, so stagger the spacing or start times to reduce the overlap.

Widening the packet spacing lengthens the time it takes to finish sending one image. So widen the spacing only as far as still delivers the frame rate you need. Setting the spacing to the maximum lowers the maximum frame rate the camera can achieve².

Packet Size and Jumbo Packet

GigE Vision images are split into packets for sending. The larger the packets, the smaller the share taken by headers and the fewer packets the PC has to process. Basler recommends setting the NIC’s Jumbo Frames to the maximum and keeping the camera’s packet size at or below the NIC’s value. It also notes that, when troubleshooting, starting with both the NIC and the camera at 1500 is the safe approach².

Large packets get through only if the camera, the switch and the NIC all support the same size. Check the switch’s support in its specifications⁶.

What Resends Can Fill In

GigE Vision sends images over UDP. For control it uses GVCP, a UDP protocol, through which the PC can request that missing packets be resent⁷. Basler’s filter driver requests a resend when a packet has not arrived by the time PacketTimeout expires, and combines several consecutive missing packets into a single request³.

sequenceDiagram
        accTitle: The flow of a GigE Vision packet resend
        accDescr: Shows part of the packets sent by the camera being lost on the way, the PC's driver requesting a resend after the wait time passes, and the image being completed if the resend arrives in time or becoming an incomplete image if it does not.
        participant C as Camera
        participant P as PC driver
        C->>P: Packets 1, 2
        C--xP: Packet 3 (lost on the way)
        C->>P: Packet 4
        Note over P: Packet 3 has not arrived after the wait time
        P->>C: Resend request for packet 3
        C->>P: Packet 3 resent
        Note over P: The image is complete if in time, otherwise it becomes an incomplete image

Figure 5: The driver fills in a missing packet by requesting a resend, but if the resend is not in time, that image becomes an incomplete image.

Resent packets travel over the same link. When packets are being discarded because the bandwidth is insufficient, resends consume even more bandwidth. If the number of resend requests keeps rising, go back to the bandwidth calculation in the previous section before changing the resend settings.

Changing Windows NIC Settings

Record the Values Before Changing Them

When you change a NIC’s advanced settings, many items take effect only after the adapter restarts. Set-NetAdapterAdvancedProperty restarts the adapter after the change unless you specify -NoRestart⁸. Communication with the camera is interrupted during the restart, so stop the machine before you start.

First, save all the current values to a file. When you need to revert, refer to this file.

Get-NetAdapterAdvancedProperty -Name "Camera1" |
    Select-Object DisplayName, DisplayValue, RegistryKeyword, RegistryValue |
    Export-Csv -Path .\Camera1-advanced-before.csv -NoTypeInformation -Encoding UTF8

The display names shown on screen (DisplayName) differ between drivers. Windows defines standard keywords for commonly used items, and their names start with *⁹. Searching by keyword lets you find the same item even on drivers with different display names. Check the allowed range here too.

Get-NetAdapterAdvancedProperty -Name "Camera1" -RegistryKeyword "*JumboPacket", "*ReceiveBuffers", "*InterruptModeration" |
    Select-Object DisplayName, DisplayValue, RegistryKeyword, ValidRegistryValues, NumericParameterMinValue, NumericParameterMaxValue

Three Items That Affect Receiving

On the NIC used for the camera, these are the main three items to review.

Microsoft also recommends setting the receive buffers to the maximum for receive-heavy workloads. Turning off Interrupt Moderation reduces latency, at the cost of higher CPU usage¹.

When you change an item, specify a value within the range you checked. The following example changes the receive buffers; 2048 is only an example. Match it to your NIC’s ValidRegistryValues or maximum value.

Set-NetAdapterAdvancedProperty -Name "Camera1" -RegistryKeyword "*ReceiveBuffers" -RegistryValue 2048

The meaning of each item and the trade-offs of changing it are covered in detail in “A Guide to Windows NIC Advanced Settings.”

flowchart TB
        accTitle: Changing NIC settings one item at a time and comparing
        accDescr: Shows the loop of recording the values before the change, changing only one item, counting dropped frames under the same conditions, keeping the value if they decreased, and otherwise reverting it and moving on to the next item.
        R["Save the current values to CSV"] --> S["Change just one item"]
        S --> M["Count dropped frames, same conditions and duration"]
        M --> J["Did dropped frames decrease?"]
        J -->|"Decreased"| K["Keep that value"]
        J -->|"Did not decrease"| B["Revert to the original value"]
        K --> N["On to the next item"]
        B --> N
        N --> S

Figure 6: Change settings one item at a time and decide whether to keep or revert each by comparing the number of dropped frames.

Maker Drivers and the Protocols Bound to the NIC

Camera makers sometimes provide a driver that lightens GigE Vision receiving and a tool that configures the NIC in one go. Basler recommends using the pylon filter driver together with the GigE Configurator⁶.

For manual configuration, Basler says to clear the check boxes for every protocol and service other than the pylon driver and IPv4 in the properties of the NIC used for the camera⁶. Before clearing them, confirm that the NIC is not used for any traffic other than the camera.

Firewall

Basler explains that with the firewall enabled, event notifications may not arrive and image reception may become unstable. It goes on to recommend turning off the firewall for camera connections and, if you keep it on, lists options such as adding inbound rules per application⁶. If company policy requires keeping the firewall on, add rules. How to create the rules is covered in “The Windows Firewall and Business Applications.”

Power Settings

For networks where microsecond-level latency matters, Microsoft lists setting the BIOS to high performance with C-states disabled and setting the OS power plan to High Performance¹. Both come at the cost of power consumption. Try them on a PC dedicated to inspection if dropped frames remain after you have reviewed everything above.

USB3 Vision Bandwidth and Connections

Separate the Host Controllers

USB3 Vision sends images over USB bulk transfer endpoints¹². Windows does not allocate guaranteed bandwidth to bulk transfers, so devices connected to one host controller share its bandwidth¹³. If other cameras or external disks sit under the same controller, the bandwidth available to the camera goes down.

Basler strongly recommends connecting to USB 3.0 ports and names Renesas, Fresco Logic and ASMedia as host controller chips that have worked without problems so far¹⁴. It also publishes an application note that measures the maximum bandwidth of each controller¹⁵.

To see which port is connected to which controller, select “Devices by connection” from the “View” menu in Device Manager and check the tree. With several cameras, give each camera its own controller or add a PCIe USB expansion card.

flowchart TB
        accTitle: How to connect cameras to USB host controllers
        accDescr: Shows that a camera and an external disk connected through a hub to one host controller share its bandwidth, while giving each camera its own controller lets each camera use that controller's bandwidth.
        subgraph shared ["Shared setup"]
            HC1["Controller 1"] --> HUB["Hub"]
            HUB --> CA["Camera A"]
            HUB --> DISK["External disk"]
        end
        subgraph split ["Separated setup"]
            HC2["Controller 2"] --> CB["Camera B"]
            HC3["Controller 3 (expansion card)"] --> CC["Camera C"]
        end
        shared ~~~ split

Figure 7: Devices under the same controller share its bandwidth, so give each camera its own controller.

Transfers can also become unstable if a cable is too long or extended in a way that does not meet the specification. Use the cable the maker specifies, and if reconnecting does not help, swap the cable and compare.

Selective Suspend

USB selective suspend is a feature that saves power by individually suspending the ports of devices that are not in use. Microsoft enables it by default and, in its documentation for driver developers, strongly recommends not disabling it¹⁶.

JAI, on the other hand, says that when a USB3 camera that had been working suddenly stops sending images and its frame rate drops to 0 fps, a possible cause is Windows switching the USB3 card into a power-saving state. It then lists a procedure for disabling selective suspend under “USB settings” in the power plan’s advanced settings¹⁷. To try it, on a PC dedicated to inspection, disable “USB selective suspend setting” in the power plan in use for both “Plugged in” and “On battery.” Record the time until the camera stops and the number of dropped frames before and after the change, and compare them. If you see no effect, change it back.

The App’s Receive Buffers and Processing

Number of SDK Buffers and How Images Are Received

The SDK prepares a number of buffers to hold images, puts received images into them in turn and passes them to the app. In Basler’s pylon, the number of buffers is set with MaxNumBuffer¹⁸.

You can also choose how images are received. pylon’s OneByOne hands over every image in order and discards images only when the buffers overflow¹⁹. LatestImageOnly keeps only the latest image and discards older ones¹⁸. LatestImageOnly suits display, but if inspection must process every image, use a method that hands over all of them, such as OneByOne. If you want to process every image but are set to receive only the latest, the app will keep discarding images internally no matter how much you fix elsewhere.

flowchart TB
        accTitle: The difference between pylon's two ways of receiving images
        accDescr: Shows that for received images, OneByOne hands over all of them in order and discards only when the buffers overflow, while LatestImageOnly keeps only the latest and discards older images.
        R["Received images"] --> S{"How images are received"}
        S -->|"OneByOne"| O["Hand over all in order"]
        S -->|"LatestImageOnly"| L["Keep only the latest"]
        O -.-> O2["Discard only when buffers overflow"]
        L -.-> L2["Discard older images"]

Figure 8: If inspection must process every image, use the receiving method that hands over all images in order.

Separate Receiving from Inspection

If you run the inspection inside the routine that is called when an image arrives (the callback), the app keeps holding the buffer for that whole time. If images that take a long time to inspect come in a row, free buffers run out and there is nowhere to put the next image.

Have the receiving routine do nothing more than copy the image into an inspection queue, and return the SDK’s buffer immediately. Run the inspection on a separate thread. When the queue is full and an image cannot be added, count and record it. This way, images discarded because processing could not keep up show up separately from frames dropped for other reasons.

flowchart TB
        accTitle: A layout that separates receiving from inspection
        accDescr: Shows the SDK callback copying the image, putting it in a queue and returning the buffer immediately, counting discarded images when the queue is full, and a separate thread taking images from the queue and inspecting them.
        SDK["SDK callback"] --> CP["Copy the image"]
        CP --> RET["Return the SDK buffer"]
        CP --> Q{"Is there room in the queue?"}
        Q -->|"Yes"| QUEUE["Inspection queue"]
        Q -->|"No"| CNT["Count the discard"]
        QUEUE --> W["Inspection thread"]

Figure 9: The receiving routine only copies the image and returns the buffer; inspection runs on a separate thread.

The following C# code is a skeleton of this layout. It assumes OnFrameReceived is called from the SDK’s callback and leaves out the SDK-specific calls. It counts number gaps and images discarded because the queue was full separately.

using System;
using System.Threading;
using System.Threading.Channels;
using System.Threading.Tasks;

public sealed record CapturedFrame(ulong FrameId, byte[] Pixels);

public sealed class FramePipeline
{
    private readonly Channel<CapturedFrame> _queue =
        Channel.CreateBounded<CapturedFrame>(new BoundedChannelOptions(capacity: 8)
        {
            SingleReader = true,
            SingleWriter = true,
            FullMode = BoundedChannelFullMode.Wait,
        });

    private ulong? _lastFrameId;
    private long _missingCount;   // Number of skipped IDs (images lost before reaching the app)
    private long _queueFullCount; // Number discarded because the queue was full (inspection could not keep up)

    // Called from the SDK callback. No inspection happens here.
    public void OnFrameReceived(ulong frameId, ReadOnlySpan<byte> pixels)
    {
        if (_lastFrameId is ulong last && frameId > last + 1)
        {
            Interlocked.Add(ref _missingCount, (long)(frameId - last - 1));
        }
        _lastFrameId = frameId;

        // Copying before returning lets the caller return the SDK buffer immediately.
        var frame = new CapturedFrame(frameId, pixels.ToArray());
        if (!_queue.Writer.TryWrite(frame))
        {
            Interlocked.Increment(ref _queueFullCount);
        }
    }

    public async Task RunInspectionAsync(Func<CapturedFrame, Task> inspect, CancellationToken cancellationToken)
    {
        await foreach (var frame in _queue.Reader.ReadAllAsync(cancellationToken))
        {
            await inspect(frame);
        }
    }

    public (long Missing, long QueueFull) ReadCounters() =>
        (Interlocked.Read(ref _missingCount), Interlocked.Read(ref _queueFullCount));
}

With a bounded channel using BoundedChannelFullMode.Wait, TryWrite returns false when the channel is full, so the callback returns without waiting. When the number goes back (for example, when acquisition is restarted), it is not counted as a gap. Copying every image with ToArray allocates memory each time. If the frame rate is high and garbage collection pauses are a concern, reuse buffers obtained from something like ArrayPool<byte>.

Set the queue capacity (8 in the example) to a number of images that can absorb variation in inspection time. If the average inspection time is longer than the frame interval, the queue will eventually fill up however large you make it. In that case you need to parallelize the inspection or make it faster.

Changing Settings and Comparing

Dropped frames may not appear within a few minutes and may show up only once every few hours. When comparing, count under the same conditions and for the same duration.

1. Acquire images for a fixed time with the same camera settings as in production (resolution, pixel format, frame rate, trigger). Record the SDK’s statistics, the NIC’s discard count, and the app’s number gaps and queue discards at the start and the end.
2. Calculate how much is sent from the pixel count, bytes per pixel and frame rate, and check that it fits within the bandwidth of the link or host controller. If it does not, review the setup before changing settings.
3. Change only one setting that corresponds to the location the statistics pointed to. Before changing NIC settings, save the current values to a CSV file.
4. Acquire under the same conditions and for the same duration as in step 1, and record the same counts.
5. If dropped frames decreased, keep the value; if not, revert it and move on to the next item.

flowchart TB
        accTitle: Steps for comparing countermeasures against dropped frames
        accDescr: Shows recording baseline counts under production conditions, calculating bandwidth, reviewing the setup if it does not fit, otherwise changing one item and counting under the same conditions, and deciding from the result whether to keep or revert it.
        A["Record baseline counts under production conditions"] --> B["Calculate output and bandwidth"]
        B --> C["Does it fit in the bandwidth?"]
        C -->|"Does not fit"| D["Review the setup (change output or path)"]
        C -->|"Fits"| E["Change one setting for the located spot"]
        D --> A
        E --> F["Count with same conditions and duration"]
        F --> G["Decide whether to keep or revert"]

Figure 10: Confirm that the output fits in the bandwidth, then change settings one item at a time and compare under the same conditions.

The absence of dropped frames in a single acquisition does not prove that the setting prevents them. If the symptom appears at intervals, make the acquisition time before and after the change long enough and repeat the comparison several times.

Related Articles

• A Guide to Windows NIC Advanced Settings - RSS/LSO/EEE/Wake on LAN
• Why TCP Retransmissions Stall Industrial Camera Communication, and How to Isolate Them
• Investigating Long-Run Crashes of an Industrial Camera App - The Handle Leak (Part 1)
• How to Work with USB Devices from a Windows App
• The Windows Firewall and Business Applications

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These are topic pages close to this theme. Starting from the article, you can go on to related services and other articles.

Services Connected to This Topic

This article leads to the following service pages. Start from the entry point closest to your situation.

Frequently Asked Questions

Questions commonly asked at the time of consultation about the topic of this article.

When a GigE Vision camera occasionally loses images, what should I look at first?

Look at the SDK's stream statistics and at gaps in the image numbers the app received. If packet resend requests or incomplete images are increasing, suspect the link or the PC's receive side; if the number of images discarded for lack of buffers is increasing, suspect the app's processing. Counter names differ between SDKs, so check how they map in the documentation for the SDK you use.

Should I set the NIC's Jumbo Packet and Receive Buffers to the maximum?

Camera makers such as Basler recommend enlarging Jumbo Packet and the receive buffers and weakening Interrupt Moderation. Jumbo Packet, however, requires the camera, the switch and the NIC to all support the same size. Record the values before changing them, change one item at a time, and compare the number of dropped frames under the same conditions.

My USB3 Vision camera stops after a few minutes, or drops frames.

First check whether other devices or hubs are connected to the same host controller, and whether the cable and port meet the specification. Some camera makers list a procedure for disabling USB selective suspend. Microsoft does not recommend disabling it to driver developers, so try it on a PC dedicated to inspection and record the effect.

No matter how I change the settings, the dropped frames do not go down.

If the camera sends more than the path's bandwidth can carry, settings will not fix it. Calculate the required bandwidth from the pixel count, the bytes per pixel and the frame rate, and check whether it fits within a single link or host controller. If it does not, lower the frame rate or the ROI, or give each camera its own NIC or controller.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and bug investigation, with particular strength in projects where existing assets remain and in investigating failures whose cause is hard to see.