I have already said that programming is not really my strong suit. But I badly wanted to experiment with the AKD1500, so I bought the M.2 card and decided to play with the coprocessor. I am doing this with Claude’s help, and I want to say that openly: without it I would not get far. I still think it is worth trying interesting things and seeing how far one can go.
The learning curve will be steep, and I could hardly be happier about it. I will try to describe the stages clearly, from the perspective of someone who does not yet know the field. Please be patient if something sounds uninformed. Sometimes it is.
Installation and first contact
The hardware was a Raspberry Pi 5 with the Akida AKD1500 M.2 card attached and, for now, a regular USB webcam. I would like to replace the webcam with an event-based camera when I can get access to one.
Assembly to first contact was fairly quick, with two detours. The card needed a 64-bit operating system; my first attempt with a 32-bit system ended in a dead end and an SD-card reflash. My Linux kernel was also newer than the official driver’s known versions, so the driver refused to build. Claude adjusted the version check in the driver source and recompiled it. After that the card appeared on the PCIe bus. If you are attempting something similar, it is solvable, and that is precisely the sort of moment when an AI coding companion helps.
Then I installed BrainChip’s MetaTF package and the chip answered its first request. That was a lovely moment. If there is interest, I can publish a summary of the commands and the problems we solved so others can benefit too.
Object recognition: the one-shot learner
Here is why I wanted the card in the first place. Akida can learn on the chip itself. I show an object to the camera, enter a name, and the chip learns it from a single camera frame in milliseconds. There is no cloud training and no hours-long run: the synapses on the silicon are updated while the program keeps running.
We built a small web application, provisionally called ENGRAM, with a live camera image, neuron-activity display and a Learn button. There were familiar lessons along the way. The camera needed fixed exposure and fixed white balance; with both on automatic, it kept presenting the chip with what looked like new images.
My favourite error of the evening was the green target frame. At first it was mere decoration. In reality, the network received an entirely different crop and diligently learned the desk background. The frame now shows exactly what the network sees.
Recognition of similar objects still had a very small margin. To the chip, a car key and a lighter were dangerously close. The next day would demand better training and a much clearer separation; more on that in Day 2.
Speed and energy
We added a small measurement area to the application: run the same neural network on the same camera image once on Akida and once on the Pi’s main processor. On that first evening, the neuromorphic chip was a little over twice as fast, with bit-for-bit identical output, and appeared to need a fraction of the energy according to the Pi-side power measurement we used at the time. Was that necessary to make the demo work? No. It was fascinating, though, and a way to see whether we were heading in a useful direction. This is a historical bench observation, not a current whole-system energy claim.
Claude also once turned 32 physical neural processors into 77 and insisted the count was right. Querying the actual hardware settled it: there are 32. The software table had double-counted. I could, of course, also have read the product description more carefully. Small mistakes like this happen often. Claude remains the more capable programmer of the two of us, so I forgive it.
A request before the next day
When you read these posts, please do not be annoyed if I write nonsense. Share what you know, correct me, and help widen my technical horizon. That is why I am writing the journey down. Day 2 follows, and that is when it gets really interesting.
The first evening described the predecessor ENGRAM setup. Current VORSA installation, hardware checks and runtime versions need their own dated verification.