I’ll let this post start with a German proverb “Not macht erfinderisch” - necessity is the mother of invention :)

Fluorescence Simulator & Firmware version 3.0

The #VFDCo Studio is locked down due to the Coronavirus pandemic. It’s where I keep all the electronics and testing equipment for Fluorescence by The VFD Collective, the IV-11 VFD digital clock. Also it’s where the upcoming firmware version 3.0 for it is being made, secretly. But in these times it’s always a better idea, no, it’s our responsibility to stay at and work from home. So… this is me, now cut off, writing the software for hardware that I can’t test. Sounds lame huh? That’s what I thought, until I realized I should really be writing a Fluorescence Simulator that could just fake the physical presence of Fluorescence. That’s what I did (hence the proverb). And that’s what I wanted the simulator to be:

• A graphical interface

• Each and every feature on the physical Fluorescence by The VFD Collective must also be implemented in the Fluorescence Simulator

• A helpful and developer-friendly environment for analyzing and tracking. Monitor every important value used in Fluorescence at any time with sufficient documentation

• Low maintenance & robustness to changes made in the firmware. If something new is added in the firmware, there is no need to change the simulator accordingly - or is kept to bare minimum

This is how Fluorescence Firmware 3.0 works

Caution: Geek chat ahead. Before I tell you what the overwhelming amount of numbers and lists in the simulator program mean, let’s first clarify how the new firmware version 3.0 works. When Fluorescence is up running, the main processor communicates with its device drivers. There are a quite a bunch of them and each device has its very own driver:

Look up the source code files I’m talking about in the GitHub repository of The VFD Collective

• vfdco_display.h: (VFD) display driver

• vfdco_led.h: LED lights driver

• vfdco_time.h: Real time clock driver. Used to keep track of time

• vfdco_hid.h: Human interface device driver. Used to detect button presses

• vfdco_com.h: Communication driver. Enables USB and Bluetooth communication

• vfdco_serialization.h: Serialization driver. Makes sure the clock remembers its settings

• vfdco_mic.h: Microphone driver

The real time clock driver for example asks the real time clock (RTC) what time it is, sends the time it got to the processor, and the processor tells the display driver to show 9:37 PM.

However, the display functionality shouldn’t stop at showing time. We want it to show date, messages, and most importantly make sure that time can be changed just using the button controls. Way too much to ask for a device driver to do, so firmware 3.0 builds a class (application specific class library) around it, namely GUIs, in vfdco_gui.h, to provide a more abstract way to telling what the display should show. So instead of talking to the display directly, we tell it to show the Time GUI, the Time Setter Menu GUI or the Stopwatch GUI. The GUI class takes care of what needs to be send to the display automatically.

Since memory is a very limited resource on a microcontroller, there always is only one active GUI called global_gui_instance.

Similarly, a class is built around the colorful lights of Fluorescence and instead of setting LED pixels directly, the class Light Patterns take care of LEDs comfortably so that you can set a Rainbow Light Pattern, a Spectrum Fade Light Pattern or a Sound Reactive Light Pattern. Again, only one light pattern can be active at one time.

Now let’s talk about the main processing function, the main clock management called vfdco_display_routines. It has access to all parts (drivers and the two class instances), is the glue that keeps them running together and calls the right part at the right time. When the user asks to change the light pattern from single color to rainbow fading, the clock routine does the switching. Switching itself is straightforward as we just need to clean up the old data and initialize the new light pattern we want. But the clock management also grabs the settings (like saturation) of the old instance and finds and loads the settings of the new instance and there are a whole lot more things that keep settings, class instances and drivers in sync, so the code in vfdco_display_routines gets a bit uncomfortably large.

This is how Fluorescence Simulator works

Awfully bored or super excited? Either way we’re now ready to learn why Fluorescence Simulator looks how it looks like and how it works. Here’s how it looks like:

And here’s how it works, component-wise:

• GUI Display Monitor: This is what the functions inside GUI class produce and what is being sent to the display. Visualized as a six digit teal seven segment display that reminds of real IV-11 VFD, with additional info about the segment binary values. Updates every millisecond

• Lights Monitor: This is what the Light Pattern class produces and what is being sent to the LED lights. Visualized as ugly rectangles that somehow resemble LEDs, with additional info about the RGB+white color value displayed as decimal and hex color code, in HSL space and its power utilization percentage. Updates every millisecond

• Raw Monitor: Displays the actual memory content of the two class instances global_gui_instance and global_light_instance. Updates every tenth of a second

• Settings Monitor: Lists all settings used in Fluorescence (*). By clicking a setting, its description and value is shown. Updates every tenth of a second

• COM: Send commands to the simulated Fluorescence and receives data from it. Protocol exactly implemented according to the 3.0 documentation (reads in the CSV exported version of the documentation). Receiver updated every tenth of a second.

• Controls: The buttons F1 to F4 like in Fluorescence. The + version (e.g. F2+) corresponds to a long press

• Power: Monitors the dimming factors of the display and the lights. Dim factors don’t have visible effect on the simulator unless ‘Visualize dimming’ is checked. Updated every tenth of a second

• Simulation: Start, halt and re-load the simulation. Enable or disable dark mode. Use the clock div to lower the simulation speed (slow-mo simulation)

So what’s the biggest gain out of the simulator? It’s certainly better than nothing and it was fun to create! Also, if you want to work on your own version of the Fluorescence/OpenVFD 3.0 firmware without an actual clock, you know the simulator will be right by your side - and I’m very sure it will help you a lot! As the firmware and the simulator is in development and being updated continuously, I won’t be providing a compiled version at this time. Feel free, however, to tear it apart and compile it yourself using Qt, I promise it’s fun, too. Here’s the simulator project on The VFD Collective repository:

That’s it for now, and I’ll get back very soon with more dev content and exciting updates coming to Fluorescence by The VFD Collective. Cheers and have a sunset picture from home 🌻.