You're seeing intermittent failures. The system works fine most of the time, but occasionally drops frames, triggers faults, or produces glitches. Standard monitoring shows everything fine. By the time you check, the problem has passed.
How do you catch a problem that only happens once an hour—or once a week?
The Core Problem
Real-time networked systems fail in ways that are invisible to standard monitoring tools. Throughput looks fine, latency averages look fine—but the application stutters.
The problem is timing variance. Averages hide the spikes that break real-time systems. A 10 ms average latency with occasional 200 ms spikes looks "fine" in the dashboard—until the application times out.
These issues are:
- Intermittent — they happen rarely, so you can't be watching when they occur
- Invisible — standard monitoring aggregates away the problem
- Hard to reproduce — you can't fix what you can't reliably trigger
The Solution: Trap + Capture
The JT-10.1 monitors packet timing continuously. You set a threshold based on your application's tolerance. When that threshold is violated:
- Trap triggers — the timing anomaly is detected
- Ring buffer captures — the last 30 seconds of traffic is saved
- You have evidence — timestamps showing exactly when and how the network failed
You don't have to be watching. Set the trap, let it run, come back to evidence.
Domains We Work With
Machine Vision
GigE Vision cameras for industrial inspection. Frame timing jitter causes missed defects and line stoppages. Typical threshold: inter-packet gap > 20 ms for 60 fps cameras.
Broadcast Audio
AES67, Dante, and ST 2110 audio networks. Packet jitter causes clicks, dropouts, and off-air events. Typical threshold: inter-packet gap > 2 ms for 1 ms packet intervals.
Industrial Control
EtherNet/IP, Modbus TCP, and OPC UA networks. Timing violations trigger connection timeouts and production stops. Typical threshold: gap > 300 ms for 100 ms RPI.
Beyond Catching Problems
The JT-10.1 also injects controlled impairments—delay, jitter, packet loss—to find where systems break before they break in production:
| Use Case | What You Learn |
|---|---|
| Finding margins | "System tolerates up to X ms jitter before failure" |
| Stress testing | Does the receiver handle degraded conditions gracefully? |
| Comparing configurations | Does this NIC/switch perform better than that one? |
| Validating QoS | Is priority queuing actually working under load? |
| Testing redundancy | Does failover work? How long does it take? |
Isolating the Fault Domain
When something fails, is it the network or the endpoint?
The JT-10.1 sits at the boundary. It sees exactly what the network delivers:
- Network timing clean, but still failing? Problem is downstream—endpoint hardware, drivers, or software.
- Network timing shows gaps or jitter? Problem is upstream—switches, cabling, or competing traffic.
Instead of "it's failing somewhere," you know which team owns the fix—and you have the pcap to prove it.
The Tools Gap
Existing tools leave a gap:
| Tool Category | Limitation |
|---|---|
| Cable testers | Validate physical layer, don't test timing behavior |
| Protocol analyzers | Capture packets, can't inject impairments |
| Continuous monitors | Observe production, can't stress test |
| Enterprise WAN emulators | Do everything, cost $50K–500K |
The JT-10.1 provides impairment injection + timing measurement + triggered capture at a price point accessible for development and integration testing, not just final certification. See how tools compare →