I will try to give updates here but we’ll see how that goes.

By now it should be evident that I’m really bad about updating this website and I’m equally absent on social media but I’d like an easy way to give all my friends and family ongoing updates and proof of life.

I was recently introduced to polarsteps and will be trying that out. It’s a free (as in beer) travel documentation tool which is funded through optional purchase of physical travel books so I don’t think I’m the product like with most free services. Check out my trip on polarsteps.

I’m thinking I’ll probably post some periodic updates on Instagram too but only time will tell if that actually happens.

I started out with a (knockoff) Agilent 82357B USB to GPIB adapter. I was able to get my power meter to respond to a GPIB query exactly once but never again. After fighting with linux-gpib configuration on and off, I got fed up and bought an Agilent E5810A Ethernet to GPIB adapter. I had no problems communicating with my power meter immedately after power everything on.

I’m using PyVISA with the pyvisa-py backend. I’ve now begun writing python device drivers to simplify scripting this and other test equipment.

import visa
rm = visa.ResourceManager('py')

ip = '169.254.58.10'
gpib_addr = 13
inst = rm.open_resource(f'TCPIP::{ip}::gpib0,{gpib_addr}::INSTR')

Backlight

Since this originally lived in my bedroom back in college I wanted to disable the backlight which is always on. This is extremely easy by removing (or disconnecting one end of) two unlabeled resistors next to P102:

Due to the nature of rocketry I feel the need to be explicit about liability. This is not a finished product and I don’t guarantee reliability or safety if you copy it. You take full responsibility for everything you make. Please don’t blow yourself up.

You Know What Would Be Cool…

The concept of a wireless igniter for model rockets was born in my college dorm room.

It all boiled down to a few basic objectives:

• Never launch unless commanded
• Always launch when commanded or inform the user of errors
• Simple enough for safe operation by inexperienced users
• Legal to operate with a technician class amateur radio license

Wanting to have something to show off as soon as possible, I built quick and dirty proof of concept with a breadboard and parts I had on hand.

That consisted of a STM32 development board, an off the shelf UHF FM radio module, and a DTMF decoder IC with the antenna from a handheld radio and an external car battery.

If you don’t know about DTMF, they’re the tones you hear when you press numbers on a telephone. Each number consists of two tones, one indicating the column and one the row on the number pad.

Yes, that is aluminum tape holding the radio module in place so it wouldn’t fall out of the breadboard. No I didn’t have anything better at the time.

It wasn’t hard to get this working very rudimentarily, though there were some serious flaws.

For one thing, I intentionally ignored power on/off tranients because I just wanted a proof of concept for myself. Especially combined with the external battery and janky aligator clips, I had concerns about any sort of power event with an igniter connected causing accidental launches. I could keep myself safe by only connecting the igniter once power was applied and configuration loaded but it certainly wasn’t stupid-proof.

The other primary flaw was the user interface. To launch the rocket, all you had to do was type a launch code into a handheld radio while transmitting. A series of tones would be sent back from the igniter to indicate the message was received and report any errors. This is all fine but the bad part was configuration. I made the launch code, frequency, and callsign configurable at power-on using a laptop over USB. In retrospect it might have been better to hard-code these values and avoid the need to have a laptop in the middle of a muddy field when you’re just trying to light some propellent on fire.

Also, I didn’t have any large power resistors and didn’t want to make anything more complex so this design had absolutely no current limiting on the output. I only blew one or two FETs by driving into a hard short. Thankfully the resistance of an e-match is high enough that it could survive normal use.

The Box That Smiles Back

No, I’m not sponsored by Pepperidge Farm.

I needed an enclosure for this pile of wires but where could I possibly find something at 10:00 PM in a college dorm? The only rational answer was my to take the empty Goldfish box from my roommate’s desk. Five minutes and a pair of scissors certainly turned a piece of trash into the flimiest enclosure I’ve ever made.

Goldfish 2

Given the flammability of cardboard we switched to a laser-cut acryllic box pretty quickly but the name stuck (and so did the front of the box).

I was also concerned about someone dropping or shaking the box and breaking the electronics so copied it over to a perf-board once I had settled on a circuit.

None of this fixed the underlying issues mentioned above (nor was intended to) so I knew I would be making something better.

Goldfish 3

Given that I ultimately wanted to make something I would be proud of and could use conveniently, it was time for a major redesign.

To eliminate the issues with power I had three strategies:

1. Internal battery to avoid momentary disconnects
2. Mechanically isolate output during any power events
3. Soft power switch so MCU can ensure things are safe during power events

The first is self explanatory. Unfortunately I messed up my charging circuit (or didn’t finish debugging it, I don’t remember anymore) so had to remove the battery for charging. This wasn’t a big deal since everything was held together with machine screws but still obnoxious.

The second and third are more interesting. I added a key switch for arming which also physically disconnects the output. This, along with the soft power switch, gates power-on so turning on the power switch will never do anything unless the arming switch is disarmed (safe).

As far as usability goes, I completely eliminated the terrible USB configuration and replaced it with a number pad and large LED segment display.

There are some other features on board including a Raspberry Pi for voice synthesis and ethernet to interface with any other sensors at the launchpad. Neither of these were fully implemented since I moved on to other projects before getting around to them.

I wish I could show a video of Goldfish 3 in use but I appear to have lost the few videos I once had.

Resources

• GitLab (This is quite a mess but I’m not going to clean it up at this point)

I haven’t touched this project for about 4 years before writing but there’s no time like the present to document past projects. Unfortunately I didn’t take very many photos and no longer have access to the hardware so please excuse the lack of quality pictures.

Design

I wasn’t sure what exactly I was looking to make so I just made some sketches that were asthetically pleasing to me.

I generally don’t like the look of knives that have a shorter blade than handle, but I also wanted to keep the blade under 3.5” (Colorado’s limit for concealed knives). The goal was for the handle to feel good in the hand while trimming its length significantly.

The Blade

Since I didn’t go into this with knifemaking experience, I wanted to work with a relatively forgiving steel. From a little research I found that 1075, 1095, and O1 steels are all pretty good for beginners and are oil quenchable. I settled on 1095 because I wanted better edge retention (over 1075) and didn’t know much about O1.

Almost the entire blade was shaped with a 1x30” belt sander. Mine is from Harbor Freight. It’s not perfect but the price is right.

To grind the bevels into the sides of the blade, I didn’t use a jig but just estimated a reasonable angle and removed metal to a center line I scribed onto the edge. I definitely could have achieved flatter bevels with a jig so in the future I will likely be using one.

Heat Treatment

This was definitely the most daunting step in the project. Heat treatment is necessary to harden what has been fairly soft steel until this point so that it will be able to hold a sharp edge.

First it has to be heated to roughly 1500°F, or a little beyond its curie point (steel stops attracting a magnet). Once the blade is uniformly at 1500°F, it is submerged in oil (I used peanut oil) to cool it quickly.

My first attempt at hardening the blade didn’t go exactly to plan. I was using 2 torches (above) in an attempt to get enough heat, however it was very difficult to get a uniform color (and therefore temperature) throughout the steel while reaching a high enough temperature. In the end, I decided to re-harden the steel with a more powerful heat source. Unfortunately, I didn’t take any pictures of the second attempt at hardening the blade, but it’s really the same as before just with a bigger torch.

The final step was to temper the blade. This softens the steel so it won’t crack or shatter as easily. I just put the hardened blade in an ordinary kitchen oven at 400°F for about an hour.

The Handle

I settled on cocobolo for the handle. The process of shaping the handle scales is fairly straightforward. I put the two blocks of wood on either side of the blade and sanded them until I was just starting to hit steel. Once the profile is mostly done, I once again connected the scales with dowel pins to keep them aligned and sanded their profiles.

I then glued the wood scales onto the sides of the steel with epoxy. They were held in place with the dowel pins and clamps. For future knives, I will definitely use more clamps and ensure better flattness of the scales since there is a small void between the wood and steel in one spot.

Once everything was glued, I could have hammered a mushroom head on the ends of the pins but I decided not to. I was concerned about accidently damaging the wood finish and since this knife won’t be getting very heavy use I’m not so concerned about it falling apart. I simply sanded off the excess of the pins and let the epoxy work its magic.

Finishing

The steel was simply finished by hand with sand paper on a flat surface. I was initially planning to take the finish up to around 1000-2000 grit but since there were already imperfections like a minor warp of the steel from heat treating as well as not perfectly flat surfaces of the bevel, I decided to stop at 400 grit. I’m still happy with this decision since it saved me a lot of time and I like that it looks more like a brushed finish.

For the handle, I was planning to use polyurethane simply because its what I had and I don’t know much about finishing woods. Luckily for me, before I started using it I did some research which revealed that polyurethane will never cure when used on cocobolo and many other exotic hardwoods. This is due to oils from the wood interfering with the reaction which cures the finish. In the end, I used a tung oil finish which turned out beautifully.

I generally havent worried too much about how sharp my knives are in the past and simply used an electric sharpener from my kitchen. This time, I wanted to do a little better so I borrowed a set of stones from a friend and put the time in to give it a real edge.

Conclusion

I’m really happy with how this turned out. The knife feels good in my hand despite having a small handle. I sharpened the blade well beyond the point of shaving hair so I know it will take an edge well. I have yet to see how well the steel holds its edge.

Resources

• Jantz Supply for 1095 steel & cocobolo block
• Harbor Freight 1x30” belt sander
• Diablo 1x30” sandling belts
• Harbor Freight propane torch
• Lansky knife sharpening set

NOTE: I initally used Harbor Freight’s 1x30” sanding belts. Their 40 and 80 grit belts are quite satisfactory however the ends of their 120 grit belts are overlapped (creating a bump) rather than having a proper butt joint. I recommend Harbor Freight 40/80 grit sanding belts over Diablo belts due to cost. Diablo is just what I could get locally.

For my freshman projects class in the Fall of 2016, we were prompted with using some aspect of touch tone phones in a new way. Ultimately, my group decided on making a cell phone targeted at the elderly population, some of whom struggle to use miniaturized cell phones or much more complicated smartphones.

The primary goal of our project was to create a working cell phone with as similar an interface to old landlines as possible to simplify use.

Design

The design is based around an Arduino and inexpensive SIM800L GSM module. Schematic, board layout, and Arduino code are available in the Git repository. As a brief overview, the ATMEGA328P (microcontroller that’s on an Arduino Uno/Nano) communicates with the SIM800L by sending AT commands over UART and monitors the keypad for button presses. There is additionally a SIM card on the back of the board which interfaced directly with the SIM800L over SPI. Interpretation of phone numbers is performed on the ATMEGA328P and currently works for calls within the United States but would need significant improvement to be used for international calling.

To save space, in addition to it just being cool, I designed a PCB for the phone.

Through this process, I learned quite a bit about PCB design and debugging as well as how that can fit into a larger project’s workflow. This is the largest and most complicated PCB I’ve made to date as well as the most difficult to solder package (LGA-88 with lots of heat dissipation).

Since I don’t personally have any reflow soldering equipment, I had to use what was available in the circuits lab here at CU. Unfortunately, the PCB arrived during Thanksgiving break and I couldn’t get access to those tools for a week, leaving me with just 1 week to populate, test, and debug the board. This ended up being pretty stressful. Population of the SIM800L module became a lot easier when I started using a hot air station powerful enough for the job as opposed to a hand held air gun.

Once populated, testing was fairly straightforward and showed only a few issues:

• Indicator LEDs (low battery, no service) wouldn’t light
• Speaker volume very low
• Battery would not charge

Unfortunately, due to the time crunch before the design expo, we abandoned charging with our fallback plan of removing the battery and charging it on a separate lipo charger. This worked both for testing and demonstration and

Final Product

The finished phone is fully capable of placing and receiving calls within the country and maintains the same interface as old touch tone phones with the addition of an answer button (green) and moving the end-call button from a base station to the handset (red).

Further Development

Throughout the design process, I came across a few additional features that I would like to incorporate into the Hohm Phone (if there ever is a version 2). The most important feature is definitely to fix charging since that didn’t work and is very essential to being functional at all in the real world. Additionally, improving audio volume would be important.

Next on the list is adding a voice changer to lower the pitch of incoming voices. I remember whenever my family would call my great grandmother, she would have no trouble hearing anything my dad said but struggled to understand anyone else because our voices were higher pitched. During this project, I came across a couple voice-changer projects which reminded me of these experiences and would be a great internal addition to a phone specifically made for the elderly.

Resources

• Git Repository (GitHub)

The purpose of this project was to gain experience with a field programmable gate array (FPGA) and design of digital logic through the creation of a reaction timer. This timer must be able to wait a random length of time before measuring how long a person takes to react to an LED turning on. The purpose of this delay is to prevent someone from simply pressing a start and stop button in quick succession without ever having to truly react to an event outside of their control.

Overall Design

This reaction timer is built around a state machine, a pseudo-random number generator, and a counter. The random number generator is used in conjunction with a counter to create a delay of random length. At the expiration of this delay, the counter then measures the time required for the user to react and press a button. Finally, either the most recently measured reaction time or the fastest reaction time (as determined by a toggle switch) is shown on seven-segment displays.

This diagram is somewhat hard to read given multiple functions all being performed in the same space. This is a simplified diagram depicting only the components used to create a random duration delay.

State Machine Design

I decided to use a zero one hot encoding of state for multiple reasons. We discussed one hot encoding in class and I liked the simplicity of logic allowing the state machine to function, but I still would have to deal with every bit being a zero when the device is initially powered on. Since I want specific actions performed when the device first powers on anyway, I decided to simply add the state where all bits are zero as one of the states.

I also need to be able to display either the most recent reaction time or the best (shortest) reaction time, so I decided to use a Mealy type state machine. Since selection between these two output modes is done with a toggle switch, it is trivial to add a multiplexer directly using the switch input to control what value is being sent to the display drivers.

Note that both start_button and stop_button above are inverted inputs. This is because the onboard buttons are low active. Also note that this module does not contain the selection of which reaction time to display as the result.

Random Number Generator

To generate pseudo-random numbers, I’m using a Fibonacci linear feedback shift register (LFSR). For this to generate pseudo-random numbers, specific numbers of bits must be used as the length of the number. For this test, I used a 7 bit LFSR.

My implementation of this shift register initally failed due to a very important misunderstanding with regards to verilog implementation in hardware. I Iniially did not realize that inital blocks only affect simulation so my LFSR was starting with an initial condition of all zeros. Unfortunately, this is the one stable state so it always output 0. To fix this problem, I simply had to change the assignment of the least significant bit from d[0] = (q[N-1] ^ q[N-2]) to (q[N-1] ^ q[N-2]) || (q=={N{1'b0}}). This simply sets a single bit to 1 if all are zero.

To ensure that the LFSR was functioning as expected (make sure I hadn’t screwed up), I sampled the value 30 times at approximately 1000-5000 clock cycle intervals.

Unfortunately, 30 samples doesn’t allow for significant trends to develop in terms of frequency of occurance of various numbers. What this sample does show is that the LFSR is providing values throughout its full output range and, when I slowed down the clock to 1Hz, confirmed that it is operating exactly as it should.

Extra Features

Though functionally useless, I also added a scrolling message on the seven-segment display when the device turns on. In honor of CU, this message is go buffs. I made this scroll across the available digits through the use of a 2Hz clock which causes the message to shift left by 8 bits (7 segments + decimal point).

Demonstration

Here is a video of the timer in action.

Further Development

This has been a really interesting experience getting to create low level hardware without ever having to physically manipulate hardware. I definitely have gained a bit more understanding as to the power of FPGAs despite the fact that I never came close to using even a single percent of this chip’s capability.

While I was working on this project I messed around a little bit with driving a VGA display since this hardware is fully capable of doing so. I never succeeded in producing a signal recognizable to my monitor, however I would like to investigate the cause of this failure in the future. It could be a good introduction to designing hardware for synchronous communication.

Resources

Due to this project being part of a course, I cannot publish the complete source code. If you are interested in seeing the source, please contact me directly.

Information about the FPGA development board I used can be found on the manufacture’s website (http://de10-lite.terasic.com)