Introduction
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
How I Use THUMP
Conclusion

Introduction

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 human-computer interface is a custom XMPP server running over wifi on an ESP8266 which also becomes a gateway to its secondary human-computer interface, a 2-meter AX.25 multi-user packet radio/APRS system with a packet BBS server, running on a Raspberry Pi Zero W.  And the Pi Zero W also has a wifi adapter that I can turn on (using XMPP) for SSH console communication during testing and programming.  If the XMPP system is online, commands can be issued to control the craft.  But if the XMPP system is down or out of range, commands could also be issued over the packet system or even the Pi wifi to control the craft.  But if all three of those higher CPUs and radio systems go down (or the clients that control them go down), the craft will still maintain core operation using two very low-power ATtiny 1634 microcontrollers called Sawyer and Huckleberry, but there is no way of communicating with the craft at that point.  In fact, I didn't even design them to communicate with each other.

THUMP allows those tiny low-level CPUs to receive Morse over the tether, and then one of them vibrates the tether to send a response.  This has many advantages, which I discuss later, and it doesn't require any additional parts, as the accelerometer was already present for tilt (pitch/roll) detection for solar tracking and other functions, and it uses the same motor for the haptic response.  I love overloading functions, nesting systems, and finding optimizations, and this satisfies all cases.

The Mysterious Wave Pulse

When you pluck a string at one fixed end it induces a wave pulse that travels to the other end, where it encounters the craft's accelerometer.  That's really all I care about.

But the wave pulse has other plans in mind...

It can reflect, even going 180 degrees out of phase, and some of the energy will increase the momentum of the craft but decrease the momentum of the pulse (conservation of momentum).  And if you don't pluck the string at the very end, you'll create two transverse wave pulses in opposite directions--one will hit the fixed end and reflect 180 degrees out of phase, and TWO pulses will reach the craft, the intended one, and shortly thereafter, its inverted twin.  Luckily, the accelerometer can be told to ignore pulses in the wrong direction (which I didn't need to utilize) and ignore pulses that are too close.  It's only the first pulse that reaches the craft that I need to detect.

A traditional hoistbot acts like the free end of a string with a heavy mass, and even acts like a mass on a spring, and TrillSat acts more like a fixed end and reflects some of the energy back 180 degrees out of phase.  If the pulse length was very large, TrillSat would probably let the pulse pass underneath, like a ship in the ocean, but the short pulses used in THUMP are like small waves crashing into the hull.

I don't need to worry too much about what happens after that first pulse reaches the craft, as long the others invert or damp away quickly.  There is the possibility of constructive "interference" when two waves happen to collide to equal the sum of their amplitudes.  I just need it to be within the threshold and timing windows of the accelerometer.  The accelerometer will see a spike in acceleration as the pulse passes, and hopefully, if I configured it correctly, ignore subsequent pulses until the next real pulse.  Interestingly, people have also used MEMS accelerometers as pickups for musical instruments, a function not unlike what I am trying to do.  And we know that tethers can send a lot of information in their vibration, as tin cans and string can even create a telephone using longitudinal waves.

But music is far more complex, and weird phenomena start to occur (resonance, standing waves, harmonics, etc).  I shouldn't have to worry about that with widely spaced pulses.  Some physical phenomena such as wind, hail, etc., could vibrate the string in unforeseen ways, but there are simple, discrete ways of stochastic error-checking if noise is a problem.

Five Most Important Factors

For THUMP there were 5 main factors that really concerned me:  the type of tether (nylon paracord for example), the type of thump used (a hammer, pluck, or yank), the length of the tether, the weight of the craft, and the accelerometer settings.

There are all kinds of dynamics that can be calculated that don't really affect detection ability, but are interesting, nonetheless.  For example, the weight increases the tension, and greater tension increases the pulse speed. The type of tether determines its density, and greater density lowers the pulse speed.  The speed of the pulse divided by twice the tether length determines its frequency.  So, like a guitar string, when you stretch the tether, it increases tension and also becomes less linearly dense, both of which increase pulse speed, which increase frequency.

Have you ever wondered why lower-pitch guitar strings are so thick?  Not being a musician, I had always thought it was because they have to be stronger, but, wait--then I started thinking about this further--they don't have to be tuned as tight as the higher pitched strings (because at least I know, with my limited knowledge, that the tighter the string, the higher the pitch).  So what is going on?  Well, remember that linear density?  More mass seems to be added to them on purpose, just coiled around a core, to increase their "mass per unit length" (linear density) which lowers pulse speed, which lowers frequency.  Sneaky, sneaky.

I had always assumed that since the strings were all the same length on the neck that tension was solely how they were tuned, but mass is another variable.

The Problem With Using Acceleration Pulses to Send Morse Code

I knew I would hit this problem early on (since I had already built a Morse decoder for a game I made a few years prior):  while accelerometers can detect wave pulses, and can even act as pickups for musical instruments, the problem with using them for single-pulse Morse code detection is the acceleration itself:  Morse encodes information in the pulse length (a DIT being 1 unit and a DAH being 3 units, the units are relative).  Creating an acceleration pulse is relatively easy--you just thump the tether sufficiently to exceed thresholds within certain timing intervals, all of which can be configured with the built-in single-click interrupt mode that I used on an LIS3DH accelerometer.  But creating a pulse 3 times longer to signify a DAH would require massive thrashing of the tether, a continuous acceleration, like a rocket, which is not practical.  A hammer, pluck, or yank isn't going to create a continuous acceleration.

A DAH could also conceivably be sent in the amplitude, by plucking or hammering the tether 3 times harder to create a larger spike, instead of a longer one, but the accelerometer interrupt is binary.  You wouldn't be able to determine if a DIT or DAH triggered the interrupt.  But, interestingly, the LIS3DH has 2 interrupts.  However, only one of them is exposed in the Adafruit board that I use (which has other nice features like a controllable LDO regulator).  Even if I was able to use that second interrupt, this would force the user's timing to be very strict and would not allow my algorithm to adapt to the user's speed.  The I2C bus could be used if the pulse speed was within its configured bandwidth, but the ATtiny 1634s are slave-only I2C devices, and even if a software master was written for them, this adds a lot of additional complexity to the system that simply doesn't need to be there.  And what if it was already hard to generate that first pulse, let alone one 3 times larger?

For example, if a hoist robot is really, really heavy, hammers (perhaps even using an actual hammer) may be the only simple option left to generate a sufficient amplitude due to the high string tension.  Think about the tension in a hammered instrument like a piano, for example, which is massive, versus that of a plucked or bowed instrument, like a harp or violin, which is less.  A harpsichord, for example, has much less tension than a piano.

Another option is to use a "bowing" effect, similar to a violin, creating a back-and-forth acceleration, like a series of plucks, long enough to be recognized as a DAH (and have the accelerometer check for a quick succession of spikes), but this would require a bow, perhaps a jagged piece of plastic, to rub against the paracord, but such a device may not be available.  Also, this would introduce those complex wave interactions that I want to avoid.  But it's not out of the question--it might actually be a very useful tool in the future.  But for now, I'm just using human hands to interact with the tether.

Yanking is a different way of generating the waves.  It is percussive, like Fred Astaire tapping a cane on the ground, and creates longitudinal waves in the tether along the Z-axis.  A yank is simple for a human to perform, and it can generate clean pulses in certain situations.  If the weight is light enough, a person could just pull the craft towards them slowly and then release the tether and let it fall back, like a dog running until it hit the end of its leash--the moving accelerometer would register a sharp acceleration when brought to an abrupt halt (as long as the winch held fast).  This would induce an acceleration spike directly at the craft itself, and all other pulses could be ignored during a short window.  But if the craft is heavy or both ends are anchored, it takes more force to induce a pulse.

Motor Feedback

Now let's think of the second part of the THUMP system, haptic motor feedback.  In the hoistbot, it's easy, simply drive the hoist or winch motor back and forth in rapid succession, using an H-Bridge for polarity reversal, and it will create that percussive yank effect which can be felt by a person with their hand on the tether.  Because the robot is much faster than a human, it can create a constant vibration (like the bowing effect mentioned earlier) and we don't need to worry about machine recognition now--a human is recognizing it.  But TrillSat is a catenary capstan craft anchored at two places (in my case a tree and the ground) and when the craft is up high, the tree begins to take more of the weight, and that end is where those pulses will be felt the most.  But I'm on the ground section, so the pulses are more muted.  However, in addition to the capstan for locomotion, I use an eccentric mass for solar panel tilt control, and this mass can be vibrated back-and-forth to generate a similar effect, even changing the axis on which it vibrates based on its cardinal orientation.  Perfect.  In other words, TrillSat doesn't have to just send a "yank", it can also send a hammer/pluck kind of vibration.

Inverting the Morse Sequence

So for Morse code detection, I had to create an inverted Morse code algorithm, called SIMTHEO SHH (as in "shh, quiet!") which times the silent pause lengths between the pulses and not the pulse lengths.  But for Morse code generation, I simply used normal, non-inverted Morse code to ease human recognition.  In 2016 researchers have shown that haptic vibrations speed up the learning of Morse code, so the THUMP output vibration provides an excellent teaching tool.

The Algorithm and Decoder

My specific implementation uses an LIS3DH accelerometer, Black & Decker AS6NG cordless screwdriver with a custom two-input H-Bridge that I built into the handle, and two ATtiny 1634 microcontrollers, running in parallel.  The bulk of the Morse code processing is performed using a C module that I created called SIMTHEO Decoder.  There isn't a lot that needs to be done in the main C program except for configuring some registers on the LIS3DH, adding some initial defines/variables, and adding a small ISR (Interrupt Service Routine) function.

The history of SIMTHEO Decoder goes back to a Morse decoding algorithm that I created in 2016 to improve my 2015 solar, microcontroller roguelike game recognition (which used Morse code as its primary human-computer interface).  I extracted the code from my game, but left out the more complicated line buffering and input system that the game uses, and created the SIMTHEO Decoder C module.  For the THUMP system, I then modified this algorithm to create the inverted mode SIMTHEO SHH, but the decoder can switch between the two modes. So the C module can be used both in my game and in TrillSat (or in other types of hoistbots/cablebots).  The decoder doesn't perform any input validation but just decodes the pulse sequence to a single letter (it is mainly a classifier), and I leave any input validation to the main program.  For THUMP, I just added an additional user validation code that can be entered within a 5-second window to confirm the letter is correct, but this is just for proof-of-concept testing in a controlled environment.

Standard Morse code, SIMTHEO, worked well in my game, since I had a physical Morse key (an SPST N.O. switch that I could hold down to ground a pullup), but with THUMP using SIMTHEO SHH, when you use the pauses to differentiate, the computer can't tell whether or not the last element is a DIT or DAH, since it doesn't know when your last pause ended.  It has to wait for a long pause before timing out and accepting the input and cannot rely on a final thump, for example.

So SIMTHEO SHH assumes that your last element is a DIT.  But if your last element is a DAH, you simply wait a long pause (but not too long, about 4 DAHs) and send a final thump, and it changes it to a DAH.  If you don't wait long enough, it will think that last thump is an element, and if you wait too long, it will timeout, but there is this zone of "just long enough".  It uses timeouts to accept user input, but if you enter that just-long-enough last pulse, it assumes you are done and considers it an input.

This works well, since only 12 letters end with DAH, but 14 end with DIT. And of those 12, 5 contain 4 elements and end in DAH (and therefore a 5th pulse immediately signifies a DAH, and inputs immediately, without waiting for the timeout). This leaves only 7 letters (MOWTAUK) that require this final, carefully-timed pulse.

By the way, the reason I originally named the algorithm SIMTHEO is that those 7 letters (SIMTHEO) are the only letters that contain homogeneous elements and are the most difficult to decode.  Ideally, a discrete single-letter decoder needs to see stark differences between the elements or pauses, so SIMTHEO and SIMTHEO SHH remember what the user considers to be a DIT or DAH by observing the last successful mixed-element letter and adjusts to the user's timing.

As mentioned earlier, I also added basic input validation by having the craft replay the letter it received back to the user by vibrating the tether, and if correct, the user enters a validation code within a 5-second window to confirm.  This validation code is what I call F1 or F2, two of the 4 four-element sequences that aren't valid International Morse Code at all.  The way it works is that you send a letter, the robot vibrates the tether to the user, and if correct, within 5 seconds you begin to send one of those validation codes (just like you would a normal letter).  If the code is correct, the CPU (or all of the CPUs in in parallel) consider it a command and process whatever they are programmed to do.  The reason I used both F1 and F2 is due to their ease of entering using SIMTHEO SHH, their similarity, and the potential to allow the one I choose to also convey an additional binary meaning, perhaps signifying ON/OFF or UP/DOWN, for example, as in "Yes, I do confirm that M to turn on the motor is correct, and by the way, its direction is DOWN."

Parallel Operation Using a Single Pin and Bus Protocol

In my case, I don't use a single ATtiny to read the accelerometer and control the motor, I use two, one to read the accelerometer interrupt line and control power regulation for the craft, called Huckleberry, and one to control the motors and read the hall-effect and solar CdS LDR sensors, called Sawyer.  (Sawyer and Huckleberry were named after two silent, hamster brothers that lived out their lives in separate cages while I built TrillSat.  At night they ran in their separate wheels but never interacted with one another just like the two microcontrollers that cooperate to provide functions to the craft, but never directly interact.)

I maxed out the I/O pins on both microcontrollers, even overloading the SPI MISO (Master Input Slave Output) line with multiple functions (occasional in-circuit programming, LED spotlight, hall-effect sensor, voltage-divider for level shifting).  Both microcontrollers share this line for programming, and the Pi just controls their individual reset lines to select which one actually receives the code, so this was an ideal pin to use to allow communication between the two ATtinys.

So I designed the SIMTHEO Decoder to allow operation in parallel over a single line with the option of running a separate instance running asynchronously on each chip.

I configured the ATtiny that reads the LIS3DH interrupt to use that line to send output, and the ATtiny that controls the motor uses it to receive input.  Two variables were created, morse_echo and morse_replay which can be toggled to create a daisy-chain system, where one CPU receives the signal, echoes the signal to the other CPU (and then both CPUs decode the signal almost simultaneously).  Several CPUs could be chained together in this way without adversely affecting timing.  The first CPUs in the chain simply have morse_echo enabled and morse_replay disabled, and the final one controls the motor and is set to morse_echo disabled and morse_replay enabled.

These two options also allow different variations.  For example, I can turn off all other CPUs and leave only the first one enabled with echo and replay.  In my case, its output also controls an LED spotlight, so it serves as a quiet, visual way to test the system.  Because they are variables, I can change them on-the-fly during testing, and so I added an XMPP command called "pulsemode" to switch between the haptic and LED modes when the ESP8266 and Raspberry Pi Zero W were still online.

The chips all interpret the Morse code signal at the same time and interpret the command in their own unique way.  If both chips receive "L" to lower the craft, for example, Huckleberry might turn on the power and Sawyer might delay a second and turn on the motor and read the hall-effect sensors until the craft is lowered.  Neither CPU really knows what the other is doing, but together they achieve something greater than the sum of their parts.  No special protocols are needed, either.  All CPUs simply use Morse.  It becomes its own single-line serial bus protocol by default.

Note that my TrillSat project is a more "complicated" demonstration for THUMP.  The THUMP system doesn't need all of this to work.  It only requires a single microcontroller and a simple hoist, not two parallel microcontollers, an overloaded MISO line, and a capstan drive system with eccentric mass...

THUMP can be configured for either type of system.

Minimal Power, Memory, and CPU

I keep Huckleberry and Sawyer powered up at all times, but one can also enable the ATtiny sleep mode and the Morse pulses will activate the interrupts and wake the CPU, then put it back to sleep when done, something I did with my Morse code roguelike game to save power (allowing it to run off of a CR2032 button cell battery for years, for example).  Roguelike games are turn-based, so this worked very well.  The LIS3DH can also be put to sleep and set to "inertial wake", but in my prototype, I leave it running the whole time, and it uses very little power.

The SIMTHEO decoder also makes a few attempts to be CPU and memory efficient, but there is still a lot of optimization needed.  It eliminates all floating-point operations, stores the Morse table in program space (flash memory) and only stores the letters using 5-bits per letter, allowing them to be retrieved using a bit mask (since bitfields are notoriously difficult to access using AVR program space).  This uses only 16.25 bytes of flash (no RAM whatsoever) to store the Morse alphabet, 2.5 bytes for the 4 control codes, and frees up 11.25 bytes for other uses.  It's a lot better than using 82 bytes to store the elements as char strings in data space (which would consume 8% of total RAM).

Configuring the LIS3DH

The LIS3DH is an inexpensive accelerometer that runs at 3.3v logic, but for various reasons, I run the two ATtiny 1634s on TrillSat at 5 volt logic.  As long as I don't turn on the pullup resistor on the ATtiny (or set it to an output high) I can safely read the interrupt from the LIS3DH which swings a full logic 0 to 1, and a 3.3v high is still within the range of a logic level 5 volt high.

I used the single-click interrupt mode of the LIS3DH to detect the pulses which can be configured with several parameters.  I wasn't sure at first how well thumps on the paracord would be detected by a mode configured for "click" detection, but it works surprisingly well in testing, and I didn't need to worry about that inverted, reflected pulse (or configure a single-direction detection) if I pulse it at the end of the tether.  And interestingly, plucking the paracord like a musical instrument (hard enough to create a low-frequency sound) works best for TrillSat--the spike in amplitude is detected, and subsequent vibrations seem to damp quickly beneath the detection threshold.  The latency can be configured to set the interrupt pulse length, which is great since it standardizes the signal and makes it easier for my decoding algorithm.  I've only tested THUMP on my wooden Test Frame so far, and I don't know how long the tether has to be before it becomes unreliable, but I would expect that it would work on a much longer tether as long as it is taut, which is pretty much guaranteed in my case since it has to lift an 8.28 lb (3.76 kg) craft.  And a longitudinal "yank" would work at extremely long distances if the right type of tether was used.  Think of flying a kite--the kite can be hundreds of meters away and one can still yank the string to dramatically affect it.  Of course, the catenary adds another variable which creates slack (by the way, I've read that the Coast Guard sometimes uses catenary slack as a safety technique).

I also had to invert the interrupt logic, as I was testing it earlier using a 5v pullup to ground switch (where keying the switch created a logic 0), and this allowed me to quickly swap out my switch and plug in the LIS3DH interrupt line.  I used my own external pullup since it was too dangerous to turn on the ATtiny internal pullup or I might forget to turn it off and damage the LIS3DH 3.3v logic.

Once the ATtiny receives the signal, it sends back a haptic response by pulsing the brushed DC drive motor which moves a 458g (around 1 lb) eccentric mass at full current back and forth at 30 ms intervals.  In TrillSat, smaller intervals were too faint to be felt, and larger ones cause more thrashing of the tether, but this would vary depending on the type of craft.  I had to be careful to also disable the haptic sensing on Huckleberry during the haptic motor replay on Sawyer or else a feedback loop would occur when using parallel CPUs (which was interesting to witness, as it seems to slowly decay to an equilibrium point).  Therefore, when replay_mode is set to 0 and echo_mode is set to 1, it knows that it is not the final haptic motor and creates a short delay.

As mentioned earlier, I also used an interrupt on the ATtiny itself to detect the interrupt generated by the LIS3DH, since my ATtinys do so many things that they have to be fast enough to keep up with the pulses.  Once inside the interrupt, I turn interrupts back on to allow my Raspberry Pi I2C processing to work (as it doesn't like delays due to a clock-stretching bug), but I turn the pin that connects to the LIS3DH off, since I don't want it to call itself.

LIS3DH Register Settings

Here are the register settings I used on the LIS3DH to get basic usage for THUMP on TrillSat, but they should be tweaked for different types of bots and situations:

CTRL_REG5, 0b10000000 - First, reboot the LIS3DH to clear any bad memory   
CTRL_REG1, 0b01110111 - 400 Hz, low-power mode disabled, z,y,x axes enabled
CTRL_REG4, 0b10011000 - Disable continuous update, little endian, max +-4g scale, max 12-bit hi-res, no self-test, spi 4-wire (not used)
CTRL_REG3, 0b10000000 - Enable click interrupt
CTRL_REG6, 0b00000010 - Invert the interrupt polarity (to match test key)
CLICK_SRC, 0b00010000 - Enable single-click detection
CTRL_REG2, 0b00111100 - Set high-pass filter to normal mode, click detection
CTRL_REG2, 0b01111100 - Set high-pass filter to reference mode, click detection

 The following are tweaked in real time using XMPP commands:

CLICK_CFG, 0b00000001 - Configure single click interrupt in X direction
CLICK_THS, 8          - Configure single click threshold (unsigned, lower 7 bits)
TIME_LIMIT, 120       - Configure click time limit x/400 = milliseconds (120 = 300 ms)
TIME_LATENCY, 75      - Configure click time latency x/400 = milliseconds (75 = 187.5 ms), length of interrupt pulse, set it longer than debounce, but keep it short so not to confuse dahs
TIME_WINDOW, 128      - Configure click time window x/400 = milliseconds (128 = 320 ms)
REFERENCE             - This register is read (in normal mode) and then used to set itself (in reference mode) to allow the high-pass filter to cancel out gravity

It might also be worth noting that there are several defines in the SIMTHEO.h source code that set the duration for various timing factors (the default duration of a DIT and DAH, for example).  These can be tweaked somewhat for the particular situation, but setting them too high could cause integer overflows.

Optional Snail Cam or Escapement Anchor

Because TrillSat is designed to be anchored to the ground, the anchor itself can include a small, weatherproof tool to hammer/pluck the line.  This might make it easier for a person to quickly generate clean pulses (or even generate a bowing effect).

For example, a simple "snail cam", a cam shaped like a snail shell, with a tiny crank could rotated to force down the tether until the cam reaches the drop point, at which time the tether quickly snaps back, generating that acceleration pulse.  The cam can be attached directly to the anchor, and a frame could be tied to the end of the tether which fits around the cam.  Then all the person would have to do is turn a lever or knob to generate a series of pulses.  This would be easy to 3D print, weatherproof, and have few moving parts.

Or a simple set of notches could be attached to the end of the tether, and a rotating gear could pull the tether until it slips off the notch, at which point the tether springs back, similar in some ways to a mechanical escapement.

How I Use THUMP


#TrillSat was designed to be an experimental satellite analog, to allow 24x7x365 multi-user text communication without reliance on the power grid, landlines, or an Internet, cellular, or satellite infrastructure.  It's a $390 prototype that just requires the Sun, a tree, and a generic Android wifi/Qi smartphone (no cell plan needed), and the phone also wirelessly recharges itself from TrillSat.

Using a capstan/mass-tilt/catenary mechanism, it is designed to drive itself high in the air on a tether, accurately angled to the sun, and uses a custom XMPP server for primary client communication which interfaces with a ham radio over a repeated, layer 2 network for wide coverage (kind of like a rudimentary mesh satellite network).  It uses an XMPP-to-AX.25 PBBS system as its primary human-computer interface (the entire project is documented in great detail at http://greatfractal.com/TrillSat.html, including annotated photographs of the dead-bug style circuitry and a full electrical schematic.)

But THUMP is a simple, backup human-computer subsystem that provides TrillSat with several important benefits:

Conclusion

I was able to adapt THUMP to TrillSat, and it works well enough for me using X-axis (hammering/plucking) detection and eccentric-mass vibration, but THUMP would work just as well, perhaps even better, on a simple vertical hoist robot.  Changing it to use Z-axis or Y-axis yanks is as simple as just changing the value of the CLICK_CFG register, and the motor vibration function would be identical.

I have an Air Hogs Fly Crane, an electric RC helicopter, which resembles a tiny Coast Guard rescue copter.  It has a tiny working rescue hoist, grappling hook, and a small rescue basket, too, so I can perform mock rescues of peanuts and raisins as I fly it around the living room.

But it might not be widely known that in the middle of the United States where I live, we also have a US Coast Guard presence, the Upper Mississippi River Sector, and years ago, I watched them do rescue demonstrations on the Mississippi using a rescue hoist.  Flying machines are fascinating, but flying machines with hoists and tethers even more so.

I've studied that scene in the film The Matrix countless times where Trinity pilots the helicopter with Neo to use the tether to rescue Morpheus, and then Neo uses the tether to rescue Trinity from the copter.  It's an inversion on many levels, even ending with the tether changing its anchor points, and the crash shows the transverse waves spread outward in the silicon window glass.  Robotic "flying winches" are used frequently in theatre and filmmaking special effects, so many action filmmakers have an good understanding of winch systems and tethers/cables (using them frequently in martial arts scenes) and it comes through in their art.

I have an interest in film, but I enjoy building communication systems more than any other type of system.  My father enjoyed building sound systems (audio systems and musical instruments).  He assembled a quadraphonic audio system in the 1970's, and later in his life, he built a santur from scratch, a Persian hammered dulcimer, a type of stringed musical instrument.  Unlike a guitar, it uses bridges spaced at different lengths (in a trapezoid) and is percussively hammered instead of strummed or plucked.

THUMP shares similarities with musical instruments, and musical instruments share similarities with communication systems.  Morse code can have a musical rhythm to it, too.  In the 1962 film The Longest Day, the DIT-DIT-DIT-DAH played is "V" in Morse code (V for Victory, used in allied war films), but it is also the opening of Beethoven's Fifth Symphony.

But in SIMTHEO SHH, it becomes DIT-DIT-DIT-DIT-DIT (the last pulse signifies the final DAH) so musically, it is not the same.  But notice that it is "five" dits, and it is Beethoven's "fifth" symphony, and V is also the symbol for the Roman numeral for 5, so there is another congruence.  But even these kinds of "meaningless" congruences are fascinating.  In my roguelike game, for example, a small solar-powered game that allows one use either Morse code or UART ASCII, Morse can even become a type of onomatopoeia by mimicking the actual sounds like footsteps (DAH-DIT to step forward, DIT-DAH to step back), or even H, to hit, (DIT-DIT-DIT-DIT), like pounding one's fist.

Information and communication, the message and the medium (or system) are intertwined in mysterious ways.