Hardware Testing "the other 83%"

The first task was to get some SMART Response XE devices. They are readily available on eBay.

All of the devices were purchased as sets of 32 to 40 devices and all were described as "working when removed from service". The problem was that "service" was back in 2011-2014. Worse still is that most of them were unceremoniously stuck in classroom closets with the batteries still inside. I took a guess that 25% would be worthless.

Before I knew what I had done I had over 500 devices arriving. I have a few really bad orders and received refunds  a also had three orders which contained NOS (new original stock) still in plastic wrap and never having batteries installed.

All I could do was visually inspect the devices when they arrived, remove any dead and often corroded batteries, perform some cleaning, and see what happened with new batteries.

What I really needed was a thorough smoketest for all the hardware. The test needed to cover everything and especially anything where corrosion could be.

SRXEcore Library and the SPI Development Adapter 

I located a few different open source code bases for the SMART Response XE hardware. I then set about to find the most up-to-date code. I merged from a couple different sources (being sure to include credits for original authors and sources). I then standardized the functions, added in some missing pieces, tested everything, and wrote full documentation.

One useful feature of the SRXEcore library is its "multi-personality" printf() functions. The printf() functions draw heavily from "tiny printf". However, the output of the print function may be directed to the LCD screen, the UART (see below), or the RF transceiver!

This was the genesis of the SRXEcore. To this library, I added font management and a series of higher level UI features specific to the SMART Response XE hardware.

The final step for the SRXEcore was to write a smoketest for all the SMART Response XE hardware. The test needed to verify the SPI interface, the LCD display, every key of the keyboard and the menu keys, the power button, internal FLASH chip, and the RF transceiver.

(the smoketest is included with the SRXEcore as it's "sample program")

Since there were a lot of SMART Response XE devices to test, I need an easy way to reprogram the devices. It was paramount to do this as easily as possible. Opening the case of every device was out of the question. Thankfully, the SPI GPIO pins of the ATMega128RFA1 are exposed through pads and hole in the battery compartment. 

There are 10 pins exposed from the battery compartment. SPI only needs 6. The other 4 were tied to JTAG but with a FUSE setting, they could be general purpose.

I revised the SRXEcore to include a bit-bang UART on one of the spare GPIO pins.

Armed with all of this data I designed a programming adapter. It has the 10 long pogo pins on one end, with a layout to match the holes in the SMART Response XE case. At the other end is the SPI connection. The remaining 4 GPIO are connected to a standard 0.1" header and LEDs (useful for debugging).

I tested over 500 devices with a failure rate of approx 17%. Most of these failures were directly attributed to corrosion on the PCB. There were some reoccurring failures. For example, a corroded trace would often cause a row of keys not to work. Corrosion around the interface pads or their traces resulted in flashing failures. A few were just DOA.
The smoketest resulted in 420 "good" devices.

Much later in the project, I found a need for getting screenshots from the SMART Response XE for writing documentation. The LCD driver supports reading but that capability was never exposed. I solution was to create a "renderer" in python.

The python screen grabber program runs on a computer and connects over UART to the bit-bang output from SRXEcore. When enabled, the SRXEcore streams commands over UART which mirror the updates to the LCD. The python code processes the stream to render its own bitmap replica of what appears on the LCD. The process is horribly slow but very effective.

The SRXEcore documentation is very extensive and covers all of the API, the smoketest, the python screen grabber, and the python font converter tool.

Enigma API

Similar to the SRXEcore, the Enigma API was based off existing open source. The problem was the Enigma engine code had never been tested outside of a quick demo. It was also written for the desktop computer environment.

Starting as before, the Enigma engine code was refactored, filled out, and all the function names normalized. Also parameters were made consistent. Several assumptions in the origin code needed to be removed and code organized into "setup" vs "run" capabilities. The three biggest efforts were (1) testing everything, and (2) applying a significant amount of user experience design to the API. I said "three". The third task was all of the documentation. This project has a lot of documentation.


Pocket Enigma

The Pocket Enigma is a pretty accurate representation of the usage of real Enigma machines.

The oral history group at Bletchley Park UK were gracious with their time and resources. Over a couple of months of emails, the staff answered me many questions about how the enigma machine was used in daily operations.   An even greater resource were their transcripts of both British and German operators of the Enigma machine.

All of this data drove the UI design of the Pocket Enigma.

The UI of the Pocket Enigma is 100% built using the SRXEcore. At times, the core library needed either bug fixes or enhancements to perform some tasks more efficiently. A good example was storing/retrieving  the Pocket Enigma configuration to the EEPORM storage transparently.


Note: There were several enigma message formats adopted through WWII. The Pocket Enigma is agnostic of the message format. However, to simply sending/receiving messages between devices using the built-in RF transceiver, one of the more mature formats has been implemented. This is not the most complex syntax used during the war but is it one of the most prolific formats found in historical documents.