SulaJalmari/final.md

The Flex-PCB Octopus device

SulaJalmari

What is this wobbly device?

At first glance, you might think we built an elaborate paperweight, but it's probably not even heavy enough for that. This is me and my friends first take on designing an MCU PCB, and of course we had to overengineer it and make it as complicated as possible. But where's the fun of making things easy.

This device was not created to serve a purpose, but to teach us PCB design and project work. It ended up as a flashy desk toy which wobbles on slightest movement, but also gains attention by confusing people around it.

Story

The story started when laying on sofa, staring at the ceiling, I got the idea of creating a flex-PCB and have it be 3-dimentional. The shape was easy, since I worked in a company called Qalmari and their mascot is an octopus which was perfect for this project (also perfect for getting the company to pay for this expensive project :D).

First step was to create a paper cutout and message my friend if he wants to collaborate on this project. I grabbed some cheap whiskey, we got components for whiskey sour (first time making it), and started designing the project.

We wanted to have bluetooth on it, but our school project with nRF chip was a disaster and we started to hate it and zephyr. But still, we decided to give it another chance and use the nRF52840 as the MCU.

I love creating weird and useless projects and I'm extremely proud of this one. This tought us so much, we got a cool project for our portfolio/CV, and we got an actual device on our desk as a reminder for this.

Prototype 1

The first prototype was designed while learning to make whiskey sour, and the result was not that good (who would've guessed). We had so many DRC errors, since we didn't set any design rules and the tolerances were too small for them, we missed a critical flaw of an accidental via from 3V3 straight to GND.

When receiving the prototype, we didn't know this and didn't have tools to find it, so we just pumped some current through and found that one leg had the whole track turning black. But this prototype proved that the mechanical concept was legit.

Prototype 2

For the second version, we switched from yellow to black/blue, to contrast the company colors and it looked way better than the first prototype. This time, we followed and solved all the DRC errors and got the device to work.

But this one was NOT without problems. Turns out, clamping to debug pins on the flex-PCB was eventually fatal to the pins and we lost access to debugging on many of the devices. We also did a lot of stress testing by smashing the device flat, to see if it can take it, and it did... for a while. After stressing it for a while, we found that some pins from the MCU got disconnected from the PCB and the device did not work properly without pushing on the chip.

Prototype 3

After breaking all the second stage prototypes, we decided to do final batch as "ready" devices. This fixed the debug pins and added a stiffener on the other side of the MCU to protect the pins. We also noticed that the vibration motor did not function as we wanted, so we didn't assemble it on the final device.

Hardware

If you're crazy enough to want to get your own expensive useless device, then the hardware files are freely available at my git as gerbers and diagrams. This was designed in EasyEDA for the convenience of not having to build our own component library, but this has made releasing the CAD project difficult...

• CPU: nRF52840-QIAA MCU (on a flex PCB).
• Sensors: ICM-20602 IMU and XYC-ALS21C-K1 I2C Ambient Light Sensor.
• Fun stuff: 2x WS2812B RGB LEDs (the eyes), 8x blue indicator LEDs, Buzzer/Vibration Motor mounts, 2x user buttons.
• Power: TP4054 battery charger, two separate LDOs (3V3 and 3.6V).
• Structure: Two custom flex PCBs (Head & Legs) attached to a main FR4 base board.

Assembly: Even though the PCBs were fabricated and assembled by JLCPCB, they still needed to be soldered together by hand, since JLC does not offer octopus assembly (yet?). We initially designed the feet and head assembly with magnets on the PCB and legs, but it did not work on the paper version as intended as the legs just kept getting tangled up. For the second and third prototypes we settled on solder pads with needle holes for alignment and assembly, which worked well for most part. But still some of the assembled devices stood a bit crooked as even a slight misalignment was exaggerated when it was standing.

Base: We designed a 3D-printed stand that attaches to the base with some room for a small battery, nothing fancy but it does the job and looks good in the final assembly.

One framework to rule them all - ZephyrRTOS

As mentioned, we came accross nRF and zephyr in a school project, where we just had to get familiar and do a small project with nrf52840-dk. Zephyr development is so fast that this turned out to be a hunt for correct documentation, since everything we found was already deprecated. Zephyr also uses devicetree and kconfig to configure the hardware, and this was new to us back then, hence also having trouble with that aspect.

Since the second prototype, zephyr version has nearly doubled, which shows how active the development is. Or how slow we are.

Nowdays, I try to use zephyr for everything. The fact that you don't need to learn a new framework for every single MCU, makes zephyr a very powerful tool for testing and development. And their extensive support for all sorts of hardware (you can even run zephyr on Cortex-A cores), makes it easy to just configure the hardware in devicetree and use the drivers in the kernel. Zephyr also makes bootloading easy, by supporting MCUboot "out-of-the-box", where you just need to configure it with few kconfigs and get it working.

Now, zephyr is not perfect and still has the problem of constantly changing things to make it harder for developers, but it is better for the greater good of making zephyr better and doing it fast.

Conclusion

This is one of my favourite projects, and while being a useless but cool piece of technology, I've still had time to figure out a use for it. For the past months, I've been vibe developing (with my limited energy after burnout) probably the only useful app for it. It's a "pomodoro" like app, that loads for X amount of minutes with the LED lights and then flashes the "eye" LED's for Y amount of seconds to indicate when to take a break after staring at the screen all the time. This is found in my chill repo.

Looking at the I2C line with logic analyzer.

Thanks

• Thank you for my friend for helping me empty the bottle of whiskey and collaborate on this project full time.
• Qalmari for sponsoring my dumb ideas and supporting us to learn and improve as engineers.
• Hackaday Europe 2026 for showing interest and urge me to share this project. (If you saw me there, say hi in the comments)