Fluid Simulation Pendant
A small round disk about the size of a regular watch, it's a neat device which runs a particle simulation that responds to gravity in real time. In other words, water is displayed on it's LED display that flows and settles naturally as you move.
Created by
Mason
Tier 1
3 views
0 followers
Mason
added to the journal ago
And the Future
Well, it's now April Fools.
The deadline has PASSED.
Although this project have already been submitted, I'd like to review some possibilities beyond the original intent of this board. Previously, I had toyed with the idea of custom animations and text banners. Thus, wouldn't be interesting to setup a custom firmware that would allow you to utilize an app? This way, you wouldn't need a nucleo or write additional programs to create cool animations. Already, I can think of a feature to pixelate a video into a readable format for the charlieplex display.

I used excel to animate frame by frame. The program parsed each csv frame to the corresponding LED. This was incredibly tedious.
Likewise, I could add pong to the game. Albeit, it'd be incredibly small.
Now that I'm really thinking, there are several possibilities beyond what I've already explored ->
1) Clock
2) Breathing animation (like that thing on an apple watch?)
3) Tilt maze, navigate a maze by tilting
4) Reaction game (maybe tilt in the direction the LED is, then display the number in ms?)
5) Sand dial?
I'll have to delve into my accelerometer's datasheet, but if I recall, it does have an onboard thermometer. I could display the value on the display.
The possibilities are VAST!
Mason
added to the journal ago
Towards Version Two
Now, this leads me to you! The "why I need funding" part.
Based on the several posts and comments, I'm aware of a small community who's interested in this gadget.
As I mentioned in my initial note, I've had the displeasure of shelving this project since February 21st. Luckily, spring break has provided me ample time to produce a version two.
In my initial prototype, I left numerous issues unresolved. Mainly, I was unable to get the sleep function working. The JST-2 wire would fall off often as well, which I soldered to the corresponding test pads. In hindsight, that was not wise.
Therefore, I decided to add an additional test pad to verify the WAKE pin signal. Addtionally, I'm soldering on a JST-2 connector on the physical board. For compatibility, I've upgraded from Micro-USB to USB-C.
Now, USB-C was more frustrating than expected. Due to the mechanical stress these ports are subject to, most USB-C connectors are designed with mechanical legs which require throughholes. This creates an unpleasant aesthetic.

Surprisingly, USB-C that do not possess these legs were incredibly difficult to find. Although USB4135 would serve as a viable option, it only allowed for power. Because I wanted to leave the option of an app viable (custom animations, programs, etc), I required a 16P USB-C.
Thankfully, I found it.


Mason
added to the journal ago
Enclosure
Since my family recently acquired a Bambu Lab 3D printer, I was able to print the necessary components for a case. With it, I was able to create iterations quickly and precisely. A feature I abused to the upmost extent. In all, there was at least 20 iterations.

Most of all, I had difficulty designing the back lid. Specifically, a method of retention.
Through all of my iterations, I tried snap on, screw on, you name it!

Eventually, I settled on this design. It utilizes clips which hang on to the side of the case.

Likewise, I created a cutout for a watch glass to protect the LED display.
Personally, I think it completes the look of the device.



Mason
added to the journal ago
POWER
Of course, there remains work to be done. The pendant currently runs off a LIPO battery.

However, I haven't been able to get the "deep sleep" to work. This is where the accelerometer tells the MCU (STM32) to go into extreme low power mode.
Without this function, the pendant won't be able to last beyond 12 hours, and even that's stretching it. I'll have to recharge every night or swap out the battery.
Currently, the accelerometer is supposed to detect motion. When none is detected over x period of time, it notifies the MCU to enter "deep sleep." When a threshold of motion is then detected, it notifies the MCU to wake up by dragging the WAKE pin to high, which is set to low by default.
Now, I suspect the issue is software. However, I cannot be sure that it is not a hardware issue.
It's possible that the accelerometer does not retain this information to "nudge" the MCU awake. It's possible that the MCU never receives the signal. Unfortunately, the pin for WAKE is miniscule. By shaking the device, it's impossible to properly probe whether the signal is being transmitted.
However, by resolving it, I do expect a signficant rise in battery life.
Mason
added to the journal ago
Accelerometer
At this stage, I encounted an issue with the accelerometer - I couldn't receive data.

Frustrated, I decided to create an animation instead. On the left of the image, you can see a frame of that program, which was an attempt at a walking sequence of a cat.

Fortunately, I was able to resolve the bug regarding the accelerometer. Unfortunately, I can't remember how I did it!
With the accelerometer communicating with the STM32, I created a program to illuminate an LED based on the direction of gravity at any given time - think the bubble inside a level.
Then, I used that program as a framework to integrate the particle simulation.

IT WORKS!
Mason
added to the journal ago
Programming
I just LOVE resolving bugs (Sarcasm, if you couldn't tell).
Over the next few weeks, I began to test the pendant.
To start, I wrote a program to illuminate each LED individually, then all at once.

Here, you can see me setting up the STM32's pin output.

Then, I made the display spell out my name. Through this program, I was able to understand how to illuminate LEDs quickly to create the illusion that more than one are on.

Mason
added to the journal ago
Assembly!
Assembly is incredibly stressful.

With the LED Display and Driver Board here, I was anxious to test them. Conveniently, other components also arrived on time.


And to my surprise, everything seemed to work!
Now, it wouldn't be a normal engineering project without some failure.
Despite my initial success, I bricked my first LED Display and Driver Board. When soldering them together, excess solder got between and shorted a connection together, preventing me from programming them.
Mason
added to the journal ago
Manufacturing is a pain
As the title goes, manufacturing is a pain.
At first, I went to PCBWay for a quote - their price was absurd. Then, I went to JLCPCB - their pricing seemed better.
Still, fortune was not upon us. JLCPCB didn't posess the accelerometer I required. So, I spent two weeks negotiating with a Chinese manufacturer through Alibaba who consigned the accelerometer to JLCPCB.


At this stage, I also noticed that the copper drill holes between the LED display and driver board did not match up. An incident so close to production was incredibly unsettling.
Anyway, remember when I said PCBWay's pricing was diabolical?

And somehow JLCPCB is still the cheaper option.
Mason
added to the journal ago
The Daughter Board
With the LED display completed, I set my sights on the driver board.
Despite Mitxela's extensive documentation, he was rather scarce on this particular matter.
Regardless, I was able to create this initial schematic.

When considering power, I initially planned to use a coin battery cell (LIR2450). But, because the cell's holder demanded a large footprint, I settled on a pouch-styled battery instead (LIPO 402025).
Similarly sized, it didn't require a mount. Likewise, it had the added benefit of removability. By soldering a JST PH 2 Male Header to Wire to the TP1 (+) and TP2 (-) pads, I could easily connect and disconnect the battery as I pleased. And, as an added bonus, it had built in circuit protection.

By consulting NCP73032-2-NC's datasheet, I was able to deduce that the correct resistor would be 20K to deliver a charge of 50mA.

After several revisions and reviews, I was able to route the driver board PCB. Now, the electronic designs were ready for manufacturing.

Mason
added to the journal ago
Project Start
Despite Mitxela's success, I was uncertain of my capabilities. So, I decided to split the electronic portion of this project into two daughter boards - the LED display and it's associated driver board.
First, I tackled the LED display by completing an initial 16x16 charlieplex schematic.

Then, I routed it. I found this process to be particularly irritating with net name conflicts.

In an early version of the PCB, I wanted to add pins so I could easily attach wires to probe each LED individually. Later, I decided against it.

Instead, I settled on a lilypad approach with exposed copper drill holes. With this setup, I could easily test and revise each board.
Mason
added to the journal ago
Foreword
Greetings Dear Reader!
Since my original submission, I've been instructed to split my journal into smaller segments. Thus, I will update my entries accordingly.
As a foreword, I wasn't aware of hackclub's blueprint grant program until recently. So, I was unable to fufill entries live due to other commitments (e.g college applications). Luckily, I've kept track of my progress.
Since January, I've been fascinated by Mitxela's Fluid Simulation Pendant.
If you're unfamiliar, you can check out his work here -> https://www.youtube.com/watch?v=jis1MC5Tm8k&t=2004s
As a beginner, I was thoroughly intrigued. With no former experience, I wanted to recreate a similar gadget. As you can imagine, I had underestimated the scale of this task.
To get started, I began with simple arduino circuits.
Arduino 1602 I2C LCD Demo - December 15, 2025 - 4 hours

Temperature Monitor - January 9, 2026 - 6 hours

To understand FLIP simulation, I began by creating a virtual pendant through HTML -> https://emperormurfy.github.io/
This took me about a day of work.
Next, I tackled KiCAD by following guides on Youtube.
I created this water detector in 6 hours.

Now, I was ready to set forth.
Souptik Samanta 🚀
requested changes for Fluid Simulation Pendant ago
lwk this is a cool project
but ur journal is cooked
plz subdivide in smaller chunk of 6ish hrs each
Mason
submitted Fluid Simulation Pendant for ship review ago
Mason
added to the journal ago
V2 and the Future
Well! It's now April Fools. The deadline has PASSED.
Although this project have already been submitted, I'd like to review some possibilities beyond the original intent of this board. Previously, I had toyed with the idea of custom animations and text banners. Thus, wouldn't be interesting to setup a custom firmware that would allow you to utilize an app? This way, you wouldn't need a nucleo or write additional programs to create cool animations. Already, I can think of a feature to pixelate a video into a readable format for the charlieplex display.

I used excel to animate frame by frame. The program parsed each csv frame to the corresponding LED. This was incredibly tedious.
Likewise, I could add pong to the game. Albeit, it'd be incredibly small.
Now that I'm really thinking, there are several possibilities beyond what I've already explored ->
1) Clock
2) Breathing animation (like that thing on an apple watch?)
3) Tilt maze, navigate a maze by tilting
4) Reaction game (maybe tilt in the direction the LED is, then display the number in ms?)
5) Sand dial?
I'll have to delve into my accelerometer's datasheet, but if I recall, it does have an onboard thermometer. I could display the value on the display.
The possibilities are VAST!
Mason
added to the journal ago
Completed Version Two + Detailed V1 Progress
Greetings Dear Reader!
As a note, I wasn't aware of hackclub's grant till recently, and was unable to fufill entries seperately due to other commitments; My fellow seniors can relate, we are swamped by work and college applications.
Thankfully, I did keep screenshots as I ran into issues.
Since January, I've been fascinated by Mitxela's Fluid Simulation Pendant.
If you're unfamiliar, check his work out here -> https://www.youtube.com/watch?v=jis1MC5Tm8k&t=2004s
As a beginner, I was thoroughly intrigued. With no former experience, I wanted to recreate a similar gadget. As you can imagine, I had underestimated the scale of this task.
To get started, I began with simple arduino circuits.


Likewise, I created a website to gain an understanding of particle simulations -> https://emperormurfy.github.io/
Eventually, I learned KiCAD. Following a tutorial on Youtube, I quickly gained an understanding over the software.

Now, I was ready to set forth.
January rolled around. Re-watching Mitxela's video & revisting his documentation, I was able to replicate a 16x16 charlieplexed display. Uncertain of it's success, I decided to split the PCB into two daughter boards for Version 1: the LED display and it's associated driver board.
Over the course of several iterations, I completed the initial LED display schematic.

This is an early version of the PCB.

Since I was uncertain that it would work, I wanted to try pins so I could probe each LED individually.
Eventually, I settled on this lilypad route with exposed holes. The associated driverboard would have corresponding holes, and solder could be easily applied. This would also allow for testing & easy of revision if a bug was discovered in either board. In other words, I wouldn't need to throw out the driver board if the LED display had issues.

With the LED display completed, I set my sights on the Driver Board.
Mitxela provided sufficient documentation. Likewise, I was able to gather information from others who are on a similar path of recreation.

When considering power, I initially planned to use a battery cell (LIR2450).
However, the holder's footprint was quite large. I settled on a LIPO 402025.
Similarly sized, it did not require a holder. Instead, I could solder a JST PH 2 Male Header to Wire to the TP1 (+) and TP2 (-). With the a corresponding female JST header, I could easily connect or disconnect the battery.

Consulting NCP73032-2-NC's datasheet, I determined the resistor at 20K for 50mA to charge the battery to it's 4.2V maximum.

Of course, I was struck by the might of the DRC frequently. Regardless, the driver board was complete.

In short, manufacturing is a pain.
At first, I consulted PCBWay. However, I quickly abandoned that route. Their pricing was diabolical.
Instead, I went to JLCPCB. Still, fortune was not upon us - they did not possess the accelerometer I required. Eventually, I was able to negotiate a deal with an alibaba manufacturer who provided the accelerometer.


At this stage, I noticed that the holes between the LED display and driver board did not match up.
An incident at this stage was too close for comfort.
Remember when I said PCBWay's pricing was diabolical?

Assembly is nerve racking.

With the LED Display and Driver Board here, I was anxious to test them. Likewise, the rest of the equipment had arrived (Eg. Nucleo).
To my surprise, everything seemed to work!


Now, it wouldn't be an engineering project without some failure.
When soldering the first LED Display and Driver Board together, I believe that excess solder got between the cracks, shorting the programming pins together.
Programming is so fun! <- Sarcasm BTW
You can see me setting up the pin outputs here.

Over the next few weeks, I began testing the board.
To start, I wrote a program to illuminate each LED individually, then all at once.

I made the display spell out my name.

At this point, I encountered an issue with the accelerometer.
I was unable to receive data.

Frustrated, I decided to program an animation into the pendant.
On the left of the image, you can see a frame of that program, which displays a cat walk sequence.

Fortunately, I was able to resolve the bug. Unfortunately, I do not recall how I accomplished such a task.
With the accelerometer communicating with the STM32, I began with a simple level. Depending on orientation, the pendant would attempt to identify the direction of gravity at any given time.
Then, I used this program as a platform to implement a particle simulation.

Of course, there remains work to be done. The pendant currently runs off a LIPO battery. However, I haven't been able to get the "deep sleep" to work. This is where the accelerometer tells the MCU (STM32) to go into extreme low power mode.
Without this function, the pendant won't be able to last beyond 12 hours, and even that's stretching it.
I'll have to recharge every night or swap out the battery. I'm currently debugging the problem.
By resolving it, I expect a signficant rise in battery life.
Currently, the accelerometer is supposed to detect motion. When none is detected over x period of time, it notifies the MCU to enter "deep sleep." When a threshold of motion is then detected, it notifies the MCU to wake up by dragging the WAKE pin to high, which is set to low by default.
Now, I suspect the issue is software. However, I cannot be sure that it is not a hardware issue.
It's possible that the accelerometer does not retain this information to "nudge" the MCU awake. It's possible that the MCU never receives the signal. Unfortunately, the pin for WAKE is miniscule. By shaking the device, it's impossible to properly probe whether the signal is being transmitted.
--
Since my family recently acquired a Bambu Lab 3D printer, I was able to print the necessary components for a case. With it, I was able to create iterations quickly and precisely. A feature I abused to the upmost extent. In all, there was at least 20 iterations.

Most of all, I had difficulty designing the back lid. Specifically, a method of retention.
Through all of my iterations, I tried snap on, screw on, you name it!

Eventually, I settled on this design. It utilizes clips which hang on to the side of the case.

Likewise, I created a cutout for a watch glass to protect the LED display.
Personally, I think it completes the look of the device.
In all, I must've spent at least 100 hours across two months of work.
Future - V2
This leads me to you! Why I need funding from the people of Hack Club.
From Reddit to Youtube, I'm aware of a community who's interested in this very gadget.
As I mentioned in my initial note, I've had the displeasure of shelving this project since February 21st till recently. This is due to several factors: academic responsibilities, FRC club, and college applications.
Luckily, spring break has allotted me the past weekend to produce version 2!
In my initial prototype, I left numerous issues unresolved. Mainly, I was unable to get the sleep function working. The JST-2 wire would fall off often as well, which I soldered to the corresponding test pads. In hindsight, that was not wise.
Therefore, I decided to add an additional test pad to verify the WAKE pin signal.
Likewise, I'm soldering on a JST-2 connector on the physical board. For compatibility, I've upgraded from Micro-USB to USB-C.
Now, USB-C was more frustrating than expected. Due to the mechanical stress these ports are subject to, most USB-C connectors are designed with mechanical legs which require throughholes. This creates an unpleasant aesthetic.

Surprisingly, USB-C that do not possess these legs were incredibly difficult to find. Although USB4135 would serve as a viable option, it only allowed for power. Because I wanted to leave the option of an app viable (custom animations, programs, etc), I required a 16P USB-C.
Thankfully, I found it.


Mason
started Fluid Simulation Pendant ago
3/31/2026 12 AM - Completed Version Two + Detailed V1 Progress
Greetings Dear Reader!
As a note, I wasn't aware of hackclub's grant till recently, and was unable to fufill entries seperately due to other commitments; My fellow seniors can relate, we are swamped by work and college applications.
Thankfully, I did keep screenshots as I ran into issues.
Since January, I've been fascinated by Mitxela's Fluid Simulation Pendant.
If you're unfamiliar, check his work out here -> https://www.youtube.com/watch?v=jis1MC5Tm8k&t=2004s
As a beginner, I was thoroughly intrigued. With no former experience, I wanted to recreate a similar gadget. As you can imagine, I had underestimated the scale of this task.
To get started, I began with simple arduino circuits.


Likewise, I created a website to gain an understanding of particle simulations -> https://emperormurfy.github.io/
Eventually, I learned KiCAD. Following a tutorial on Youtube, I quickly gained an understanding over the software.

Now, I was ready to set forth.
January rolled around. Re-watching Mitxela's video & revisting his documentation, I was able to replicate a 16x16 charlieplexed display. Uncertain of it's success, I decided to split the PCB into two daughter boards for Version 1: the LED display and it's associated driver board.
Over the course of several iterations, I completed the initial LED display schematic.

This is an early version of the PCB.

Since I was uncertain that it would work, I wanted to try pins so I could probe each LED individually.
Eventually, I settled on this lilypad route with exposed holes. The associated driverboard would have corresponding holes, and solder could be easily applied. This would also allow for testing & easy of revision if a bug was discovered in either board. In other words, I wouldn't need to throw out the driver board if the LED display had issues.

With the LED display completed, I set my sights on the Driver Board.
Mitxela provided sufficient documentation. Likewise, I was able to gather information from others who are on a similar path of recreation.

When considering power, I initially planned to use a battery cell (LIR2450).
However, the holder's footprint was quite large. I settled on a LIPO 402025.
Similarly sized, it did not require a holder. Instead, I could solder a JST PH 2 Male Header to Wire to the TP1 (+) and TP2 (-). With the a corresponding female JST header, I could easily connect or disconnect the battery.

Consulting NCP73032-2-NC's datasheet, I determined the resistor at 20K for 50mA to charge the battery to it's 4.2V maximum.

Of course, I was struck by the might of the DRC frequently. Regardless, the driver board was complete.

In short, manufacturing is a pain.
At first, I consulted PCBWay. However, I quickly abandoned that route. Their pricing was diabolical.
Instead, I went to JLCPCB. Still, fortune was not upon us - they did not possess the accelerometer I required. Eventually, I was able to negotiate a deal with an alibaba manufacturer who provided the accelerometer.


At this stage, I noticed that the holes between the LED display and driver board did not match up.
An incident at this stage was too close for comfort.
Remember when I said PCBWay's pricing was diabolical?

Assembly is nerve racking.

With the LED Display and Driver Board here, I was anxious to test them. Likewise, the rest of the equipment had arrived (Eg. Nucleo).
To my surprise, everything seemed to work!


Now, it wouldn't be an engineering project without some failure.
When soldering the first LED Display and Driver Board together, I believe that excess solder got between the cracks, shorting the programming pins together.
Programming is so fun! <- Sarcasm BTW
You can see me setting up the pin outputs here.

Over the next few weeks, I began testing the board.
To start, I wrote a program to illuminate each LED individually, then all at once.

I made the display spell out my name.

At this point, I encountered an issue with the accelerometer.
I was unable to receive data.

Frustrated, I decided to program an animation into the pendant.
On the left of the image, you can see a frame of that program, which displays a cat walk sequence.

Fortunately, I was able to resolve the bug. Unfortunately, I do not recall how I accomplished such a task.
With the accelerometer communicating with the STM32, I began with a simple level. Depending on orientation, the pendant would attempt to identify the direction of gravity at any given time.
Then, I used this program as a platform to implement a particle simulation.

Of course, there remains work to be done. The pendant currently runs off a LIPO battery. However, I haven't been able to get the "deep sleep" to work. This is where the accelerometer tells the MCU (STM32) to go into extreme low power mode.
Without this function, the pendant won't be able to last beyond 12 hours, and even that's stretching it.
I'll have to recharge every night or swap out the battery. I'm currently debugging the problem.
By resolving it, I expect a signficant rise in battery life.
Currently, the accelerometer is supposed to detect motion. When none is detected over x period of time, it notifies the MCU to enter "deep sleep." When a threshold of motion is then detected, it notifies the MCU to wake up by dragging the WAKE pin to high, which is set to low by default.
Now, I suspect the issue is software. However, I cannot be sure that it is not a hardware issue.
It's possible that the accelerometer does not retain this information to "nudge" the MCU awake. It's possible that the MCU never receives the signal. Unfortunately, the pin for WAKE is miniscule. By shaking the device, it's impossible to properly probe whether the signal is being transmitted.
--
Since my family recently acquired a Bambu Lab 3D printer, I was able to print the necessary components for a case. With it, I was able to create iterations quickly and precisely. A feature I abused to the upmost extent. In all, there was at least 20 iterations.

Most of all, I had difficulty designing the back lid. Specifically, a method of retention.
Through all of my iterations, I tried snap on, screw on, you name it!

Eventually, I settled on this design. It utilizes clips which hang on to the side of the case.

Likewise, I created a cutout for a watch glass to protect the LED display.
Personally, I think it completes the look of the device.
In all, I must've spent at least 100 hours across two months of work.
Future - V2
This leads me to you! Why I need funding from the people of Hack Club.
From Reddit to Youtube, I'm aware of a community who's interested in this very gadget.
As I mentioned in my initial note, I've had the displeasure of shelving this project since February 21st till recently. This is due to several factors: academic responsibilities, FRC club, and college applications.
Luckily, spring break has allotted me the past weekend to produce version 2!
In my initial prototype, I left numerous issues unresolved. Mainly, I was unable to get the sleep function working. The JST-2 wire would fall off often as well, which I soldered to the corresponding test pads. In hindsight, that was not wise.
Therefore, I decided to add an additional test pad to verify the WAKE pin signal.
Likewise, I'm soldering on a JST-2 connector on the physical board. For compatibility, I've upgraded from Micro-USB to USB-C.
Now, USB-C was more frustrating than expected. Due to the mechanical stress these ports are subject to, most USB-C connectors are designed with mechanical legs which require throughholes. This creates an unpleasant aesthetic.

Surprisingly, USB-C that do not possess these legs were incredibly difficult to find. Although USB4135 would serve as a viable option, it only allowed for power. Because I wanted to leave the option of an app viable (custom animations, programs, etc), I required a 16P USB-C.
Thankfully, I found it.

3/31/2026 9 PM - V2 and the Future
Well! It's now April Fools. The deadline has PASSED.
Although this project have already been submitted, I'd like to review some possibilities beyond the original intent of this board. Previously, I had toyed with the idea of custom animations and text banners. Thus, wouldn't be interesting to setup a custom firmware that would allow you to utilize an app? This way, you wouldn't need a nucleo or write additional programs to create cool animations. Already, I can think of a feature to pixelate a video into a readable format for the charlieplex display.

I used excel to animate frame by frame. The program parsed each csv frame to the corresponding LED. This was incredibly tedious.
Likewise, I could add pong to the game. Albeit, it'd be incredibly small.
Now that I'm really thinking, there are several possibilities beyond what I've already explored ->
1) Clock
2) Breathing animation (like that thing on an apple watch?)
3) Tilt maze, navigate a maze by tilting
4) Reaction game (maybe tilt in the direction the LED is, then display the number in ms?)
5) Sand dial?
I'll have to delve into my accelerometer's datasheet, but if I recall, it does have an onboard thermometer. I could display the value on the display.
The possibilities are VAST!
4/8/2026 6:45 PM - Foreword
Greetings Dear Reader!
Since my original submission, I've been instructed to split my journal into smaller segments. Thus, I will update my entries accordingly.
As a foreword, I wasn't aware of hackclub's blueprint grant program until recently. So, I was unable to fufill entries live due to other commitments (e.g college applications). Luckily, I've kept track of my progress.
Since January, I've been fascinated by Mitxela's Fluid Simulation Pendant.
If you're unfamiliar, you can check out his work here -> https://www.youtube.com/watch?v=jis1MC5Tm8k&t=2004s
As a beginner, I was thoroughly intrigued. With no former experience, I wanted to recreate a similar gadget. As you can imagine, I had underestimated the scale of this task.
To get started, I began with simple arduino circuits.
Arduino 1602 I2C LCD Demo - December 15, 2025 - 4 hours

Temperature Monitor - January 9, 2026 - 6 hours

To understand FLIP simulation, I began by creating a virtual pendant through HTML -> https://emperormurfy.github.io/
This took me about a day of work.
Next, I tackled KiCAD by following guides on Youtube.
I created this water detector in 6 hours.

Now, I was ready to set forth.
4/8/2026 6:57 PM - Project Start
Despite Mitxela's success, I was uncertain of my capabilities. So, I decided to split the electronic portion of this project into two daughter boards - the LED display and it's associated driver board.
First, I tackled the LED display by completing an initial 16x16 charlieplex schematic.

Then, I routed it. I found this process to be particularly irritating with net name conflicts.

In an early version of the PCB, I wanted to add pins so I could easily attach wires to probe each LED individually. Later, I decided against it.

Instead, I settled on a lilypad approach with exposed copper drill holes. With this setup, I could easily test and revise each board.
4/8/2026 7:07 PM - The Daughter Board
With the LED display completed, I set my sights on the driver board.
Despite Mitxela's extensive documentation, he was rather scarce on this particular matter.
Regardless, I was able to create this initial schematic.

When considering power, I initially planned to use a coin battery cell (LIR2450). But, because the cell's holder demanded a large footprint, I settled on a pouch-styled battery instead (LIPO 402025).
Similarly sized, it didn't require a mount. Likewise, it had the added benefit of removability. By soldering a JST PH 2 Male Header to Wire to the TP1 (+) and TP2 (-) pads, I could easily connect and disconnect the battery as I pleased. And, as an added bonus, it had built in circuit protection.

By consulting NCP73032-2-NC's datasheet, I was able to deduce that the correct resistor would be 20K to deliver a charge of 50mA.

After several revisions and reviews, I was able to route the driver board PCB. Now, the electronic designs were ready for manufacturing.
4/8/2026 7:13 PM - Manufacturing is a pain
As the title goes, manufacturing is a pain.
At first, I went to PCBWay for a quote - their price was absurd. Then, I went to JLCPCB - their pricing seemed better.
Still, fortune was not upon us. JLCPCB didn't posess the accelerometer I required. So, I spent two weeks negotiating with a Chinese manufacturer through Alibaba who consigned the accelerometer to JLCPCB.


At this stage, I also noticed that the copper drill holes between the LED display and driver board did not match up. An incident so close to production was incredibly unsettling.
Anyway, remember when I said PCBWay's pricing was diabolical?

And somehow JLCPCB is still the cheaper option.
4/8/2026 7:16 PM - Assembly!
Assembly is incredibly stressful.

With the LED Display and Driver Board here, I was anxious to test them. Conveniently, other components also arrived on time.


And to my surprise, everything seemed to work!
Now, it wouldn't be a normal engineering project without some failure.
Despite my initial success, I bricked my first LED Display and Driver Board. When soldering them together, excess solder got between and shorted a connection together, preventing me from programming them.
4/8/2026 7:20 PM - Programming
I just LOVE resolving bugs (Sarcasm, if you couldn't tell).
Over the next few weeks, I began to test the pendant.
To start, I wrote a program to illuminate each LED individually, then all at once.

Here, you can see me setting up the STM32's pin output.

Then, I made the display spell out my name. Through this program, I was able to understand how to illuminate LEDs quickly to create the illusion that more than one are on.
4/8/2026 7:24 PM - Accelerometer
At this stage, I encounted an issue with the accelerometer - I couldn't receive data.

Frustrated, I decided to create an animation instead. On the left of the image, you can see a frame of that program, which was an attempt at a walking sequence of a cat.

Fortunately, I was able to resolve the bug regarding the accelerometer. Unfortunately, I can't remember how I did it!
With the accelerometer communicating with the STM32, I created a program to illuminate an LED based on the direction of gravity at any given time - think the bubble inside a level.
Then, I used that program as a framework to integrate the particle simulation.

IT WORKS!
4/8/2026 7:26 PM - POWER
Of course, there remains work to be done. The pendant currently runs off a LIPO battery.

However, I haven't been able to get the "deep sleep" to work. This is where the accelerometer tells the MCU (STM32) to go into extreme low power mode.
Without this function, the pendant won't be able to last beyond 12 hours, and even that's stretching it. I'll have to recharge every night or swap out the battery.
Currently, the accelerometer is supposed to detect motion. When none is detected over x period of time, it notifies the MCU to enter "deep sleep." When a threshold of motion is then detected, it notifies the MCU to wake up by dragging the WAKE pin to high, which is set to low by default.
Now, I suspect the issue is software. However, I cannot be sure that it is not a hardware issue.
It's possible that the accelerometer does not retain this information to "nudge" the MCU awake. It's possible that the MCU never receives the signal. Unfortunately, the pin for WAKE is miniscule. By shaking the device, it's impossible to properly probe whether the signal is being transmitted.
However, by resolving it, I do expect a signficant rise in battery life.
4/8/2026 7:27 PM - Enclosure
Since my family recently acquired a Bambu Lab 3D printer, I was able to print the necessary components for a case. With it, I was able to create iterations quickly and precisely. A feature I abused to the upmost extent. In all, there was at least 20 iterations.

Most of all, I had difficulty designing the back lid. Specifically, a method of retention.
Through all of my iterations, I tried snap on, screw on, you name it!

Eventually, I settled on this design. It utilizes clips which hang on to the side of the case.

Likewise, I created a cutout for a watch glass to protect the LED display.
Personally, I think it completes the look of the device.
4/8/2026 7:30 PM - Towards Version Two
Now, this leads me to you! The "why I need funding" part.
Based on the several posts and comments, I'm aware of a small community who's interested in this gadget.
As I mentioned in my initial note, I've had the displeasure of shelving this project since February 21st. Luckily, spring break has provided me ample time to produce a version two.
In my initial prototype, I left numerous issues unresolved. Mainly, I was unable to get the sleep function working. The JST-2 wire would fall off often as well, which I soldered to the corresponding test pads. In hindsight, that was not wise.
Therefore, I decided to add an additional test pad to verify the WAKE pin signal. Addtionally, I'm soldering on a JST-2 connector on the physical board. For compatibility, I've upgraded from Micro-USB to USB-C.
Now, USB-C was more frustrating than expected. Due to the mechanical stress these ports are subject to, most USB-C connectors are designed with mechanical legs which require throughholes. This creates an unpleasant aesthetic.

Surprisingly, USB-C that do not possess these legs were incredibly difficult to find. Although USB4135 would serve as a viable option, it only allowed for power. Because I wanted to leave the option of an app viable (custom animations, programs, etc), I required a 16P USB-C.
Thankfully, I found it.

4/8/2026 7:31 PM - And the Future
Well, it's now April Fools.
The deadline has PASSED.
Although this project have already been submitted, I'd like to review some possibilities beyond the original intent of this board. Previously, I had toyed with the idea of custom animations and text banners. Thus, wouldn't be interesting to setup a custom firmware that would allow you to utilize an app? This way, you wouldn't need a nucleo or write additional programs to create cool animations. Already, I can think of a feature to pixelate a video into a readable format for the charlieplex display.

I used excel to animate frame by frame. The program parsed each csv frame to the corresponding LED. This was incredibly tedious.
Likewise, I could add pong to the game. Albeit, it'd be incredibly small.
Now that I'm really thinking, there are several possibilities beyond what I've already explored ->
1) Clock
2) Breathing animation (like that thing on an apple watch?)
3) Tilt maze, navigate a maze by tilting
4) Reaction game (maybe tilt in the direction the LED is, then display the number in ms?)
5) Sand dial?
I'll have to delve into my accelerometer's datasheet, but if I recall, it does have an onboard thermometer. I could display the value on the display.
The possibilities are VAST!