Tethered Haptics Using Morse Pulses

Waves of Dits and Dahs in a Tether Sea

Similar projects worth following
Have you ever seen those scenes in films where a Coast Guard helicopter lowers a rescue hoist to rescue somebody, and the rescue swimmer sends hand signals to the flight mechanic operating the hoist to lift the rescue basket? If it's too dark to see, they might use radio or wave a chemical light. But what if the radio was down and visibility was still too low? Could the flight mechanic, with a gloved hand on the tether, feel the signals? Divers have done this for over 100 years, as they had to deal with low visibility conditions without radio contact and use various line (rope) signals to physically pull the tether to contact the line "tender", who pulls back, often including some sort of handshaking protocol for error correction. But what if the hoist operator was a machine, or even a spaceship, and not a human being?

That's the basic idea behind THUMP (Tethered Haptics Using Morse Pulses), an experimental electromechanical system for two-way line signals.

The Mysterious Wave Pulse
Five Most Important Factors
The Problem With Using Acceleration Pulses to Send Morse Code
Motor Feedback
Inverting the Morse Sequence
The Algorithm and Decoder
Parallel Operation Using a Single Pin and Bus Protocol
Minimal Power, Memory, and CPU
Configuring the LIS3DH
LIS3DH Register Settings
Optional Snail Cam or Escapement Anchor


First, please let me clarify that, at this time, THUMP is in no way suitable for critical emergency situations.  It is an experimental subsystem that I built to communicate and control a small, solar-powered, self-propelled, tethered robotic radio platform, in cases where its primary radio systems go down.  But such a system could be applied to a variety of different types of craft, and building it has provided fascinating insights.

THUMP is a low-cost, low-power system that uses a subset of International Morse Code for the full A-Z alphabet.  And instead of only hoisting something up or down, as in the helicopter/diver example, robotic hoists can also be inverted, anchored at one end, and the hoist platform itself can be instructed to move up or down (a vertical hoistbot, or a horizontal/oblique winchbot or cablebot) turning it into a tethered flying, or even submersible, craft.  THUMP requires only a 3-axis accelerometer interrupt for sensing and uses the hoist/winch motor for haptic pulse generation.  The operator simply "thumps" the tether (hammering, plucking, or yanking) to instruct the robot to move or perform any desired function within its capabilities, and the machine vibrates back a response.  A resource-efficient Morse code algorithm and decoder was created for an ATtiny microcontroller, which can also be daisy-chained to multiple microcontrollers for asynchronous, parallel operation in more complex cases where different CPUs control different subsystems (which was the case with my prototype).  It creates its own serial bus protocol (using Morse, of course!) and has zero reliance on other protocols, which is nice.

Ebb and flow, flotsam and jetsam, dits and dahs...  A traditional hoistbot with a winch and take-up reel is kind of like a helicopter, but TrillSat is a little different.  It's an oblique capstan-driven cablebot, anchored at both ends, that sails, on what I like to call, a "tether sea".  When using the tether for capstan locomotion, the craft acts like a buoyant ship or airship on a medium, but when the tether is used for Morse code communication, THUMP shows that the tether really is a distinct medium.  Think of the armed forces of different countries, for instance.  They are usually divided into mediums or their absence/combinations (land, air, water, and maybe even space).  And even in space, both end-over-end rotation and "gravity-gradient stabilization" can keep a tether taut, and because the tether is the medium, a gas is not needed for wave propagation. Each medium has unique characteristics that have to be understood, and the tether has unique characteristics.

And, interestingly, many of these characteristics have been understood for centuries, since a simple 1-dimensional tether, anchored at both ends, form a vibrating string which has provided musicians, mathematicians and physicists a simple way to discover and study WAVES.  And the corpus we have on this subject is immense (and a joy to research), but I do not claim to be an expert.  Waves are hard, even for musicians to master, and much of our academic understanding lies in the oscillating, dynamic world of differential equations.  I'm neither a musician nor a physicist, but I do have a good grasp of logical information processing, and so I use my discrete tools, as best as I can, to bound and observe those wiggly, squiggly things.

THUMP is actually the fourth human-computer interface in #TrillSat .  TrillSat's primary...

Read more »


Updated version of the source code for the SIMTHEO Decoder, with a couple of bug fixes, licensed under LGPL 3.0, which is used as the Morse Code decoder and generator and performs most of the work.

gzip - 23.51 kB - 08/25/2018 at 03:19



This is the source code for the SIMTHEO Decoder, licensed under LGPL 3.0, which is used as the Morse Code decoder and generator and performs most of the work.

gzip - 23.40 kB - 08/16/2018 at 05:12


  • 1 × LIS3DH 3-axis accelerometer Detects tether wave pulse
  • 1 × ATtiny 1634 8-bit microcontroller Runs SIMTHEO decoder and interacts with motor and accelerometer
  • 1 × SIMTHEO Decoder To decode and generate A-Z International Morse Code
  • 1 × Black & Decker AS6NG cordless screwdriver To generate haptic vibration on tether
  • 1 × H-Bridge To allow motor direction reversal for haptic feedback

View all 6 components

  • --. --- --- -.. -... -.-- .

    Lee Djavaherian09/07/2018 at 11:07 0 comments

    This project page will no longer be updated, and any future updates will take place on the main TrillSat site at  I created this page specifically for the Human-Computer Interface Challenge, but this marks the 4th loss for my #TrillSat project in a row, without any recognition whatsoever, except for a single like from a user named AKA.  Thank you @AKA for being the brave lone voice that recognized this project.

    TRILLSAT-1, signing off.

  • Source Code Implementation of the Haptic System

    Lee Djavaherian08/25/2018 at 03:32 0 comments

    I just published new updates to the source code over at the #TrillSat project which show how the tethered haptic system was implemented.  About two weeks ago, I had published the SimtheoDecoder module, which performs the Morse decoding (and does most of the work), but now I've released the remaining code (and a small update to the decoder) to show exactly how THUMP was implemented on the prototype itself, the working cablebot known as TRILLSAT-1, to control the motor, perform the EEPROM haptic code validation, and process actual commands.

  • Haptic Video Demonstration

    Lee Djavaherian08/24/2018 at 01:49 0 comments

    Ok, I just posted 4 new videos of the TRILLSAT-1 prototype over at my #TrillSat project page, and one of them demonstrates this tethered haptic Morse code system in operation (shown below).  In the demonstration, I set the haptic passcode lock, unlocked it, and then sent a command to turn on the wireless Qi charger via the two-way haptic system.  I also show the effect of acceleration due to gravity when the craft tilts for its solar tracking function.  I hope these videos give you a better feel for the project.

  • ​Gravity is Yet Another Variable

    Lee Djavaherian08/21/2018 at 05:46 0 comments

    I thought I had the five most important variables taken into account for practical tethered haptic detection on my oblique cablebot, but the force of gravity itself, not just the weight of the craft, added a sixth.  I didn't notice this when testing my craft horizontally or even at a slight X-axis tilt, but when I was testing the motor yesterday, at extreme tilts to the side, the threshold for X-axis detection seemed to increase, making recognition more difficult, even if I struck the tether along that same tilted axis.

    This shouldn't be an issue for typical, vertical hoistbots that remain level, as you're always going to have the same constant level of acceleration due to gravity which can be subtracted by the accelerometer, but my prototype is an oblique cablebot which is designed to tilt throughout the day for accurate solar alignment.

    Gravity does two additional things in my case: it presents a changing source of acceleration to the X-axis accelerometer when tilted at different angles (of which I already took advantage for pitch/roll detection for the craft), and it seems to limit the amplitude of the wave pulse along the same axis, reducing the detection sensitivity.

    If the craft is plucked along a leveled X-axis, it can oscillate horizontally fairly easily, but if the craft is tilted sharply, like an airplane banking with its ailerons, gravity acts like a spring pushing against one side, and the taut tether acts like a spring pushing back (confining the pulse between a rock and a hard place, so to speak.)  Imagine placing a small wooden board on a lake and pushing it sideways, which only takes slight effort, versus turning the board sideways and trying to push it underwater or lift it out of the water, which takes more force to move the same distance.

    So I turned on the LIS3DH high-pass filter using CTRL_REG2 to allow me to cancel out the DC component (gravity) for click detection, which allows the pulse to be more easily seen by the accelerometer.  This helps, but the reference needs to be adjusted, by using the REFERENCE register, for each tilt angle.  I've been experimenting with the Autoreset feature, as well.  So I plan to add more code to my prototype to set the reference a minute or so after each motor tilt operation (to allow the craft to swing to a halt).  And then I may also read the tilt angle and increase or decrease the threshold, CLICK_THS, dynamically, which should counter any remaining effect.

    Again, the #TrillSat project prototype is a more complicated use of the THUMP haptic system.  I described some the particular difficulties in it's log entry here.

  • ​EEPROM Passcode Validation System

    Lee Djavaherian08/19/2018 at 19:40 0 comments

    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...

    Read more »

  • Added More Commands to TRILLSAT-1

    Lee Djavaherian08/17/2018 at 20:23 0 comments

    Even though THUMP is now installed and working in the #TrillSat project, I need it to actually do something useful, and so I'm adding more commands to my TRILLSAT-1 prototype.  On, I've created a series of XMPP commands that I can issue to the ESP8266 (which is sent to the Pi over the UART).

    The Pi then sends I2C commands to the LIS3DH so that I can change its parameters on-the-fly for testing:

    cfg [0-255]     Set CLICK_CFG register to set click direction (1 is x, 4 is y, 16 is z, add for combos)
    ths [0-255]     Set CLICK_THS register to change threshold (for changing the sensitivity)
    limit [0-255]   Set TIME_LIMIT register
    latency [0-255] Set TIME_LATENCY register (for changing the pulse width)
    window [0-255]  Set TIME_WINDOW register

    It also sends some I2C commands to the two ATtinys (Sawyer and Huckleberry) which run THUMP and SIMTHEO:

    pulse            Instruct Sawyer to send a short haptic motor pulse for testing
    pulsemode [1|0]  Set the morse_echo and morse_replay variables differently on the two ATtinys to enable haptic mode (1) or LED mode (0)
    thump [1|0]      Turn the THUMP interrupt on or off

    And on trillsat.c, I am now assigning commands to the various letters A-Z.  Hopefully 26 letters (plus an optional binary confirmation which allows 52 combinations) will be enough for me, and I won't need to add a second letter.  I can always add a second letter, which will take more time for the user to enter, to raise the number of combinations to 26^2 = 676 (plus that binary confirmation).  This is why Unix-like systems can get away with using so many two-letter commands--there are over 600 from which to choose.

    Here are the haptic commands so far (but are tentative until I see how I like it):

    X   Disable all power to the craft, including power to the ATtiny itself (if it is night, the craft will then be completely dead)
    L   Turn on the ESP8266 (via its LDO regulator)
    B   Turn on the 5v boost converter on Batt 2
    Q   Turn on the Qi charger (important if the smartphone is dead and needs to charge to regain XMPP control)

    I will add more commands later (and experiment with OFF or toggle commands) and release the updates to the TrillSat source code, showing how THUMP is actually working on the prototype.

View all 6 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates