Museum and Demo Controller

[drew.baker]

I thought I would drop this here for those that might be interested.

I wanted to have an automated demo/attract mode for the Enigma Touch to put on display in my office along with all my other "blinkies" (PiDP's  Altair, Kenbak's, etc) 

This project started off as an ESP32 controller patched into the Enigma Touch serial port which connected to my Home Assistant that allowed me to send weather reports, etc to the Enigma over WIFI.  The drawback to this was it required modification of the Enigma Touch and was not a "User Friendly" solution.  The Limited computing power and available IO on the ESP32's limited the ability to control more than one Enigma Touch for some of the fun Ideas I had in mind.  I decided to abandon the ESP32  and move to a Raspberry PI which can provide additional IO for multiple Enigma Touch simultaneously, does not require any modifications to the Enigma, and can provide enough power via USB to run and charge the Enigma without modifying the ESP32 or Enigma.

This is a work in progress and far from complete but tossing it out here now that it works "good enough".  I still have to update the documents and clean it up a bit more.

What it provides:

* Museum/Attract mode - Pulls from a bank of messages that are user definable.

* Curses Local Display for debugging and visualizing messages encoded/decoded

* WebPage showing status of message encoding/decoding, future todo will be adding a slideshow that can be configured to also display information and history with messages.

* English and German modes (I don't speak German, so forgive any sins AI might  have made in the translations)

* All encoding and decoding is done by the Enigma Touch itself. Yes I could port the Enigma Ciphers to Python but that defeats the point and is no fun.

I want to add some 2 way modes using 2 Enigma Touch devices along with Web interfaces, as well as the historic slide shows. 

One thing that I forgot to add to the documents so far is the need to ensure that the Enigma Touch has been configured to either the 4 or 5 Full rotor position logging mode. 

|  |      |  |

 4        5

"Input, output and rotor position are logged, on a new line for each letter typed. This lets you follow the complete encryption or decryption process. Empty lines are inserted after every four or five keystrokes"

I've tested this with Firmware 1.12

I've tested it on a ChromeBook, MacBook, And Raspberry PI 1,2,4,5.   It works on all, however I would use a Pi 2 at least to avoid obnoxious flicker on local display.

Project is open source, Feel free to comment, suggest, fork, etc. 

https://github.com/dotelpenguin/enigma-touch-museum

[Jürgen]

Hi Drew,

Wow -- that's impressive work, thank you very much for sharing!

I very much like the idea of driving the attract mode externally. If an external host is required anyway to control the printer, it might as well do the "typing" in attract mode. Makes it much easier to provide a nice management and configuration interface for setting things up!

The only thing missing for a "museum mode" for public access is a restriction of the configuration options -- e.g. stop the visitors from setting a different machine type. (Not required for displaying the Enigma touch at home, of course.) I will still need to implement that in firmware. But it could just be enabled and disabled via USB serial commands, so the external "museum mode controller" can set this up as required. While I am at it, I should implement USB commands to set the desired logging format via USB too; then the external host can control this as well.

I still need to close the loop with the museum which had originally asked for this mode. I just nudged them again and hope to have their requirements very soon -- and would then get an updated firmware underway.

Best,

Jürgen

[drew.baker]

> The only thing missing for a "museum mode" for public access is a restriction of the configuration options -- e.g. stop the visitors from setting a different machine type. (Not required for displaying the Enigma touch at home, of course.) I will still need to implement that in firmware. But it could just be enabled and disabled via USB serial commands, so the external "museum mode controller" can set this up as required. While I am at it, I should implement USB commands to set the desired logging format via USB too; then the external host can control this as well.

This would be great,  Currently I have an optional setting to reset the machine type, rotors, and ring setting prior to processing a message, this is a work around to ensure the encoding is correct, but changing the logging type WILL break everything. Locking the settings and allowing the logging type to be configured by serial would solve this.  Adding a print function wouldn't be that hard either. The script already calls a function to parse and analyse each character returned when Encoding/Decoding it would be a trivial change to optionally pass the results off to a new function to output to a printer.  I don't have any label or continuous feed printers to test with but as long as it's some form of standard protocol I don't see any reason it couldn't be added. 

[Jürgen]

Ok -- I guess when I get to this, I should implement USB commands for all the replica-specific settings in the "Modell" setup mode: Sound volume, lamp brightness, and logging mode. And for public display scenarios, at least a USB command which locks (or unlocks) access to the "Modell" settings entirely, and maybe additional commands to lock the Rotor and Ring setups as well?

But I'll need to prevent the possibility of locking yourself out: Sending the USB command to block touch access to the Modell mode, then setting the USB mode to keyboard emulation, would be a path of no return...

[drew.baker]

>Ok -- I guess when I get to this, I should implement USB commands for all the replica-specific settings in the "Modell" setup mode: Sound volume, lamp brightness, and logging mode. And for public display scenarios, at least a USB command which locks (or unlocks) access to the "Modell" settings entirely, and maybe additional commands to lock the Rotor and Ring setups as well?

For Kiosk/Museum mode I could see these being very useful.  Personally for my office display I just mounted a small switch on back of case for the speaker on sound.  I like the "ka-chunk" sound, but since mine would be "ka-chunking" every 2s 24/7 I needed to consider my long term sanity.  From a simplicity standpoint I would just make an enable/disable by USB mode for the three Modell/Rotor/Ring buttons on the hardware. Modell being the most critical, as far as somebody changing the Ring Position in Attract mode I think that is fine.  Since the Enigma Touch reports the ring positions when encoding the attract controller can easily compensate and reset it back when attract starts again. Touching any of the letter keys would break or stop any encoded message in progress anyways. If we make a mistake encoding while in attract mode it's not mission critical and I doubt anybody would ever even notice. If some kid visiting the museum actually figures out the encoding error then we have just identified either the next genius engineer or possibly super villain. 

>But I'll need to prevent the possibility of locking yourself out: Sending the USB command to block touch access to the Modell mode, then setting the USB mode to keyboard emulation, would be a path of no return...

I can see this happening, Tho I believe the demographic that would be at the highest risk of accidentally locking themselves into this "path of no return" by playing around with the USB mode is also going to be the same demographic that would be able to easily re-flash new firmware back on the device to fix it. Personally I would just make the documentation clear that if you choose to enable keyboard emulation AND lock the settings that restoring the firmware is your only out. At least for the quick/first iteration of the museum/attract firmware release.  I don't know how the power button is being latched by the STM32, and if it could detect a long keypress to reset settings or not.  If that can be done, I would modify a special "Museum/Kiosk" version of the Enigma Touch hardware, and simply solder the power switch as a normal surface mount (currently it is mounted upside down through the PCB), or make it a pin header with external button lead that can be mounted away from the public's curious fingers. This way if it's in a public venue staff can reset it and it would prevent the public from turning it on or off.  

[Jürgen]

Alright, looks like we have a plan. I think I should just get to it!  With your concept, the external host has so much flexibility in how it wants to shape the "museum mode" that this should satisfy various needs of private or public displays.

Adding USB commands to control volume, brightness and logging format should not be complex. The main challenge is to come up with a set of somewhat consistent two-letter commands -- my lazy choice of command syntax has created a bit of a bottleneck there...

To avoid a "locked myself out" situation, it should be enough to offer only the USB serial modes (but not keyboard mode) when setting the logging mode via USB, right? And make USB commands the only way to lock touch access to the "Modell" setting mode. 

When someone touches a key while attract mode is active, wouldn't that immediately end attract mode and go back to interactive operation anyway? So it could not "mess up" the current message in attract mode, but would just stop it. This is under control of the external host of course, so different behaviors could be programmed there. -- Oh, but: How does the external host detect that a key was pressed, i.e. that an output character in the USB serial data stream is not in response to a host-generated input character but to a physical keypress? Would you need some kind of indication to tell the two apart?

Good point about the power button -- that's bound to be the first thing some curious kids press! The "power" button on the Enigma touch is actually a Reset button, and the firmware decides (based on the prior state) whether it powers up the replica or sends it into deep sleep. So I could simply add a USB command which disables the "power off" function of the button. Powering off could then be done either by removing the external 5V supply (assuming that there is no battery), or via another USB command. No dedicated hardware variant needed.

(For a public display setting, we would have to assume that the USB and +5V supply connection is "physically secure". It could come in from below, via the solder pads on the PCB, with the replica bolted down on a stand. Private display installations could use the regular USB connector in the back, of course.)

[drew.baker]

To avoid a "locked myself out" situation, it should be enough to offer only the USB serial modes (but not keyboard mode) when setting the logging mode via USB, right? And make USB commands the only way to lock touch access to the "Modell" setting mode. 

That would work for the use cases I had in mind for a Museum/Display scenario.  If somebody wants to hookup a printer or use a keyboard output to simulate something via printer or other Kiosk that might be an issue. I can't think of a practical use case for locking/unlocking it without USB mode unless a full Attract mode is added to the Enigma Touch firmware. 

 

When someone touches a key while attract mode is active, wouldn't that immediately end attract mode and go back to interactive operation anyway? So it could not "mess up" the current message in attract mode, but would just stop it. This is under control of the external host of course, so different behaviors could be programmed there. -- Oh, but: How does the external host detect that a key was pressed, i.e. that an output character in the USB serial data stream is not in response to a host-generated input character but to a physical keypress? Would you need some kind of indication to tell the two apart?

I just realized that this morning as I was playing with the code. I believe I have a solution for it tho.  I planned on reworking the message "pre-encoding", to generate in advance a JSON file that includes all the sample messages, their settings (Model, Ring, Reflector, etc), and encoded results. The original intention for this was to allow a simulation mode if the Enigma Touch was not connected, and to restore the proper spacing in message after it's been broken into 4/5 chr groups. I also wanted to add the ability to have coded messages using different Models and rotor settings, currently they must all be the same.  This will also give the host the ability to detect if it's received a response that was not expected as next character. It has a 1/26th chance of being wrong if somebody hits the exact character it's expecting and not detecting it, however doing this would also cause the rotor position to advance, invalidating the rest of the cipher anyways. Worst case there is a single character delay in exiting attract mode (in theory maybe 2 if the statistics hit just right).

 

Good point about the power button -- that's bound to be the first thing some curious kids press! The "power" button on the Enigma touch is actually a Reset button, and the firmware decides (based on the prior state) whether it powers up the replica or sends it into deep sleep. So I could simply add a USB command which disables the "power off" function of the button. Powering off could then be done either by removing the external 5V supply (assuming that there is no battery), or via another USB command. No dedicated hardware variant needed.

Yes, currently the script doesn't handle turning off the Enigma Touch or disconnecting it gracefully.  It will simply exit, wait 5 seconds and relaunch. I would want to use the "Simulation" mode to take over in this event and try to reconnect in the background. It would just be parroting the message file, not doing any encoding/decoding. 

 

(For a public display setting, we would have to assume that the USB and +5V supply connection is "physically secure". It could come in from below, via the solder pads on the PCB, with the replica bolted down on a stand. Private display installations could use the regular USB connector in the back, of course.)

This would be J2 - USB? Does this also provide power or just USB host serial?  I have batteries in both of mine.  I have only used the USB-C connector to power/charge and control it.   Just removed the battery in one of mine, looks like a Raspberry PI 2, 4 and 5 (I don't own a 3) power it just fine without a battery over USB while also in USB mode.  Doesn't look like the Raspberry Pi 1 can tho. I have a 2.5amp PSU on it, and the Enigma Touch flickers and reboots when I send commands to it over USB. Probably was borderline on power and the battery  was helping smooth out the drop. Not a big deal, I think making a PI 2 the minimum requirement won't impact anybody.  Yes Always assume visitors will try everything you couldn't possibly think of. (Previous Job was developing public information and safety  kiosks)

 

[Jürgen]

Yes, J2 (USB) is wired fully in parallel with the USB-C jack, so you can also supply +5V there. On the other hand, if you don't want to draw power from the USB host, you can use the dedicated solder pads J6 to supply +5V. (Just below the power button and jumper JP2.) In that case, you can cut jumper JP1 to disconnect the power supply via J2 and the USB-C  jack.

The Enigma touch only draws ~ 40 mA for CPU and display operation. If a LiPo battery is installed, it can take an extra 200 mA of charging current. And the audio amplifier can draw peak currents of a several 100 mA, depending on the volume setting (front-panel control and pot on the back). Probably the latter was what brought your Raspberry Pi 1 power supply to its knees -- if so, sending characters to be enciphered should have caused problems, but sending other commands should not.

Some straightforward way to detect whether the user has pressed a key would be nice to support museum mode, and attract mode in particular. E.g. the Enigma touch could send the ciphertext as either upper- or lowercase characters, depending on whether it is in response to input via the touch keys or USB. Would that work, or does it look ugly for those who use  the USB serial mode directly (interactively)?

[drew.baker]

On Wednesday, December 3, 2025 at 10:55:16 AM UTC-5 Jürgen wrote:

Yes, J2 (USB) is wired fully in parallel with the USB-C jack, so you can also supply +5V there. On the other hand, if you don't want to draw power from the USB host, you can use the dedicated solder pads J6 to supply +5V. (Just below the power button and jumper JP2.) In that case, you can cut jumper JP1 to disconnect the power supply via J2 and the USB-C  jack.

Understood, yeah for simplicity I would think powering it over USB would be the best for most public displays. Either from USB-C if it can be secured, or the pads under to completely hide it. 

 

The Enigma touch only draws ~ 40 mA for CPU and display operation. If a LiPo battery is installed, it can take an extra 200 mA of charging current. And the audio amplifier can draw peak currents of a several 100 mA, depending on the volume setting (front-panel control and pot on the back). Probably the latter was what brought your Raspberry Pi 1 power supply to its knees -- if so, sending characters to be enciphered should have caused problems, but sending other commands should not

Verified, PI 1 doesn't have issues if I mute the speaker.

 

Some straightforward way to detect whether the user has pressed a key would be nice to support museum mode, and attract mode in particular. E.g. the Enigma touch could send the ciphertext as either upper- or lowercase characters, depending on whether it is in response to input via the touch keys or USB. Would that work, or does it look ugly for those who use  the USB serial mode directly (interactively)?

Good question,  Would be a simple solution tho.  Lower case for direct keyboard input and UPPER for USB.  I would guess that people using it directly via  USB will rarely press keys on the device.  Tho who knows, I'm sure there are are lots of people using this is ways  you never imagined.   One benefit  would be making it easier to write something that allows simpler 2 way communication.  You could make a more interactive interface with greatly simplified logic.