For anyone joining the story here: on my desk a Raspberry Pi 5 and one BrainChip AKD1500 had learned objects in about a second. Day 2 gave the network better glasses, Day 3 gave the system a way to restart itself. Today there are two stories, and the first begins with a confession.
The truth was in the system log
The celebrated “self-healing” was, in hindsight, treatment for a
symptom. Eventually I wrote the sentence that changed the day: perhaps
we should solve the problem instead of forever arranging to restart
after it. We dug into the logs. Deep down was an unassuming
Timeout+ line. The PCIe bus, the connection between Pi and
card, had been silently accumulating transmission errors from power-on.
The card was not temperamental. The connection was.
The fix was to step the bus down one gear and turn off PCIe link power saving. Two configuration lines. The proof was a torture test: ten minutes at maximum request rate, the very pattern that had previously made the card fail. It produced 8,238 recognitions, no dropout and an empty error counter.
Naturally we wondered whether the fast bus could work if we only turned power saving off. The first thirty seconds looked great. Then the test reported 2,227 recognitions per second. That sounds like a record, but it is physically impossible for this workload; the real card took roughly 50 milliseconds per image. Under load it had stopped computing and began answering instantly with garbage data. No crash. No error message. The card had effectively begun to lie.
We reverted that experiment. The stress test now contains a lie detector: on that historical workload, replies below five milliseconds count as a failure, just as a timeout does. The honest operating point took 73 milliseconds per recognition. That was the price of a system whose output could be trusted, not a current VORSA benchmark.
Story two: ENGRAM 2.0
Then something happened that I had not planned. In one weekend the experiment became a program with a name, a version number and an interface I could show to someone else. ENGRAM began to look like the control room of a small factory: deep navy, steel-framed panels and amber highlights for matches. Here is a brief tour of what it could do then.
Search had three gears. If nothing moved in the image, ENGRAM did absolutely nothing: no calls to the card, and existing outlines stayed where they were. If a known object moved, the system followed its outline using a handful of measurements. Only when something changed in an unfamiliar region did it scan the entire field again. A tiny greyscale image and a before-and-after comparison made the decision, using simple arithmetic. Most of the time the card could rest; when it mattered, it woke up.
The search could also take a second look, which was my favourite feature. If one object partly covered another, the first pass saw only the top object. ENGRAM then painted that discovery grey and looked again. The covered object emerged by itself and got its own outline. Training images were augmented with random grey patches so the system learned that half a carabiner was still a carabiner. We were slowly getting multiple-object recognition to work, including some overlaps.
Recognition thresholds adapted by class. ENGRAM measured how much each class reacted while its object was absent and put that class’s threshold just above the noise. The manual control still existed, but I had not touched it for hours.
Learning had turned into a loop. Hold up an object, type or speak a name, wait about a second, and it is learned. The generated prototype images could be added to a training collection with one button. Another button retrained the network’s “glasses” in the background while recognition continued. When the new model was ready, the application installed it and relearned the stored objects from their prototypes. No terminal and no manual restart. The computer running all of it cost about as much as a better coffee machine.
A bad button layout had deleted an entire class that afternoon. The log showed I had clicked it, so the code was innocent; the design was not. Every deletion now made an automatic copy first, with a one-click undo. ENGRAM wrote an event log and evidence photos to the SD card, backed itself up at three each morning, and could start the Pi directly in a full-screen view. Plug in power and the machine would run.
The numbers from that day
The historical test produced 73 milliseconds per honest stable recognition and 8,238 recognitions in a ten-minute stress run with no dropout. A still scene caused zero card calls. The desk-side energy comparison suggested 22 millijoules per recognition on the card versus 236 for the Pi CPU. There were ten learning positions and twenty neurons per object. Processing one image or twenty-five in a batch took the same time per image in that test, with no visible management overhead. This suggested a near-linear benefit from more cards for that workload. These were ENGRAM observations on that setup, not measurements of today’s full VORSA cell.
Four cards on the seating plan
Three more AKD1500 cards were due the next week. The historical plan in the interface gave card 1 uninterrupted recognition, cards 2 and 3 a share of the search, and card 4 a mirrored learning state as standby. We estimated that a 1.8-second search pass could fall towards 0.5 seconds. That was a projection from the per-image test, not a completed four-card result. Card 4 had the most relaxed job: know everything, do nothing, and step in when another card weakened. I know colleagues with the same job description.
Obstacles of the day
This became a new regular section: what failed, how to recognise it, and what helped.
The card froze or returned nonsense under sustained
load. sudo lspci -vv showed Timeout+
in the PCIe error status. On that Pi we set
dtparam=pciex1_gen=1 in config.txt, appended
pcie_aspm=off to cmdline.txt, rebooted and
reran the load test. The slower bus cost about 22 milliseconds per
recognition in that test, and each was worth paying.
A test that only waits for error messages misses the worst failure. The card could return immediately with invalid data. We flagged responses that were implausibly fast for the tested model: under five milliseconds. Impossible speed failed the test just as surely as a crash.
Camera numbers changed across boots. A service that
depended on /dev/video0 could fail even though it had
worked the day before. We stopped relying on the number: the startup
path probed available cameras and repaired the selected setting.
Two delete buttons beside each other made a trap. One click erased a class. Before every delete, the application now saved a copy and offered undo. It took an hour to implement and saved a great deal of worry.
Correct me if I get something wrong. I learn at least as much from comments as from building. What stays with me from Day 4 is this: a system that heals itself is good; a system that no longer needs that healing is better. A system that can look beneath an overlapping object is why I started this journey.
ENGRAM’s proposed four-card seating plan was a historical projection. VORSA INSPECT 1.9.37 uses cards 0–2 for prototype recognition and card 3 for the optional M3 detector. The historical 22 mJ figure is not a full VORSA-cell measurement.