Lab401 Light Messenger : Development Log

Part 2 of our "Product Manufacturing with Lab401" series.

In the Part 1, we discussed our approach and methodology to creating, manufacturing and launching products.

In this part, we deep-dive into the behind-the-scenes of producing Lab401's Persistence of Vision / Light Painting accessory for the Flipper Zero.

What is the Light Messenger?

The Light Messenger is a Persistence of Vision and Light Painting accessory for the Flipper Zero. It has 16 RGB LEDs and an accelerometer; when plugged into your Flipper Zero and swiped back and forth, "paints" text and images in the air.

It's open-source and completely hackable - and the community has already added some great new features.

Huge shoutout to @tixlegeek, the engineer behind the project, and @codeallnight for their contributions to the code-base since product release.

Step 0: What Will We Build?

Initially, we kicked off with a brainstorming session during which we jotted down several ideas. The goal was to find concepts that were fun, interesting, and capable of bringing real innovations to the Flipper Zero, rather than just replicating the same hardware modules that are proliferating as clones. We aimed to create a project that is novel, captivating, and educational.

Next, we evaluated each idea to determine where to begin. This was a first for us, so it was crucial that the initial project be clearly defined and accessible.

In addition to the "Product Metric" defined in the previous post, because this would be our first Flipper Zero accessory, we had several other additional metrics:

• Learn the Flipper Zero hardware architecture
• Learn the Flipper Zero software development architecture (FURI)
• Establish and manage a full supply chain (development, prototyping, production, etc)
• Test the market for Flipper Zero accessories

Because of this additional overhead, it was important that we set achievable goals. As such, we wanted to ensure that the accessory scope was relatively simple, in order that we could concentrate on building knowledge without being overwhelmed.

We settled on the "Persistence of Vision / Light Painting" accessory, as it was relatively simplistic in terms of hardware and production, which would allow us to concentrate on the more complex elements : software development & Flipper architecture.

Likewise, if there was no market for Flipper accessories, and the entire project was a failure, we would fail quickly (and therefor more cheaply).

In summary: this project allowed us to learn and explore what we could do, and how. 

Design

Initial product sketches

Before diving into the final design, several factors had to be considered. We had to work within physical, budgetary, and logistical constraints that would steer our technical choices:

• Mechanical Robustness
  The add-on will be used by real people, with large hands and sometimes dogy usage. Thus, we needed to design a robust module, especially taking into account the GPIO limitations of the Flipper Zero's external port.

• Development
  The code must remain clear and accessible so that anyone can understand and contribute. This is why we chose to organize the project into several modules (configuration, accelerometer management, graphics rendering, etc.) and to use proven standards (such as JSON for configuration and Bitmap for images).

• Production
  Every element must be easily manufacturable with readily available components. Our choice of the LIS2DH12/SK6805 pair proved to be a sound decision in terms of reliability and sourcing.

• Cost
  The approach was to remain simple and efficient. We prioritize what’s necessary to ensure that the final product is available at a reasonable price.

• Aesthetics
  Aesthetics can often be easily overlooked, but they contribute significantly to the user experience, the product's appeal, and the creators' image. Both Lab401 and I wanted to be as proud as possible of what is offered to the user, ensuring they feel respected and valued. The aim was to provide something beautiful that shows we truly tried our best.

Sketching

I start with this point because it’s one of my favorite steps. I wanted all the add-ons to share a common story and a red thread to create a genuine lore. This attention to detail strengthens user engagement, even if it isn’t strictly necessary from a technical standpoint.

I began on paper, sketching ideas, and then finalized the drafts using Inkscape (<3).

For the back of the PCB, I designed a cheat sheet on “Information Security” focused on encoding, including the Shannon model, comparisons between Encoding, Encryption, and Hashing, as well as a condensed ASCII table and a diagram for Morse code.

Prototypes

We went through numerous iterations, from the proof of concept to the final version, enabling us to iterate quickly whenever an issue was identified:

First prototype that allowed us to control the peripheral functions and test various options

Some of the prototypes that were developed

Each prototype allowed us to test a specific aspect of the module, from motion detection to LED display, and to refine our code. This approach enabled us to kick off serious development on a robust foundation.

Component Selection

To kick off production, we needed to ensure that all components could be sourced in sufficient quantities. After numerous tests and design iterations, we opted for the LIS2DH12/SK6805 pair:

• LIS2DH12: An accelerometer offering all the required functionalities, with excellent reliability and software support provided by STMicro.

• SK6805: The only model that emits from the side, which wasn’t initially planned but turned out to be the ideal solution. They are also readily available.

PCB

The PCB was designed using KiCad (<3), a free and open source software that is extremely powerful. Its dynamic community and advanced features allowed us to design a circuit tailored to the project’s specific needs, while maintaining a professional quality.

Operation and POC

This section delves into the heart of the project. The specifications were as follows:

• Text display

• Image display

• Bidirectional display

To meet dimensional constraints while ensuring good resolution, we opted for an array of 16 RGB LEDs (SK6805).

For motion detection, we used an accelerometer with at least two “tilt” type interrupts. These interrupts detect force inversions and generate pulses on the GPIO pins, which are essential for triggering interrupts in the code.

It’s important to keep in mind that the Flipper’s GPIO port is very well designed but also quite limited. We had to run several tests, seek ideas and help from the Flipper teams, but eventually, it worked, and we quickly implemented a satisfactory POC.

First glances of "working" implementation

First functional code

The Code

Developing the code was the real challenge.

• Modular Structure:
  The code is broken down into several clear modules:

  • Configuration: Reading and parsing the JSON file to define the display and parameters.

  • Accelerometer: Managing interrupts via the zmax_callback and zmin_callback functions, which determine the direction of motion and update the application structure through swipes_init.

  • Graphics Rendering: A shader computes in real time the colors of all pixels in a column based on parameters and the accelerometer’s state.

• Real-Time Optimization:
  The main thread runs continuously to recalculate and update the LED display. Fine-grained microsecond management allows us to balance performance and responsiveness, even on limited hardware.

• Dedicated tools for creating text and image easily, given the limitations of the flipper zero (monochrome screen, and a few buttons)

• Ease of Contribution:
  We ensured that the project is easily extensible. By using standards such as JSON and Bitmap, users can effortlessly generate, import, and modify files without having to master complex pipelines.

The code was designed so that each new feature (like adding colors to images or enhancing the shader) can be integrated without disrupting the overall system.

First successful tests of the "bitmap" function

Operating Details

The accelerometer plays a central role in orchestrating the LED matrix display. Once the "SWIPE" message is displayed, a dedicated thread (app_acc_worker) takes over to manage the interrupts and steer the display.

Note:
As you peruse the code, you’ll notice that we don’t use traditional mechanisms like mutexes or event queues inside the "display" routine. The Flipper API, based on FreeRTOS, offers these structures, but way too costly at this level. We opted for more direct techniques, even if some might call them "dirty." After several weeks of iterations, this approach proved to be the most reliable for our use case, garanteeing timings and stability

The two interrupts generated by the accelerometer trigger the zmax_callback and zmin_callback functions. These functions update the direction of movement, which is then used by the main thread to animate the LEDs using a dynamic shader. This shader is designed to be easily modifiable via a simple callback function change, allowing for the exploration of different color palettes and visual effects.

The Flipper Ecosystem

Working on the Flipper Zero is both stimulating and challenging. The efforts of the community and the development teams are impressive and dynamic, even though the constantly evolving API sometimes necessitates revisiting parts of the code. This dynamic nature ensures that the project remains cutting-edge and benefits from the latest system improvements.

Manufacturing, Production and Testing

Once we'd iterated to final hardware, we were able to put a few processes into parallel:

• PCB / PCBA 
• Testing / QC
• Packaging 

PCB / PCBA

When you're manufacturing, the first step is to send your full project files to the selected factory. These are typically the "GERBERS" and "Bill of Material" (BOM).

This will allow the factory to manufacture the Printed Circuit Boards (PCBs), and prepare the Solder Masks and Silk Screen, and also prepare for Printed Circuit Board Assembly (PCBA) - where the components are picked, placed and soldered onto the PCB.

We opted to use one of our existing contacts in Shenzhen for the PCB + PCBA.

Initial PCB Tests

Production PCBs. We opted for the "snap-off ladder style" to make testing easier. Once a PCB was tested, it could be snapped off, so there'd be no confusion on what had been tested or hadn't been tested.

Testing / QC

There are multiple approaches to testing / quality control.
In our experience, 100% testing (ie, each product is tested individually) is safer, more reliable, and in the long run, cheaper than random sampling.

To perform 100% QC, you need to supply the factory with an SOP (Standard Operating Procedure) document, which outlines how a product should be tested, and what the PASS/FAIL conditions are.

If at all possible, it's preferable that testing is done in a "jig". This is a semi-automated device that will allow the factory to quickly test each individual device.

Typically, if you can supply the schematic + firmware + SOP, the factory will work out how to physically build the jig to meet their needs.

The SOP document

The factory's implementation of the testing jig (with unexpected alien 👽)

Sample of a passing unit

Sample of a failing unit (accelerometer failed during PCBA)

Packaging

Packaging is a fascinating subject: it plays a significant role in a customer's perception of a product; this perception can even taint a customer's first hands-on experiences with a device.

At the same time, unless it's a collectable device, packages will be almost instantly discarded.
Ethically, were is the boundary between providing the customer with a perception of quality, while also not over-charging them for something that will be thrown away?

Likewise, packaging has a large environmental impact. At production, there are all sorts of chemicals used to bleach and colour raw materials; at reception, it's going to go into landfill.

We prefer to use simple packaging:

• Unbleached, uncoated cardboard to minimise our footprint of damaging chemicals
• Soy-based inks, to minimise environmental impact
• Simple foam inserts (no custom cutting, etc) to minimise costs

We believe this strikes a balance between our ethical engagements, while still providing the customer with a pleasant unboxing experience. Likewise: we're being honest to the customers - they're not paying for something that they're going to throw away.

After making these choices, we selected a format that worked for us, but still remained slim enough to qualify for "envelope" postage prices.

However, we could and should have made this even slimmer - even a 50% height reduction would have reduced our palette, shipping and storage costs significantly. Lesson learned for the next accessory!

Our box.

Conclusion

This project turned out to be far more complex than anticipated, but we gave it our all to deliver a finished, functional, extensible, aesthetic, educational, and fun product! Every line of code, every technical choice, was made to provide a rich user experience and a solid foundation for future contributions.

As we develop new projects, the Lab401 team and I will continue to gain confidence, organization, and skills.

Our ambition remains to create devices that fully embody our initial vision, and we invite you to explore, contribute, and share your ideas on GitHub.

If you're interested in checking out the final product, the LightMessenger, we'd be humbled - and very interested to see what you do with it!

Customer shots showing light-painting, bitmaps, text modes and different colour effects.