FFNK0104B FIELD GUIDEFlash & setup ↗

The story behind the firmware

From a board of possibilities.
To a desk companion.

How a collection of small applications grew into a Codex monitor, found its voice, connected to Desktop and gained a little personality.

Read from the beginning: each chapter follows a turning point in the application’s history. Dates mark milestones in Australia/Sydney local time.

· A board with possibilities

The project began with the board itself: a display, touch input, networking and storage, with no complete application chosen yet. Exploring those capabilities left room for the idea to take shape.

A calculator was an early step toward something usable. Connectivity tools brought scan results and an on-screen keyboard. The question was becoming less about what the board had and more about what someone could do with it.

· An easier way in

As the collection of small applications grew, trying one needed to be straightforward. A browser installer and named firmware catalog brought discovery and installation together on GitHub Pages.

That became part of the project’s approach: give each application a clear purpose, and let an owner move from reading about it to trying it in the same place.

· The board found a voice

Audio opened another direction. Microphone recordings could reach a speech service on the local network, with LocalLink finding the service. The board was beginning to connect physical interaction to software running nearby.

· Starting to feel like an appliance

Everyday behavior began to matter alongside individual capabilities. The screen could turn off after inactivity while touch stayed available. Wi-Fi setup moved into the browser, authorized by a code shown on the board.

These choices gave the project an appliance-like shape: something an owner could configure and leave on a desk, rather than a screen that stayed lit all the time.

· More than a screen

A live microphone meter made audio input visible. Speaker playback, an SD file manager and a standalone wireless-update application expanded the possibilities further.

The capabilities still had lives of their own. The project had not yet folded everything into one application; these separate directions left choices about what a future monitor should include.

Standalone wireless-update app ↗

· A purpose emerged: the Codex monitor

The board gained a clear role when the local bridge, animated dashboard and Bluetooth idle settings came together as a Codex monitor. Usage and agent activity could now live on the desk, with attention and unavailable states included in the experience.

The bridge then became a managed local service with streamed status updates. Quiet mode made room for an unobtrusive companion. The project was moving from a collection of capabilities toward an application with a daily purpose.

· Two paths for voice

Local wake-word detection and voice commands opened a way to interact with the board itself. Those commands joined the monitor, alongside its usage display and agent activity.

A standalone recorder kept another path open: save audio to SD, use touch controls, and play it back without needing a network service. Local commands and offline recording served different needs, so both remained part of the project.

· Making voice interaction understandable

Adding voice meant explaining what the board was listening for. A command and a recorded message are different interactions, so they received distinct guidance and timeouts.

Microphone feedback and a command guide made that distinction visible. Separate quota and agent views, together with reset bars, also helped the monitor explain what it was showing.

· A direct link to Desktop

The Wi-Fi bridge was no longer the only connection. An unofficial Codex Micro connection over USB opened a direct path to Codex Desktop, including controls and microphone audio.

That changed the screen’s role. With Micro connected, bridge threads gave way to Desktop slots and command keys. Desktop supplied the colors; the board represented those slots without inventing thread names or running-agent counts.

· Giving each connection a clear job

Bluetooth computer controls would compete with browser configuration for the same connection. The direction became clearer when Bluetooth stayed responsible for settings and USB handled computer controls.

Three agent slots and four joystick controls became the usual layout, with six slots available as an option. Keeping slot identity and meaningful status stable made the display easier to follow.

USB controls and avatar options ↗

· Voice controls that fit Desktop

The first microphone gestures did not fit comfortably with Desktop customization. Hold to talk became the default, sending audio while the button was pressed. A separate optional Voice button left room for continuous audio.

The distinction between board and Desktop also became clearer: the browser handled board preferences, while Desktop owned action mappings. Mic ON, Mic OFF and Waiting described the board’s outgoing audio. They could not tell the whole story of a Desktop voice session.

Voice controls and preferences ↗

· Updates became part of the application

Wireless updates had started as a standalone capability. They now belonged in the monitor’s settings, where an owner could check for a new version and explicitly choose to install it.

The update experience included a way back if new firmware could not start. Changes to speech models or the storage layout still called for a full USB installation. Bringing updates into the monitor meant carrying those boundaries along with the convenience.

Wireless updates and recovery ↗

· A little personality

The USB view began with numbered shortcuts. Robot avatars offered another way to look at the same slots, keeping the colors, header and touch actions while giving the screen more personality.

Each robot stayed with its slot through status changes. The numbered view remained the default, and the robots represented slots rather than particular threads.

USB controls and avatar options ↗

· The robots became expressive

The next step was to let those stable robots react. Their expressions began following thinking, input and error states drawn from Desktop lighting colors.

The screen became more expressive while keeping the same source of meaning: what Desktop actually supplied. A robot could change expression without changing identity.

USB controls and avatar options ↗

· Something personal between tasks

A standalone SD photo frame suggested a use for the monitor’s idle moments. Personal photos could fill the screen while the live usage bar stayed visible.

Photos became an optional idle mode alongside the normal and blank views. Configurable delays and the existing screen-off countdown kept the choice in the owner’s hands. The monitor could be useful during work and personal between tasks.

Idle-photo options ↗

· Status reached beyond the screen

The rear LED gave agent activity another presence on the desk: green for working, yellow when work ended, and red for attention or errors. Yellow described an ending without promising success.

The light was meant to be a brief notification. It defaulted to a one-minute timeout, could be disabled, and would not keep restarting for an unchanged status.

From there, the choice became more personal: each status could have its own Solid, Blink, Breathe or Rainbow pattern. Solid remained the quiet default. Rainbow offered an effect in place of the usual status color.

LED patterns and preferences ↗

· Knowing how long the pause will last

The monitor already showed how much Codex allowance remained. Reaching a five-hour or weekly limit raised a different question: when could that allowance return? The center of the screen became a place for the reset countdown, replacing the agents and shortcuts while the allowance was exhausted.

Voice controls stayed within reach. An exhausted included allowance did not establish that every interaction was unavailable, especially when credits could allow work to continue. Showing both exhausted windows kept a short reset from implying that a longer limit had also cleared.

Usage reset behavior ↗

· Updates could keep the board personal

Preparing a wireless update exposed a gap: the monitor’s preferences already stayed on the board, but its connection to the computer could still be tied to a private firmware build. Updating from the public image could leave the usage display without its bridge.

The bridge address and key became saved board configuration, with an encrypted setup form for changing computers or restoring a connection. Keeping those details alongside the existing preferences let later updates carry the application forward without asking the owner to rebuild their setup.

Persistent settings and migration ↗

· Making room for a growing setup

The setup page had grown alongside the monitor: microphone mappings, LED patterns, photos and a saved bridge connection each brought more controls. Showing every detail at once made ordinary settings harder to reach, while the added panels left awkward gaps.

Everyday controls remained visible. Optional settings and longer instructions could be opened when needed, updates sat alongside the main controls, and Wi-Fi and bridge configuration became separate cards under the same secure connection. The page could accommodate the monitor’s options without presenting them all as one long form.

Device setup guide ↗