Project POCKIT

3 types of Camera blocks, with different resolutions and fields-of-view (FOV). All of them run through the CSI (Camera Serial Interface).

This particular one supports night-vision, when paired with the IR-LED Block (shown in Update #25).

An 'accelerator' Block, meant for AI-class applications. I will cover this in a future demo, after finalizing the testing phase.

Until recently, Pockit has always had a plastic shell but with the magnets always exposed (for stronger attraction). But exposed magnets = greater damage risk + corrosion (even with the nickel-based coating).

Inspired by a post on the project's Facebook group, I decided to see how I could embed the magnets within Pockit's housing.

The updated CAD model adds pockets in the top (lid) for the magnets to fit into, together with other changes. Several dimensionally adjusted variants were made to speed up the mechanical-fit testing+finalization.

Also, as part of the top surface design, I added protrusions (bosses) that mate with pockets designed into the Blocks. This adds biaxial movement constraint and further strengthens the Core↔Block connection.

The previously built stepper-driven jig performed several hours of automated-testing of electrical contact quality + gripping strength, for comparison of design variants.

Side-by-side of old version and new design, with thicker magnets, full enclosure of the magnets, and also upgraded pogo-contacts. Works very reliably, and holds Blocks slightly stronger. Better appearance too.

A close-up of the new design's top surface, showing the newly added plastic bosses (4 for each slot). They seem to also do a good job as locating-pins, making the alignment more easy + precise.

The newest version of Core has the STM32 as the primary processor — plus a DDR connector to optionally attach a CM3+, whereupon CM3+ signals can interface w/ any Pi-compatible Blocks (incl. Camera, HDMI, etc.)

So the Core can now work as default, or with the optionally added CM3+. The circuit layout above shows the STM32 (temporarily F105, later will return to F429) & optional CM3+, enabling a dual-processor board.

When the CM3+ is in play, the internal battery struggles for space. The battery has always been a good candidate for modularity, so I took this chance to separate it into its own Block (using a tiny connector).

Plus, with the new method, the Core can be powered from a Battery Block with greater (and choosable) capacity — e.g., the huge 3000mAh battery in the new Battery Block benefits Linux-based use cases.

The modular design using a bottom BTB connector (w/ I2C signals) enables other possibilities too: e.g. a Fan Block for when the Broadcom CPU gets hot. Perhaps a 'Giant' 4S Battery Block for robotics/outdoors?

The pH-sensor Block (here shown without the probe) and Mini-Relay Block. Perhaps a good pair for gardening or... chemistry-related automation?

IR LED. Ethernet. Fingerprint sensor. Reading data from the latter was a pain, thanks to a poor component datasheet, but the sensor's detection speed is impressive.

The full demo!

The absolute minimum needed (for automatic watering) would be a Soil-Moisture-Sensor Block and the (newly completed) Pump Block.

But I wanted a more capable setup, so I plugged in a Temperature-sensor Block, a UV-sensor Block, and some Button Blocks, etc.

The OLED Block + various control Blocks together let the user browse data from the multiple sensor Blocks (here, gardening-related ones), or control the output Blocks (e.g., the Pump Block).

Wireless synchronization is fully working now (with the inbuilt ESP32 + ESP-NOW protocol). So, what one Pockit sees/does with its Blocks can be seen/done by nearby Pockits, forming a virtual-expansion ability.

Here, for instance, the sync feature makes remote monitoring easy. Note that the UI is Block-agnostic. So whether an OLED, TFT, or Epaper Block, the data stays, while the layout is auto-tailored to that Block.

LiPo batteries (same chemistry used in smartphones) come in nearly any dimensions, specified as HHLLWW (height, length, width), with proportional capacity. The older battery was 404050. The new one is 405060.

The 405060 battery with 1800mah capacity (about 40% bigger than the old one) is the largest that now fits inside Pockit's updated enclosure. CAD shown here is after the recently made layout adjustments/tweaks.

A primary strength of Pockit's circuit design is components with low-quiescent-current + dynamic disabling by the MCU. The battery discharge-time should be > 26 hrs for worst-case always-awake Core by itself.

However, months of runtime on a single charge can happen with proper sleep rationing. I've designed Pockit's firmware with focus on easy entry (or auto-entry) into Sleep mode. MCU wakeup takes microseconds.

This refinement needed heavy testing + revising — esp. for antenna performance — and difficult PCB routing. But the result is a more direct circuit + more Z-axis room under PCB (maybe a bigger battery?).

Bottom view of the single-board reincarnation. Already at v7 now, the tightest one yet. The trace-routing is a city of its own, dense highways and streets going everywhere, and with a big party at the STM32 BGA.

Pseudo-3D view (Altium Designer has several nice features like this) of the completed Core design.

With SPI between ESP32 and STM32, and STM8 control of STM32's RESET+BOOT pins, I added a wireless firmware-download feature for the STM32. No more bothering with a USB cable. Should've implemented this earlier.

I'm also working on a wireless-sync mode where 2+ CORES can unite (through ESP32) into a single workspace with 12 * N slots. So the 3 Blocks (colored) above could be read/controlled by any of the 3 Cores.

Layer hierarchy of Pockit's software. (Note: To simplify the diagram, I didn't include a few of the Core's internal components like Buzzer, PowerButton, etc.)

A rough drawing (made in Altium) of the firmware structure implemented in the CoreOS, i.e. LAYER2 from Card-1. Each Pos_[X] refers to one of the Block interface slots/positions.

The most significant, and time-consuming, portion of the firmware development was certainly the CoreOS itself — the collection of sytem drivers/classes that bridge the libraries to the hardware-access layer.

With libraries + base-classes in place, app code can be written in friendly, Arduino-like syntax. I focused on directness of abstraction to avoid control/performance loss compared to, e.g., the Arduino system.

The Pockit project aims to make hardware assemblies easier. Likewise, I'm thinking now about how to further enhance the programming of that hardware too: More simple or more control?

In recent Core PCBs, I've begun to use RK818 for power management. Intended for phones, where space is scarce, this PMIC does the work that 4-5 previous ICs did together (some shown in this image's background).

The RK818 has many features attractive for Pockit: LiPo battery charging + gauge, load-sharing, multiple output channels w/ configurable voltages (incl. boost), and current up to 4A/channel... And I2C control.

So, the power circuit is significantly simpler now, supplying 3.3V & 5V (up to 3A) power to the Core + Block grid... All from a source of battery or USB-C (when both present, charging simultaneously happens).

I've made two interesting (but experimental) recent additions to the circuit for providing wireless-charging capability. I am also testing BQ51013 as an alternative receiver IC w/ higher AC-to-DC efficiency.

The resulting internal hardware for wireless charging works well so far, but is yet to be optimized... The battery is charged to > 80% in ~5 hours (the Core can be used during this time, as with USB charging).

After the alarm clock video, many people asked me how the project was made, so I filmed this to show a close-up of the internals — both the typical PCB components and the Block's mechanical construction.

This video demonstrates the practical context of Pockit, with an example demo of an alarm-clock build, then a summary of the modular-blocks story, finally ending with an e-paper clock/notifier/Bitcoin-ticker.

Pockit into a... pocket. Still a lot of work to be done for the Blocks + firmware, but pretty pleased so far with the compact dimensions of the Core.

The clock/notifier/Bitcoin-ticker in the video was made with the E-paper Block; I'm really liking its screen quality. I am still working on procuring the bi-color screen variant I mentioned in Update #14.

There are numerous embedded Linux CPUs available (e.g. the above list). But compared (unfairly) to a full Pi, most have difficult documentation, or demand a complex circuit, or are pricey, or have weak specs.

A full RPi board inside a Block/Core is too bulky (even a Pi Zero) + won't expose enough modularly usable pins. Then... I began testing the Pi Compute Module 3+, which fans out pins of the same CPU as a Pi.

The Compute Module is in a way even better than a full Pi: nearly ALL signals/peripherals of the Broadcom CPU go to contacts on the module's SODIMM connector. This flexibility is apt for modular design.

Plus, it would occupy a sixth of the volume a full Pi board would use. I love this, and began designing a minimal experimental variant of the Core, with the CM3+ as the brain (instead of STM32).

The original problem: A large Block, e.g. a display Block, if made to attach on top of Core, would steal too much Block grid space that's needed for other simultaneously used hardware (sensors/UI Blocks, etc.)

So, I thought of attaching bulky Blocks on the side of the Core. But easier said than done. After MANY experiments, I solved it with a 'Bridge': a tiny PCB with pogo-pins (signal transmission) + 2 screw-holes.

The resulting mechanical+signal interface between Core↔Side-Blocks. The Bridge PCB (above) is made of strong FR4, and also 2mm thick (vs. typical 1.6mm). It will be white in the future, to blend in.

Example with Core↔TFT Side-Block. The resulting assembly is robust + leaves convenient grid space. And it only takes seconds to connect/disconnect the Side Block (this can probably be improved further).

Two copies of the resulting half-Core-size experimental-boards (one shown with some of the newest Blocks attached, as an example). Absolutely tiny, and might be great for some portable/IoT-style projects.

A size comparison of the experimental board (half-business-card) vs. the standard Core design (full-size).

It was a relief when the super dense PCB layout+routing actually worked out.

ESP32-PICO makes for a versatile primary MCU, but limited GPIOs is a problem... 6 Block slots, 2 of them with restricted Block compatibility. I might shelve this half-size concept at least until the ESP32-S2.

PIR Motion Sensor Block, RTC Block (with integrated coin-cell), and the GPS Block (with ATGM336H, which has good performance and is intended as a replacement for the more expensive NEO-M8N).

ControlPad, D-Pad, Joystick, and Slider (3-unit size) Blocks. I might eliminate one of the first two after testing which one feels more comfortable... the D-Pad has appeal for gaming-style applications though.

E-Paper Block. I'm considering replacing the display in this one with a bi-color (red-black) version, but the supplier doesn't currently have those in stock.

SD card Block (with SPI interface as well as SDIO for higher speed). There is currently a positional misalignment between the card socket and the enclosure slot, so this Block is not done yet.

In the updated design, the Core's magnets enter into matching pockets in the Block's plastic case. This further constrains X & Y-axis movement, creating a much better hold than using magnetic attraction alone.

Demo of Core↔Block attachment strength. The design update mentioned in Card-1 (and asymmetric layout of magnet polarities) prevents Block↔Core positional misalignment & mismatch of signals.

A temporary jig (using a stepper-motor + lots of hot glue) to test robustness of the magnets/attachment method. 10,000 automated attach-detach cycles in under an hour... a significant relief vs. hand-testing!

An SLA printer, while pricier & slower, yields much higher surface quality than an FDM (the typical, filament-based) printer and produces dimensional accuracy (10s of μm) that, e.g., precise snap-joints need.

Typical CAD for a Block's case. The top and bottom are now attached with snap-fits, instead of adhesive or bulky screws, to achieve both reopenability and compact size (21 * 21 mm unit size for Blocks).

Pretty self-explanatory... Of course, with that name in place, there's a bit of self-imposed pressure to keep the design pocket-sized. 😎

Pogo-pin-compatible contacts for electronic connection + magnets for mechanical connection. (The traditional breadboard+wire forest in the background is for aesthetic contrast.)

A quick demo of the system. Hot-plugging circuits (Blocks) like this is very enjoyable. The STM32 code here is designed to show real-time Block detection + auto-dynamic behavior. Lots of room for play still...

The ingredients. Button, dial, LEDs, OLED, and a couple of LED matrix Blocks. These are just a few inputs and outputs I made for initial testing. Already ordered PCBs for more exciting ones.

Here, I'm lifting a hammer with one magnet I've been testing to use on Core + Blocks. The type I use, N52-grade magnets, can go up to 15,000 gauss in field-strength. A typical fridge magnet is ~100 gauss.

Magnets I've acquired over the recent weeks for testing: various sizes, grades, and coatings (and a huge range of costs!).

The final choices based on performance vs. Block-suitable size. So 3 such magnets on each of the 12 slots of the Core.

...And 3 corresponding magnets on the Blocks. The attraction holds the Block and also keeps the pogo pins connected, by applying a force opposite to the pins' internal-spring extension.

An important design subtlety is that I used, for each slot, an asymmetric layout of the magnets/polarities. This prevents accidental shorts and ensures positional alignment.

A test board w/ LEDs, to verify connectivity + overall concept. Feels secure. This is an important milestone; CAD + PCB routing (of MCU signals) is successful, so should be smooth sailing to make real Blocks.

What are pogo pins? An exploded view above. They are conductive pins with an internal spring applying a force on the plunger, creating a durable connection w/ target pads (or even with printed PCB pads?).

Pogo pins are also compact + low-cost. Plus, they are proven to work on numerous consumer gadgets. After fidgeting with some from an earphone charging case, I immediately ordered several sets of pins.

The pin models I bought, w/ various sizes, stroke lengths, max current, spring force. Mostly surface-mount; space is critical for Blocks. One model is attractive: compression force of ~30g, and 1A max. current.

A close-up view of (a brief handheld test of) Pogo pins mating to pads on a PCB I made for experimentation.

Bare PCB pads made unpredictable contact with pogo pins. I then tried solder bumps, and also specially made copper contacts. The latter has produced reliable connectivity (multiple tests w/ 1000s of cycles).

CAD of current design, showing how a Block's pogo-pins (top) connect to the Core's female contacts. Later, I'll explore an inexpensive simplification — bare PCB pads but with selective hard gold plating.

Of course we need a mechanical force to press the pogo-pins (+ hold the Block to Core). I'll use Neodymium magnets for this. The new PCB version accommodates these. More details soon after comparative testing.

A comparison table, showing the conclusions of my analysis for several connector options. The last row would obviously win but unrealistic to prototype with, so I prefer to use something off-the-shelf for now.

A Core PCB mockup w/ various Board-to-board connectors, my top choice for connecting Blocks (white 3D prints, w/ blank circuit-boards). I'll test electrical connectivity later w/ a more intelligent board.

Various other connectors that I've been testing recently. Frankly, I'm not fully satisfied with any of them yet.

Summary of my 6 ideas for the hardware strategy. Method 'E' aligns best with my vision of a standard, but dynamic, circuit board. And the (one-time) routing difficulty can be simplified by using a 4/6 layer PCB.

I decided on Method 'E' + aspects of 'D' & 'F' :
▸ Core board: Main MCU (brain) + ESP32 (assistant for wireless download + comms)
▸ Each Block: STM8 (tiny, low-power MCU to inform CORE about Block + ID)

A system-level diagram of the main elements I will put into Core + Blocks. The last remaining puzzle (the first in reality): finding a suitable 'Main MCU'.

Digikey's columns with filter+sort (here, by GPIOs) sped up the MCU research. The STM32F4 series has strong candidates. Plus, software written for them can be up/down-graded to most MCUs in ST's vast ecosystem.

My choice for now is the STM32F429, a 180MHz ARM-Cortex-M4 with 2 MB FLASH, tons of GPIO and 6 SPI buses. Plus interfaces like DCMI (camera), LCD, and I2S, which will be great for some Blocks.

(Source: STM32F429 datasheet.) The 216-pin variant of the STM32F429 comes in a BGA package... hard to prototype with, but extremely compact, which is critical for what will surely be a dense board.

I first tabulated realistic size estimates of all major components I envisioned, then did a hybrid (half-observation, half-computer-simulation) analysis, including weighting based on more common use-cases.

The ideal grid-cell size seemed to be ~20-21mm (bigger than I imagined in Update #4). The resulting 4x3 grid seems promising — I used cardboard mockups to verify several typical Block-combinations / applications.

A rough Solidworks design of, e.g., how a full SD-card Block with housing might look — in this case, 21x21mm (1 unit size). This gives a tight but realistic fit of the socket + circuitry (PCB of max. 18x18mm).

Minimum CAD models were designed for a few other Blocks too. Above drawing (in mm) is an example assortment of Blocks (various unit-size multiples). The 0.4mm allowance gap can be adjusted after 3D-printed tests.

A size that fits into a pants pocket seems meaningful. Whether a Walkman, an iPod, or recently a smartphone, pocket-sized gadgets are attractive for a reason -- the portability plus the hold-in-hand feel.

So, after trial & error, I settled on business-card size. And an 'editable' space (7x4 grid?) on top. In the above mockup, I put components (each w/ one function) to make, e.g., a Bluetooth music player.

The construction might be like my old 'motherboard' design from a while ago, but heavily compressed, with tiny feature-modules. So a base ('Core' board) with its own circuitry, to which 'Blocks' are affixed on top.

Overall I really like this new approach; pretty obsessed with it for the last 2 days. Intuitively, my experience with sub-circuits tells me this is the right way. The hard part now: how to implement it.

The original problem: After appending enough modules, the accumulated load causes a large deflection (imagine a cantilevered beam). This threatens the reliability of the connection.

Fortunately 3D-printed cases = easy to experiment w/ new attachment methods + variable strengths. I mainly had success with snap-joints (a staple of injection molded designs too, so a future-proof approach).

After adding cantilever snap-fits to the module designs, I did trial-and-error with incremental-size-variants to determine the snap size for optimal balance between flexural-load-handling and detachability.

Together with a few other refinements, above is an X-ray view showing the newest module design, here a Joystick module. (The pushbutton at bottom is temporary, just for hardware reset.)

The resulting 3D-printed boxes for a couple of example modules. In the background is an attached pair.