You'll get a message when a new demo/update or Pockit units are ready.
Pockit is a new kind of computer — it's made for the physical world. On top of its powerful, versatile Core, you can attach modular Blocks and interact with the world in your own unique way.
WHAT IS POCKIT?
#33: DEMO: The 2022 state of Pockit!
March 8, 2022
Time for a comprehensive demo... With the hardware designs finalized, I recently ironed out several issues for the firmware + software. I wanted to briefly show the full range of capabilities so far; it turned out to need a long (and hopefully enjoyable) video.
▸ 1 video, 3 images
The demo video of Pockit's developments in the last few months, especially the recent board upgrade, and some exploration of my thoughts on modular electronics.
The old Pockit CORE board vs. the new one. The speed boost enables smooth performance with computationally intensive applications, like visual tracking and machine learning.
The multi-protocol nRF52840-based Block (see post #30) is yet to be integrated with HomeAssistant, so I temporarily made a CC2531-based Zigbee Block, which worked well in my tests with appliances.
A much improved Dashboard with completion of the programmable tile grid, and lots of fine-tuning of the App-selector.
#32: Transition to a 1.5-GHz CPU
November 26, 2021
It took three more revisions of the Core PCB but the migration is finally done and it was fully worth it — Pockit with CM4 runs significantly faster than with CM3.
I maintained compatibility with all Blocks designed so far (except one, which will be re-routed), but importantly the CM4 opens up greater computational power and peripheral flexibility, which means new Block possibilities.
▸ 1 video, 3 images
Bottom/internal view, showing the new PCB. Note: The CM4 has 32 GB eMMC, which is terrific, but in the circuit I also included an SD-card socket (seen in this photo) for compatibility with CM4-Lite.
With greater power came... more challenging signal routing. The CM4's numerous peripherals/signals called for a rethinking of the slots' pinouts. Particularly tricky were Camera, HDMI, and PCIE.
I'm working on a generic PCIe Block especially for M.2 SSD use. (But providing USB3.0 too would need the CM4 PCIe bus, so I'm still thinking about the design... For now, I used a solder-jumper selection on the Core).
I designed the PCIe Block with a slot, into which a typical M.2 form factor SSD (2242 size shown here) can easily slide in, much like an SD card.
#31: Dashboard / Control Center
August 2, 2021
Big milestone reached: The Pockit dashboard software (briefly revealed in a past video) is now mostly ready and stable. And the HTML+JS frontend makes it accessible wirelessly on a Linux/Mac/Windows PC, or through the server on an optionally inserted Compute Module.
The dashboard is a real-time, remote monitor+commander for Pockit. It centers around 'apps' — analogous to phone apps, but here focusing on rich hardware interplay.
▸ 7 images
The 3 sections: Apps are run from the CONTROL page (blue). The EDITOR (red) lets you make/edit an app (with specified behavior for attached Blocks). The GALLERY (yellow) shows all of Pockit's ready-to-use apps.
Whenever you attach one or more Blocks, Pockit auto-detects them. Then a multi-factor algorithm scores each item in the full apps-list on the likelihood of the user intending to use it (with the current Blocks).
The calculation is instant and results in a sorted list, with best-matching app shown at top and also auto-loaded, creating intelligent adaptive behavior of the device. The user can also manually choose an app.
The CONTROL page, once an app loads, shows tiles baked into that app. Tiles have 'widgets' (like web UI-components). So an app, through its tiles, lets you read/control Blocks in a specific, holistic manner.
A couple of widget examples: a textfield-widget or plot-widget could display Pockit's readings of a Temperature Sensor Block. Likewise, a slider-widget might control outputs such as a Motor Block's speed.
More widget examples: a Camera-stream that runs from a Python script. Or a widget that interacts with multiple Blocks: e.g., a button-widget could record from a Camera Block to an SD-Card Block).
Apart from the UI, the backend implementation of the data pipeline (for Blocks↔Pockit↔Dashboard) was the most time-consuming part, and involves a heavy dose of C++ and Python.
#30: Mesh/Zigbee Block + a possible upgrade to the Compute Module v4
April 7, 2021
▸ 4 images
Based on substantial interest from Reddit's home-automation community, I've designed a 'Mesh-network' Block with Zigbee+Bluetooth-5.0. The circuit uses the feature-rich (and power-efficient) nRF52840 SoC.
The finished PCB v1 of the Mesh Block, currently with a chip antenna. After further testing, I will add a U.FL antenna connector (just like the LoRa Block), to enable extra-long-range communication.
The nRF52840 supports Zigbee, 802.15.4, ANT+, and Thread stacks. It also has interesting Bluetooth-5 features like Direction-finding + 4x-Long-Range (Coded PHY) — and perhaps most usefully: BLE Mesh support.
Other news: Many have asked whether I'll upgrade Pockit to use the new (Pi) CM4. Well, I've begun research+design. But not sure yet... CM4 dimensions are tricky, plus feature creep is risky; so let's see.
#29: DEMO: Mini-computer with Linux
March 18, 2021
Here is a first look at the full scope of possibilities with the recent integration of Raspberry Pi into Pockit...
▸ 1 video, 2 images
Pockit goodness with tiny Compute module. This video shows me quickly assembling, rearranging, and using a Linux PC, then transforming it into a handheld.
The back of the new version of the Pockit Core provides a SO-DIMM-type connector to optionally insert a Pi Compute Module.
So, Pockit's real-time interaction with Blocks can now be married with the accelerated capabilities of a Linux-capable processor. The video (1st item) was for showing various possibilities with this combination.
#28: The most data-heavy Blocks yet
February 26, 2021
High-speed-signal (HSS) PCB layout is difficult to do well, but provides great rewards — such as high-resolution, high-framerate camera streams.
▸ 3 images
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.
#27: Revamped housing design
February 13, 2021
This is one of the most important updates so far, and the conclusion of almost 5 weeks of intense testing+modifying — which I'm glad to say resulted in a much better overall design.
▸ 7 images
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.
#26: Linux/Pi integration completed + BTB on bottom + Battery Block
January 20, 2021
After enthusiastic feedback from the community, I decided to explore the Linux board idea more seriously.
Previously, I created an experimental Core, which had the Pi CM3's CPU as the primary processor. While it worked well for Pi-related features, there weren't enough free pins to distribute to every slot of the board and for every type of Block. Moreover, a lot of applications need only a simple, low-power-consuming STM32, so it would be wasteful (power-consumption, cost, weight) to have a permanent/sole 1.8 GHz processor on the board.
After testing various potential solutions to this, I ultimately decided to modularize the Pi Compute Module (CM3+), and a couple of other things, too. Here is how...
▸ 1 video, 4 images
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?
#25: Fresh new year, fresh new Blocks
January 2, 2021
▸ 2 images
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.
#24: DEMO: Gardening: Pockit to Pockit to Plant
November 26, 2020
Houseplants are getting a lot more love this year, with people spending more time indoors. I wanted to show Pockit being used for a smart-gardening type of application.
▸ 1 video, 5 images
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.
#23: Bigger battery (1800 mAh)! And Sleep mode...
September 29, 2020
One goal of repositioning the ESP32-related-circuitry onto the main PCB (in Update #22) was to expand the free space under the main PCB.
I took advantage of this to integrate a significantly bigger battery (40% greater capacity).
▸ 4 images
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.
#22: Optimized PCB, and implemented OTA + Sync between Cores
September 14, 2020
A lot of progress, both hardware and firmware:
On the hardware front, the overall design has been optimized. The circuitry has been condensed from two PCBs to one, opening up some empty area for other possibilities.
I've also added two long-awaited software features that exploit the ESP32: Wireless download of application binaries, and Wireless communication + synchronization between multiple Cores (in progress).
▸ 5 images
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.
#21: Anatomy of the firmware
July 9, 2020
The software side of Pockit (primarily the STM32 firmware) is of course constructed in a modular way, much like the hardware is. But there are multiple vertical layers. I've made a couple of diagrams to explain the architecture:
▸ 5 images
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?
#20: All about power (& wireless charging)
April 4, 2020
The Core works with a (1300 mAh) Lithium-Polymer rechargeable battery, but can also be powered+charged using a USB-C cable. Regulated 3.3V and 5V supplies also run to at each of the top-grid slots, to power the various Blocks.
There have been some significant recent improvements in the overall power circuit design.
▸ 5 images
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).
#19: Blocks' teardown video
March 23, 2020
▸ 1 video
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.
#18: DEMO: Alarm clock + background story
March 20, 2020
▸ 2 videos, 1 image
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.
#17: Idea: More computational power with RPi
February 18, 2020
I was recently using OpenCV on a Raspberry Pi board, and began deliberating on what it would take to make a 'Linux-capable' Block, or even Core.
Linux-capable processors abound nowadays, but few have documentation + price-to-performance ratio as good as the powerful Raspberry Pi board. So I started experimenting with a particular interesting spinoff of the Pi.
▸ 4 images
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).
#16: Side-Blocks + the 'Bridge' concept
February 9, 2020
Typically, Pockit's Blocks are attached on top of the Core, but I began to think of attachment on the side of Core too (2-axis modularity?), because some special Blocks might need that.
To achieve this, I designed a circuit-board-based component that I call a BRIDGE, which accomplishes both mechanical and electrical connection to 'Side-Blocks'.
▸ 1 video, 3 images
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).
#15: Experiment: Chop Pockit in half?
January 30, 2020
A couple of months ago, I ordered a bunch of the tiny ESP32-PICO microcontrollers.
In the last two PCB orders, I decided to try a side-experiment to see how small I could potentially go with Pockit while still keeping a useful amount of Block slots.
▸ 4 images
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.
#14: More Blocks
December 27, 2019
▸ 4 images
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.
#13: Achieving a strong fit between Blocks and Core
December 10, 2019
Refinements in the vertical positioning of CORE magnets and CAD of the Block enclosures, and heavy testing...
▸ 3 videos
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!
#12: SLA 3d prints + snap-fits
November 2, 2019
Someone recently asked me how I get such great prints out of my FDM 3D printer. The answer is: I don't.
Almost all the Block housings in the last few months were fabricated by a manufacturer that specializes in industrial SLA (resin-based) printing together with a repeatable post-processing sequence.
▸ 1 video, 1 image
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).
#11: A new name... The Pockit Project
October 26, 2019
▸ 1 image
Pretty self-explanatory... Of course, with that name in place, there's a bit of self-imposed pressure to keep the design pocket-sized. 😎
#10: DEMO: Working Core + First completed Blocks
October 17, 2019
It's up and running! (after a LOT of board assembly, desoldering, soldering, testing firmware, and debugging)
▸ 1 video, 2 images
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.
#9: Neodymium magnets are STRONG
July 29, 2019
I've used neodymium magnets in past projects but in the last few weeks I'm really in awe of their strength after some tests for the Block connection mechanism.
▸ 1 video, 5 images
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.
#8: Pogo (spring-loaded) pins enter the ring!
June 10, 2019
This might be it... I'm seeing some real promise with a new contender for the connector method: pogo (spring-loaded) pins. Possibly a turning point with respect to project feasibility.
▸ 3 videos, 4 images
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.
#7: Battle of the Connectors
June 2, 2019
Heavy research on an important problem: what connection method will be used to attach+interface each Block to the Core board.
▸ 3 images
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.
#6: Electronic architecture
May 25, 2019
I've spent the recent weeks fleshing out the design details (the implementation strategy, selecting suitable ICs, etc.) for the business-card sized board idea that I discussed in the last two posts.
The hardest challenge was the interfacing details — the Core board's brains, together with sufficient + versatile signal-pins for 12 slots, and variable connectivity, etc.
▸ 6 images
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.
#5: Locked down the grid + Block dimensions
May 20, 2019
In the new idea with a business-card sized grid of electrically connectable Blocks, it's important for modularity that each Block is of either the same fixed size (a unit-size) or a multiple of it.
But what should this unit-size (i.e., each cell of the grid) be?
A small unit-size is important to maximize the number of Blocks that can be connected on the board — but the unit-size also needs to be large enough that a commonly-used Block like a Pushbutton or a Dial doesn't use up more than one unit (one position slot) of the board real-estate.
Essentially, we have to find the most practically useful 'common divisor' of the various Block circuit sizes, while also adding a bias based on realistic awareness of common Block usage in applications.
▸ 4 images
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.
#4: New approach: A business card-sized board?
May 18, 2019
Frankly, as much as I like the idea of infinitely chainable electronic bricks, the overall concept of the last few months has some discouraging flaws.
Such a series of modules (with multiple dynamic SPI slaves) has made the bus-communication a lot harder to code and higher-latency than I expected; plus, there is excessive signal length for even a simple assembly. But most importantly, the 1-male 3-female USB connector setup takes up too much space, making each module big and heavy.
Maybe time to return to the drawing board. My goal with this modular project has always been to make not just a flexible but also compact solution. It's certainly not ideal to carry around a train of large blocks (with questionable signal integrity); it's nowhere as condensed or reliable of a properly designed gadget's printed circuit-board (PCB).
So yesterday, I began thinking asymptotically: What is the closest I can get to emulating a compact PCB, but with easily attachable+arrangeable elements? Specifically, instead of even considering what was possible, I decided to strictly constrain myself to what was ideal — a modular board with actual gadget-like compactness. How might that look?
▸ 4 images
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.
#3: Snap-fit for stronger connection
April 26, 2019
Turns out USB-C by itself is great for electrical connection but not for mechanical mating of the blocks. While a chain of 2-3 modules held well, strength issues popped up for any longer than that. So I've added snap-fit features to the casing design — this produces a more confident attachment of the modules.
▸ 5 images
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.
#2: Electronic 'bricks' using USB-C connectors
March 12, 2019
In the last couple of months, I've been working on a revival of my old modular system, but in a rather different way.
This is essentially an experiment in the style of Lego construction, with 3D-printed enclosures containing small circuit boards. The joining between the bricks (using USB-C connectors) seems to work great so far.
▸ 1 video, 6 images
How the pieces fit together: Attachable/detachable modules, where each has one functionality (e.g., here a Dial, an LED, a Control-Pad).
Connecting the modules with header-pins would be bulky. So I went a different route; I used USB-C connectors, which have recently gained popularity with their well-thought-out design (e.g. symmetric pluggability).
So the PCBs (+enclosures) were designed with integrated USB connectors — for both electrical + mechanical connection between modules. This created a snug fit; the attach-detach action feels very satisfying.
CAD example of a module — Each module is sized as a multiple of 40mm * 40mm (the 'unit' size). A male connector + 3 female connectors allow biaxial attachment (all 4 edges).
Particularly attractive about one variant of USB-C connectors is its 24 pins. This gives us abundant channels for bussed-data strategies + power (e.g., higher currents by distributing across multiple pins).
A couple of the module circuit layouts. I tried a few protocols: CAN-BUS (slow + needs transceiver IC), I2C (slow + address limits), and daisy-chained SPI. I finally made an SPI-like protocol w/ embedded addressing.
Some new modules I've recently begun testing, including a 4-unit sized keypad (with Cherry Keys), Mounting-Block, Dial, ControlPad, LED, Joystick, and AC Relay.
#1: Version Zero: How I began with the modular concept
A long time ago!
In my early embedded-engineering days, I designed essentially a mother-board and a bunch of child-modules to speed up my prototyping for various projects. Not the most beautiful things in the world, but extremely handy.
▸ 1 image
One of the early base-boards with processor + circuitry. Ports on top accepted modules, each w/ SDcard, or Dial, or OLED-display, or Wifi, etc. Prototyping got much faster (concept-to-testable in 1-2 days).