Electronics — PCB, firmware & wiring

Flip forward display modules are powered by a small controller board that contains an ESP8266, a stepper driver and plenty of auxiliary electronics and connectors.

The boards for controlling 28BYJ-48 and for controlling NEMA-Type steppers are physically different. You need to choose a motor type before getting a board and you can't swap motor types without changing the controller board.

The design goal of the controller board is to make a single module easy to control, and to let that scale to bigger installations without extra hardware. All boards come flashed with the flip forward firmware build for the stepper driver on the board - TMC2209 for NEMA-Type steppers or the ULN2003A for 28BYJ48 Steppers.

Installation

The board fits on the back part of the case. There's two designated mounting holes and you can use M3 Screws that go directly into the plastic.

28BYJ-48

For this variant, you only have to connect the 5-PIN JST Connector of the motor to the connector on the top right of the board. That's really it.

TMC2209 / NEMA

In this variant, you have to connect the motor wires to the screw terminal on the board. Use the below picture for the color order.

Please note that there isn't really a standard for the colors on NEMA motors, but so far, this color scheme has consistently worked. If it doesn't for the motor you're using, please reach out.

Connectivity

The board runs on 12V, and the power is injected either through one of the JST-XH 5 Pin-Connectors at the bottom of the board or through the dedicated connector for Flashing firmware. We recommend either using a standard flip forward connection board to inject power or using the Flash Board with Barrel Connector to inject 12V.

Each module draws up to 500mA and the daisy chaining has been dimensioned so that 3A can safely flow through the modules. Recommendation is to never power more than 5 modules from the same power injector.

The module is protected against reverse polarity, but the easy way to not inject power the wrong way around is to pay attention to the text on the PCBs - if it's all oriented the same way between connectors and the boards, you're fine.

Those power groups are also the fault containment for the whole display. Each injector board carries a TI eFuse, so an overcurrent or a short stays limited to the five modules behind it. Planning an Installation covers what that means for a permanent installation, and how a failed module affects the ones downstream of it. The specifications page has the voltages and currents.

Talking to the module

There are two designated ways to send commands to the module - using a serial connection through the dedicated Flash Board, or by connecting through WiFi.

Flash Board

When connecting the Flash Board it's imperative to connect both the 12V barrel jack, as well as USB. The Flash Board will show up as "flip forward programmer" - and you can flash the ESP or connect to it using a Serial Monitor - the baud rate of the firmware is at xxx.

WiFi

When power is applied, the LED of the ESP-Module shortly flashes in blue. After a few moments, a new WiFi is going to appear that bears the name "flip forward". You can connect to that and open a browser - it'll greet you with a setup page where you can home the module, configure the alphabet and so on. You can also enter your WiFi credentials there - the module will then connect to the specific WiFi. If the WiFi connection can't be established, the module will fall back to having an open WiFi that can be used to set new credentials.

note

WiFi is automatically terminated when commands are received via Serial - this is to ensure that there's not 50 open WiFis in the daisy chain setup of a larger installation.

Once connected, the module is reachable using any browser using its IP Address as a host, allowing you to interact with the module using the same web page.

Serial-over-HTTP

There's a second option, which is to use HTTP POST from a HTTP client (Curl, Postman) to directly send commands to the module. All requests have to go to http://HOSTNAME/command, as POST, with a form field called command containing the command to be sent - like 0:BLINK to make the receiving module blink its LED.

An example in curl looks something like this

curl --request POST \
  --url http://IP/command \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data command=@:SHOWWORD:%m

This option is great for writing integrations.

Protocol Design

The protocol that the modules use to communicate between each other is almost human readable, simple and efficient. The good news is that there are facilities that ensure that it's always human writable.

Making modules addressable

A lot of open source split flap designs use established protocols, such as I2C, to communicate to multiple modules. We're taking a very different approach - the daisy chaining in the flip forward world is simply achieved by hooking up the transmitting serial pin of Module N to the receiving serial pin of Module N+1. In turn the transmitting serial pin of Module N+1 is connected to the receiving serial pin of Module N+2 and so on. That also means that communication is unidirectional.

Individual modules are simply addressed by their relative position. If my first module is connected to a computer via Serial, issuing a command for module 0 means: the first module. Issuing a command for module 1 means the next module (N+1).

Message format

The messages that are sent between modules always have the same format:

• One magic byte to indicate the begin of a protocol message
• Two bytes that contain the length of the message
• One byte module index
• Payload

The payload itself encodes the command, and this part is always human readable:

0:COMMAND:ARGUMENT

The first part is the module the command is intended for. 0 means the relative first module, 1 the second and so on. If you want to run the same command on all modules (i.e. run a firmware upgrade), you can replace that with @ and it'll be executed by all modules receiving it.

Some commands do have an argument, others do not, see the list below.

If you're sending commands directly to the module, either via Serial or WiFi/HTTP, you can simply use the format above and the firmware will translate it into the protocol version.

The protocol is intended to be really fast - the messages actually transmit instantaneously, while still retaining some form of readability - we want debugging to be fast and not needing other tools than a HTTP client or a serial monitor.

Supported Commands

Name	Meaning	Arguments	Comments
BLINK	Blinks the diagnostic LED	—	For diagnostics
DISPLAYCHAR	Moves the display to show the indicated character	Char to display, e.g. c or C. Will automatically uppercase.	—
SHOWWORD	Shows the word in the argument	—	Always addressed to all displays (@) for performance reasons.
MAXSPEED	Indicates the speed at which the display moves after accelerating	1–200	Start high, go lower if something doesn't work.

Examples

What	How
Make the receiving module blink	0:BLINK
Make all connected modules blink	@:BLINK
Make the N+1 module blink	1:BLINK

Homing and First Use

The only mandatory step is to home the display after assembling it. This is the process of teaching the firmware where the magnet is in relation to the characters in your display.

The firmware supports a homing mechanic called smart homing, since it takes up to 5 samples and asks you which character you're seeing - and then determines the homing position based on that. It's more robust than taking a single character and the flap point (i.e. the point at which the character changes).

You start smart homing by issuing:

N:SMARTHOME:3

(or 5 if you want 5 samples, but three is usually fine)

You then wait until the display comes to a rest and type which character you're seeing:

N:SMARTHOME_CHAR:X

You do that for every sample - the display will then automatically move to Blank (if that's in your character set) and you're done.

This mode is also supported on the diagnostic web page.