Half Square Triangle formula

My quilting genius, and very crafty, dear wife asked me a simple question: How do I calculate the size of a "half square triangle"?

"What is a Half Square Triangle?" I asked?

This is "sewing magic" where you start with two square pieces of fabric, sewn together with a 1/4" seam around all edges. Then you cut that square into 4 pieces, across the diagonals of that square. You then unfold the "triangle" along the sewn seam, now you have 4 smaller squares.

See the picture below of what I'm describing:


The question my wife asked: For a desired "magic square" size of say 4", which is one of these four "trianular bits" unfolded along the seam line: What is the larger fabric square size to use?

Hmm, this is a question for the Numberphile YouTube Channel, I thought. This involves some rather serious use of the Pythagorian theorem. In the spirit of Numberphile, I broke out some Teletype Paper - similar to the traditional brown Butcher Paper all maths is scribbled out on Numberphile. I then proceeded to "dazzle" my wife with my 'mastery' of Algebra and Geometry.

This turns out to be a rather tricky maths problem. Cutting a square along the diagonal, then unfolding along the sewn seam to reveal four smaller squares, which are rotated 90° from the larger "parent square" is a bit of a mind bending problem to solve.

After an hour attempting to understand the original problem, and drawing out pictures of the cut squares transformation on paper, it was obvious the Pythagorian Theorm is required to answer this question.

My wife had two prototype half squares constructed. Once I understood the problem, the answer rather quickly was drawn out as a picture on Teletype paper. Applying Geometry, this equation solves the original ask:



HST = Square Edge length "magic square"
FullSquare = Starting square edge length


Example: Desired Half Square Triangle size is 4 inches. What is the size of the starting FullSquare?

Applying the above formula, let's solve this equation one step at at time.

The desired Half Square Triangle size is 4". For this equation HST = 4.



Now square that answer of 8:



Divide 64 by 2:


Now take the square root of this resultant mess:


This is 5 11/32 inches. Almost done. Just add 1/2" to this result and you now have the size of the parent square:



This is close enough to round up to 5 28/32, or 5 7/8".

See, Easy Peasey!

Backing up Ancient Linux Virtual Machine

Many years ago, perhaps over a decade, I designed my network configuration around the "trusted" and "DMZ" separation of zones mode. Operating within the DMZ (De-Militarized Zone) are services which are directly exposed to incoming connections from the Internet. These systems are "hardened" so they should be more difficult to be hacked by a malicious script kiddie. All of these systems are running in Virtual Machines. By leveraging the VM "snapshot" feature, restoring a hacked/vandalized or otherwise damaged DMZ system is simple, restore the snapshot and the system is operational again. VMware Workstation also offers strong hardware isolation for multiple systems running on the same physical hardware. This approach also allows "portability" of DMZ systems to improved hardware. Install VM software, restore the virtual machine disks from backup and the environment is up and running.

Fast forward to 2017. Over time, I've changed which physical hardware is hosting the DMZ environment. Originally, these were all running on a 2 processor Pentium Pro W6LI motherboard, with 512MB of memory. I was able to squeeze 5 VMware Workstation VMs onto this system, barely. Over the years, the need for faster compute, more disk, memory, the DMZ environment is now running on a Dell PowerEdge R610. I've also virtualized other important non-DMZ development computers. The operating systems are all Linux, and all very old. RedHat 9 is the "newest" of the lot running in this environment.

Backing up these VMs is obviously important, as these are core compute and infrastructure systems. However, no backup is worth the disk space it is consuming if you cannot restore the backed up computer to a running system. Proving these systems could be restored proved to be a much larger task than I expected.

So far, only one important RedHat 9 VM is backed up to a 500GB IDE hard disk. This disk is "scavenged" from a failed Buffalo 2TB RAID device, which contained 4-500GB IDE disks. The disks are fine, the RAID controller failed. This IDE disk has been brought back to life using an PATA/SATA to USB disk enclosure.

With this RedHat 9 system is now "backed up" at the file system level, my fear of data loss is less concerning. However, I'm still proving I can "recover" this system from backup. This is easier said than done.

Plan 1: Create a new virtual disk, partition it like the RH9 system. Boot a Live CD system, mount this disk, copy the backup data to this virtual disk.
Problem 1: Making this disk bootable. Fortunately, this RH9 system boots with GRUB vs LILO. Unfortunately, this is a GRUB 1 implementation. This appears to be imcompatible with GRUB 2, found on modern distributions, like Mint 18 or Ubuntu 16.04. No amount of fiddling around with GRUB, and other Linux Rescue tools were able to make this "recovered" virtual disk bootable. My last ditch attempt was to copy the actual 512 bytes MBR from the original RH9 system to the restored disk. That "almost booted".

Plan 2: Install a minimal RH9 system from the original distribution ISO images. That will definitely make a bootable system.
Problem 2: Finding the correct Virtual Machine hardware which is compatible with the Linux kernel/disk drivers present on the RH9 installation media.

Choosing "ESXi 5.0 and later (VM version 8)" virtual hardware, and "Debian GNU/Linux 4 (64-bit)" OS type worked. I had the proper disk driver which would read the file system present on the RH9 ISO disks. Fantastic!

I now have a bare-bones RH9 system installed. Copying files with ssh from my backup NAS server is the next hurdle. Modern sshd servers use more secure cipher and key exchange (KEX) algorithms than are found on the RH9 ssh client. My NAS server is running sshd 7.2p2, OpenSSL 1.0.2g. The restored RH9 system is running ssh 3.5p1, OpenSSL 0x0090701f (0.9.7.1f?). Attempting to log in to the NAS server from the RH9 system failed with "no matching cipher found".

I've encountered this problem in the past. My solution was to build from source OpenSSL/OpenSSH. This is not a good option for this configuration. Installing all of the build environment on this ancient RH9 system is too much effort. Time to finally solve by configuration this issue. I've gone down this path before, with some success. The first configuration change on the NAS sshd server added to /etc/ssh/sshd_config:

     Ciphers 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,arcfour128,arcfour256,aes128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

This gets past the "no matching cipher found" error. Now the error is "no kex alg". That is where I gave up previously. Not an option today. I found the missing configuration needed on another blog post:

    KexAlgorithms diffie-hellman-group1-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1

With these to additions to the target server's /etc/ssh/sshd_config file, kill -HUP SSHD_PID, success!

Security concerns: All systems I am working on are running on my trusted network, so I'm not worried about people breaking the traffic on the network. However, I will comment out these "weak ciphers/kex alg" settings after the restored RH9 system is proven working.

Ref:  http://sysadm.mielnet.pl/no-kex-alg/
         http://steronius.blogspot.com/2014/10/ssh-no-matching-cipher-found.html

Raspberry PI Teletype Project

Project Software

Software to control a Teletype with Raspberry Pi GPIO interface 

 

Skip forward to The Project section for details of how the software/hardware are integrated together. My project is using an old Raspberry Pi Model B. Newer Raspberry Pi models GPIO pins may be in a different order. Please research and verify the pin outs before connecting any external electronic to your Rasberry Pi.

Background

Since High School, I've surfed shortwave radio utility bands. These frequencies contain commercial and military traffic, which use "advanced modulation".

My two specific areas of interest are Radio Teletype (RTTY) and Radio Facsimile (FAX) transmissions. During the late 70's and through the early 90's, the HF radio spectrum (3MHz-30MHz) was quite rich with many interesting utility band broadcasts.

Between 1979-1990, I amassed quite a collection of surplus military radio, RTTY and FAX equipment. Over time, I realized I was acquiring the "best of breed" equipment, mostly used by the Navy.

I've retained a small portion of that collection to this day. Today the HF utility bands are not as exciting to monitor, yet there still remains some weather FAX (WEFAX) and weather-related RTTY traffic.

Today's go-to technology for receiving this traffic is a computer. Equipped with an audio card, both RTTY and WEFAX can be easily rendered by laptop/desktop computers. In the early 80s, this was not true. Personal computers were very expensive, and beyond the reach of a teenager communications technologist.

My first teleprinter was a Model 15 Teletype. This was mostly a automated typewriter. Using a clever combination of electromagnets and mechanics, these devices implemented a "serial port" supporting 5-bit Baudot code. This equipment was acquired at a Ham Fest in Wheaton IL, one very cold winter weekend. The trick then was to bring this equipment to life, and actually print something. This is where my youthful interest in electronics and shortwave radio were further developed. This heavy, noisy equipment became my pride and joy when I finally was able to print news feeds from shortwave radio.

I quickly learned the Model 15 was limited, by only supporting 60WPM, or 45 baud, traffic. Most press outlets on the HF bands used 66WPM, or 50 baud traffic. Listening to the "tweedle-tweedle" frequency shift key (FSK) audio signals, you could tell the speed of the broadcast, with a little experience. There was obviously still faster traffic, which turned out to be 100WPM, or 75 baud, traffic.

By today's standards, these speeds are painfully slow. However, for mechanical teleprinters, 100WPM, or 10 characters per second, is actually quite impressive to see in action.

Model 28 ID Tag

The king of the 5-bit Baudot teleprinter machines is the Model 28 Teletype. This was developed for the U.S. Military in the 50's by the Teletype Corporation. This is considered the most rugged teleprinter they ever developed. This is a marvel of mechanical engineering, and telecommunications. The Bell Labs exhibit at the Museum of Science and Industry in Chicago had a Model 28 TTY on display, printing UPI press feeds. This exhibit made a lasting impression on a pre-teen science enthusiast.

Images of my Model 28 printing a test pattern from my Raspberry Pi:

Model 28 Printing Test Pattern (close up)

Front view of printing teletype:

Model 28 Printing (front view)

Model 28 Selector Unit (front) 

Close up views of data selector unit, where binary 1's / 0's are converted mechanically to 5-bit codes. This is a mechanical serial port.

Model 28 Selector Unit (solenoid)

 

 

The Project 

The Raspberry Pi Teletype Project's goal is to bring back the press feed printed on the Model 28 Teletype I retain from my collection of surplus military radio gear. Using breaking news emails as a source of data, the Raspberry Pi is both an email filter and a teletype driver.

The Raspberry Pi GPIO (General Purpose I/O) pins are ideal for such a project. The interface to any teletype is primitive: a single solenoid used to key 1's and 0's data into the mechanical data selector of the Teletype. Using one GPIO pin to send a stream of binary Baudot code data to the Teletype, with some simple electronics to interface the Raspberry Pi with the Teletype, this 50's vintage teleprinter is back in operation again.

Step One: RPi LED "Blink"

Having no  Raspberry hardware programming experience, I searched for demo projects which expose this functionality. The WiringPi project an programming API to access to the GPIO / UART / PWM pins on the Raspberry Pi. Nice. Example one: "Blink".

RPi Blink wiring

 Wiring Blink is simple enough. There is one small challenge: connecting the RPi pin header to a prototype board. My solution: cannibalize an old floppy disk IDE cable. This has more pins than needed, but this works.  The wiring for Blink is simple enough; one LED and a 330 ohm resistor.

Copy/Paste the blink source code, compile, run and sure enough, the LED blinks at a 1/2s rate.






Next test: Can the GPIO pins be cycled on/off quickly enough to control a Teletype. Just modify blink.c to delay 22ms, vs the 500ms value in this example. Running that code, you can't visually tell what is happening. So I tried 44ms, which is slow enough for my eye to see the LED is actually blinking. From this success, I assumed 22ms worked, I just couldn't see it. Yes, I could have hooked up an O-Scope, but this test seemed good enough.

Step Two: Controlling the Teletype Loop Current

GPIO Relay Control
(Note: Wiring above is for NC relay!!)

 The Model 28 controlling "electronics" is a solenoid magnet, which keys bits into the selector unit. This is the input to the mechanical "UART" of the selector unit. This should be 120v-150v at 20-60ma. My main concern was to completely isolate this high voltage loop circuit from the RPi. This simple circuit allow easy control of a relay through any RPi GPIO pins. Modify the "Blink" demo hardware, replacing the LED with this circuit. You can then "hear" the relay click on/off at a 22ms rate.

Raspberry Pi GPIO Pin Out

Here is the full table of Raspberry Pi GPIO pin wiring.
















Raspberry Pi GPIO Heder Model A&B P1 Header (wiringPi Project)

 
The final piece of this project is the Raspberry Pi software to convert input text to Baudot code. That ASCII to Baudot code conversion, and then finally to a bit stream to key the Teletype solenoid magnets is performed by this small software project. Github rtty-rpi Teletype driver project.

To build this project, you must have make and the GCC C compiler installed. Additionally, there is a dependency on the wiringPi project, which is simple to install:

    sudo apt-get install wiringpi

Once these prerequisites are met, just run "make" in the rtty-rpi project.

To test, run this command:

    sudo ./rtty-pi --test-data

This will print the following test pattern:

THE QUICK BROWN FOX JUMPED OVER THE LAZY DOG'S BACK 1234567890
RYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRY


You can also type data from your computer in "real time" using this command:

    sudo ./rtty-pi --keyboard

To exit the --keyboard option, you MUST type this sequence of keys: <ENTER>NNNN.

Please note: The default data rate sent by this project is 60WPM. Should you have a Teletype with a gear shift for other speeds, such as 66WPM, 75WPM or 100WPM, you should use the --wpm option. 

Example: sudo ./rtty-pi --wpm 75 --test-data

Your other option: Set your Teletype gear speed selector to 60WPM.

You can investigate other options with the --help command.

Model 28 Teletype Operation Details

For over more than a decade, I used my model 28 Teletype. Yet, I didn't fully understand exactly how all of the mechanics worked between receiving a serial 5-bit Baudot code from the radio to printing text.

The Internet is a great resource for knowledge. The full Navy training manuals for all things Teletype is available. I am slowly going through the Model 28 Teletype training manual.

The incoming bits from the Baudot signal are decoded by the Teletype Selector Unit - essentially a serial modem mechanically implemented. The question that eluded me for years is just how does the Teletype decode the bits to a specific typing pallet on the type box?

 

Below are images that describe how the incoming Baudot code selects a letter from typing pallet, printing that letter on paper. 

 

Marking / Spacing means 1 / 0 or current on / off through the Teletype selector unit solenoid:

 

I find this diagram a little hard to read. Here is a hand sketch I created that makes sense to me:

 

What does the incoming signal look like? Here is a hand sketch that illustrates the signaling protocol:

Here is a picture of the type box as installed on the Teletype:

This view is the front of the type box. The Teletype moves the type box left/right and up/down based on the incoming code value, and then the typing hammer "pecks" the back of the pallet to print a letter on the paper.

This is the font side of the type box:

"Shadow image" of disassembled type box:

Notice the rows are perfectly horizontal, but the vertical columns are not perfectly vertical, following a "curved arc" pattern. This curiosity hits at the complexity of the Model 28 operations, and now much engineering precision was involved in the development of this device.

For the seriously curious, here is a Navy training manual for a specific Model 28 Teletype. This link jumps to the section describing how a received code is converted mechanically to selecting a type box pallet.

Model 28 Navy training manual: Pallet selection

The full manual can be read. Warning: This document is very, very pedantic, and plodding reading. However,  to truly understand how this mechanical wonder works, this is a great reference source.