Urchin is a 34-key wireless board built around nice!view and nice!nano

Thirty-four keys, two displays, and no wires

Urchin is a keyboard design rather than a firmware project or a case repository. The designer's account of why it exists is specific: he wanted to upgrade his Sweep with nice!view displays, and the result is a 34-key board with native nice!view support.

The feature list in the readme is short and each item is checkable. The design is fully optimized for wireless, it supports nice!view natively, it keeps a familiar Ferris and Sweep layout with an improved outline shape, it uses Kailh hotswap sockets, and it has mounting points for cases. The package also includes a 3D printable enclosure, switch plate files in three options, and MCU and screen cover files.

Two constraints are stated in bold in the readme and they define the project. It is a strictly wireless-only design, and it is only compatible with ZMK and nice!nano. Only Choc v1 switches with hotswap are supported.

That last sentence is the one to read twice. It rules out Cherry MX switches, it rules out a soldered board, and it means this is not a drop-in replacement for a mainstream keyboard. It also means the board is designed around low profile parts throughout, including the sockets and the two nice!nano controllers named in the parts list.

The MIT licence covers the design files, and the repository is not archived, with the last push on 2026-10-02.

The switch matrix with diodes is why Sweep firmware will not work

The readme carries a question and answer that answers the most common objection to a design like this.

The question is why this is not just another Sweep. The answer is that supporting the nice!view display required a switch matrix with diodes instead of the Sweep direct pin design, and that this means the firmwares are not interchangeable. A different PCB shape was also chosen, which makes it incompatible with Sweep cases.

The mechanism behind that answer is worth understanding. A direct pin design assigns a microcontroller pin per key, so the number of pins bounds the number of keys and the wiring is direct. A matrix with diodes routes keys through a grid of rows and columns with a diode per key, which is what allows 34 keys plus two displays to fit on two nice!nano controllers. The price is that the scanning and key mapping live in the firmware configuration, and that configuration is board specific.

So the compatibility boundary is real and it is not an inconvenience that a later firmware release will fix. The Sweep firmware expects the direct pin layout; Urchin expects a matrix. Anyone coming from a Sweep will need to use the firmware project the author points them at, and anyone hoping to reuse existing keymaps or ZMK overlays needs to know that before ordering parts.

The board also carries an edge design taken from the Swoop, which is credited in the readme along with the nice!view integration reference.

The repository holds KiCad sources, prints and plates

The top level of the repository gives a good picture of what a hardware project like this contains.

The design files are there in KiCad form: main.kicad_sch for the schematic, main.kicad_pcb for the board, main.kicad_pro and main.kicad_prl as the project files, plus a fp-lib-table and a lib directory for footprints and symbols. A main.step file gives a 3D model of the board.

The mechanical side lives in two directories. 3d-prints holds the printable case files, and plate-case holds the switch plate files, of which the feature list says there are three options. There is also a gallery directory with images of the case and the board, and a main.kibot.yaml file, which is the configuration used by KiBot to automate board fabrication output such as Gerbers and drill files.

The one thing that is not in the repository is the board itself. The part list marks the PCB kit as required and says that the files for it are in the releases section, so the fabrication data travels with the release assets rather than with the design files in the repository. That is a sensible split, since a given release can change the board without the repository history pretending it did not.

The readme also links a build guide as a video, which is the most practical document in the project for anyone assembling one.

The parts list is the build plan

The part list is precise enough to order from, and it is worth reading as a specification rather than as a shopping list, because several of the quantities tell you about the design.

The required items are below, in the order the readme lists them.

- 1× PCB Kit (files for it are in [releases](https://github.com/duckyb/urchin/releases))- 34× Kailh Choc v1 Switches
- 34× Keycaps
- 34× SMD diodes (SOD-123)
- 2× nice!nano
- 2× Lipo battery (301230)
- 48× mill-max machined pins
- 2× Pair of female headers

The numbers tell the story. Thirty-four sockets, thirty-four switches, thirty-four keycaps and thirty-four diodes match the 34-key layout and confirm the matrix design, since a direct pin layout would not need a diode per key. Two nice!nano controllers handle the halves of the board, and the mill-max machined pins and female headers are how the two halves connect to each other, which is the standard arrangement for a split wireless board.

The optional list adds two nice!view displays, two reset switches of type B3U-1000P(M), two power switches of type MSK 12C02 and ten adhesive silicone feet. So the displays are optional in the sense that you can build the board without them, but the nice!view support that motivated the design is a headline feature rather than a corner case.

Cases: one official print, others in the repository

The case story has a named official version and a community set.

The official case is the Coral case, described as available on Makerworld for free, with a link to the model and profile. Other cases are described as being found in the repository inside the 3d-prints folder, and the readme credits three people for 3D cases, along with a separate credit for the case artwork, the coral, rocks, sand and bubbles concept.

There is a caveat attached to all of this hardware. Installing a case, a microcontroller cover or a screen acrylic cover requires additional M2 hardware that is not included in the parts list, with screws, standoffs, nuts and heat set inserts named as examples. That is a small thing but a real one, since it is the kind of omission that stops a first build at the last step.

The release history shows the mechanical side has been iterated rather than frozen. v1.0 in March 2023 was titled 3D Printable Cases, v1.1 in March 2025 was a silkscreen fix, and the first release, v0.0.1 in November 2022, was titled Big Bang. So the project has been through the initial release, a mechanical follow-up and a labelling fix, which is a reasonable pattern for a design that people are actually building.

Firmware lives in a separate ZMK repository

Urchin supports ZMK only, and the readme is direct about where to start. You go to the zmk-urchin repository and follow the instructions provided there.

That separation is worth pausing on. The hardware repository holds the design, the prints and the documentation; the firmware repository holds the board configuration. For a wireless ZMK board, that configuration is the part that encodes the matrix, the key positions and the display layout, so it is the part that cannot be shared with a Sweep.

The credit list names two people for ZMK firmware help, which suggests the configuration is something contributors have had to work on together rather than a single file dropped in by the author. If you are comfortable reading a ZMK keymap and a board configuration, that is the skill the build needs on the software side.

The readme also collects video links, with a build guide link and an additional video, plus a Discord channel for the project. For a design that most people will only ever build once, a walkthrough video and a place to ask questions are a large part of the actual user experience, and the repository provides both.

Who should build this, and what to check before ordering parts

Urchin is a good fit for someone who wants a small wireless keyboard with displays and who is prepared to do the work: order parts from a parts list that lists exact part types, print a case, solder sockets and diodes, and flash firmware from a separate repository. It is also a good reference design, since the KiCad sources, the footprint library and the fabrication files are all in the open under the MIT licence.

It is a poor fit for a plug-and-play builder. Only Choc v1 switches with hotswap sockets work, the design is wireless only, the case needs extra M2 hardware that is not in the parts list, and the firmware will not drop into an existing Sweep setup. If you want to type on it tomorrow with the switches you already own, this is the wrong project.

The check to make before spending money is revision matching. The PCB kit files live in the releases, and the case files live in the repository, so confirm that the board revision you are downloading matches the case and plate you are printing. After that, the second check is the switch type, because Choc v1 compatibility is the constraint the author states most firmly, and the third is the firmware path, because ZMK from the zmk-urchin repository is the only supported route.

The last push was on 2026-10-02, and the repository is not archived, so the design files are being touched even though the last tagged release is v1.1 from 2025.

Editorial conclusion

Urchin fits a builder who wants a small wireless keyboard with displays, who is comfortable ordering parts, printing a case and flashing firmware, and who accepts Choc v1 switches as the only option. It is the wrong project if you need a wired board, a standard Cherry MX layout, or firmware that drops into an existing Sweep, and the wiring difference makes that last point non-negotiable. Check first that your switch choice is Choc v1, that you are prepared to run ZMK from the separate zmk-urchin repository, and that the PCB kit files in the repository releases match the revision of the case you print.

Frequently asked questions

Official sources

1. duckyb/urchin on GitHub
2. Issues
3. License: MIT
4. README
5. Releases