Installing the Solid State Relay

I conducted a simple test today by hooking up the Solid State Relay (SSR) to the toaster oven and an Arduino's power supply.

The hot wire was already connected to both heating elements so I just connected the neutral side of the heaters to terminal 1 of the SSR using a connector I bought from RadioShack. Terminal 2 is connected to neutral in the power outlet. Terminal 3 and 4 are simply connected to 5V and GND on my Arduino. Having 5V across terminals 3 and 4 turns on the relay, creating a return path for current to pass through the heating elements. You can see that the toaster was successfully turned on.

Now, all I have to do is install the thermocouple and digitally control the temperature using the Arduino.

Taking Apart the Toaster Oven

Today I spent some time taking apart the toaster oven that'll be modified into a reflow oven. Not surprisingly, it was mostly empty. The wires seen here are temperature resistant, so I will be hanging onto these, and unlike most others I plan to keep the knobs in place for aesthetics. Now I need to figure out where to mount the thermocouple, which by the way I had to remove the heat shrink from because it will be heated beyond its 250C rating. I also now need to order the Solid State Relay I've been putting off buying.

Making a Reflow Oven

I've started working on a DIY reflow oven based on this instructable.

Instead of working on it my usual way from scratch I decided to do it the easiest and fastest way using an arduino and a breakout board from adafruit linked here.

Today I got my breakout board and thermocouple in the mail so I put it together and tested it with the example code provided on the website. It turns out that as people have noticed the thermocouples have incorrectly colored wires. This was easily fixed by reversing the wires.

I broke down the project into the following steps, of which I am now moving on to step 2. However, before moving on to the next step I will need to figure out if the heat shrink around the sensor can handle high temperatures. When I tested it over a lighter it was smoking a bit and most pictures don't show a heat shrink tube around it.

1. Setup and test the thermocouple
2. Install thermocouple in toaster oven and monitor its temperature
3. Order then install a solid state relay to control the temperature

Android App Tutorial

Just built my first android app following android's official tutorial. I've been pretty frustrated by the lack of Kindle apps so I decided I will build them myself. Specifically, I am frustrated most by Bloomberg's android smartphone and kindle fire apps. They are awful..

The tutorial itself felt kind of lacking. Given the ridiculous amount of app developers out there I'd assumed that the tutorial would be much easier to follow, but it does require programming experience. In fact it requires experience learning a new programming language or API. I'm no expert in either, but I guess I knew enough to get through the first step of the tutorial. Here are some interesting takeaways from my first step:

1. All 'Activity's must be declared in the manifest
2. Every 'Activity' is invoked by an 'Intent'
3. 'Activity's can get its invoker using getIntent()
4. Most programming is done within the framework provided. My job as an app builder is to work on the actual content

I'm not sure how long this will last, but hopefully my efforts will be fruitful.

The Trap of Design vs Analysis

"Don't be intimidated and just start somewhere"

Over my years as an undergrad, school exposed me to much theory and many closed form solutions. I have been inspired by the science and mathematics behind engineering. Having started from DIY high school I always found theories to be irrelevant for the most part, simply because any circuit can be tweaked to operate correctly. However, despite my initial preference towards practical learning, I somehow became obsessed with closed form solutions: solutions that can be entirely and certainly solved through theory and math. I couldn't step up to the task in my earlier graduate courses in analog IC design. In thinking too deeply about everything that could go wrong I forgot that what matters is that your design works.

A few days ago at my design review meeting with my professor about my LNA my professor clearly saw I was struggling. Even with the deadline approaching I was still characterizing the IC process to derive constants of the transistor devices. He then told me to stop being intimidated and start somewhere. I always found this prof to be very intimidating for how he speaks, but this time his words resonated (no pun intended) with me. He began sketching up a design based on the project specifications and very simple device parameters; before I knew it, he was done with enough to begin simulation.  

Although his design was using idealized components (no noise, loss-less, etc.) with all of the theory I've learned I can easily make up for the discrepancies later. Back when I didn't understand anything and I didn't know better but to build first, then learn, then fix. It turns out that I was doing the right thing all along! The only difference that knowledge of theory seems to make is in early design stages and when the bugs arise; with each bug we are simply able to make informed and goal-directed decisions. What's great is that this type of work can also lead to invention and innovation, as the frontier or engineering may simply seem like another bug. Theory moves engineering forward but only through implementation!

After telling my classmates the same thing all along, it's ironic that I would be trapped by the same mistakes of thinking I'm a scientist when I'm an engineer. I could never understand why people couldn't build, but now I understand why. I will forever appreciate my professor for saying that right thing at the right time. 

Realization

I've slowly come to realize how naive I am as a circuit designer. While working on my robotics circuits I have experienced unreliable circuit performance countless times. However, I had never considered to mitigate this effect through better design practices; instead I have constantly relied on programmed software calibrations to counteract variations between circuits. Considering that I use very basic 8-bit microcontrollers in my robotics projects, the several instructions for software calibrating sensor data was wasted processing time. Additionally, as someone studying circuit design this is a depressing state of ability to be in after studying so hard. Looking back to all of my circuits, I see that although my ability to analyze complex transistor typologies have grown I have never applied any of my new found skills. From now on I hope to utilize what I spent the last 4 years as an undergraduate studying as I rebuild old circuits and design new ones.

Optical Encoder Tested

I tested the completed speed sensor. The first picture below is the output waveform (sinusoidal-looking yellow line) of the photo-transistor. It looks like there are two traces because the infrared LED is pulsed. The straight top yellow line is when the infrared LED is off. The peaks of the output occur when the photo-transistor sees the least infrared light (reflected off the dark part of the encoder wheel) and the troughs occur when the photo-transistor sees the white sector of the encoder wheel. 

The two screen captures below show the output of the photo-transistor and comparator circuit. The comparator circuit compares the output to the photo-transistor with a reference voltage of 4V (mid-way between the peak and trough) and outputs 0V or 5V depending on whether the sensor output is bigger or smaller than 4V. The periodic glitches seen in the circuit is from the H-bridge, which is driving the motor with a 25% duty-cycle square wave. For the final mobot we will use separate power sources for the motor and the rest of the mobot.

config vs config1 explained

Recently I started to use pic18f27j53 for a robot project. I picked it since it had USB functionality, and I thought I could learn about USB through it. Just as I copy-pasted my old code from my previous robot projects, error messages began to show up on the compiler output saying that opentimer1() was missing an argument. This confused me and, upon research, I discovered that many others were confused as well. So I decided to look through the source file (t1open.c) in the C18 library to see why there were two arguments (config and config1) as opposed to just one (config1).

Well, it turns out that some of the new microchip hardware has included some new functionality called Gate Control to the timer hardware, which introduces the possibility of controlling it through external asynchronous inputs such as the comparator module. This, I think, allows users to count the duration of an input.

Anyways, for those who do not intend to use the Gate Control Hardware, config1=0 should do the trick. Since config1 controls TxGCON (Timer X Gate Control), according to the datasheet, if you set config1 to zero Gate Control will be disabled.

Optical Encoder Protoype

Above is the speed sensor prototype and its schematic. The infrared LED (TSMF1020) and photo-transistor (TEMT2020) will be reading from a rotating disk colored black and white. The photo-transistor will detect the highest levels of infrared light when it sees the white part of the disk, which will lead to a higher voltage drop across the 100 ohm resistor.

The board will be tested to find the optimum system geometry and the system's sensing limitations (e.g. max velocity).

Transmission Line Effect: Bouncing Voltages

It's 4am on black Friday at Walmart. A single door opens and millions of people including yourself run to the entrance as one mob. You're running as fast as everybody around you. As the people near the building, those who luckily made it to the door enter the building. However, you, being at the front of the mob and having not run close enough to the door, smash into the outer walls of the building. The people behind you don't see the wall yet and keep running, pushing you into the wall even more. Soon enough, you have the collective force of thousands of people squishing you. 

The same thing happens with voltage. When entering a high impedance load (narrow doorway) from a low impedance cable (wide parking lot), voltage (pain) can spike up as you can see in the simulations below (Line C, top trace). The input voltage is only 100V, but the voltage at the load jumps up to 160V.

When you push back, the people behind you push the people behind them, and a wave of shoving propagates down the mob of people. When this wave reaches the end of the mob (the people at the very back) they push forward and that wave propagates back to you. This phenomenon is called ringing as demonstrated in the oscillation seen in the top trace.

Below are models of cabling. The inductor keeps the current going, just like you want to run at the same speed as the people behind you (to stay alive). The capacitor is like the space infront of you; it's somewhere to run to. Almost all conducting cables can be modeled this way, a chain of infinitesimally small units of L, R, and C. All cables have parasitic inductance and capacitance. Line D and the top trace demonstrates how doubling the cable length (double length of Line C) doubles the amount of time for the voltage to hit the load. This is just like having the parking lot double in length. It takes twice as long for you to run into the wall.

 Moral of the story:

• Walmart on black fridays is dangerous. 
• Unexpected voltage spikes fry parts when cables are too long or impedances are not matched.

Dual H-Bridge Board

Below is the result of one full week of thinking, layout, and planning. These H-bridges are made to control two small dc motors. The H-bridge can take up to a 500 mA load. This board will probably be integrated into my scrapbot. The simulation for this circuit can be found here.

I am currently working on a microcontroller to modularize the h-bridge unit. The plan is to be able to send serial instructions to the H-bridge driver microcontroller to drive the motor.

Awesome Resource on PIC ASM

I have recently been working on a project that requires me to return to Microchips Pic Assembly Suite. Having worked mostly on Pic C18 for a while, it was a little difficult to program in assembly again. After a couple minutes of research on the web, I found an awesome resource for Pic hardware and assembly.

Gooligum Electronics has very detailed information on various ranges of hardware complexity and accompanying assembly code to help use the hardware as well. This link will also be included in the useful links box on the right.

H-bridge simulation

I always believed that to build an H-bridge I needed to use FETs. I'm guessing that it was because of the small device package of Bipolar Transistors that I thought that it will not be able to power it. Well today I realized that some of my motors are probably small enough (low power) to be powered by BJTs. This also made for a great opportunity to test LTSpice some more. Eventually I hope to improve my mobot H-bridge design in efficiency using these tools.

Below are the results. You can see that the flyback diodes really do help protect by limiting the various potential differences to below their respective breakdown levels. The blue trace represents the input signal and the green trace is the voltage at one end of the inductor with respect to ground. 

WOOOOO! FPGAA

I just got my new FPGA development board, BASYS2, by Digilent. Since everybody at my workplace seems to be using VHDL rather than Verilog, which is what I learned in school, I will be attempting VHDL this summer!

My first project will be to make an oscilloscope by the end of this summer. I will be polling an external analog to digital converter, giving it a time stamp, and sending it over USB to a Python script that will process the data and display it. The reason for using an FPGA is first to get practice with it since it looks like people like digital hardware experience. The second reason is because I can simultaneously poll and communicate if I create a buffer. If I were to do this with a microcontroller I would have to interlace the two actions, which is a pain.

My first step is to make basic components such as a register so I can start creating finite state machines and whatnot.

Completed Mobot

30 minutes into the competition, after about 20 hours of non-stop building, we finally completed our mobot. The mobot, patched together by band-aids, gave us problems until the the very end, until everything just came together and worked. From the back of the mobot, you can see the h-bridge, microcontroller, and power board. In the very front under the cardboard is the sensor board.

We were able to make our last heat, but unfortunately we were not able to place. Other than our lack of time we had issues such as an under-spec motor and incomplete sensor board, which essentially decreased the mobot's performance. The motor was run at almost double its rated voltage and as a result we saw constantly degrading speed and torque. The sensor unit used was actually the sensor module built for testing and not for the competition. We simply didn't have enough time to create a new one. 

Overall, this season of mobot was pretty good considering the quality and sophistication of hardware produced. Being students at Carnegie Mellon, we are fed so much information and work at a sporadic rate that the difficulty of managing time is understandable. However, this will be our main challenge going into mobot 2012.

Playing with Darlington Pairs

I wanted to light an LED without affecting the input impedance of the device I was measuring without buying a FET. Having the Darlington pair creates the digital-like steep ramp you see below in the simulation results by achieving the product of the current gains (beta) of each of the NPN transistors. The base resistor decreases the base current to a minimum to prevent affecting the load of V2. The green line shows the I-V relationship of voltage source V2 and its current output. You can see a slight change in slope (Ohms) at the output end, but it is negligible considering the purpose.

Custom Interface Design

For the last three months I have been designing a custom interface for the auditory lab at Carnegie Mellon University. I built an array of infrared sensors and interfaced them to MATLAB using PIC18f25k20 and other proprietary hardware. The chassis was put together by Guilliaume Lemaitre and Nicolas Zuniga from the auditory lab. The goal of this project is to measure motor response time to auditory stimulation. 

Below are photos of the setup and circuits. The sensor unit shown below is a part of this circuit. The infrared LED driver portion can be seen on the cpu board. They were separated to minimize sensor size. The cpu board accepts up to 4 sensors: one IR long distance (5cm) sensor and three IR (1cm) sensors. The 5cm sensor is used to detect vertical movement and the 1cm units detect if and object is above it. The IR sensors used to be contact switches, but they had to be replaced because it contaminated the auditory stimuli.

Tutorial on H-bridges

Here is a pretty descriptive tutorial on H-bridges : http://www.pyroelectro.com/tutorials/h_bridge_4_transistor/index.html

Back to Basics

After briefly reading my textbook, I decided to build a current mirror using random BJTs that were lying around. Q3 is there to reduce the base-current error. Since I don't have a desktop current source I decided to use a biased PNP transistor. This was a great opportunity for me to try the simulation capabilities of LTSpice. As you can see below, the LTSpice simulation closely matched the actual data.

Strangely, regardless of Q3, there was a 33% loss in the current mirror. This was probably because of the low current level I was mirroring. High beta values lead to higher error as well.

Two days left!!

There are only two days remaining between today and the competition!

We have successfully integrated the