We were running a sensor evaluation for medical imaging projects, and we needed to characterise a new high-speed black-and-white CMOS sensor. The Arducam evaluation kit was the fastest path to get it on the bench, but after a few days of work it became clear that the stock software tooling wasn’t enough: it was fine for saying “the sensor works”, not for actually understanding it.
The problem, in two lines
The SDK’s demo GUI was basic by design — open the device, show a frame, save. We needed more than that. The hard part of imaging isn’t checking that frames come in: it’s iterating on the sensor’s registers. Around a hundred of them, each with mutual constraints you discover by reading the datasheet and then verifying on the bench. Exposure, analog gain, digital gain, windowing, synchronisation modes.
What we really lacked was three things working together: a register editor guided by the datasheet (not a raw text field), live preview while you change values (not “edit → restart → look”), and JSON profiles you could save and reload per sensor.
The iteration loop we needed was minutes, not tens of minutes.
What we built
A desktop GUI in Python with Tkinter. The language choice was pragmatic: speed of development first, the Arducam SDK already had Python bindings, Tkinter gave us enough cross-platform support without pulling in a heavy UI framework. For an internal tool meant to be iterated daily on the bench, it was the right combination.
We opened the architecture from the start, with future uses in mind: each sensor is described by a JSON profile with its register map, its functional groups, its datasheet-style help. Adding a new sensor means dropping the .cfg file produced by the Arducam tooling into configs/, then creating the matching JSON profile in sensors/ starting from _template.json. No Python code changes: the GUI picks it up on restart.
On top of this we built the functions that actually mattered for characterisation work: a register editor with a toolbar for filtering and grouping, a per-byte view switchable to a combined multi-byte view, live help from the active profile. And a software auto-exposure loop with optional auto-gain — something the original Arducam GUI didn’t have. We added it because we needed to separate sensor noise from illumination variations during tests, but we wrote it generically, not tied to the sensor we were testing.
When the tool becomes a bargaining chip
At some point the tool was working well, it covered our case, and we ended up holding documentation for a specific sensor — register map verified on the bench, functional groups, operational constraints — that Arducam hadn’t yet published for that model.
We wrote to a technical contact at Arducam by direct email. It wasn’t a cold pitch or a request for endorsement: it was a concrete offer. We had curated, verified sensor JSON profiles; they had information on the official registers that we were missing. A proposal for an exchange between engineers.
The reply came back enthusiastic within two days. They appreciated the tool to the point of including it in their official documentation as a useful resource for people working with their evaluation kits, and the exchange went ahead: we now have access to more detailed configuration information from their side, and they have a curated open-source tool to point their community to.
What struck them, judging from the messages we got back, wasn’t a single feature: it was the open architecture. The fact that the tool wasn’t tied to a specific sensor but to a data model — the JSON profiles — meant it was extensible to any EVK in their catalogue without rewriting code. Another person could add their own sensor in half an hour.
The value of a public tool
The tool was built for us, on a specific case, with the real time constraints of a project — not with Arducam in mind. What happened next — the email, the enthusiastic reply, the inclusion in the official docs, the ongoing technical exchange — was the consequence of a choice made upstream: opening the architecture from the start, even when we could have just hard-coded the sensor we were testing.
Sometimes the most effective way to be seen isn’t writing a marketing post: it’s releasing well a tool that was genuinely useful — and designing it so that it can be useful to others too.
The tool is open source, MIT-licensed, and lives on GitHub: arducam-evk-gui. For the full technical documentation, see the dedicated wiki page, and the repository card collects the links. The tool is cited in Arducam’s official documentation; we will add the direct link to the page here.
Working on high-speed black-and-white CMOS sensor characterisation, or on a similar use case? Let’s talk.