Adam's Random Technology Hacks
Saturday, May 8, 2021
Half Square Triangle formula
"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!
Thursday, July 20, 2017
Backing up Ancient Linux Virtual Machine
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
Ref: http://sysadm.mielnet.pl/no-kex-alg/
http://steronius.blogspot.com/2014/10/ssh-no-matching-cipher-found.html
Sunday, October 4, 2015
Raspberry PI Teletype Project
Project Software
Software to control a Teletype with Raspberry Pi GPIO interface
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 |
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 |
Here is the full table of Raspberry Pi GPIO pin wiring.
Link to Raspberry Pi GPIO Heder Model A&B P1 Header (wiringPi Project)
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 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
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?
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:
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.