Event camera polarity and timestamps: when events beat frames

A frame camera samples the world in fixed slices: at 30 fps you get one 33 ms window, then a 33 ms gap, over and over. Anything that starts and ends inside a gap never reaches your algorithm, and anything that moves during the window comes out blurred. An event camera works the other way round: each pixel watches its own signal and reports the moment it changes, as a tiny record carrying coordinates, a timestamp and a polarity. This guide explains that record, works the bandwidth arithmetic on both sides of the comparison, and ends with a decision rule for fast production lines, mobile platforms and condition-monitoring points. The frame cameras and accessories we sell cover the frame side; the event side is set out here so you can tell when adding it earns its keep.

What an event camera sends instead of frames

A 12 MP frame camera transmits 12,000,000 pixels whether anything changed or not. An event camera keeps each pixel silent until its brightness changes by more than a set threshold, then emits one short record. The stream is the address-event representation, usually abbreviated AER: coordinates, time and a sign.

Time is the biggest difference. The timestamp comes from the sensor's own clock at roughly 1-10 µs granularity, so records stay ordered exactly as the scene produced them. How a driver hands you these records — files, buffers, iteration order — is covered in Event camera data format: coordinates and timestamps, not pixels.

Output volume scales with scene dynamics, not with pixel count. A still scene emits almost nothing; a busy one can emit a few million events per second. That one property drives both the bandwidth win and the integration work further down.

Timestamps: continuous sampling versus frame slices

Take a transient that lasts 100 µs: a spark, a seal popping, a reflection sweeping past. A camera sampling at 1,000 fps opens a window every 1 ms, and the window overlaps the event only if the event's phase happens to fall inside it:

With the event's phase uncorrelated to the frame clock, you catch it 10% of the time and miss it 90%. Raising the frame rate helps linearly: catching that same 100 µs transient 90% of the time needs a sampling period near 111 µs, about 9,000 fps, with bandwidth and strobe cost rising step for step.

An event camera stamps each change as it happens. The same 100 µs transient is one burst of positive events followed by a burst of negative ones, with no phase lottery. Latency from change to record sits in the microsecond range; a frame camera's latency is exposure plus readout plus transfer, typically milliseconds. Measurements also show event-camera latency varies with scene activity while a frame camera's profile stays flat, so bench-test your own part before trusting a latency figure.

Frame cameras stamp time coarser. Most frame metadata marks the frame boundary rather than the instant light hit, and chunk data timestamp: camera time at exposure end and how to latch it shows how to latch exact exposure time when a tracking loop needs it. On any busy link, records can arrive out of order or share a timestamp, so give your consumer code a deterministic tie-break; the same failure pattern is documented for EtherCAT in diagnosing EtherCAT out-of-order frames with identical timestamps.

Polarity: the sign of every change

Polarity tells you the direction of the brightness step at one pixel. On a dark cap moving across a light belt, the leading edge darkens the pixels it covers: negative events. The trailing edge uncovers them: positive events. Pair a negative edge with its positive partner a fixed distance behind, and you have part edges, speed and direction of travel from timing alone — no strobe, no reconstructed image unless you want one.

What polarity cannot give you is the value itself. A uniform, stationary surface emits nothing at all, so reflectance, colour, texture, print and surface finish stay frame-camera work. Treat an event stream as a change map, never as a picture.

Lighting interacts in specific ways. A steadily lit scene stays quiet, while a PWM-dimmed panel imprints its switching frequency on the stream as periodic event bursts. Moving shadows, flickering lamps and passing reflections all generate genuine events your filter must absorb. The upside is dynamic range: data sheets commonly quote scene-brightness tolerance near 120 dB for event sensors against roughly 60 dB for a conventional global-shutter part, which is why event perception holds up through door openings, weld glare and dusk-to-worklight swings on mobile platforms.

The bandwidth arithmetic, both ways

Frame side first. A 12 MP mono camera at 8 bits sends 4000 × 3000 = 12,000,000 bytes per frame. At 30 fps that is 360 MB/s, or 2.88 Gb/s. A single GigE link carries about 118 MB/s of payload, so 12 MP at 30 fps already needs USB3 (about 400 MB/s usable) or 10GigE, and colour doubles the bill. Planning recorded capture multiplies it again; high frame rate camera data rate: plan 2000 fps recording runs that arithmetic for a recording rig.

Event side, with the assumptions stated. Pack one event — coordinates, polarity, a microsecond timestamp — into about 8 bytes. A busy scene at 5,000,000 events/s then produces 40 MB/s, or 320 Mb/s, comfortably inside one GigE link. A quiet line at 50,000 events/s produces 0.4 MB/s. The point is not that events are always smaller; it is that event data tracks change, so idle cost sits near zero and burst cost scales with how much actually moves.

When the frame side runs several cameras at high rate, the interface follows the link budget, and that is what the frame grabbers category and the accessories finder are for. The MV-GT2104 quad-port 10GbE NIC carries four 10GigE camera links on one card.

Where event sensing wins

• Continuous fast motion: webs, pills, caps and print at metres per second, where freezing every frame needs a strobe and a fat link. Events give position versus time for every edge at microsecond resolution.
• Transients shorter than a frame period: arcs, sparks, impacts, latch releases. The 90% arithmetic above is the budget you are fighting.
• Vibration and oscillation: a fixed camera watching a vibrating fixture turns per-pixel event timing into frequency content without a contact sensor.
• Mobile platforms: power and bandwidth are budgets, event output collapses when nothing moves, and the wide dynamic range survives lighting swings and dust.
• High-rate counting: repetitive blob or droplet passages become timestamped on/off pairs you can tally into the thousands per second.

When a frame camera is still the right tool

Grading is frame work: colour verification, print and OCR, surface finish, dimensional metrology, and depth, where profile- and stereo-based 3D sensors build organised point clouds from full captures. Static stations a PLC triggers in sequence are frame work too; nothing changes between parts, so an event camera just idles. Every audit and traceability record is a frame by definition.

Worked example, frame side. Part: a 120 mm wide cap seal on a belt running 600 mm/s. Defect to catch: 0.2 mm. Working distance: 300 mm above the belt. The pixel rule wants 4 px across the smallest defect, so the image scale target is 0.2 / 4 = 0.05 mm/px. A 1.1-inch 12 MP sensor carries 4096 × 3000 pixels at 3.45 µm, so 4096 × 0.05 mm = 205 mm of usable field width: the pixel rule clears with room. Camera resolution for defect detection: size it by the pixel rule covers this sizing step in detail, and the calculator below runs it.

Now the lens. Target field of view: 140 mm, the 120 mm part plus margin. Magnification m = sensor width / FOV = 14.13 / 140 = 0.101.

The nearest standard focal length is 25 mm. Check the real geometry: m = f / (WD - f) = 25 / 275 = 0.0909, so FOV = 14.13 / 0.0909 = 155 mm and mm/px = 155 / 4096 = 0.038. The 0.2 mm defect now spans 5.3 px. Pass, with margin.

Exposure last. A blur budget of 1 px at 0.038 mm/px and 600 mm/s belt speed gives:

Sixty-three microseconds against a 10 ms exposure is 160 times less light, about 7 stops — that is the strobe you must budget, and exposure caps the achievable frame rate as RGB camera frame rate limits: pixel format and exposure shows. The MV-CH120-11UC is the 12 MP, 1.1-inch, global-shutter USB3 camera behind this example sensor, and as the high-speed version it holds its frame rate at short exposures.

Integration: getting events into a machine

A PLC cannot consume this stream. Scan cycles run in milliseconds while events arrive microseconds apart, so put a pre-processing node between sensor and controller. Bin events into time slices — 1 ms reconstructed frames are the common input to CNN and rule-based code — or reduce the stream to rate, position and count metrics that drive discrete I/O. That node is a PC-class box next to the camera, and industrial mini PCs are built for that mounting position.

Timestamps need discipline. An event camera's clock is its own; when you fuse with frame cameras, share a hardware trigger or latch times, then match records across streams — pair frames from two synced cameras by timestamp covers the matching for two frame cameras, and the same logic carries over. Before committing, log the event rate on your real scene at line speed for a minute and multiply by 8 bytes per event; that one measurement settles the bandwidth question.

The decision, per case

1. A feature shorter than your frame period that you cannot miss: event sensing, or a much faster frame camera with a continuous strobe, paying the bandwidth either way.
2. Grading surface, colour, print or dimensions: frame camera, strobed to freeze motion, sized by the pixel rule — the worked example above is the template.
3. Both on the same line: hybrid. The event camera times and locates every change; the strobed frame camera grades the part; fuse the two by timestamp.
4. Tight bandwidth or power budget with sparse change: events, because idle output sits near zero.
5. Static, PLC-sequenced stations: frames alone; an event camera adds data there, not information.

For case 2 at a stop station, the MV-CU020-90GC is a 2.5 MP colour GigE camera with a global shutter — enough for presence and gauge checks.

If frames win your case, size one in the area scan cameras range with the camera finder, then run the link numbers before you pick the interface. If events win, budget the pre-processing node and the timestamp discipline from the integration section, and treat the sensor as one input beside frames, PLC states and drive data. More stream-level arithmetic lives on the systems topic page, and if the decision is close, contact us with your belt speed and part size — we will run both sides of the arithmetic with you.