PC based temperature control

Our project is a standalone temperature and fan monitoring and control unit for the PC. It uses the temperature readings to adjust fan speeds in order to regulate temperature and noise. The system is flexible in that it can be configured to be either completely autonomous, or set up to be configurable. It is also highly configurable in the setting up of the features and parameters. The entire unit is controlled by the 2 Atmel Mega32 MCUs - 1 for the main control unit and 1 for the RF remote control, with inputs to the ADC (for thermal sensors), port pins, RS232 serial connection and output to the LCD, port pins and RS232 serial connection. The RF remote control controls specific settings of the unit. The main unit is powered off a standard 4-pin PC Molex power connector while the remote control is powered off a 9V battery.

Computer devices have steadily increased in transistor count and clock speed as dictated by Moore's Law. Despite various attempts at reducing power consumption and dissipation, power budgets have increased steadily, and thermal output has also increased correspondingly. Over the past 2 decades, microchips have gone from requiring no cooling, to passive cooling with a heatsink only and subsequently to active cooling with a heatsink and fan. As thermal output continues to increase, exotic cooling techniques that require large and fast spinning fans will undoubtedly be required.

Figure 1. Comparison of fan noise vs fan speed for various fans

With such high spinning fans comes another problem of noise. There is typically a tradeoff between cooling performance and generated noise. PC enthusiasts often go to great lengths in order to achieve an acceptable balance. Traditional fan systems have dealt with this problem either with manually adjustable fan speeds by the user or automatically by the host CPU. The former requires user intervention, which is cumbersome and potentially unsafe, and the latter requires intervention by the host CPU, possibly slowing down the system and requiring system hardware and software support for temperature monitoring and control. Autonomous standalone units are available, but they are rare and very expensive. A DigiDoc 5+ 5.25" front panel unit with similar features can cost over $50. We designed and build a flexible, inexpensive, microcontroller controlled standalone PC temperature monitoring and control unit that can either be run autonomously or configured manually.

The system behaves in one of two modes - autonomous mode or manual mode. Mode selection can be done either via the pushbuttons, HyperTerminal commands or the with remote control.

Autonomous mode

Figure 1. Fan Speed vs Temperature

In autonomous mode, the MCU monitors temperatures via the 2 LM34 temperature sensors, and determines the appropriate fan speed to spin the attached fans. Below a user configurable threshold temperature, the fans are disabled. Once the temperatures detected are above the threshold temperature, the fan speed will be ramped up linearly from not spinning to maximum fan speed at another set temperature. The fans stop spinning once the temperatures detected drop below the threshold temperature. If the temperatures continue to increase past a temperature limit, a corresponding alarm and LED is triggered, warning the user of high system temperature.

The speed of the fan can be varied with 2 methods, either by voltage regulation or PWM. With voltage regulation, the fan supply voltage is varied in the range of 7-12V. With PWM, the supply voltage is alternated between 0V and 12V with a varying duty cycle. Both methods achieve fan speed monitoring, but have their pros and cons. Voltage regulation is easy to implement and has few side effects, but since most fans only start spinning at ~7V, the minimum speed of the fan is limited to ~50% of the maximum speed. PWM has the advantage of a lower minimum speed of down to 10% of the maximum speed, as well as reduced power output and less voltage loss, but has the added complexity of requiring additional circuitry to retain the fan tachometer signal.

Manual mode

In manual mode, the user will have access to 2 potentiometers that vary the fan supply voltage to either fans independently. If the monitored temperatures exceed the maximum value, the alarm and corresponding LEDs are activated. In both modes, the monitored temperatures and the fan speeds(if supported) are output to the LCD for feedback. If supported, the system will also detect a locked fan rotor and activate a corresponding alarm and LED. The system parameters such as threshold/ maximum temperature and modes are user configurable via HyperTerminal. In addition, a remote control allows threshold temperature adjustments and mode switching.

The entire system consists of 2 units - the main control unit and the remote control. The high level block diagrams are shown below:

Main Unit

Figure 1. Main Unit Block Diagram

As the above block diagram shows, the main unit utilizes several of the MCU features learnt in class, including the I/O port pins, RS232 serial connection, the ADC(internal, not shown), LCD display, LED output, piezo speaker output and PWM output with varying duty cycle. In addition, a 4-bit R-2R DAC was built to control fan 1 via linear voltage regulation from 7-12V, and several switches were used to switch between inputs. For the switch between HyperTerminal and the RF receiver, we used a MAXIM MAX4053 triple analog mux to handle logic level signals, and for the switch between autonomous and user mode, we used two OMRON GE6 SPDT electromechanical relays to handle high current, +12V voltage sources.

Remote Control

Figure 2. Remote Unit Block Diagram

The remote control is relatively simpler than the main control unit. It simply has an MCU on a protoboard, a RF transmitter into the RS232 port to wireless transmission of user input, buttons for user input, and LEDs for status display.

The hardware design of the fan controller was more involved than we anticipated. Because we are interfacing several I/O pins with the DC fan motor, we had to use several optoisolators, one for each pin. In particular, the 4-bit DAC required 4 optoisolators just for the input to the DAC alone. This is one of the reasons why we didn't go with a higher resolution DAC.

The circuit was conceived and designed before the lab, and simulated in software. This saved us a considerable amount of time trying out potentially bad ideas and focus on building good ones. Even so, due to the complexity of the circuit, getting the hardware to work correctly was a trying process that took us around 2 weeks. In the process, we went through several optoisolators, opamps and transistors. All circuits were done on breadboards and component boards.

Figure 1. Bird's eye view of the breadboards in an intermediate state

Temperature Monitoring

Temperature monitoring was pretty straightforward as it was already accomplished in Lab 5. However, we are now monitoring 2 temperatures, and hence require twice as much hardware. We chose the LM358 dual opamp as it was in our possession beforehand, and hence was free. More importantly, it was a dual opamp in a DIP-8 package, hence saving us valuable breadboard estate, which as you can see in the above diagram, was large. A gain of 3 was used in both sensors with a 10K resistor dip pack, to raise the voltage output of the LM34 sensors to a higher level. Both sensors were calibrated in software.

Fan Speed Monitoring

Figure 2. Fan tachometer output scope

We supported fan speed monitoring via the tachometer output from standard 3-pin PC case fans. Research was done on what the signal looked like. Contrary to initial speculation, the output isn't a voltage corresponding to fan speed, but rather a pulse of varying period, created by the hall effect sensor within the fan. A 1Kohm pullup resistor to 12V was used to produce a nice clean square wave that is fed into the emitter side of an optoisolator. A 1Kohm resistor was chosen to provide enough current (12V/1000ohm = 12mA) to drive the emitter side of the optoisolator, while keeping the current low enough not to damage the fan tachometer circuit. The collector of the detector side is pulled up to 5V with a resistor in series, and the emitter is fed into the MCU port pin and translated to a fan speed by software.

Temperature/Fan Control

Temperature is controlled by regulating the fan speed of the fan. In user mode, the user has control over the speed of the fan via 2 trimpots (right side of Fig. 1) that directly adjusts the fan supply voltage from ~7-12V. In autonomous mode, Fan 1 is controlled by voltage regulation with a 4-bit R-2R DAC that is optoisolated from the fan motors. An enable pin switches the fan on/off with a TIP31A NPN transistor. When the fan is on, a 4-bit binary value is specified by the MCU with 4 port pins. This value is then converted to a 0-12V voltage by the DAC, with 16 discrete voltages in between. It is then compressed to the 7-12V range with a resistor divider network, and then current boosted with an emitter-follower circuit. The emitter-follower circuit includes a low power 2N3904 NPN transistor and a high power TIP32C PNP transistor. A 0.7V voltage drop is incurred, but this is a design choice. A low-dropout adjustable voltage regulator could have been used instead, but this would cost more at the benefit of losing only 200mV. The fan 2 circuit is identical to fan 1, except the DAC is removed (auto mode is now connected directly to +12V) and the enable bit is now the PWM signal. The circuit is protected against reverse current spikes of the the motors of the 2 fans with a diode. In addition, the MCU is optoisolated from the fan circuit.

A Venable bit was used on the DAC/PWM voltage sources to turn on/off the fans. In the PWM mode, this bit is also used as the PWM signal. It is implemented with a TIP31A transistor acting as a switch, and the signal is optoisolated. A 1K resistor was chosen to provide sufficient current to the optoisolator while not drawing too much current from the prototype. While the original 300ohm resistor worked for the STK-500, the protoboard is apparently unable to support the current draw of the combined output pins.

Switching

Switching between user and auto modes is done with a 12VDC SPDT relay that has a 3A current rating. During the design phase, we explored the use of analog multiplexers, reed relays, high current SPDT IC switches, but ultimately decided to use electromechanical switches as only they had a high enough current rating to support normal DC fans and was economical. The downsides are the slight size increase, the soft clicking sound when a switch occurs, the low switching speeds and the fact that it contains moving parts. None of these are issues for our application though. Since the relay is a motor, it creates a negative current spike on a switch. We placed a diode in parallel with the relay coil to guard against this, as well as optoisolate it from the output port pin.

Switching between wireless mode and HyperTerminal mode is required since both make use of the serial port. It is an inherent design limitation with using the serial port of the MCU, but one that doesn't pose a huge problem. A MAX4053 triple 2:1 analog multiplexer was used to switch between the 2 inputs. The MUX was chosen as it supports both analog low voltage signals as well as CMOS/TTL level signals, and had 3 MUXes for redundancy. The select bit is physically connected to toggle switch that toggles between the 2 modes.

Switching between on and off (or high and low for PWM) for the auto mode is done with a TIP31A NPN transistor as it was free, has a high enough current rating and worked well. A slight voltage drop from 12V is incurred, but this isn't a big problem in our application.

MCU/Protoboards

Figure 3. Protoboards in an intermediate stage

To stay within budget, we opted to use 2 protoboards instead of the STK-500 development board. Testing was done on the STK-500 and then verified on the actual protoboards. Extra hardware such as the DIP sockets and power sockets were soldered on even though they were not needed in the final design. This was done to aid in debugging, for redundancy and "just in case", as the soldering stations were often packed. In the final design, the main unit is powered off a computer power supply unit (PSU) and the remote control unit is powered by a 9V battery.

The remote control unit has 5 buttons that send data to the main control unit in order to control it. Four of these buttons control the threshold temperatures for the 2 fans(up/down), and the 5th switches between user and auto mode. All 5 are connected to port pins of the remote MCU.

RF Wireless

Figure 4. Remote controller unit in action

We used the Radiotronix RCR-433-RP receiver and RCT-433-AS transmitter. The receiver is soldered onto the main unit protoboard, and the datasheet pinouts were connected to the relevant signals. A 0.1uf capacitor was put between Vcc and GND so as to reduce power supply noise. An 18cm antenna was used as it's 1/8 the wavelength of the signal The antenna is decoupled with a 100pf capacitor according to the spec sheet. The additional resistor/inductor RF choke was not connected due to space limitations. The resulting setup worked satisfactorily for our application even without them. The transmitter unit was mounted on the protoboard of the remote control unit. A 0.1uf surface mount capacitor was also placed between Vcc and GND. A similar antenna is used. Vcc was set to be 5V, which provided sufficient signal strength for the required range.

Software was written for two units. The majority of the software complexity resides in the main fan controller unit. In contrast, the remote control is rather simple with little more than a software debouncer for the push buttons.

Main Unit

The software design made use of a time based scheduler. The clock runs at 16MHz and timer2 was used to generate an interrupt once every 0.1ms. This acted as the heartbeat for the rest of the program. The interrupt routine did two things. It decreased the count down timers for individual tasks, and detected the tachometer signal pulse from the fans. Timer0 was setup with PWM operation for one of the fans, and the serial port was setup with non-blocking interrupt based transmit and receive. This ensured that other time critical functions such as adjusting the fan speed can proceed while the system was printing to the terminal.

The main program loop called each of the individual tasks when they are scheduled to run. In addition, the main program loop also took care of the status lights and alarm, as well as the starting and stopping of timer0 (for PWM mode) based on system parameters. The 6 scheduled tasks were: Outputting to the LCD, outputting to HyperTerminal, getting input from the keyboard, reading the temperature sensor, adjusting the fan speed, and pulse stretching for PWM.

Care was taken when coding the fan control system so that the program can easily be extended to support more than two fans. The #define MAXFAN parameter sets the number of fans in the system. Floating point variables typically begin with "fp", threshold variables are prefixed by "t_", and system flags are prefixed by "f_". This allowed the code to be more easily understood, minimizing debugging headaches.

Displaying fan status to the LCD:

Each fan and sensor pair's RPM and temperature reading is displayed on the LCD. Since the LCD is only 16x1 lines, we decided to alternately display the information from each pair. The LCD will first display the information from fan1 and then display the information from fan2 after a 2 second interval. The variable "lcddispnum" keeps track of the fan number the LCD display is currently showing.

Displaying fan status to HyperTerminal:

The same information shown on the LCD is also displayed on the computer terminal. However, HyperTerminal will always display both fan speeds and both temperature readings simultaneously. It will also show the operation mode of the system (auto vs user, wireless vs computer). The screen is updated once every 2 seconds by first clearing the screen with a form feed command. For each fan, the computer terminal will also display the minimum threshold temperature at which point the fan will turn on and the maximum threshold temperature at which point the alarm will go off. It will also show a warning, "Fan fault detected!" if a fault is detected.

Parsing keyboard input:

All commands were parsed based on a simple command line interface consisting of a letter followed by a number. The letter determines the functionality and the number provides the parameter to be used.

a<number>

- sets fan1's (DAC fan) minimum temperature threshold

b<number>

- sets fan1's (DAC fan) maximum temperature threshold

c<number>

- sets fan2's (PWM fan) minimum temperature threshold

d<number>

- sets fan2's (PWM fan) maximum temperature threshold

f<number>

- toggles fan <number> on and off in auto mode

t<number>

- changes the tachometer divider to <number>

- toggles the Operation mode between 'auto' and 'user'

Getting the temperature:

Since there is only one ADC unit on the MCU, in order to gather temperature information from multiple sensors, the ADMUX register had to be continually updated to read from different ports. This functionality resides in a scheduled task. Each time the function is called, it will read ADCH to get the temperature reading and setup the ADMUX register to read from the next sensor. The "sensornum" variable keeps track of the temperature sensor it is currently reading from.

The temperature sensors are calibrated for each MCU at room temperature. The initial room temperature voltage reading is defined by "inittemp" and the MCU's analog reference voltage is defined by "Arefvolt". By defining these parameters at room temperature, the sensor will be properly calibrated.

Adjusting the fan speed based on temperature:

The fan speeds are adjusted periodically based on temperature from the temperature sensors. At the minimum temperature threshold, the fan is turned on. The fan speed will then ramp up linearly with increasing temperature, reaching full speed at 75% of the way between the min and max temperature thresholds. In the function, if "fanspeed" is 1.0, it indicates the fan should be spun at fullpower. The formula for calculating the fanspeed is:

fullspeedtemperature = (maxthreshold - minthreshold) * 0.75;

fanspeed = (current temperature - minthreshold) / fullspeedtemperature;

For PWM, the fan speed is controlled by varying the duty cycle of the PWM pulse. The PWM signal is sourced from timer0. A prescalar of 64 was used with fast PWM mode to generate a signal on OC0 at close to 1kHz. OC0 was set to clear on upcount and set on overflow if the PWM fan is on. To set the duty cycle of the fan, we would write different values into OCR0. This value is saved in "pwmspeed".

For the DAC, the fan speed is controlled with a value between 0 and 15 inclusively to the 4bit DAC input. This value is saved in "dacout".

Reading the tachometer pulse:

The interrupt service routine detects the tachometer pulse by continually sampling each of the tachometer port pins. It records when the tach pulse is high and when it is low. On the falling edge of each pulse, it calculates the length of time the pulse spent in the low stage during the last period. This was used to calculate the RPM of the fan using the formula:

RPM = 600000/(input*divider);

where divider is a unique number for each fan indicating the number of pulses per revolution and input is the input waveform. This formula is derived from the observation that:

L(ms) = (60000ms/RPM)/(pulses per revolution)

where L is the period of each the tachometer pulse. Solving for RPM, we get the above RPM formula.

Pulse stretching with PWM for RPM detection:

Figure 1. Tachometer-output waveforms in 3-wire fans - ideal, and under PWM control

The tachometer only works when power is applied to the fan. With PWM the duty cycle causes the tach pulse to disappear when power isn't applied, which results in sporadic and unreliable tachometer output. To alleviate this problem, we use pulse stretching. Periodically, the PWM signal will use a 100% duty cycle for the purpose of getting a proper tachometer reading. The pulse is stretched for 3 full tach periods - enough time for stable detection of the RPM reading.

Figure 2. Pulse stretching to gather tachometer information

This is the biggest drawback of PWM. While it wins in hardware simplicity, the fan speed detection is not as accurate as the DAC fan. The pulse can only be stretched periodically which makes the RPM update rate slower. Furthermore, with slow speeds (eg, 10% duty cycle), pulse stretching to full power can noticeably affect the operation of the fan as it repeatedly spins up and down. A DAC fan provides constant power, making RPM detection simple.

Locked rotor detection:

The interrupt service routine also detects locked rotors when sensing the RPM. A fan fault is detected if one of the following occurs:

The tach pulse stays high or low for more than 60 ms.
The high pulse is more than 3 times longer than the low pulse for 5 consecutive periods.
The low pulse is more than 3 times longer than the high pulse for 5 consecutive periods.

Alarm system:

An alarm will light and sound when either of the temperature sensors exceeds their maximum threshold temperature or when a fan failure is detected. This check is done in the main program loop. If the alarm is to be turned on, the "f_alarmsound" flag is set. In the main interrupt service routine, if the above flag was set, it will toggle the alarm port pin. This creates a square wave with a period of 0.2 ms. This square wave drives a piezoelectric buzzer that creates a high pitched beep.

Serial I/O:

Serial I/O to and from the serial port and from the wireless remote control was done with a non-blocking method. When data is received, the receive interrupt is called, and the data is put into r_buffer one character at a time. When a whole command string is detected, this data is read out with gets_int(). Data to be transmitted is put in the t_buffer and sent using puts_int(). When the transmitter is ready, it will send the contents of t_buffer one character at a time. This method ensures that I/O will not block the operation of other scheduled tasks.

Switching operation modes:

There are two sets of operation modes: Auto vs user, and wireless vs computer. In auto mode, the PWM duty cycle is continually updated with the "pwmspeed" variable, and the DAC value is continually updated with the "dacout" variable. In user mode, the PWM speed signal is driven high continuously to turn the fan on, and the DAC fans are sent the enable signal. This allows both fans to operate and to be controlled by the user adjustable potentiometer.

Since the MCU can only receive serial data from one source at a time, a physical switch will be used to switch between wireless and computer mode. The mux control signal is set based on the input of the switch. The software maintains transmission to the terminal at all times.

RF Wireless

Wireless information was received using the receive interrupt. All wireless data packets are encased by a start packet and a stop packet. The MCU will only use the data packet if the start and stop packets are detected. This prevents the system from picking up random noise and transmissions from other remote controllers. The start, data, and stop packets are DC balanced so the receiver can maintain proper gain levels. Since only 5 different buttons are on the remote transmitter, the data packets were simply hardcoded as 5 unique bytes. RF transmission was done at 4800 baud to increase reliability.

Remote Controller Unit:

The remote control consists of five buttons. Four are for setting the minimum threshold temperature and one is for toggling between auto and user mode. The software uses a button debouncing state machine to read button presses into the 'inbutton' variable. This variable is checked and based on the button that is pressed, it will transmit it over the RF link. Input is only valid if only one buttons is pressed.

Figure 3. Debounce state diagram

Transmission is done by first sending 15 bytes of 0xaa. This creates a DC balanced signal that the receiver can hone onto. Next 0xff followed by 0x00 are sent. This syncs the receiver so that the stop bit is detected and it is ready for the transmission packets. RF transmission was done at 4800 baud to increase reliability.

Figure 1. Picture of the fans running

After a grueling month of conceptualization, design, building, testing and headaches, the final result of our PC temperature monitoring and control unit was very satisfactory. Almost all the initial features were implemented. Some worked better than others, and some proved to be trickier than others. We've exhaustively tested all cases of operation that we could think of, including the following:

Basic autonomous fan operation: threshold temperature activation, alarm temperature triggering of LED/alarm speaker
Basic manual fan operation
Switching between the 2
Temperature detection
Fan speed detection
Control of fan speed based on temperature
Wireless remote control of the system

Testing

Figure 2. Complete main unit showing fans running with temperature/fanspeed monitoring/detection

The complete unit underwent rigorous testing before it was declared working. Testing was done on the various sub-units separately to make sure individual functions work. For example, the 4-bit DAC was manually supplied voltages for the input, and output voltages are measured to ensure that they are linear between 0-12V. All the switches were also manually turned on/off to ensure that they work, and voltages of the output are scoped to ensure the correct voltage levels before hooking it up to the fans or the MCU. This ensures that a non-working circuit will not damage the fans or MCU, which would have set us back considerably in both time and budget. The oscilloscope and multimeter were invaluable tools in the hardware troubleshooting process.

The software was also tested separately on an STK-500 board to ensure correct functionality. For example, output pins of the PWM output were scoped to ensure that the correct waveform was obtained. The various select/control bits were also tested at the port pins to make sure that they switch between 0-5V. The use of LEDs and LCD displays was also crucial in the debugging process.

After the individual blocks were tested to work, they were combined with other blocks to build larger blocks which were then tested again as another sub-unit. Gradually, the system encompassed a larger and larger subset of the entire feature set. Finally, the hardware and software were integrated, and the actual protoboards were used instead of the STK-500. This limited the scope of our errors, allowing for easier debugging/troubleshooting.

Since the system isn't time critical, nor does it require stringent accuracy requirements, it performs over a wide but acceptable accuracy range. The voltage levels for the fans were measured at ~7-11.3V instead of the desired 7-12V range. The voltage drop is due to the use of bipolar transistors in our enable and current boost circuits. Low dropout voltage regulators and/or MOSFET transistors could have been used to bring the voltage closer to the 12V rail, but bipolar transistors are cheaper and more available. Speed of the system is acceptable, but in some cases isn't instantaneous. For example, due to the use of an electromechanical relay, there is a slight delay in switching between user/auto modes. This is acceptable as the system isn't meant to be continuously switched at a high rate. The system is controlled by HyperTerminal and various buttons. Simple, intuitive commands are entered into HyperTerminal, which makes it user friendly. Buttons are labelled and are also inherently foolproof.

As the unit was built on time and budget constraints, certain design choices had to be made about the functionality of the system. Below are some of the limitations that could be addressed in future versions.

The current limit of fans connected to the connector is 1A/fan. This is plenty for a single fan, but users who daisy chain several fans to a single connector might find this insufficient. Use of beefier amps/switches and other components in the circuit would increase the current handling of the system.
Monitoring and control of only 2 temperatures and fans this was chosen due to size constraints. Expansion to more fans should be trivial given more circuit estate
Fans cannot be turned off manually - we assume that if a user connects a fan, he would want to leave it on. This will help in case the user leaves the system in user mode with the fans turned off, and the system temperature rises.

We started out wanting to make a 5.25" drive bay mountable, fully standalone PC temperature monitoring and control unit. In the end, we got real close to the original design. While it isn't mountable to a drive bay, the overall size of the unit suggests that it's entirely possible, especially if a PCB is used instead of a breadboard. Sadly, we do not have access to custom PCBs. Overall, we managed to monitor 2 temperatures and control the fan speeds of 2 fans, as well as monitor the fan speed. The I/O interface that was initially proposed was accomplished, including pushbuttons, HyperTerminal, LCD display, LEDs and alarm speaker. In addition, we added the RF wireless remote control, which was a non-trivial addition to the design. On top of this, the project was kept well within budget, and also below the price of similar units on the market. All in all, this project was a success!

2. to avoid real or perceived conflicts of interest whenever possible, and to disclose them to affected parties when they do exist;

RF conflict: there were several groups using the 433MHz receiver/transmitter set from radiotronix and we this presented a problem when multiple groups were transmitting/receiving, especially towards the end of the project. In order to resolve this conflict, we walked the lab to inform others of our tranmissions, and also took note of other groups who we transmitting.

4. to reject bribery in all its forms;

No bribery was accepted during the course of the final project.

5. to improve the understanding of technology, its appropriate application, and potential consequences;

During the brainstorming of project ideas before the actual project design, we considered several features of the unit. We chose to implement both voltage regulation and PWM fan control despite the superiority of PWM fan control, and discussed the pros and cons of both methods.

7. to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others;

We accepted the suggestion from TAs to add a wireless interface to our overall design to enhance functionality and increase its complexity. We also accepted help from TAs to understand the implementation details of the fan tachometer readings, as well as usage of relays as the voltage source switches.

8. to treat fairly all persons regardless of such factors as race, religion, gender, disability, age, or national origin;

Cornell has a diversified community. The ECE department is even more diversified with different races, nationality, gender and religion. We observed no discrimination in this class and people do respect individual differences.

9. to avoid injuring others, their property, reputation, or employment by false or malicious action;

We followed basic laboratory safety rules. Dangerous equipment such as the soldering iron were carefully used.

Our wireless RF transmission falls under Part 15 of the FCC regulations, which lays out the rules and regulations involved with unlicensed transmissions. Our project complies with these regulations, as:

We only constructed 1 transmitter, less than the limit of 5.
We did not cause interference with licensed radio communications as the frequency of 433MHz was used, which isn't being used by any known licensed radio communications in the area.
Transmissions were only broadcast when needed.
FCC regulations only require "homebuilt" wireless devices to to comply to the best of the builder's extent, and this is certainly the case here.

Schematics of all circuits are presented here. download here

Fan 1 circuit