Because I'm already capturing a sequence of two Morse code characters (the A-Z letter and the F1 or F2 confirmation character) for each haptic command, I decided to tack on a secondary system that checks for invalid confirmation characters to unlock a 2-letter passcode.  As I mentioned previously, a "Q" followed by "F1" within 5 seconds, for example, will send a command to turn on the Qi charger to charge the smartphone.  But with this new system, a "Q" followed by an "A" within 5 seconds, will not activate that command, but could instead match a passcode that was previously set by the user, called "QA".

There are 676 two-capital-letter combinations, which is sufficient for a simple passcode that is easy to set, easy to haptically enter, secure enough to keep a random person from casually entering codes, and makes it more difficult for natural phenomena (wind, rain, hail, etc.) to spontaneously enter commands.  For example, for rain to activate the Qi charger if a "QA" passcode was set, it would have to send a SIMTHEO SHH Morse Q (. . ...), then within 5 seconds, send a SIMTHEO SHH Morse A (..          .), which unlocks the device, then send another SIMTHEO SHH Morse Q (. . ...), then within 5 seconds, send a SIMTHEO SHH Morse F1 or F2 (. . . .) or (. . . ..).

That's not impossible, but it's improbable during the length of time of an intense rainstorm in my area, which would have to trigger the X-axis interrupt.  Wind, rain, hail (or an animal) would have to hit the tether sideways in such a way to trigger the accelerometer at just the right amplitudes and pauses, the Infinite Monkey Theorem.

But it could happen, and if I find that it's a problem, I may later add additional timeout delays, such as a 1-minute delay if an incorrect unlock code is entered (which would also extend any brute force attempt to an average of several hours of tether plucking to find the unlock code).  But the system is hanging on a tether anchored to the ground--it's not physically secure, so this is mainly to keep out nature not human beings.  Or maybe I'll also add a timeout delay to reset the lock after it has been unlocked for a certain period (like the sudo password timeouts in Linux).  I don't want to increase the complexity of the passcode, as that just makes it harder to enter the haptic input.  And I'm also trying to keep my haptic commands rather benign, that if they are activated in error (or if I activate them in error) that their interaction with the craft's operation isn't that big of a deal.

But the way it currently works now is that, on boot, the system is unlocked and haptic commands can be entered normally.  I added a new XMPP command on the #TrillSat project prototype called code [A-Z][A-Z].  If the user sets the code to a two-capital-letter sequence (such as QA, XZ, UV, etc.), it will set the haptic lock and write the code to the EEPROMs on both ATtiny 1634 microcontrollers running in parallel.

Once the user unlocks the code, a global flag is set, and the system remains unlocked until it loses power or resets.  Then on boot, the ATtinys read the EEPROM and put the lock back into effect.  This ensures that at nighttime, if the system loses battery power and goes completely dead, once it boots up after the sun hits the solar panel in the morning, the lock remains in place.

If the user sets the code to an invalid two-captial-letter sequence (such as 5Z, yt, 00, etc.), it simply clears any haptic lock and writes it to the EEPROM so it will remain cleared.

Another one of the benefits of using a haptic Morse code system over, say, a flashlight pulsed onto the photocells at night, is that it is more difficult to perform a passcode replay attack.  Without using OTPs (one-time passwords), at night, a person could pay attention to the flashlight pattern and then shine a light from far away to replay the codes.  But the haptic vibrations are too fast for the naked eye, yet too slow for the ear (at sub-audible frequencies).  So as long as one's hand is not readily visible to distant onlookers, it would be difficult for them to observe the codes.

I've also decided to leave the haptic communication system enabled at all times, even when the Pi and ESP8266 are online, since the user will not be able to send commands to recharge their smartphone if the smartphone experiences complete battery failure and loses the ability to send XMPP commands to lower the craft and turn on the Qi charger.  Because of this, I've decided to turn off replay_mode temporarily to disable any haptic motor feedback until the correct passcode is received (which allows the craft to save power in a rainstorm, for example).  When the correct code is entered, the motor then vibrates back a response and accepts normal haptic commands as long as it has uninterruped power.