Cranium Developer console

In development

A DJ controller,
without the laptop.

Cranium is a mounted attachment for beginner DJ controllers such as the Pioneer FLX4. With Bluetooth audio and a Raspberry Pi, the controller is meant to run on its own, with no computer at any point.

It is being developed by a student team at Penn, and it is not for sale. Where it stands says what has been built and what has not.

How updates are secured Source on GitHub

What it is

An attachment, not a replacement.

Cranium mounts on the controller a new DJ already owns and takes the laptop out of the setup. It is meant to be more familiar, cost-effective and sustainable than upgrading to an all-in-one DJ system.

The design runs playback, mixing, library browsing and setup from the controller and a built-in screen. Bluetooth Low Energy audio is there to take on the usual problems of wireless sound, and a Raspberry Pi drives the display.

Comes in

  • DJ controllerSuch as the Pioneer FLX4
  • USB driveA library, with its playlists and saved track markers

Cranium

  • nRF5340Inputs, outputs, wireless
  • Heartbeat and battery level, over UART
  • Raspberry PiMixxx on Raspberry Pi OS, and the screen

Goes out

  • Bluetooth audioTo be authenticated before it reaches your other devices
  • Dual XLR and RCAWired outputs
  • 3.5 mm jackHeadphones
Fig. 1 How it is designed to connect. The attachment stands where the laptop stood. Further down, Where it stands says how much of this is built.

Secure updates

Over the air, a board takes only what was signed, and only after a person says yes.

Firmware for the nRF7002 DK arrives over Wi-Fi through AWS IoT. An update has to pass every step below, and a new image that cannot prove itself is replaced by the previous one, with nobody touching the board.

  1. SignedOn the release builder, not the server
  2. CheckedBy the server, on upload
  3. OfferedAn AWS IoT job. Nothing downloads yet
  4. Button 1 pressedA person says yes
  5. DownloadedInto the inactive slot, digest compared
  6. VerifiedBy the bootloader, which swaps the slots
  7. On trial5 minutes to reach AWS IoT
  8. ConfirmedThe new image marks itself as good

Not confirmed: back to the previous firmware

Fig. 2 One update, from signing to confirmed.

  • Signed images

    Every image carries an ECDSA P-256 signature over its SHA-256. The console holds only the public key, so it can check a signature and never create one. A break-in there cannot produce firmware that a board accepts.

  • A person presses a button

    An update arrives as an offer. Nothing is downloaded until Button 1 on the board is pressed, and Button 2 declines. A cancelled update is dropped, before the download and again before installing.

  • Verified by the bootloader

    On every reset MCUboot checks the SHA-256 and the signature of the application's image, and starts it only if both are valid. It has no network stack, so nothing reaches it over the air. An image that fails is never started.

  • Automatic rollback

    A new image runs on trial. It must join Wi-Fi and reach AWS IoT within 5 minutes to confirm itself. If it does not, the next reset swaps the previous image back and the board reports the rollback.

Failures

What happens when an update goes wrong.

A bad signature, or another key
MCUboot never starts the image. The board keeps running its current firmware and reports the update as failed. The server refuses such a file as well.
Older firmware
Over the air, the application refuses a job that is not newer than what it runs, and MCUboot compares versions before it swaps in an update. A swap back after a failed trial skips that check, and serial recovery has none: see Known limits.
A corrupted or incomplete download
The application compares the SHA-256 of what arrived with the digest in the job. On a mismatch the image is erased and nothing is installed. A failed download gets up to five attempts in all, each with a fresh link.
Faulty code with a valid signature
It runs on trial and cannot confirm itself, and a watchdog covers a hang. The next reset makes MCUboot swap the previous image back.
Power lost during the swap
MCUboot continues the swap on the next boot. Tested with a reset through the reset pin, not with a power cut.
Cancelled after it was offered
The board asks AWS IoT before the download and again before installing. A cancelled job is dropped: an image that is complete is erased, and a partial one stays unused until the next download overwrites it.

Specification

What it is being built to do.

These are requirements from the project's public specification. They are targets, not measured results.

  • USB-C
  • 2 × USB-A
  • 2 × button
  • Screen
  • 2 × XLR
  • RCA
  • 3.5 mm
Fig. 3 The ports and controls it calls for. Connector faces, not a drawing of the enclosure.
Computers needed, at any point
0
From power-on to ready, at most
30s
To recognize the controller, at most
5s
Mounting
On the FLX4, with zero mechanical load on the controller's USB and RCA ports.
Library
Prepared directly from a USB drive, keeping playlists and saved track markers.
Controller
If it is disconnected, the system resumes on reconnection without a restart.
Audio
No more than 3 seconds of delay and no dropouts, in a test with two decks and effects running.
Battery
A graceful shutdown with no filesystem corruption when the battery drops below 5%.
Updates
Written to an inactive partition, and never begun without confirmation or while audio is playing.
Enclosure
Spill-resistant, with a lock slot and no externally accessible debug headers.

Where it stands, as of November 2026

In development, and plain about it.

Built and tested

Over-the-air updates for the nRF7002 DK through AWS IoT, tested on one board. The developer console is built, and those tests did not go through its sign-in. A person at the board can also go back to one frozen image with a button, tested on that board with the debug port holding the button.

Not built yet

  • Audio. The board has no audio yet, so what this page says about Bluetooth and wired sound is the design.
  • The enclosure and the mount. So far it is a development kit on a bench.
  • Updating the Raspberry Pi with RAUC, driven by the same console. The design is written, and none of it is built.

Known limits

  • The development kit's debug port is open, so MCUboot and its key can be replaced through it. A product build would have to lock it, and there is no such build yet.
  • Serial recovery, which takes an image over the board's serial port, has no version check and no trial. Any image ever signed with this key can go on that way, and if it is a bad one, only another upload or the frozen image brings the board back.
  • MCUboot does not check the network core's image. It is flashed over the debug port, and it has no radio stack and no keys.
  • The board's device key is stored encrypted and never leaves the board, but code running in the application could read it and act as that board.
  • The board speaks TLS 1.2. TLS 1.3 is not enabled.
  • The update image is not encrypted. It contains no secrets.
  • Downgrade protection compares versions. There is no hardware counter, and code running in the application could ask for a swap back to an older signed image.
  • The button gesture for the frozen image has not been done by hand yet, and no power has been cut during a restore.
  • An update over Bluetooth is written as a build option, and it is off. It has not been tried with a phone.
Updates in a row that passed
10of 10
From Button 1 to confirmed
181–227s
The swap in MCUboot, every time
81s
Measured On October 31, 2026, on one nRF7002 DK and AWS IoT, with firmware 1.1.30 to 1.1.39. A test bench pressed the button, and these runs created the job with AWS credentials, not through the console.
Developer console Where the team uploads signed firmware, deploys it and watches each board update. Accounts are created by an administrator, and signing in takes a password and a code from an authenticator app. GitHub repository The firmware, the update server, its console, and the documents behind this page.