Belize Update

I realize I’ve been kind of quiet about it on my blog, but for the next few months, I will be in Belize learning electronics from my Uncle, who works quite a bit with electronics. Today is close to my third week in Belize, and it’s been pretty busy so far. I don’t have much opportunity to use the internet, so that’s why I’m just now writing for the first time.

Living out here in the jungle, there are no public utilities, so my Aunt and Uncle provide their own infrastructure. For electricity, the house is powered off of two large arrays of solar panels, which charge an array of 12 lead-acid batteries. The DC voltage is converted into 120 V AC supply using a converter and inverter. During cloudy days and days during heavy energy demand such as when the washer and dryer are being used, a gas generator is used to power the house up. I’ve found I have to be very careful to turn off lights behind me and unplug all unused electronics, because it is easy to overload the system and cause it to shut down. I simply need to plug in my laptop sometimes, and the entire house loses power.

Water is collected from rain water. The roof of the house is designed so all the water that hits the roof flows into gutters, and is collected in large tanks. The water is then heavily filtered and supplied to the house at 40 psi. There is no hot water, so all my showers have been cold lately; it’s not a big deal in this climate, anyway. Right now, I’m staying in the guest house, which is its own separate building apart from the main house, consisting of a bedroom and bathroom. The house has it’s own separate water collection system, and the electricity is supplied using an extension cord from the main house.

The first few days here, I worked through a few Electrical Engineering problems, refreshing myself on concepts that have been taught to me during my time at the University of Washington. After my crash refresher course, I was put on a project of getting a 6502 microprocessor emulator device my Uncle built before I was even born to work again, and to upgrade the memory on the board. Originally, the project entailed just getting the circuit working. I was a bit intimidated looking at the tangled mass of wires, some of which have become disconnected, so I need to figure out where they used to go. Also, I was relatively new to soldering when I came down, and the last couple weeks has been a crash course into how to solder together prototype circuits. Soon, the project evolved into modifying the circuit to include an updated SRAM, since they evolved since he designed the circuit. Later, I found there were major revisions to the circuitry I needed to make to cause the circuit to run properly, so I ended up taking a lot of the circuitry apart and rebuilding it, and improved on the design quite a bit. I’m in the process of testing the logic and rewiring the circuit, and I have a feeling this project might take a while longer before I’m even ready to start programming it with Forth (a stack-based microcontroller programming language which very few people use, because it was oversold in the 1970’s). After that, I might design a control circuit for a gas generator, which automatically starts and shuts down the generator to ensure adequate battery voltage. Also, one of the Mennonites at a hardware store is requesting a microprocessor-based grain dryer controller, which might become one of several entrepreneurial opportunities I’ll have while down here in Belize.

Being here with my Uncle is like having a personalized electronics tutor. I have been learning about electronics pretty much non-stop the last few days, and my brain has sometimes been in information overload mode. I have been learning all sorts of things about power electronics lately, which my uncle is currently writing a book on.

Anyway, I have a lot more to say, but I’ll save it for a future post. I will at least attempt to write once in a while, and I’ll try to upload images some time.


Hello to all… Yesterday I finally graduated with a BS in Electrical Engineering after 2½ years at the University of Washington, Seattle. I don’t know if it would have been possible without the support of my friends and family, and especially my Mom and Dad. Anyway, here’s a small selections of photos from yesterday…

IMG_0145 IMG_0211
Left: In front of Suzallo Library.

Right: Me with Dr. James Peckol, with who I’ve had for a total of four classes, EE 271, EE 399, EE 472, and EE 478. He has a reputation of being one of the most demanding professors in (especially in regards to documentation), although, he perhaps prepares you better for industry than most professors.

Now that I’ve graduated, I have to now do a lot of organization, moving, and preparing for my Summer ventures to Central America for a while.

Embedded Keyboard Project, Part 6

Since my last post, our team has completed the final project. On Monday, we conducted the final demo, and just today, we submitted the lab report. Here is the final layout of the keyboard:


Completed keyboard project

As you could see, my lab partner Whitney did a fine job organizing all the electronics, securing them to the keyboard. He made a nifty stand for the LCD display using plastic risers and hot glue. As you can see, we’re now using a Seeeduino board instead of the Arduino board — which is for the most part the same circuit, except it has a few added features and a slightly different board design. Also, note the use of the infrared optoelectronic distance sensor on the lower left side of the board. We decided to make the circuit a little more complex, so we added what is known as a D-beam, and it is used in a lot of Roland synthesizers, for instance, the Lucina AX-09 (video — WARNING: click only if you can handle extremely cheesy product infomercials). We implemented the D-beam using a Sharp 2Y0A21 distance sensing device, and we freed up an analog input on the keyboard controller for the analog sensor signal. We programmed the keyboard to process the same range of pitch bend as the Roland model in the video clip I posted above, which is about a whole step of range. The analog data coming from the sensor is really noisy, so it adds kind of like a chorus effect to the sound quality which we really couldn’t filter out very well.

We reconfigured the entire keyboard to run off of USB power, which is 5 volts, 2.5 watts. The entire circuit ended up only running off of 1.2 watts. We could probably cut down on power even more, especially with the LCD, which consumed a half a watt.

Since our synthesizer output standard MIDI out, it was compatible with another group’s project, which was designing the actual synthesis. In the following video, I used our project as a keyboard interface to their synthesizer using our MIDI output. Here is a video I shot of us connecting our projects together:

Note: Video was deleted at some point. In process of trying to find it again…

The overall cost of all the circuit components is just short of $100, which is more than the original keyboard was worth. We actually probably had the cheapest circuit out of all the groups. If we had more time, ideas I had for further developing our design would be to add a recording / playback feature, which I could very easily do with an SRAM chip, integrating the controls into the LCD menu. Since we ended up getting the synthesizer chip working in serial mode, all the parallel signals could be freed up to drive an SRAM chip. Here are the files that we created for our project:

final_presentation.ppt – Class presentation (Microsoft PowerPoint)
final_report.pdf – Final lab report (Adobe Acrobat) – Project source code (zipped)

Some of the other groups in the class ended up creating really cool embedded projects. Perhaps the most expensive project implemented was a series of robots which implemented swarm intelligence. The robots would scan an area for a target of a specific color, and when it found the target, it would wirelessly broadcast a message the other robots that it found the target, and emit infrared radiation in all directions. The other robots would then turn and locate the robot, and move in towards it. Here are some photos I took of their project:

IMG_0095 IMG_0106
Another cool project was one group that worked with a touch-screen LCD, which had applications which allowed you to draw pictures, play music, and operate a remote-controlled toy car. Here are some images of their project:

IMG_0115 IMG_0119
Another group designed an automatic plant watering system, which allows you to automatically water your plants when it senses the soil is too dry. You can also monitor if your plants are being watered on Twitter. I thought this was a really creative design idea.

Also notice the very creative white-board artwork. Over the weekend, there was an art competition in the lab. Here are some examples of peoples’ creativity:

IMG_0100 IMG_0124
IMG_0092 IMG_0096
Notice that sleep is a common theme in the artwork. No doubt, many groups had to pull overnighters this weekend on their projects, and sleep deprivation seems to be a common theme in classes like this. Working on these projects, you completely lose perspective of time, and can easily spend over 10 hours on a project in one sitting. Well, continuing on with the artwork… One group decided to take their artwork a little further and etch their artwork onto a circuit board.

IMG_0121 IMG_0122
And here is my team’s artwork, which my lab partner drew. It isn’t nearly as creative, simply because we didn’t have to spend overnighters in the lab this weekend, since we had our entire circuit working last Monday and completed on Friday.

One of the most amusing pieces of art in the embedded classroom is the “Wall of Death”, which is a hodgepodge of broken microcontrollers, comic strips, and student artwork.

There were some other cool projects created this quarter, some which worked others that didn’t. Dr. Peckol usually publishes all of our embedded projects on his web page. Our projects should be up and running on his site within a week or two. You could visit our class project showcase here (if it is even up yet). More photographs can be found on my Flickr page.

Embedded Keyboard Project, Part 4

Hello, this is just another update on our keyboard project. I feel we got a *LOT* done since the last time I posted. The project is now going very smoothly, and we feel we are meeting our schedule very well. I feel like we are around 80% done. Anyway, I wanted to share with you the following recording:

Okay, I guess that’s not my best recording yet, but after a few frustrating days of trying to get our ATSAM2195 Atmel synthesizer chip to work, we finally were able to produce sound output. This note was our first recording of the sound output off the chip.

Our final project circuitry actually fits on only one breadboard. We have a pic microcontroller, which has the task of reading all the key states, and generating NOTE ON and NOTE OFF commands to the synthesizer chip whenever a key changes value. The commands are then converted to MIDI messages, and sent to the ATSAM2195 synth chip.

Final project layout

In the image above, you can see our entire final project, minus the Arduino and LCD display, and minus the audio amplifier my lab partner built for this occasion. We decided to switch to parallel mode communication with the synthesizer chip, simply because we felt it was a bit easier to get going. Anyway, here is a quick and dirty c file we wrote for the PIC18LF4525, with which we were able to communicate with the synth chip:


Next we need to integrate all the code for the keyboard controller, so actual key events on the keyboard trigger MIDI commands.

What I spent most of my time on lately was creating drivers for the Crystalfontz CFA533-YYH-KL LCD screen, which is a 2-row 16-character LCD display with 6 navigation buttons. We’re having an Ardueno Duemilanove control the LCD through a RS-232 connection. The navigation menu allows configuration of various things such as instrument, master volume levels, reverb, and chorus. We uploaded a list of the 128 different instrument sounds incorporated on the synthesizer chip.

We also incorporated commands to save current settings into the Arduino’s EEPROM, and restore to default settings. The settings are coordinated with the keyboard controller via I²C connection.

Testbench for LCD display controller

The I²C communication ended up not being straight forward, since I had trouble getting the Wire.h Arduino library to trigger interrupts in the PIC controller when the Arduino is asking for a byte of data. I ended up writing my own Master I²C drivers, which pretty much bit-bang the SCL and SDA signals. Using my library, I was able to get the Arduino talking quite nicely with the PIC controller.

Our current code files for the LCD display and menu drivers are as follows:

  • arduino_module.pde – Arduino project main file
  • common.h – Shared constants between keyboard controller and LCD driver
  • eeprom_driver.cpp
  • eeprom_driver.h
  • i2c_driver.cpp
  • i2c_driver.h
  • lcd_driver.cpp
  • lcd_driver.h
  • menu_items.h – List of items in the LCD menu


As of now, the LCD driver is mostly complete, besides some later proof-reading. Also, I can think of a few more features I would like to incorporate if I find the time such as transposition, and I want to change some things about how the menu is displayed.

Anyway, next time I post, the project might be completely done, perhaps just over the 3-day weekend. I have just one more week to work on this project, during which time I’ll be finishing the final project, preparing a 20-minute presentation on the project, writing one of Dr. Peckol’s typically long lab reports, and conducting a demo of our design.

Embedded Keyboard Project, Part 3

Today, I put several hours into the embedded project. My lab partner extended the 15-wire band by soldering on longer wires, then running the wires outside of the keyboard case, where they’re much easier to access in a bread board.
In the picture, the black wires are for the key matrix rows, and the red wires are for the key matrix columns. We also broke out controls for the power switch on the keyboard and for the two speakers, and we think we probably will try to incorporate them into our design.
After probing the 15-wire keyboard bus, we determined the overall schematic for the keyboard matrix:
This matrix design is exactly as I had speculated in an earlier post. I got keyboard drivers working, which as of now, detects when any of the keys have changed state, and which keys changed. The driver works by driving one of the rows high and the others low, then reading in the columns. This happens repeatedly for each of the seven rows. The old values of the columns are saved and compared to the new values, and when a change is detected, that is when we process a key change, and send MIDI commands to the Atmel synthesizer chip. Here is a PIC16F877a microprocessor wired up:
As you could see, we found we needed pull-down resistors for the column pins. We found without them, we got misread key strokes, since the voltage on the column pins wasn’t falling fast enough. We speculate the diodes introduce capacitance to the column pin nodes. We found 10 kΩ resistors are small enough to discharge the nodes in time for the next read.
The keyboard driver is currently written to toggle the LED on or off every time a key event is detected. The idea is, you press down one key, the LED turns on; press down another key, it turns off; release a key, it turns on again; etc. The current drivers for the keyboard controller can be found using the following links:
After pounding around for a while, we’re now pretty certain that every key event is being processed correctly, since after all keys are released, the LED always ends up in the off state.
Pressing down one key turns on the LED
As of now, we’re still using a PIC16F processor, which runs off a supply voltage of at least 4 volts. Our synthesizer chip runs off of 3.3 volts, and we don’t really want to deal with level shifters, voltage regulators, or use multiple logic supply voltages. So we requested some free PIC18LF samples from Microchip, which should be arriving early next, which can run off of a 3.3 volt power supply. Once those arrive, we could begin to try to send key commands to the synthesizer chip.
So I feel the project is falling together pretty well so far. Next week, we will begin trying to interface the ATSAM2195 chip, and we’re really hoping that we figure it out fairly quickly. As of now, I think all the soldering and modifications to the keyboard are complete. Just out of curiosity, I’m thinking about having my blood lead levels tested.

Embedded Keyboard Project, Part 2

For my Embedded capstone project, we ordered and are us using the ATSAM2195 Atmel synthesizer chip. This chip comes in a 44-pin QFN (quad flat no leads) package, and with this chip, you input MIDI commands using 31,250-baud serial communication, and the chip simply provides the output analog signal. The chip is only 7 mm × 7 mm × 0.9 mm large, and the pins on the chip are only 0.3 mm wide, making it is virtually impossible to use a soldering iron to attach the chip to a PCB.

Three ATSAM2195 synth chips

Since we were prototyping on a breadboard, we had to order an adapter, which converts a QFN-44 case to a DIP-44 (dual in-line package) case. Searching online, I found a kit with adapters, a stencil, alcoholic wipes, a tube of solder paste, plastic tab, tin headers, and a header spacer.

QFN-44 to DIP-44 adapter kit

The first step of the process is to apply the solder paste to the minuscule pin plates on the adapter. To do this, we taped the QFN-44 stencil to the PCB, then wiped a layer of solder paste over the holes using the plastic tab.

If we were lucky, when the stencil is taken off, the PCB would then look something like this, where each pad had just the right amount of solder paste on it, and there were no solder past bridges between pads.

The next step which required perhaps the finest motor skills was placing the QFN package on the PCB, without smudging the solder paste, and aligning the pins just right.

Once we felt the chip was aligned squarely on the pads, the next step was to start our ‘reflow oven’. Actually, it’s more of a ‘reflow skillet’. Strangely enough, the Electrical Engineering department at the University of Washington doesn’t have any tools for PCB printing, so we had to think of something else. So we found a tutorial on SparkFun for using an iron skillet for doing reflow. So we got the exact same model skillet as used in the tutorial, from Target, and put it to work.

Our reflow skillet

After a few minutes, the solder will melt and turn shiny, and after that, we removed the PCB, and inspected for bridges and continuity.

After reflow

The final step is to solder the header pins on, which is the easiest part. The header pin spacer is used to ensure the header pins are the correct distance apart, so it will easily fit into the solderless breadboard.

Abofe, we show the chip connected up to the bread board. The oscillator is there just for show, since unfortunately, the ATSAM2195 chip runs off of a 3.3 volt 9.6 MHz oscillator, but I’ve been finding it impossible to find one in a DIL package, so we’re sticking to the function generator until we find one. Below is another one we made, just for backup.

So, right now we’re crossing our fingers that the chips actually work, and they’re connected correctly. If using the chip is as straight forward as I hope it is, we should be making music with it by early next week. As of now, I’ve been working on drivers for the keyboard interface, which we’re going to implement on the PIC16F877a microcontroller. My other lab partner is writing display drivers for an Arduino Duemilanove (don’t ask me to pronounce that) for a hierarchical menu on an LCD screen. The idea is that the Arduino will be used as the user interface to set MIDI options, such as reverb, volume, instrumentation, etc…, and hand the options over to the PIC, which outputs the MIDI commands to the synth chip.

On a completely different topic, here is a C programming challenge I found online published by the company RapLeaf, and it took me around three hours to figure it out. I thought I would throw it out, because I found it fun to think through, and maybe some of my readers who are programmers would like a little bit of a challenge. They’re looking for programmers that are good at solving problems like this. I’ll be interviewing with them this coming Saturday since they liked my solution, although just for fun. It looks like their positions are geared heavily towards Computer Science majors, which I’m not.

Embedded Keyboard Project, Part 1

This is the first of a series of posts detailing our EE 478 final project, which is to create a MIDI instrument. The idea is to dismantle an electronic keyboard, and rewire all the keys in order to make our own keyboard instrument. I’m feeling more free to publicize my work on this project, since my lab professor Dr. Peckol publishes our work on the class web site for future classes to use as reference, anyway (link).
For this project, we’re creating a 49-key digital keyboard instrument. The keyboard is equipped with an LCD screen interface which shows a navigation menu, and is navigated with pushbuttons. The navigation menu allows the user to change musical settings, such as instrument, reverb, chorus and volume. The system is designed to be low-power and low-cost. We are running all components in the system on a 3.5 Volt supply (except for the external speakers). The 49 key musical keyboard input is controlled by a PIC microcontroller, which converts the keyboard input into MIDI serial data that is sent to a synthesizer chip. The microcontroller is also responsible for interfacing with LCD and pushbuttons for musical configuration settings.
Today, we made our first leap into the project by purchasing a used 49-key MD-500 ‘Optumus’ Radio Shack keyboard on Craigslist for $20.
As you can see, the keyboard is equipped with all sorts of features, including a MIDI recorder / playback feature, metronome, prerecorded songs, auto-rhythms, MIDI-out, and more. For our project, we are creating our own features, so all of that stuff is going to be removed.
After taking apart the keyboard, here is what is in the inside:
As you can see, there are five visible main sections. There are the two speakers, which we may not end up using. There is the panel for all the buttons, which we won’t need either. On top of that, there is the LED screen for the front panel, which is not useful. The keyboard is powered by a battery pack, which we probably won’t use. There is the keyboard section (bottom), which has groups of 8 diodes, each for a section of eight keys. Total, there are 49 diodes on this board. Connected to this board through the large gray ribbon is the ‘mother board’ for the keyboard.

The ribbon consists of 15 wires, connecting the 49 keys to the keyboard controller. I needed a soldering iron to completely remove the mother board to see the circuitry on it, but by peeking under, here was what was uncovered:
As you could see, the keyboard wires feed into a 38-pin DIP adapter, which feeds into some mysterious ball of black glue. What’s under this black glue is probably the keyboard controller / MIDI synthesizer.
Hmmm… 15 wires and 49 keys… how does that work? Well, I found an informative site online, for creating a simple keyboard controller with the PIC16F877A microcontroller, which we now have quite a bit of familiarity with:

(Credits for this diagram go to Thomas Scarff, Lecturer at Dublin Institute of Technology, School of Electronic and Communications Engineering)
The circuitry in the keyboard is probably very similar to the image above. The keys are arranged as a matrix with rows and columns. On the keyboard I got, the notes are probably grouped by rows of 8, not 16. The keyboard controller polls only one of the rows of eight keys at a time by asserting high one of the row selector pins (pins 34 through 40 in the image). When a row is selected, the values of the notes on the row will appear on the column pins for the keyboard controller (pins 2-9, and 19-30 in the image). For 49 keys, you need 7 columns of notes to select out the individual row of eight notes (49 / 8 = 7, rounded up). Doing the math, 8 rows + 7 columns = 15, which accounts for all the wires in the ribbon. Our next step is to figure out which wire corresponds to which row or column on the key matrix.
The keyboard controller continuously loops through all the rows of keys and collects data on the state of all the keys. When one key is noticed to have changed, a on or off key event will be triggered, depending on the new state of the key.
Well, that’s all for now, I will continue to give updates as our project progresses.

Spring Break

It’s Spring Break now. I officially have only one more Electrical Engineering class left before I graduate, EE 478, which is the capstone for Embedded Computing taught by Dr. Peckol, who I would have had for a total of four courses during my time at the University of Washington.
This past quarter was perhaps my busiest quarter yet… I took three 400-level Electrical Engineering courses. I took EE 477/525, the VLSI capstone course in designing digital integrated circuits. The class ended up taking massive amounts of time for the projects. There were three projects in total, which amounted to over 150 hours of work each. We used the FreePDK45 design kit to lay out the first two projects, which were a 256-bit SRAM cell and a 20-bit adder.
For each of the projects, we were graded competitively on a certain Figure Of Merit (FOM), which was a number we got from multiplying several measurements of our circuit. For our first project, which was to design a 256-bit SRAM cell, the FOM was Area×Delay², which you calculate by measuring the total area taken up by the chip and multiplying it by the worst possible delay for storing data in the chip squared. The team that got the best FOM got full points for the competition portion of the project, the group with the worst FOM got no points, and everybody else was graded in between on a linear scale.
For the first project, the 256-bit SRAM, my lab partner Kaitlyn and I did pretty well, and got the second-best FOM in the class. The following image shows our final circuit, which measures 19.38 µm × 13.78 µm (267.1 µm²). For reference, the smallest size square particle a person with 20/20 vision can see is 100 µm × 100 µm, so you can fit around 35 of these cells in that area.
Our 256-bit SRAM cell (click to zoom in)
This SRAM consists of five distinct parts: a 5-to-32 decoder, 16 bit-line pre-chargers, 16 high-skew inverters, and 8 bit-line write drivers. With our design, we measure a maximum read delay of 1.055 ns.
For our second project, we were required to design a 20 × 20 bit adder. For our design, we designed a delay-insensitive carry-lookahead with speed-up circuitry (DICLASP) based on an IEEE article we found online. What attracted us about this specific adder design was that it implemented an O(log(log(n))) algorithm, whereas most tree adders we encountered used an O(log(n)) algorithm. We deviated a lot from the implementation used in the article, whereas we made it not self-timed, and used N-P domino logic. Looking back, that might have not been a good idea, since we found out it took an extreme amount of time to lay it out, since it required 11 unique cells. One of the only three overnighters I pulled this quarter involved starting the layout for our design at 8:00 AM with my lab partner, and not finishing the layout until 1:00 PM the next day (29 straight hours of layout). Unfortunately, our effort on this project was not worth the results, since we learned N-P domino logic is not the best choice if you have long wires in your circuit…. Anyway, here is our final project layout:

20 × 20 bit delay-insensitive carry look-ahead adder with speedup circuitry (click to zoom)
I feel if we had more time, we could have optimized this circuit to have a much better delay, but we ended up with a delay of 1.898 ns, area of 453 µm², and power consumption of 322 fJ per computation. We ended up having the second-worst FOM, which was Area×Power×Delay² for this project. I felt that we really chose one of the hardest designs to lay out, and if we had more time for the project, we could have done a lot better with the FOM.
By the end of this project, we felt we really didn’t have much time to spend on the final project, which was a 10×10 2’s compliment multiplier with modified Booth encoding, so we stuck with a static logic implementation for the entire circuit. The most time-consuming part of this project was figuring out how to do 2’s compliment signed multiplication, since all the examples we were shown were for unsigned multiplication. We had to figure out on our own how to implement the partial products for signed multiplication on our own, pretty much, since there was nowhere in our text book or on the internet which explained how to do signed 2’s compliment multiplication.

New Apartment

Hello, everyone;

Yet again, I need to apologize for not blogging in a really long time. Time just tends to fly between posts, and being in Engineering, it feels like I can never find any leisure time to update.

I just moved into my new apartment in the last week. I promised I would upload some photos of my new place. I decided to move off campus for several reasons. One of the primary reasons is that the UW Housing and Food Services decided on a new rule that if you live in the residence halls, you have to subscribe to the university meal plan. The food really isn’t that great, and it is way overpriced. To illustrate, for a simple breakfast of a waffle, scrambled eggs, bacon, and orange juice, you can be charged over $10. I found myself in the habit of eating out every day, since it was cheaper and higher quality than provided by the HFS.

So after a week of searching, a fellow Electrical Enginner colleague and I found a good 2 bedroom apartment at Travigne Apartments. Our place is located on 11th Ave in the University District. After spending a week of searching, we decided on this apartment, since it is unusually high quality for the low price. I’m paying just a little more than I was for the residence halls, but now I am able to cook for myself, plus it is a significant increase in quality.

Main entrance

Our apartment is the one with the balcony on the top floor.

Inside the lobby area

Coming out of the elevator, our apartment is the first door on the left.

My futon, which until just recently, served as a bed rather than a couch. I got the blanket when I was on my first deployment with the USAF to Qatar.

Bookshelf containing the textbooks my roomate and I have been accumulating over the years, as well as leisure reading.

Looking outside to the balcony

Looking down from off the balcony.

My roomate’s grill, so we could eat lots of barbecue.


Kitchen area

The coffee pot, which is now used primarily for making tea since I quit coffee.

My desk and dresser area

My bed.

The apartment opens up rooftop access to the residents.

Views from the roof of the apartments. Blessed Sacrament Church (catholic), and a view of downtown Seattle and space needle.
Right now, I’m taking the Summer off from school. I began the Summer Quarter out taking a full load of classes, although I began to have really bad anxiety attacks for some reason while performing coursework. I think the main causes for this anxiety are because for Spring Quarter, I was pushing myself too hard, pulling too many overnight study sessions, and drinking coffee. This combination can make you really go crazy after a while. A couple weeks ago, I decided to quit drinking coffee, because I think that was the main culprit. After I quit coffee and went through a period of withdraw, I felt a lot better.
Now that I’m off, I intend to catch up with a lot of things that due to my course load, I never really could find much time to do: reading, learning new music, exercising, research employment opportunities and organizing unsorted computer files and stacks of papers. I’ll also be looking for Summer jobs painting and doing yard work.
I intend to be complete with all my coursework after Spring Quarter next year, and I will have a Bachelor’s of Science in Electrical Engineering. This next year is going to be my toughest year, since from the looks of it, I have a capstone design class every quarter. I’m intending on getting completing at least two areas of knowledge in the next year in Embedded Systems and Analog Circuit design, and if I feel like it’s not too much, attempt VLSI (Very Large-Scale Integration).
A couple weeks ago, I got called last minute to put together music last minute for a wedding. Due to a misunderstanding, the organist who was expected to do the wedding wasn’t in town for that day, so I was called up as a last resort a week before the wedding. I pretty much chose out all the music, and I got together with a good friend who plays the violin, and we put together a prelude. I recycled pieces I had used for another wedding a couple years ago on Bremerton Naval Base, and tried a couple other pieces that I used for Resurrection that I thought would work. Overall, I got very positive response for the music, so I was glad I could help out and remove that burden from the family.
Speaking of weddings, congratulations to my sister Rachel for her recent engagement to Alex! She is getting married on January 2 at Faith Presbyterian Church. May God shower his blessings on both of you.
In September, my Dad and I are once again hiking the Wonderland Trail (110 mile hike around Mt. Rainier), and we’re planning to spend a week doing that, so I’m trying to put together camping trips and day hike trips to make sure I’m in shape for that. Later this week, I will be at Eagle Creek for two days with my dad and some good friends.
Anyway, that is my spiel for the time being. I’ll try to update more often, although when classes pick up again, I really won’t have any time, so I’ll apologize in advance for not posting in so long, and I hope you understand.


I just happened to notice that my blog was horribly updated, and my last post was from back in August. Last year I took a web programming class to motivate me to create a really decked out web page, but it only taught me that it’s way too time consuming and too much effort. So here I am, using still.

I’m now on Skype, which seems like a really nifty online phone service. If you want, you can reach me with my user name, jfeucht82, and I’ll try to leave it on as much as possible. My philosophy is that I should pay as little on telephone communication as humanly possible. If you’ve ever tried calling me, you’ve probably noticed that I rarely carry my phone on me wherever I go, and I respond to email a lot faster than I do via telephone. I currently own the cheapest AT&T pay-as-you-go phones I could possibly get, and it’s malfunctioning because the ringer doesn’t work anymore for some reason.

I was just looking through my online degree audit (or a listing of classes you still need to graduate), and I figured if I take the right classes, I might be able to graduate the end of Spring Quarter in June. I’ve been following mostly the program requirements of VLSI (Very Large Scale Integrated) Circuits, although the final courses I would need for that program aren’t offered until the Summer or Fall quarter. On the other hand, I could take two engineering courses next quarter, and be done with the program requirements for Embedded Computing Systems, which is another field I have quite a bit of interest in. And I kind of want to exhaust the funds in my GI bill before I get out of the University of Washington, and I have funds to cover me through Fall Quarter this year, if I take classes over the summer.

So that’s something I’m going to have to start thinking about. I’ve been prettying up my résumé and cover letter for possible internships and jobs coming up, and I have some career fairs to attend…

This quarter, I’m taking two engineering courses, and a writing course (I have to take two technical writing courses). I’m also taking my first 400-level UW course, E E 471 Computer Design and Organization. This class seems like it’s going to be quite a bit of work. We’re learning how to design our own microprocessor using Verilog, which is a computer language designed specifically for modeling digital circuits. Over the course of four lab assignments, we will design critical components of the processor. The class pretty much deals with figuring out how a processor processes machine code, and how all the components in a processor interact with each other.

The other engineering course I’m taking is E E 332 Devices and Circuits II, which is a continuation of an engineering class I took last quarter. This class deals primarily with designing circuits with BJTs (Bipolar Junction Transistors), which are pretty much electronic parts that amplify signals. Our final design project is to design and build an audio amplifier.

Anyway, that’s all I have to say for now. Sometime in the near future, I might come up with something that’s actually interesting to talk about and blog about it, but as for now, if you’re too bored, you can check out my AC to DC in my previous post and marvel at how incredibly interesting it is.