SpaceCommsKit — https://spacecommskit.com Version 1.0 — DRAFT
The SCK-PBL-1 is SpaceCommsKit's payload board: a Raspberry Pi Pico (RP2040)-based flight computer with onboard camera, GPS, SD storage, and barometric sensing, designed to bolt directly onto an SCK-915 or SCK-2400 Mini radio board for HAB and CubeSat missions.
It is also a standalone development board in its own right. Every
Pico GPIO is brought out to breakout headers, the firmware (main.py)
is open source, and the board can be powered and operated with no
radio board attached at all. If you're building a project that needs
a camera, GPS, SD logging, and a barometer in one package — with or
without SpaceCommsKit RF hardware — this board is a legitimate
starting point.
This guide covers both uses:
Bolt-on mode — SCK-PBL-1 mounted to an SCK-915 or SCK-2400 Mini, running the stock payload pipeline firmware
Standalone mode — SCK-PBL-1 on its own, running stock or custom firmware, with no radio board present
| Subsystem | Hardware | Interface |
|---|---|---|
| MCU | Raspberry Pi Pico (RP2040) | — |
| Camera | ArduCAM Mini-Cam-Plus (OV2640) | SPI0 + I2C0 |
| GPS | GPS6MV2 (u-blox NEO-6M-based) | UART1 |
| Storage | microSD card slot | SPI0 (shared w/ camera) |
| Altimeter | MS5611-01BA03 barometric pressure/altitude sensor | I2C1 |
| Power | LM2576-5.0WU-TR (5V rail, fixed) + MC33269DR2-3.3 LDO (3.3V rail), see §2.1 | — |
| Power input | JST-PH 2-pin battery connector (LiPo), wall adapter, raw wire (wall adapter connector TBD) | — |
| Radio interface | UART0 — connects to SCK-915 (CC1110) or SCK-2400 Mini (CC2652P) | UART, ESP framing |
| Status LEDs | 5x onboard — camera, SD, GPS, altimeter, fault | GPIO |
| Expansion | Every Pico GPIO broken out to headers | — |
| Ref | Part | Description | Source / Part Number |
|---|---|---|---|
| U3 | LM2576-5.0WU-TR (TO-263-5) | 5V rail regulator, fixed output | — |
| U4 | MC33269DR2-3.3G | 3.3V LDO regulator | Digi-Key MC33269DR2-3.3GOSCT-ND |
| — | Inductor | Buck regulator inductor (LM2576 stage) | Digi-Key 495-4547-1-ND |
| J10 | S2B-PH-K-S | Battery power connector, JST-PH 2-pin, side entry | Digi-Key 455-1719-ND |
| U9 | MEM2080-00-128-00-A | microSD card slot | Digi-Key 2073-MEM2080-00-128-00-ACT-ND |
| U5 | MS561101BA03-50 | MS5611 barometric pressure/altitude sensor | Digi-Key 223-1622-1-ND |
| — | ArduCAM Mini-Cam-Plus (OV2640) | Camera module | — |
| — | GPS6MV2 (NEO-6M-based) | GPS module | — |
| J9 | 54-00134 | Power adapter jack, R/A PCB, 5.5x2.5mm barrel | Digi-Key 839-54-00134-ND |
Confirmed: this is the fixed-output LM2576-5.0WU-TR in a TO-263-5 package, so the 5V rail is a straight fixed 5.0V — no external feedback resistor divider involved. The original BOM note ("not 5 volts package") appears to have been a mislabel, not a hardware issue.
MS5611 sourcing note: the sensor can also be sourced pre-mounted on a breakout board (SPI or I2C) from smart-prototyping.com if hand-assembling a prototype rather than using the production SMD footprint — this is the path used for early bring-up before the on-board MS5611 footprint bugs (CSB short, SDA/SCLK/SDO pin shift) were caught and fixed on the PCB itself.
The SCK-PBL-1 was designed as a bolt-on payload for two radio boards:
Both interface with the Pico over a 4-pin UART header (GND / RX / TX
/ +3V3) using the same ESP framing protocol
([0x22][0x69][length][payload]), so the same main.py firmware
runs unmodified against either radio board for basic commands.
| Radio Board | UART header pins | Baud |
|---|---|---|
| SCK-915 (CC1110) | Fixed by OpenLST board.c UART0 config | 115200 (Pico UART0, GPIO0/GPIO1) |
| SCK-2400 Mini (CC2652P) | DIO12(RX)/DIO13(TX) → Pico UART0 | 115200 (Pico UART0, GPIO0/GPIO1) |
SCK-2400 Mini additionally exposes a high-speed SPI1 payload interface (DIO23–26, see §6.4) for future higher-bandwidth payload data — not yet implemented in firmware as of this writing.
Hardware variants referenced in firmware comments:
SCK-915 Prototype — hand-wired jumper board, reduced SPI/UART speeds required (see §7)
SCK-PBL-1 — production PCB, this board, full-speed operation
Because main.py runs on stock MicroPython with no dependency on a
specific radio board, you can:
Power the board via LiPo, wall adapter, or raw wire — no radio board required
Flash MicroPython + main.py to the Pico as normal
Talk to the board directly over USB serial (REPL) instead of UART0, or wire UART0 to any other microcontroller/UART source
Strip out or replace any subsystem you don't need — camera, SD, GPS, and altimeter are independently initialized and independently fault-flagged, so removing one doesn't break the others
Use the breakout headers to add your own sensors on any free GPIO
This makes it a reasonable starting point for HAB payloads, rover sensor packages, or any project wanting camera+GPS+SD+barometer without designing that combination from scratch. You are not required to use SpaceCommsKit RF hardware at all.
If you go standalone, note:
The command/response protocol (§5) assumes a UART0 host sending
ESP-framed commands. If you're driving the board purely from USB
REPL, you can call the underlying functions directly instead of
going through handle_command() — read the source, it's a normal
linear dispatch.
The autonomous GPS beacon (10s interval by default, see §5) still
fires over UART0 whether or not anything is listening. Disable it
with CMD_BEACON_CTRL or by setting _beacon_enabled = False if
you don't want it.
All communication over UART0 uses ESP framing:
[0x22][0x69][length][payload bytes...]
Byte 0 of the payload is the sub-opcode.
| Opcode | Name | Response |
|---|---|---|
| 0x00 | PING | PICO:ACK |
| 0x01 | READ_TEMP | TEMP:xx.xxC (RP2040 die temp) |
| 0x02 | SNAP | SNAP:OK:<filename>:<bytes> |
| 0x03 | LIST | LIST:<file1>,<file2>,... (chunked) |
| 0x04 | GET_INFO | INFO:<filename>:<bytes>:<chunks> |
| 0x05 | GET_CHUNK | CHUNK:<index>:<200 bytes data> |
| 0x06 | DELETE | DEL:OK:<filename> |
| 0x07 | GET_GPS | GPS:<lat>,<lon>,<gps_alt>,<sats>,<fix>,<hpa>,<baro_alt>,<temp_c> |
| 0x08 | GET_BARO | BARO:<hpa>,<baro_alt>,<temp_c> |
| 0x09 | BEACON_CTRL | BEACON:ON / BEACON:OFF |
Max single-packet payload is 251 bytes; larger responses (file
listings, file chunks) use a chunked continuation pattern — first
chunk prefixed LIST:, continuations LIST+:, final chunk has no
trailing separator.
Autonomous beacon: when enabled (default ON), the board
transmits a GPS/baro packet every 10 seconds without being asked,
in the same format as a GET_GPS response. Disable during
high-rate file transfers to avoid interleaving.
Adding a new command: the firmware has a documented extension
pattern at the bottom of main.py ([SCK-DEV: ADD_COMMAND]) —
define a new sub-opcode, add a dispatch branch, and mirror the
opcode on the ground station side if you're using one.
| Signal | Pico Pin |
|---|---|
| TX | GPIO0 |
| RX | GPIO1 |
| Signal | Pico Pin | Notes |
|---|---|---|
| TX (Pico→GPS) | GPIO8 | UBX config commands only |
| RX (GPS→Pico) | GPIO9 | Continuous NMEA stream |
Default GPS baud: 9600.
| Signal | Pico Pin |
|---|---|
| SCLK | GPIO18 |
| MOSI | GPIO19 |
| MISO | GPIO16 |
| SD CS | GPIO17 |
| Camera CS | GPIO15 |
Both devices share SPI0; both CS lines must be HIGH before switching between devices — see firmware comments for the required CS management pattern.
Speed: 400kHz confirmed on the production PCB; raise toward
1.32MHz (sdcard.py design speed) once signal integrity is verified
on your build. See §7 for prototype-vs-production speed guidance.
| Bus | Signal | Pico Pin | Device |
|---|---|---|---|
| I2C0 | SDA | GPIO4 | OV2640 camera config (addr 0x30) |
| I2C0 | SCL | GPIO5 | — |
| I2C1 | SDA | GPIO2 | MS5611 altimeter (addr 0x76) |
| I2C1 | SCL | GPIO3 | — |
MS5611 max I2C clock: 400kHz. PS pin must be tied HIGH on the PCB to select I2C mode.
| LED | Pico Pin | Color | Meaning |
|---|---|---|---|
| Camera | GPIO10 | Green | Camera initialized OK |
| SD | GPIO11 | Green | SD card mounted OK |
| GPS | GPIO12 | Blue | Slow flash = searching, solid = fix |
| Altimeter | GPIO13 | Yellow | MS5611 initialized OK |
| Fault | GPIO14 | Red | Any subsystem failed |
| Onboard (boot) | GPIO25 | — | Boot confirmation blink |
| SCK-2400 Signal | Pico Pin | Function |
|---|---|---|
| DIO23 (SSI1 SCLK) | GPIO26 | SCLK |
| DIO24 (SSI1 PICO) | GPIO27 | MOSI |
| DIO25 (SSI1 POCI) | GPIO28 | MISO |
| DIO26 (SSI1 CS) | GPIO22 | CS (plain GPIO) |
This bus is wired but has no command handler yet — reserved for future higher-bandwidth payload transfer when using the SCK-2400 Mini. Do not use GPIO10–13 for this (claimed by status LEDs) or GPIO24 (not broken out on the physical Pico header, despite being a real RP2040 SPI1 pin electrically).
RP2040 internal die temperature sensor, ADC channel 4. No external
pin — used for CMD_READ_TEMP health telemetry, not a substitute
for the MS5611.
The Pico sits centered on the board with a full 20-pin breakout header running down each long edge (J1 and J2), exposing every physical Pico pin — power, ground, ADC, and all GPIO, including pins already used internally by camera/SD/GPS/altimeter/LEDs. This is deliberate: even "claimed" pins are still available on the header for probing, piggybacking, or reference, though driving them externally will conflict with the onboard subsystem using them.
J2 (top edge, left → right): VBUS, VSYS, GND, 3V3_EN, 3V3, ADC_VREF, GP28, AGND, GP27, GP26, GP22, RUN, GP21, GND, GP20, GP19, GP18, GND, GP17, GP16
J1 (bottom edge, left → right): GP0, GP1, GND, GP2, GP3, GP4, GP5, GND, GP6, GP7, GP8, GP9, GND, GP10, GP11, GP12, GP13, GND, GP14, GP15
Debug header (J3, 3-pin): SWDIO, GND, SWCLK — the Pico's SWD debug interface is broken out separately from the main headers, so you can attach a debug probe without disturbing anything on J1/J2.
This confirms the design intent: the board is built to expose the entire Pico, not just the pins the stock firmware happens to use — consistent with treating it as a genuine standalone dev board rather than a fixed-function payload module.
If you're working from schematics/reference rather than a stock SCK-PBL-1 unit, be aware the firmware still carries conditional guidance for a hand-wired prototype board:
| Parameter | Prototype (hand-wired) | SCK-PBL-1 (production PCB) |
|---|---|---|
| SPI bus speed | 400kHz max | 1.32MHz (sdcard.py design speed) |
| SD slow-init speed | 100kHz | up to 400kHz |
| UART timing | May need increased PICO_TIMEOUT_OUTER on radio side |
Nominal |
These differences exist because of jumper-wire capacitance/crosstalk on the prototype — a genuine SCK-PBL-1 unit with PCB traces should not need any of these compensations. If you see intermittent SD errors or camera capture failures on a production unit, that's a signal integrity issue worth investigating with a scope, not something to work around by dropping the SPI speed.
Power the board — LiPo, wall adapter, or raw wire input (confirm connector types/voltage range before publishing)
Flash MicroPython to the Pico if not already loaded (standard
RP2040 UF2 bootloader procedure — hold BOOTSEL, connect USB, drag
.uf2 file)
Load main.py onto the board (Thonny, mpremote, or your
preferred tool)
Reset the board — onboard LED blinks confirm boot; subsystem LEDs light as camera/SD/GPS/altimeter initialize
Talk to it — either wire UART0 (GPIO0/1) to a host sending ESP-framed commands per §5, or work through USB REPL directly
Check the fault LED — if lit, one or more subsystems failed init; check the corresponding status LED to isolate which one
main.py is structured for extension:
New commands: add a sub-opcode constant + dispatch branch (pattern documented inline at the bottom of the file)
Large responses: use the chunking pattern already implemented for
LIST/GET_CHUNK if your response exceeds 251 bytes
Subsystems are independent: camera, SD, GPS, and altimeter each have their own init function and fault flag, so you can delete or replace any one without touching the others
If you build something on top of this board, we'd like to hear about it — open an issue or PR against the firmware repo.
[ ] Confirm official board name/SKU (using "SCK-PBL-1" per firmware header comments — replace if a different customer-facing name is chosen)
[ ] Verify J1/J2 header pin order in §6.8 against silkscreen/schematic (reconstructed from PCB layout screenshot — spot-check before publishing)
[ ] Add photos/diagrams once board is populated