Last updated: 7/9/2018

Here are some of the projects I have been working on over the last couple of years. I try to keep this page as up to date as possible with information on what I'm doing. Most recent projects are at the top. All information is free to share as long as it is properly cited. To the left is a list of the projects housed on this page with jump links to the relevant position on the page.

To fulfill the final credits required for my Electrical Engineering degree at Oregon State, I took it upon myself to design a new access control system for the Universities Amateur Radio Club, W7OSU. I was able to make this into a project work upper division credits with the sponsorship of my Senior Design instructor Don Heer. The project started out at two credits, though this was eventually changed to six credits in order to reflect the amount of work put into the design and construction.

With any club, providing access to resources for members can be a difficult challenge. Balances between cost, ease of use, and security must be made in order to allow for this to be a smooth process. Since 1984, the OSUARC has had a simple keypad door lock system connected to the club room door allowing for members who knew the code to access the room. Three years ago, this access control system broke, and as such it was decided to design and build a new system to take advantage of the technological improvements that have been made in the world of electronics since the original system was first created. It was decided that the new system should allow for multiple ID numbers to be entered so that each individual in the club can have their own entry number, and entries can be tracked by user using an integrated access log.

The door lock itself is built around an Arduino Nano microcontroller board. The decision was made to use an Arduino board instead of a standalone microcontroller such as the Atmega328 because of the added features of the Nano such as the USB to serial interface and integrated regulator, all in a small size compared to through-hole components. A secondary regulator on the board allows for different voltages to be supplied to the door strike which is controlled through the relay circuit. Communication between the ID card reader or keypad and main board is done over the Wiegand protocol, and industry standard access control protocol which allows for long transmit distances. Headers are also provided for serial communication for things such as Bluetooth and a jumper configurable relay override is also provided which allows the door to be opened with an external power source in the event of a power outage. Settings such as programming mode and server authentication are set using the five DIP switches on the board. The door strike mechanism can be implemented in many different ways though generally it is done using a 12V solenoid. A SPI header and standoff mounting points allow for an Ethernet module to be installed providing server authentication.

For software the Nano is programmed in Arduino-C, with plans to recode the system in pure C for better optimization. In standalone mode, the door lock can hold up to 30 non volatile ID numbers of up to 9 digits each. These numbers are stored in EEPROM and can survive power failures. The system also includes a volatile access log and time which must be set through the serial terminal upon reset or power cycle. Information about the system such as time, access log, whitelist and adding/removing can all be accessed through the serial terminal which is connected to a computer through a mini USB cable. Programming can also be done with the DIP switches located on the board, allowing for both adding and removing of ID numbers through the keypad or ID card reader when the system is set into programming mode.

When in server authentication mode, the system will query a server through UDP over the Ethernet connection when an ID is entered onto the keypad or ID card reader. The server then sends back either a granted or denied message and both the server and system log the transaction in their respective access logs. When first starting up, the door lock will receive an IP address from the DHCP server, which in standard configuration is running on the same system as the Access Control server. This computer also runs an NTP server which the door lock queries to update the internal clock of the system. If the door lock queries the server and does not receive a response within a specified time then it will use the system on board whitelist. The Access Control server is written in C++ and runs on any Unix like system that also supports running NTP and DHCP servers. All network traffic is unencrypted UDP so it is highly suggested that the server and any connected door locks be run on a separate LAN network disconnected from the Internet and any other devices. At this time I am not releasing schematics or code for the system but bellow are images of the door lock installed in the W7OSU club room as well as images of the PCB and assembled system.

For my degree in Electrical Engineering at Oregon State, we are required to complete a senior design project. This is a year long design challenge where we work with a stakeholder to develop a product from simple requirements all the way to a completed product that we can show at the Engineering Expo at the end of May. This is an ongoing project , and as such, information here will continuously change. Most information though will be located at our Senior Design Project Site, whose link is down below.

My team's product is a bike power USB charger, capable of converting the mechanical energy of riding a bike into power that can be used to charge a USB device such as a phone or table. The design provides an output of at least the minimum USB specification of 500mA, with plans for a higher output as well as an internal battery to allow continued charging even when the bike is not in motion. Our team consists of myself and two other Electrical Engineering seniors and our stakeholder is a PHD student in the Electrical Engineering program at Oregon State. At this point, we have a block diagram complete, along with designs and prototypes for certain internal components. The system also has a companion Android smartphone application that is capable of reporting power generated by the device over time.

Senior Design Project Site

One of my favorite engineering courses at OSU was ECE 473, Microcontroller System Design. This course was taught by the wonderful Roger Traylor, and following with his style, was a dive right into the deep end of microcontroller design. The course saw students writing firmware for an Atmega328 Development board in pure C, making use of an ever growing number of ports and protocols as the course progressed. This culminated in the design of an alarm clock with a built in radio allowing for music to be played when a specified time was reached. Bellow are photos of my completed alarm clock and a link to all my relevant files for the course.

As with many of my projects, the system centered around an Atmega328, this time on a development board also used for other courses in my time at Oregon State. The screen is controlled using a shift register and is encoded in hexadecimal, as is fairly standard with seven segment displays. The rotary encoders are controlled through interrupts and a number of pins that can decode the position of each encoder. The buttons, arguably the simplest input of the system, are controlled through polling, being checked every clock cycle. Output is sent to an indication light bar using the SPI protocol, and control of the radio board is done using I2C. Managing to get everything to work in harmony is something wonderful to see, and to feel knowing what all is going on behind the scenes.

ECE 473 Class Files

For my Electronics 2 class at OSU, we were tasked with designing and building a stereo audio amplifier using only BJT transistors capable of driving an 8 ohm speaker on each channel and having a minimum gain of 10. The amplifier runs off of USB power, constraining maximum current draw to 500mA. The amplifier circuit at the center of the design is divided into three stages. First being the gain stage, where the signal is maximized as much as possible. Next is the buffer stage which helps to match impedances between the input and output. Finally comes the power stage, in this case a class AB amplifier which provides the necessary power to be able to drive the speakers, and maintain the magnitude of the signal.

Our task also required us to improve on the basic amplifier design in at least one way. I decided to implemented two improvements, these being a case which could house the amplifier and speakers, as well as having panel mounted volume control and input and output terminals. The other being a digital VU meter on the front panel of the case that could actively display the volume of each channel up to a maximum of 3.1V. The VU meter is based on two LM3915N logarithmic bar graph drivers which can be be configured to a specific reference voltage and LED current. While the LM3915N can drive up to 10 LEDs in a bar graph, I chose to only use 5 LEDs per channel because of limitations on panel space and current restrictions. The entire design draws approximately 200mA max, and has a gain of about 10. Below are photos of the finished amplifier in case and the schematic for the amplifier circuit as well as that of the VU meter.

Amplifier Presentation Slides

For my ECE 322 class at OSU, our lab project was to build a variable bench power supply, that we could use going forward in our time at school. The power supply is plugged into a wall outlet and is able to output between 2V and 12V both positive and negative with a maximum currnet draw of 1 Amp. To add some extra funtionality to mine, I decided to install two multimeters on the front panel, which allow you to see the current output voltage and current draw from the power supply. While the general idea of each part of the circuit was taught to us in class, all values were calculated by each student, leading to mostly unique units. The power supply I designed and built is able to go down as low as 1V, and also has a fan on the rear panel, to help manage heat from the transistors.

One problem that I had while building the power supply was being able to test each circuit, as they all rely on each other to be able to see any considerable output. Transistors can also be somewhat fragile if they are not used in the correct way, this means that when a compent was not connected correctly, it could lead to a failure and the need to replace the component. This can be very difficult when all components are soldered to a circuit board. One of my fellow classmates had the idea to use female headers to be able to quicly replace the transitors should they fail. While I did not implement this idea on my power supply, it is definitely something I will consider in the future, as it would have saved a considerable amount of time when trying to isolate a problem while building and testing. For a more in depth look at the design, including a parts list and circuit schematics, take a look at the power supply specification document below.

Power Supply Specification Document

As an update to the power supply I designed and built for my Electronics 1 class at OSU, I decided to create a printed circuit board for the power supply in order to build multiple power supplies to give as gifts to a few of my engineering friends. I designed the boards using Eagle and had them manufactured by DirtyPCB. The board contains all circuitry needed from initial transformer input to variable output except for the potentiometers and volt-ammeters. The PCB circuit maintains all the features of the prototype but is half the size, and much more robust. This allows for a smaller case and smaller footprint. It also means that it is possible to have two PCB circuits in the same size case as the prototype, giving two positive, and two negative channels.

While testing one of the PCB circuits I did come across a possible flaw in the capacitor discharge circuit design. The MOSFET that allows current to flow through the discharge circuit is turned on when the voltage across the gate and source is above the threshold voltage. This occurs when the circuit is on and the gate voltage is kept high by a half wave rectifier. When the circuit is turned off this stays high for a while because of the capacitor, while the source voltage is zero, turning the MOSFET on. The problem is that both the rectifier and MOSFET have a voltage drop of .7V, resulting in a total 1.4V drop. The threshold voltage of the MOSFET used can vary between .8V and 3V, which means that the threshold voltage can be less than the voltage drop meaning the MOSFET is always on, drawing too much power through the discharge circuit. The only way to remedy this is to check the threshold voltage of each MOSFET before using it in a circuit.

PCB Files

I came up with the idea for the equation clock out of my own necessity. I have a hard time waking up in the morning, and sometimes turn my alarm off without even knowing it, resulting in sleeping in and even missing a flight. To help with this I thought about how I could be become more awake when getting up. I decided that doing math would probable get my brain going and so I came up with the idea of an alarm clock that makes you solve an equation to turn it off.

At the time I started designing and building the equation clock, I had only a minimal, self-taught knowledge of electrical engineering concepts, and some experience working with Arduino. With these skills I began creating my design of the clock. The clock is based around an Atmega 328 microcontroller and features an LCD screen and keypad for entry, as well as speakers. It is battery operated but can also be plugged in as well. While the original concept slightly resembles movie prop bomb, I envision the final product to look more like an actual clock, or maybe something like a landline office phone.

Current Souce Code

This was a project that I completed with two other students in my Principles of Engineering class during high school. We had to complete a design challenge of building a three level elevator. We had a personal goal of being able to use it to lift a small robotic tank we had previously built, that is why it is so large. While my colleagues worked on the physical design of the elevator, I designed the sensor arrangement and wrote the firmware. The elevator is built using a VEX Robotics kit and the controller is programmed in RobotC. The firmware can be found both below, and in the Program Repository.

The elevator has a switch on every floor that acts as a call button, a rotary encoder at the top attached to the motor axle, and a limit switch at the base of the elevator shaft. One major problem we had was with inaccuracies with the rotary encoder after prolonged use of the elevator. This would cause the platform to either go too far, or not far enough when trying to reach a floor. To resolve this issue, we placed the limit switch at the base, so that every time the elevator goes to the first floor, the position is set to zero. Below are pictures and a video of the elevator in operation.

Elevator Souce Code

During my senior year of high school, one of the classes I took was Principles of Engineering, the subsequent class after Introduction to Engineering Design. This class covered general engineering topics in multiple fields, including civil, mechanical, and a small a mount of electrical engineering as well as computer science. The class used the VEX Robotics kits for much of the second semester design projects including the elevator seen above. While we did not use the robotics kits until the second semester, we were permitted by our teacher to learn how to use them during study times. My friend Alex and I decided we wanted to make a small robotic tank using the kits and we started building it fairly simple, and continued to add items and features over the course of the year. Starting out, we designed the body to the tank to be long and fairly narrow. The tank tread layout is somewhat based of the English WWI tank design, with the treads shallow slanted in the front and more steeply slanted in the back. One consequence of this design was that the front is heavier than the rear, so that when the tank it at rest, ti leans forward, but as as the tank moves, the rear portion of the track is on the ground. Each tread is powered by it's own motor, allowing for the tank to turn sharply. A problem with this though is that both motors do not run at the same speeds, so tuning was necessary to allow for the tank to go straight.

Initial control of the tank was through a game controller connected to the tank's microcontroller through a USB cable. Bluetooth transceivers were included in the kit, though establishing a link can be difficult. A claw was added which could be lowered and raised using the controller, this could also help to shift weight and change on which side of the treads the tank rested on. We then decided to add an autonomous function to the tank, and we decided the best way to implement this would be to allow it to be able to drive itself. To accomplish this, we mounted two ultrasonic distance sensors, more commonly known as sonar sensors to the front of the tank, each slightly angled outward. These provide the tank with a sensor of distance to objects in front of it, and with both sensors angled outwards, the tank is able to decide which way it should turn when faced with an obstacle. The firmware for the tank can be found below as well as in the program repository. Autonomy can be switched on and off from the controller, and while in autonomous mode, the tank is able to drive almost entirely on its own. Some places where the autonomous mode has problems is when the tank is faced with thin objects, as the sonar sensors have a hard time detecting them, as well as when the tank reaches a corner, as it tends to continuously move forward and backward indefinitely. I attempted to remedy this by forcing the tank to back up and turn if it moves forward and back enough times but I don't know if it was entirely successful.

Building this robot gave my friend and I an advantage in the design challenges that followed during th course. Because we were already familiar with the hardware, including sensors, and how to interface with them, it was very easy for us to be able to work on the electronics and control side of the projects, such as the elevator seen above. Below are pictures, as well as a video of the tank along with the source code for the tank's firmware which is written in RobotC.

RC Tank Souce Code

 

Home

Created and maintained by Drake Vidkjer, for more information contact me at drake@vidkjer.net