USB Interrupt Endpoint bInterval Debugging: Polling Rate, HID Latency, Full-Speed vs High-Speed, and Missed Input

USB interrupt endpoints are used by keyboards, mice, game controllers, sensors, touch panels, barcode scanners, UPS devices, and many custom HID tools. Users search for "USB bInterval", "HID polling rate", "USB interrupt endpoint latency", "missed input reports", "USB device 125Hz 250Hz 1000Hz", and "bInterval full speed high speed" when input feels delayed or reports arrive at the wrong rate.

BusScope is useful because polling behavior is defined by endpoint descriptors and actual bus timing. The operating system UI may only show "device connected"; the capture can show what interval the host actually uses.

What bInterval means

An interrupt endpoint descriptor includes bInterval. This value describes the polling interval, but interpretation depends on speed and endpoint type.

Important distinctions:

• Low-speed and full-speed interrupt endpoints use millisecond frame-based intervals.
• High-speed interrupt endpoints use a different encoding based on microframes.
• Host controller scheduling and hub topology can affect observed timing.
• Application read timing is not the same as USB bus polling.

If an engineer only looks at application callbacks, they may miss the actual endpoint schedule.

Common symptoms

Polling interval problems show up as:

• Mouse or controller feels laggy.
• HID input reports arrive every 8 ms instead of 1 ms.
• Device advertises 1000 Hz but behaves like 125 Hz.
• Sensor data is bursty.
• Barcode scanner drops fast scans.
• Touch panel feels delayed after resume.
• Firmware sends reports faster than host polls.
• High-speed mode changes report timing unexpectedly.

These issues are usually searched as latency or responsiveness problems, but the root evidence is in the USB descriptor and packet timing.

Full-speed vs high-speed interpretation

The same numeric bInterval can mean different effective timing depending on speed. A full-speed HID endpoint with bInterval=8 is not the same scheduling model as a high-speed endpoint with the same byte value.

Debugging should capture:

• Actual negotiated speed.
• Endpoint descriptor.
• Endpoint address.
• Transfer type.
• bInterval.
• Observed IN token or transfer cadence.
• Report payload timing.

BusScope should show descriptor values and observed timing together.

Firmware overproduction

Some firmware generates input reports faster than the host polls. Those reports may be overwritten, coalesced, or dropped before the host ever sees them.

Symptoms:

• Device internal logs show events.
• Host receives fewer reports.
• Fast button presses are missed.
• Motion looks smoothed or delayed.
• Reports after a burst contain only latest state.

This is not a USB packet-loss problem. It is a firmware buffering and polling contract problem.

Host polling is not application read rate

An application may read every 1 ms, but the USB host may only poll every 8 ms. Or the host may poll on time, but the application event loop may process data later.

Packet capture separates:

• Bus polling interval.
• Device response timing.
• Host driver buffering.
• Application callback latency.

That separation is critical for HID latency support cases.

bInterval descriptor mistakes

Common descriptor bugs include:

• Accidentally advertising bInterval=10 instead of 1.
• Copying full-speed interval into high-speed descriptor incorrectly.
• Using one interval in HID descriptor expectations and another in endpoint descriptor.
• Firmware comments claim 1000 Hz but descriptor says slower.
• Alternate setting changes interval but firmware does not handle it.

The byte in the descriptor is the contract the host schedules against.

Debug checklist

Use this workflow:

1. Capture enumeration.
2. Identify interrupt endpoint descriptors.
3. Record actual device speed.
4. Decode bInterval.
5. Measure observed interrupt IN cadence.
6. Compare with expected polling rate.
7. Trigger fast input events.
8. Check whether reports are missed or coalesced.
9. Compare direct port vs hub.
10. Preserve descriptor and timing evidence together.

Final diagnosis

USB interrupt latency is not just an application performance issue. It depends on endpoint bInterval, speed mode, host scheduling, report generation, and firmware buffering.

BusScope helps prove whether a HID or interrupt device is truly being polled at the intended rate and whether missed input is caused by descriptor settings, firmware buffering, or host/application timing.