This is a DIY ESP32-based split-flap display, optimized for easy assembly at home in small quantities but able to be scaled up to large affordable displays.
The splitflap community Discord server is the best place to keep up with the latest changes or ask questions about the project!
Want to help support development or just say "thanks"? Consider a one-time or monthly sponsorship:
:heart: Sponsor scottbez1 on GitHub |
---|
Using this project in a commercial setting or for paid client work? Go right ahead - it's open source (just make sure to follow the terms of the Apache License)! I would, however, ask that you consider sponsoring the project. I've been developing and maintaining this project in my free time for over 8 years, and I'd love to continue working on it. Sponsorships allow me to pay for prototypes and development tools that make this project possible. Unlike pure software projects, every iteration has real hardware costs; sponsorships allow me to keep iterating and improving the project faster. Thank you!
Releases have been tested and used to produce working units, but as this is a continuously evolving open-source project, there may always be minor issues and/or incomplete documentation from time to time.
Component | Version | Notes |
---|---|---|
Enclosure/Mechanics | v0.7 | https://github.com/scottbez1/splitflap/releases/tag/v0.7 |
Electronics - Sensor | v1.1 | https://github.com/scottbez1/splitflap/releases/tag/releases%2Fsensor%2Fv1.1 |
Electronics - Chainlink Driver | v1.1 | https://github.com/scottbez1/splitflap/releases/tag/releases%2FchainlinkDriver%2Fv1.1 |
Electronics - Chainlink Buddy [T-Display] | v1.0 | https://github.com/scottbez1/splitflap/releases/tag/releases%2FchainlinkBuddyTDisplay%2Fv1.0 |
Firmware | latest | Current firmware is backwards-compatible and not strictly versioned; use the latest from the master branch |
Control Software Examples | latest | Example Typescript and Python code for driving the display is in the software directory. The Typescript library and examples are more actively developed. |
Here's a video of a large 108-module display powered by 18 Chainlink Driver boards and a Chainlink Base:
A minor refresh of the mechanical and sensor design is currently in beta, and the stable release is expected in Summer 2024.
The beta designs (seen on this page) have been tested are nearly feature-complete, but documentation is still in progress.
Here's what to expect in v2:
But many things are staying the same for easy upgrades/compatibility:
I'd love to hear your thoughts and questions about this project, and happy to incorporate any feedback you might have into these designs! Please feel free (and encouraged) to open GitHub issues, email me directly, reach out on Twitter, and get involved in the open source development and let's keep chatting and building together!
If you have any questions, please don't hesitate to ask in the community Discord server!
Note: the ordering and assembly guides have not yet been updated for the beta v2 designs. Ask in Discord if you have any questions about ordering or assembling a v2 display!
The mechanical/structural components are made from laser-cut 3mm MDF or acrylic, and held together with M4 bolts and nuts. The design is parametric and built using OpenSCAD. See below for more info on rendering/modifying the design.
You can view an interactive 3d model of the design here.
The beta v2 mechanical design officially supports variants with 52 flaps (perfect for use with the new "Epilogue" printed flaps) and 40 flaps. But you can always modify the design to customize it further.
The v0.7 stable release artifacts can be found at the v0.7 tagged release.
Module dimensions:
Latest auto-generated (untested!) artifacts:warning::
:warning:For tested/stable/recommended artifacts, use the latest release instead
Module dimensions:
Latest auto-generated (untested!) artifacts:warning::
:warning:For tested/stable/recommended artifacts, use the latest release instead
[!NOTE] For small displays (up to 3 modules), you can skip the custom controller boards and use off-the-shelf ULN2003A driver modules plugged into an Arduino Uno. This is partially documented in the wiki but may require some additional tinkering to get it to work. Help wanted: if you'd like to help improve these instructions, please reach out in the Discord server, thanks!
The "Chainlink" electronics system is designed to support long chains of driver boards to control medium/large displays (up to 100+ split-flap modules). It's also designed to be easy and cheap to order pre-assembled or build yourself, especially in higher quantities, due to its simple BOM and surface-mount components.
To build a display, you'll need 3 different electronics:
Each module needs a hall-effect sensor for start-up calibration and fault monitoring.
Older sensors for the v0.7 and older laser-cut hardware can be found in the tagged sensor release
Older sensors for the v0.7 and older laser-cut hardware can be found in the tagged sensor release
Latest auto-generated (untested!) artifacts:warning::
:warning:For tested/stable/recommended artifacts, use the latest release instead
Key features:
Chainlink Driver boards are available mostly-assembled in the Bezek Labs store, and come with the additional connectors and ribbon cables you'll need. Purchases support continued development of this project.
More information on building and using Chainlink Drivers is available in the Chainlink Driver User Guide.
Or if you'd like to order these directly from a fab, this design is optimized for assembly at JLCPCB, and files are automatically generated for ordering assembled PCBs there. Or if you wish to assemble this board yourself instead of paying for assembly, you can view the interactive BOM/placement tool
Depending on available stock at JLCPCB, you may need to manually modify the BOM file to use alternative components, or regenerate the files
yourself using export_jlcpcb.py
and specifying one or more LCSC_ALT_*
field names to use a pre-selected alternative part number. See
the schematic for available pre-selected alternatives (check the symbol's properties/fields).
Latest auto-generated (untested!) artifacts:warning::
:warning:For tested/stable/recommended artifacts, use the latest release instead
The Chainlink Buddy [T-Display] is a convenient way to connect a T-Display ESP32 board (recommended microcontroller) to a chain of Chainlink Drivers.
Key features:
Chainlink Buddy [T-Display] boards are available in the Bezek Labs store, and come with the additional connectors you'll need. Purchases support continued development of this project.
Latest auto-generated (untested!) artifacts:warning::
:warning:For tested/stable/recommended artifacts, use the latest release instead
The Chainlink Buddy [Breadboard] makes it easy to connect a Chainlink Driver to a breadboard for prototyping. You could use 5 dupont wires and have a messy rats nest, or you could use a single ribbon cable and this slick breakout board.
Chainlink Buddy [Breadboard] boards are available in the Bezek Labs store, and come with the additional connectors you'll need. Purchases support continued development of this project.
Latest auto-generated (untested!) artifacts:warning::
:warning:For tested/stable/recommended artifacts, use the latest release instead
For larger displays, you should take additional care to make the hardware more robust to potential faults. The Chainlink Base is an experimental (but unsupported) controller design that adds some additional functionality. This has been tested and appears to work, but is not recommended for general use.
The Chainlink Base PCB is an optional alternative to a Chainink Buddy, designed for particularly large displays. It hosts the ESP32 and adds additional connectivity options (terminals for UART and RS485 serial) and power distribution (independently-monitored power channels for multiple "zones" of Driver boards).
Key features:
Latest auto-generated (untested!) artifacts:warning::
:warning:There are currently no stable releases of this board, and none are planned. Some past variants of this board have been used, to some success, but it is not considered an officially supported design
The Classic driver board is deprecated and unsupported.
The Classic controller board was designed to plug into an Arduino like a shield, and could control 4 stepper motors. Up to 3 driver boards could be chained together, for up to 12 modules controlled by a single Arduino.
The driver uses 2 MIC5842 low-side shift-register drivers, with built-in transient-suppression diodes, to control the motors, and a 74HC165 shift register to read from 4 hall-effect magnetic home position sensors. There are optional WS2812B RGB LEDs which can be used to indicate the status of each of the 4 channels.
If you'd like to print your own flaps, or cut custom vinyl letter stickers, the project includes a script to generate vector design files that is extremely configurable:
TODO: finish documenting this and render some example images...
The project also includes a number of optional 3D printed designs to make assembly easier. These include:
All of these designs are parametric and customizable within OpenSCAD. To print them, open up the relevant file in OpenSCAD and use File -> Export -> Export as STL
to render the design as an STL file for your slicer.
This is not likely to be useful unless you're planning to manufacture dozens to hundreds of Chainlink Driver boards, but the Chainlink Driver Tester is a complete testbed for Chainlink Driver boards as they come assembled by the PCBA fabricator.
This is currently under very active development.
Key features:
Latest auto-generated (untested!) artifacts:warning::
:warning:There are currently no stable releases of this board, and there may never be as it is a niche production tool, not an end product. If you need this tool, you are likely actively involved in development and should understand the revision history and current status of development enough to make an informed decision about which revision(s) to use.
The driver firmware is written using PlatformIO with the Arduino framework and is available at arduino/splitflap/Splitflap/Splitflap.ino
.
The firmware implements a closed-loop controller that accepts letters as input over USB serial and drives the stepper motors using a precomputed acceleration ramp for smooth control. The firmware automatically calibrates the spool position at startup, using the hall-effect magnetic sensor, and will automatically recalibrate itself if it ever detects that the spool position has gotten out of sync. If a commanded rotation is expected to bring the spool past the "home" position, it will confirm that the sensor is triggered neither too early nor too late; otherwise it will search for the "home" position to get in sync before continuing to the desired letter.
The display can be controlled by a computer connected to the Arduino over USB serial. A basic python library for interfacing with the Arduino and a demo application that displays random words can be found in the software directory.
Commands to the display are sent in a basic plain-text format, and messages from the display are single-line JSON objects, always with a type
entry describing which type of message it is.
When the Arduino starts up, it sends an initialization message that looks like:
{"type":"init", "num_modules":4}
The display will automatically calibrate all modules, and when complete it will send a status update message:
{
"type":"status",
"modules":[
{"state":"normal", "flap":" ", "count_missed_home":0, "count_unexpected_home":0},
{"state":"sensor_error", "flap":"e", "count_missed_home":0, "count_unexpected_home":0},
{"state":"sensor_error", "flap":"e", "count_missed_home":0, "count_unexpected_home":0},
{"state":"sensor_error", "flap":"e", "count_missed_home":0, "count_unexpected_home":0}
]
}
(Note: this is sent as a single line, but has been reformatted for readability above)
In this case the Arduino was programmed to support 4 modules, but only 1 module is connected, so the other 3 end up in "sensor_error"
state. More on status updates below.
At this point you can command the display to show some letters. To do this, send a message to the Arduino that looks like this:
=hiya\n
The =
indicates a movement command, followed by any number of letters, followed by a newline. You don't have to send the exact number of modules - if you send fewer letters than modules, only the first N modules will be updated and the remainder won't move. For instance, you could send =a\n
as shorthand to only set the first module (even if there are 12 modules connected). Any letters that can't be displayed are considered a no-op for that module.
Whenever ALL modules come to a stop, the Arduino will send a status update message (just like the one following initialization, shown above). Here's what the fields mean in each module's status entry:
normal
indicates it's working as intended, sensor_error
indicates the module can't find the home position and has given up trying (it will no longer respond to movement commands until told to recalibrate - see below). panic
indicates the firmware detected a programming bug and has gone into failsafe mode (it will no longer respond to movement commands and requires a full reset of the Arduino to recover - should never happen).normal
state, it means the module successfully recovered from the issue(s). However, if this number keeps going up over continued use, it may indicate a recurrent transient issue that warrants investigation.If you want to make all modules recalibrate their home position, send a single @ symbol (no newline follows):
@
This recalibrates all modules, including any that were in the sensor_error
state; if recalibration succeeds they will return to the normal
state and start responding to movement commands again.
Looking to make some modifications or play around with the design on your local machine? Jump right in! Note that all of the scripts and automation are developed for Ubuntu. Mac OS support is planned, but not currently implemented (but feel free to open a PR if you want to help!).
The main design file is 3d/splitflap.scad
You'll need a recent version of OpenSCAD (e.g. 2015-03), which may need to be installed through the PPA:
sudo add-apt-repository ppa:openscad/releases
In general, solid objects such as the enclosure sides or spool components are built from 2d primitives and then extruded to the appropriate thickness for 3d rendering, rather than using 3d primitives. This simplifies the design without losing expressiveness; the perpendicular laser cut beam doesn't allow for cuts that vary in the Z dimension anyway.
Note that while the design is parameterized and many values may be tweaked, there is currently no error checking for invalid parameters or combinations of parameters. Please take care to validate the design if you change any parameters. For instance, while most of the design will adjust to a changed num_modules
value, certain values may cause some elements to intersect with other elements or protrude beyond their expected dimensions.
The design can be rendered to 2d for laser cutting by running 3d/scripts/generate_2d.py [--panelize <number>]
, which outputs to 3d/build/laser_parts/combined.svg
. The optional --panelize
argument allows for rendering a panel of modules in a single SVG, for bulk laser-cutting.
Internally, the design uses a projection_renderer
module (3d/projection_renderer.scad
), which takes a list of child elements to render, and depending on the render_index
renders a single child at a time. It also adds material to each shape to account for the kerf that will be cut away by the laser.
The generate_2d.py
script interacts with the projection_renderer
module by first using it to determine the number of subcomponents to render, then runs OpenSCAD to export each component to an SVG file. It does some post-processing on the SVG output (notably adds "mm" to the document dimensions), and then combines all components into the single combined.svg
output.
Once the combined.svg
file is generated, you'll want to double-check there aren't any redundant cut lines that are shared by multiple adjacent pieces, to save time/cost when cutting. They should be detected automatically (and highlighted in red in the rendering above), but it doesn't hurt to double-check. In Inkscape, select the "Edit paths by nodes" tool and select an edge to delete - the endpoints should turn blue. Then click "Delete segment between two non-endpoint nodes", and repeat this for all other redundant cut lines.
The design can be rendered to a rotating 3d animated gif (seen above) by running 3d/scripts/generate_gif.py
, which outputs to 3d/build/animation/animation.gif
The generate_gif.py
script runs multiple OpenSCAD instances in parallel to render the design from 360 degrees to individual png frames, which are then combined into the final gif animation. As part of building the animation, generate_gif.py
renders the design with multiple configurations (opaque enclosure, see-through enclosure, no-enclosure and no flaps) by setting the render_enclosure
and render_flaps
variables.
The design can be rendered to a series of STL files (one per color used in the model) in order to be displayed in an interactive web-based 3d viewer. Similar to the projection_renderer
used to render individual components for laser-cutting, the ColoredStlExporter detects all the colors used in the model and renders them one-by-one to separate STL files, along with a manifest that maps each STL file to its RGB color. The STL files and manifest are loaded using three.js to display an interactive model on a web site using WebGL. See this blog post for more details on how the export and three.js renderer work: OpenSCAD Rendering Tricks, Part 3: Web viewer.
All of the electronics are developed using KiCad 5. Panelization is provided by KiKit and gerber/BOM generation is provided by KiBot.
The mechanical and electrical design renderings and links above are automatically updated on every commit with the latest rendering. See this blog post for more details on how that works: Automated KiCad, OpenSCAD rendering using Travis CI.
The PCB layout can be rendered to an svg or png (seen above) by running electronics/scripts/generate_svg.py file.kicad_pcb
.
This uses KiCad's Python scripting API
to render several layers to individual svg files, manipulates them to apply color and opacity settings, and then merges them to a single svg.
For additional details, see this blog post: Scripting KiCad Pcbnew exports.
For reviewing the design, a pdf packet with copper, silkscreen, and drill info can be produced by running electronics/scripts/generate_pdf.py file.kicad_pcb
.
Gerber files for fabrication can be exported by running electronics/scripts/generate_gerber.py file.kicad_pcb
.
This generates gerber files and an Excellon drill file with Seeed Studio's naming conventions and produces a .zip
which can be sent for fabrication.
EESchema isn't easily scriptable, so to export the schematic electronics/scripts/export_schematic.py
starts an X Virtual Frame Buffer (Xvfb) and open the eeschema
GUI within that virtual display, and then send a series of hardcoded key presses via xdotool
to interact with the GUI and click through the dialogs. This is very fragile but seems to work ok for now. For additional details, see this blog post: Using UI automation to export KiCad schematics.
I'd love to hear your thoughts and questions about this project, and happy to incorporate any feedback you might have into these designs! Please feel free (and encouraged) to open GitHub issues, email me directly, reach out on Twitter, and get involved in the open source development and let's keep chatting and building together!
This project is licensed under Apache v2 (see LICENSE.txt).
Copyright 2015-2021 Scott Bezek and the splitflap contributors
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.