Over at my new #Tethered Haptics Using Morse Pulses project, I have decided to leave the haptic system enabled full time on the TRILLSAT-1 prototype, instead of just during low-power situations, and have created a new EEPROM haptic passcode validation system which reduces the chances of nature (or a casual passerby) to spontaneously enter commands over the tether.  A two-capital-letter passcode is set via XMPP which allows 676 combinations.

While simple to use in a "typical" system, implementing all of this on TRILLSAT-1 is more complex due to both its oblique angle (and another angle which changes depending on the sun), and the fact that it resource-shares a single overloaded MISO line using two ATtinys running in parallel.  I'm essentially cramming a new, full-time system onto an already overloaded line, and all of these systems have to be carefully orchestrated.  There are some interesting nuances in exactly how the circuits and software need to interact to allow successful operation.

The MISO Line

The SPI Master In Slave Out line is now used for five different purposes:

•     Occasional bitbang SPI in-circuit programming of the two ATtiny microcontrollers
•     On/Off control, by both the Pi and ESP8266, of the LED spotlight
•     Motor position alignment via a hall-effect switch read by Sawyer (the motor-control ATtiny)
•     Serial bus between Sawyer and Huckleberry (the power-regulation ATtiny) for repeating standard Morse code characters from haptic input
•     On/Off control of the LED spotlight by Huckleberry

And the settings vary depending on whether or not the Pi and ESP are up or down, the LEDs are on or off, the position of the motor is aligned over one particular hall-effect switch, and whether any in-circuit programming or haptic communication is taking place.

The I2C Lines

Two I2C lines (which are also used as SPI lines) are shared by two masters (Pi Zero W and ESP8266) and three slaves (LIS3DH and two ATtiny 1634 microcontrollers), but the infamous hardware I2C clock-stretching bug on the Pi has caused many difficulties over the last two years, forcing me to both slow down the bus and spawn off jobs in parallel so to not delay the line.

These lines are the only way to access the LIS3DH registers, so if the Pi or ESP go down, the LIS3DH can only generate interrupts to one of the ATtinys based on previous settings and the registers can no longer be set dynamically.  So I had to make sure the Pi (or ESP) sets it correctly before any power failure occurs.  Because the three slave devices cannot communicate with each other, the only options for the ATtinys would be to set variables which are polled by the Pi or ESP, if active, so they can then send master I2C commands as needed.

The LED Spotlight

The LED serves as both a spotlight for illumination and also an important diagnostic tool, allowing Morse code output to be visualized without turning on the haptic motor, and it can even flicker when performing SPI programming without affecting the data integrity.

If all systems are operational, the ESP should keep the LED spotlight ON (floating), but the Pi should keep the LED spotlight OFF.  Because the LED is being controlled at the transistor base after the series resistor, it doesn't ground the entire MISO line and leaves it usable.  So the Pi and ESP can keep the LED off, yet still allow the MISO line to operate for SPI programming, haptic Morse signals, and hall-effect motor position detection.  But if Huckleberry needs to control that LED for testing when pulsemode is 0 (visual only; no haptic), the Pi and ESP must relinquish their hold on the LED spotlight, and then Huckleberry can control it.  Sawyer can control it too, but it never needs to.  It just needs to monitor that line at all times for its hall-effect switch, in-circuit programming, and incoming haptic signals.

So if Huckleberry is sending Morse to Sawyer, you'll see the LED spotlight flash, unless the Pi and ESP have turned it off.  But if the Pi is down, it is no longer grounding that transistor base and the LED spotlight comes back on.  And any haptic transmission from Sawyer to Huckleberry will light up the LED if the Pi and ESP are down.

Now, if just the Pi is down, the ESP should know this, as it controls the power to the Pi and has full communication with it over the UART.  So the ESP can always take over to keep the LED spotlight off, too.  It should default to ON, so haptic pulsemode 0 will work by default.

But if the ESP is also down, haptic pulses to Sawyer must always light up the LED.

Unless... the motor is in a position where a particular hall-effect switch has triggered, then the LED will remain off and neither Huckleberry, nor the Pi or ESP, can turn it back on.  But in this case, haptic communication is no longer possible with Sawyer.

I've decided that I need to arrange the jumpers on the two hall-effect switches to make the one that uses the MISO line on the West, sunset-facing side.  I'll explain why below.

The Sunset Position Hall-Effect Switch

When the Pi wants to move the motor, it must turn off the LED spotlight (to keep the light from flashing at night), then instruct Huckleberry to turn on the LED spotlight (but it doesn't really come on, due to the Pi override) to release the ground on the MISO line to free up the sunset hall-effect switch needed by the motor for position sensing, then tell both Huckleberry and Sawyer to ignore haptic pulses by disabling the interrupt, then tell Sawyer to move the motor, then it tells Huckleberry and Sawyer to receive haptic pulses again, then tells Huckleberry to set itself back to where it was, and then the Pi turns the LED spotlight back on again, to give Huckleberry a chance to control the light if it needs to.

If the LED was on, it will turn off if the motor is moved to the sunset position.  And when that hall-effect switch is triggered, Sawyer can no longer be programmed nor receive haptic Morse code messages either.

Huckleberry could set a flag which is polled by the Pi and ESP8266 to instruct Sawyer to drive the motor away from the hall-effect switch to allow it to temporarily see those signals, but if the Pi and ESP are offline, this is not possible.  However, if the hall-effect switch that uses the MISO line is the one at the sunset position, the most precarious physical position, where the planetary mass only needs a slight nudge to physically fall away from that sensor into the Night "tridant", it allows the user to simply "shake" the tether to free the sensor.

When programming Sawyer using a BASH shell, I added updates to my trillsat_burnsaw.sh script to first check to see if the MISO line is sinking (which means that either Huckleberry is grounding the line to keep the LED spotlight off or the sunset hall-effect switch is sinking), and then use i2ctransfer (one of the commands from the Linux i2c-tools package) to send an I2C command to Huckleberry to turn on the LED spotlight, and then checks again.  If the MISO line is still sinking, it informs the user that the motor position must be moved before programming can commence.

When the hall-effect switch is not sinking, 5v is sent through 1502 ohm resistors which meet up with a 1k resistor to form a 1.5k/1k voltage divider at the LED spotlight's control transistor, sending about 2 volts to the Pi and MISO line which doesn't interfere with the Pi's 3.3v logic bitbang SPI programming.  When the sensor is sinking, Sawyer sees a direct ground at the MISO line, but Huckleberry now sees the 3.3v line after only a 334 ohms (502 ohms + 1k in parallel) load is applied, which draws only about 10 mA on the Pi GPIO pin, not enough to keep the SPI programming from working, and the 3.3v logic is still seen as a 5v logic high on Huckleberry.  It's interesting that if Huckleberry grounds the MISO line, then this does block Sawyer from programming, even if the hall-effect switch is not activated, since Sawyer sees a 1k/502 ohm voltage divider, which lowers it to 1.1 volts, too low for a 5v logic high.

And when programming Huckleberry, I also added updates to my trillsat_burnhuck.sh script to send an I2C command to Sawyer to tell it to disable its THUMP interrupt until programming is complete.  This is necessary to ensure that, if the sunset hall-effect sensor is not blinding Sawyer from the MISO line that Sawyer doesn't try to interpret Huckleberry's SPI programming signals as haptic Morse code instead.

Whew!  I told you TRILLSAT-1 was more complicated than a typical use case.  But, wait, there is more!

Tilt Angle Changes THUMP Parameters

And finally, because TrillSat is an oblique-angled craft that changes its tilt angle for solar tracking, the tilt increases X-axis (or even Y-Axis) acceleration due to gravity that must be subtracted by the accelerometer to keep the sensitivity constant, instead of inversly proportional to the tilt angle.  But the physical constraints of the tilt also limit the sensitivity, so both the LIS3DH high-pass filter REFERENCE and the threshold CLICK_THS registers would probably need to be read/set after ever motor move.

Ideally, I need two axes (X and Z) in TrillSat for consistent, single-axis click detection at every tilt angle, where a typical, flat, vertical hoistbot, that didn't tilt, would need only one.  The accelerometer can be configured to detect multiple axes (6D orientation), but it would still have to be configured for each tilt angle to know how to interpret the pulse for an interrupt, which brings me back to the same problem.  I do like this feature and may use it in the future, as it can exclude pulses in the wrong direction.  Without using the LIS3DH I2C line, which is not possible on the ATtiny 1634s in my situation, or the Autoreset mode (which I'm still experimenting with), the accelerometer system is not smart enough for dynamic calculations.  So I have to rely on the Raspberry Pi Zero W (or ESP8266) to set the accelerometer over I2C beforehand, which would allow the THUMP system to operate normally using interrupts at that tilt angle, until it changes again.

But because Sawyer and Huckleberry will continue to track the sun, even if the Pi and ESP are offline, this is not an ideal solution.  So before a "planned" low-power shutdown situation occurs, I'm going to either have to switch to the Autoreset mode or have the Pi turn off the high-pass filter and thus make the pragmatic, but sometimes incorrect, assumption that the system is always level.  This would mean that the haptic passcode could be easily unlocked at noon, when solar power is at maximum, or at night when a "shake" can move the mass to solar midnight position and also level the craft.  Then, when unlocked, any, non-haptic, motor locomotion operations will be told to stop at noon position, to ensure subsequent haptic commands are easy to enter, until the THUMP system times out and normal solar tracking resumes.

And there are many more orchestrated systems like this in TrillSat--this is only a small example.

So just because things seem fairly easy going over at my #Tethered Haptics Using Morse Pulses project, every new system I cram into the TRILLSAT-1 prototype is a logistical nightmare.  But this is by design--I wouldn't have it any other way.  It is exciting!

That's the main reason I build projects like this--to see what the maze-like constraints of Nature and Information allow me to do, how much I can overload, how much I can't, to find those outer boundaries, and then, go deeper and find those inner ones, too.