Today’s tale of being in the right place at the right time comes from [fabe1999], who was doing an intern gig at the airport when the controller on their split-flap display bought a one-way ticket going south. They were just going to throw away thousands of these letters and replace them with monitors, but the intern intervened.
[fabe1999] grabbed an armload, took them home, and set about making them flap again, one letter at a time. An ATtiny worked okay, but it wasn’t really fast enough to flip them at their full clacking potential, so [fabe1999] switched to an ESP8266. So now there is one ESP for each of the 20 characters, and another that runs a web server where text can be directly entered for immediate display.
Each letter uses two sensors to flap to the right letter. The first one acts as a start sensor, detecting the blackness of a blank character. Another sensor counts the letters and makes the ESP stop the motor on the right one. So far, [fabe1999] hasn’t figured out how to recognize when a blank character can stay blank, so they flap all the way around back to blank for now. It certainly adds to the rich, flappy sound, but that can’t be good for the long-term life of the letters. Your flight is now departing for Post Break Island, where the letters are spending part of their retirement showing song titles from Spotify.
No chance of split flaps falling into your lap? Here’s a tip: you can fab your own flip.
I know it would drive you crazy to have this operating in your home (or office)… but I want it anyway!
I made an electromechanical seven segment combo wifi connected youtube sub count/clock a little while ago and left it running in my bedroom for a month and as cool as it was it started driving me insane so I had to relegate it to my home office.
At south station in Boston they have a modern display sign for the departures and arrivals, so they play a recording of the flap flap sound when the sign changes.
Is this really green? I mean “I recycled something to burn a lot of energy doing a task that has no real benefit to anyone” is still technically recycling, but hardly good for the planet.
I highly doubt its used 24-7 and Im pretty sure it doesnt really take that much power to run.
In theory, it should have quite a low idle current when the display is not changing. (If it was done even halfass right, but no guarantees with this one by the looks) so therefore it may use less than even just inch high LED letters, or other similar scale display technology for a change every 4 mins. But yah, tablet screen is already doing it really, so unless there was a pressing need to announce the info to a scattered audience it’s not doing much good.
your comment will consume more power than this sign when hackaday’s readers bring it up in their browsers.
Wow cool fact. Did you make it up yourself?
> one ESP for each of the 20 characters
Sorry, but that is some impressive embedded systems design fail. Let us never make fun of a Raspberry Pi being used to generate a square wave again.
at $1 each it seems like a perfectly good design decision to me, $20 to drive 20 letters.
Here’s a free hint for you: stuff that would be silly in a product is perfectly acceptable in a one-off design.
> stuff that would be silly in a product is perfectly acceptable in a one-off
Sure, if someone is paying you to do it, but this is an amateur project, and I have higher expectations for quality when something is done for its own sake rather than to pay the bills :D
doesn’t make it 1% less bad though
lets not forget plenty of 1 off designs became the revolution that we now enjoy, and in a future of 100% bad design is kind of why we need a freakin micro that has more horsepower than the AGC in our toasters, when sunbeam did it better 80 years ago with a bit of heat sensitive wire and plates
I gather from the reddit thread that the high level code is barely able to keep up with one number flipping in real time, hence one MCU per character.
Thanks – interpret overhead makes sense as a likely culprit. I figured it was something like that or some kind of total debouncing fail making it generate a zillion interrupts. I was like… any modern MCU should be able to keep up with twenty mechanical things flipity-flapping on a 1-10ms timescale….
Though remembering the older uses of these, they always changed sequentially so maybe had an 8 bit concentrating on one at a time, even though it was one per input.
It still seems to me that a 32bit demux could do it yes? The ISR routine has to be really simple but in my experience making other ridiculous electromechanical boards, you can poll OR generate at appx 100khz with an ESP as long as you have the right IC’s providing input or output.
It seems to me you could just poll the demux at max speed and call the ISR when you have a hit to add +1 to a register with raw bitmath. you can manually debounce by requiring a min number of negative polling events (at 100khz it would be a lot).
It would be a little more than just 2 lines of code in the ISR which would reduce the polling rate but I don’t think you would need to poll faster than 50khz or so, that would be BLAZING fast in terms of letter speed.
These display were originally designed this way, with one MCU per character. But it is a much lower end MCU without embedded Wifi.
For example, in some Krone branded displays, it is a 4-bit Hitachi HMCS44C, running at 400kHz.
It’s much more simpler to design this way: you don’t have to monitor a crazy amount of IRQs (2 IRQs per character: home position, and sheet/flap detection) occuring randomly and almost simultaneously. And also, you avoid a single point of failure: one failed MCU = only 1 failed character.
I’ve also tried to drive 20 displays, and thought it should be easy to control all of them with only one modern MCUs.
In my Krone’s displays, it takes 60ms between 2 sheets, which seems not really fast and complicated to deal with.
But the motor is synchronous, so synchronised to main’s frequency. That means that every characters are spinning almost simultaneously. In consequence, i’ve measured that between only 2 displays, sheet detection/IRQ is occuring at an interval of only 100µs or less.
With an Arduino Mega, i can barely drive 2 displays before i start missing counting some sheets from time to time, because of too many simultaneous IRQs. And also i don’t have enough interrupt pins for 20 displays.
I’ve then switched to an Arduino Due with 54 digital interrupt capable pins. But with only 4 displays, i still not react rapidly enough to count sheets correctly and stop rotation early enough.
I’m not a MCU nor electronics guru, so may be i’m doing something very wrong. But i was seriously thinking about going the same route with 1 MCU per display.
My tries were a little more than one year ago, but since then, i’ve not had time to try again. And i’ve not documented it on the Internet neither. Too bad otherwise i could have been that guy granted by an article on Hackaday ;-)
It seems like the difficulty comes from trying to service all these as separate interrupts immediately, as soon as they happen. If you can defer servicing an interrupt just long enough to finish servicing the previous one, then you can use that more relaxed 60ms window for handling an interrupt from any given display.
A priority encoder chip like the 74HC147 would be a way to do this. This takes ten input lines and outputs the largest index of the inputs that are set LOW, as a 4-bit number. You’d also want to use a flip-flop (as in single-bit registers) to extend the pulses from the sensors. When the sensor trips, the signal should go LOW. The signal should stay LOW until it is reset by the MCU, ideally indexed through a demux IC.
You’d use only one of the MCU’s interrupt lines, and this tells you when the priority encoder has *any* of its inputs set. Your MCU should then read the outputs of the priority encoder, which will tell you which stored counter value to increment as well as which flip-flop to send a reset signal to. After sending the reset, check the priority encoder again. If it still has any input set, repeat this process until none of its inputs are set.
Interrupts are not the right solution for everything.
In this instance, it’s better to use polling. Finite State Machines help too.
Use a fast bit library, or connect sensors to a single port that can be read in one go.
Have two arrays, with as many elements as pins to monitor. One array is for the previous status of the pin (0, or 1) and one for a debounce timer.
Initialize both arrays to 0.
Read the pins, either one at a time or all together.
do for all pins:
If the value read for one pin indicates it is active:
1) if the value of the corresponding element of the status array is 0, trigger the desired action for that pin activating (zero the position variable or increment the variable for value currently displayed)
2) set the status array to 1 and set the debounce timer value for that element to a constant (lets say 250). This prevents this pin from triggering the action again until the value has been inactive for a while and then another activation event comes in. Start small and increment the debounce timer until an event is counted only once.
If the value read for that pin indicates it is not active:
1) If the value of the element for the debouice timer is 1, set the value of the element in the status array to 0
2) if the value of the element for the debounce timer is greater than 0, decrement it.
now the code has time to read the serial port or do some other processing related to receiving from instructions from the master (don’t take too long here…)
process the next pin.
An optimization would be to merge the status and debounce arrays and instead check the debounce array for zero or non-zero values for the previous status logic and decrement its value for the debounce logic.
I think this depends on your loop to be faster than the pulse time that comes from the sensor. Using an interrupt would let the microcontroller do other work while waiting for pulses. Gérald mentioned that the pulses come bunched together because of the synchronicity of the motors, which IMO makes this not an ideal situation to use polling.
Also if you’re using a micro you’re definitely reading the pins one at a time. You’d have to use an FPGA to read them all together. Eventually you’ll run out of GPIO pins if you want to add lots of character units. If you don’t get tangled up in their individual sensor wires first, or get tired of picking up false positives from the nearby radio tower.
A more robust and scalable way to control the displays is to configure each unit to receive a simple “set character” command issued by the main controller, and count up to that character on its own steam. You’d also want to put the displays on a shared bus, and make them addressable. The protocol could be something simple like a parallel bus, or it could be a serial connection like I2C to keep the wire count lower. You’d only need at most log(N) wires instead of N; and thus wouldn’t have to go looking around for some kind of Arduino MEGA Mega with even more pins.
Interesting suggestion! I didn’t heard about priority encoder before. Will investigate that. Thanks!
Connection between Raspberry Pi and Spotify is available if you get the Spotify Audio Converter from AudFree. It is OK to get the Spotify music files via the tool. Thus, you will be able to sync the songs to your device. Thins are not difficult for the streaming Spotify on Raspberry Pi or otehr devices of yours.
Connection between Raspberry Pi and Spotify is available if you get the Spotify Audio Converter from AudFree. It is OK to get the Spotify music files via the tool. Thus, you will be able to sync the songs to your device. Thins are not difficult for the streaming Spotify on Raspberry Pi or otehr devices of yours.
This is going to be the next Nixie.
It should be easy to avoid unnecessary flipping by keeping track of current position for each letter. You only need to search for the blanks at power up.