Camera user flash: store calibration data on GigE and USB cameras

Last month's camera swap cost you an hour of re-pairing: lens shading tables, flat-field references, the license file that enables your software on exactly one unit. The camera can carry that data itself. Most current GigE Vision and USB3 Vision cameras reserve a small non-volatile user area that you read and write through the camera's file access feature, and the bytes stay with the camera through power cuts, reboots and moves to another host. This guide gives you the sizes to plan against, a worked example of what fits, the write-read-verify cycle that puts data there safely, and a clear line between what belongs on the camera and what stays on the host.

What camera user flash is

User flash is a small block of non-volatile memory inside the camera housing, separate from the image buffer and from the settings RAM. Bytes you write there survive power-off, reboot, reinstallation on another PC and shipping to another site. It is the camera's own pocket storage, and it travels with the serial number.

You will meet it in two forms. Register-style user data is a few hundred bytes living directly in the feature map — room for a serial tag or a checksum, nothing more. File-style flash is the useful one: tens of kilobytes to several megabytes exposed as named files through the File Access feature over GigE Vision or USB3 Vision. A widely deployed USB3 area-scan documents 6 MB of it; other models sit above and below that figure. Your model's spec table prints the number — look for the non-volatile memory or flash row and plan against that value, not against a class average.

Do not confuse it with a user set. A user set records the camera's own parameters — exposure, gain, packet size — into a slot that loads at startup. User data is arbitrary bytes that you define. Most finished builds use both: the set for the imaging recipe, the flash for your files. The parameter side is covered in Save camera parameters as a user set that loads on startup.

How much space you get, and what fits

Size the file before you promise anything. Two lines of arithmetic decide the whole design:

Flat-field and dark frames are the trap. The full-resolution correction frame a modern sensor wants is far larger than any camera's flash; the compact representation your software actually applies is not.

Small text beats images on this storage. A license key, a station-geometry JSON or a coefficient table runs a few kilobytes; a 6 MB area holds hundreds of such files by byte count alone. Keep 2× headroom for the metadata you will inevitably add, and design to a 1 MB ceiling for anything that must also fit the smaller file-style flashes — that leaves 6× headroom on a 6 MB camera and still fits the modest ones.

How the write and read cycle works

The File Access feature is a group of GenICam nodes on the camera's feature map. You select a file entry, open it in a mode, stream bytes at a working offset and close it. Every SDK that speaks GenICam reaches the same group, and the vendor's feature browser shows it before you write any integration code.

1. Confirm the feature exists. Open the camera in your SDK's feature browser and look for the file access group; minimal or old firmware sometimes omits it.
2. Select the entry the manual marks as user data. Firmware images and logs can share the same feature, and those entries are not yours.
3. Open for write and stream the file in chunks at increasing offset until the byte count matches. Transfers go over the control connection in small chunks, so budget seconds per megabyte — never write inside the production loop.
4. Close, then read the same length back and compare a checksum in your own code. A write without a read-back is a hope.
5. Power-cycle once and read again. That single commissioning test proves the persistence you are designing around.

Two failure modes come up often enough to have their own pages. Streaming bytes from Python trips type conversions; Python 3 GenICam file access: fix binary data errors walks through it. Nodes missing from the map point to the feature, not to a full flash — GenICam node not existing: diagnose feature access errors covers the diagnosis. And writes refused after a reconnect are usually write protection, handled in Camera feature write-protect errors after reconnection.

Where on-camera data earns its place

The pattern that pays is data that belongs to the unit, is small and is read at startup.

• License and entitlement keys bound to the camera serial: the entitlement works wherever the camera is plugged in, and moving the camera to a second line does not break it.
• Compact calibration: a downsampled lens-shading map, distortion coefficients for the lens you mounted at commissioning, a focus offset.
• Station geometry and recipes for board-level cameras on embedded heads, which have no disk of their own — a few kilobytes of JSON restore the whole configuration after a power cut.
• Pairing records that tie camera to lens or camera to fixture, so a swapped part announces itself instead of quietly passing inspection.

Typical cameras for this pattern span both interfaces: a 20 MP USB3 workhorse for detailed inspection, a 12 MP GigE camera for longer cable runs, and a bare-board USB3 module for the embedded head.

Moving parts change the sensor choice, not the storage pattern: your commissioning script talks to the feature group, so the same script serves rolling- and global-shutter cameras alike.

3D sensors take the travelling-data idea furthest. A laser profiler's per-unit factory calibration turns sensor peaks into millimetre coordinates and must survive the unit's whole service life; the same logic argues for keeping your station geometry — mounting height, encoder scale, tilt offsets — in the user area, so a replaced sensor comes up with numbers that match the mechanics. Mounting height and working distance are exactly what the 3D camera working distance and positioning guide walks through, and the 3D sensors range holds the profiling and structured-light families where this pattern applies.

What belongs on the host instead

Four limits set the boundary.

Capacity: full correction frames do not fit. The worked example above puts a 12 MP flat-field frame at 24 MB against 6 MB of flash; even a 1080p frame at 16 bits is about 4 MB, most of a small flash. Images belong on the host, in RAM or on disk.

Churn: anything that changes per shift or per cycle belongs in a database or version control on the host, not in flash cells you have to erase.

Endurance: flash cells survive a finite number of program/erase cycles — typically 10,000 to 100,000 for the grade used in embedded gear. Commissioning writes barely dent that; per-cycle logging destroys it.

Secrecy: the flash reads back to anyone holding the camera. Store license keys your software can validate against the serial, not credentials whose exposure costs you.

When the capture box is an embedded board, its own storage takes the frames the camera cannot hold — Store camera images on embedded vision board flash in C covers that host-side pattern.

Checks before you build around it

• Read the exact flash size from the spec table row for your model — non-volatile memory or flash, in MB — and design to 2× headroom.
• Confirm the file access group exists in your unit's feature browser before writing integration code.
• Run the full proof once at commissioning with the real file: write, close, read back, compare checksums, power-cycle, read again.
• Repeat that proof after every firmware update; on some models the update rewrites regions that include the user area.
• Keep the master copy of every file under version control on the host, named with the camera serial.
• Put the restore procedure in the runbook for camera swaps, so a replacement is back in minutes.

The swap case deserves its own planning: Board level camera replacement when a sensor goes end of line lists what else has to be re-matched when a camera changes.

The decision

Store it on the camera when the data is under about 1 MB, belongs to that unit and is read at startup: license keys, compact shading maps, distortion coefficients, station geometry, recipes. One megabyte keeps 6× headroom on a 6 MB flash and still fits the smaller file-style cameras, so it is a ceiling that travels across models.

Keep it on the host when the data is large, changes often or must stay secret: full flat-field and dark frames, per-cycle images, credentials.

Calibrate the middle ground. A parameterised model — a downsampled shading map or a polynomial — rides on the camera while the full-resolution master stays in version control; a replaced camera then carries enough to run while the host rebuilds the rest. That split gives you cameras that travel with their brains and a host that keeps the archive.

Pick the class first — area scan cameras for production inspection, the camera finder to filter by interface and resolution — then read the flash row on the spec sheet before you commit the design. More on the software side of camera integration sits on the systems topic page.

If you want a second pair of eyes on the sizing, send the camera model and your file sizes through the contact page.