[Kirk Kaiser] isn’t afraid to admit his latest project a bit strange, being a plant-controlled set of robotic bongos. We don’t find it odd at all.  This is the kind of thing we love to see. His project’s origins began a month ago after taking a class at NYC Resistor about creating music from robotic instruments. Inspired to make his own, [Kirk] repurposed a neighbor’s old wooden dish rack to serve as a mount for solenoids that, when triggered, strike a couple of plastic cowbells or bongo drums.

A Raspberry Pi was originally used to interface the solenoids with a computer or MIDI keyboard, but after frying it, he went with a Teensy LC instead and never looked back. Taking advantage of the Teensy’s MIDI features, [Kirk] programmed a specific note to trigger each solenoid. When he realized that the Teensy also had capacitive touch sensors, he decided to get his plants in on the fun in a MaKey MaKey kind of way. Each plant is connected to the Teensy’s touchRead pins by stranded wire; the other end is stripped, covered with copper tape, and placed into the soil. When a plant’s capacitance surpasses a threshold, the respective MIDI note – and solenoid – is triggered. [Kirk] quickly discovered that hard-coding threshold values was not the best idea. Looking for large changes was a better method, as the capacitance was dramatically affected when the plant’s soil dried up. As [Kirk] stood back and admired his work, he realized there was one thing missing – lights! He hooked up an Arduino with a DMX shield and some LEDs that light up whenever a plant is touched.

We do feel a disclaimer is at hand for anyone interested in using this botanical technique: thorny varieties are ill-advised, unless you want to play a prank and make a cactus the only way to turn the bongos off!

Now that the Apple wristwatch is on its way, some people are clamoring with excitement and anticipation. Rather than wait around for the commercial product, Instructables user [Aleator777] decided to build his own wearable Apple watch. His is a bit different though. Rather than look sleek with all kinds of modern features, he decided to build a watch based on the 37-year-old Apple II.

The most obvious thing you’ll notice about this creation is the case. It really does look like something that would have been created in the 70’s or 80’s. The rectangular shape combined with the faded beige plastic case really sells the vintage electronic look. It’s only missing wood paneling. The case also includes the old rainbow-colored Apple logo and a huge (by today’s standards) control knob on the side. The case was designed on a computer and 3D printed. The .stl files are available in the Instructable.

This watch runs on a Teensy 3.1, so it’s a bit faster than its 1977 counterpart. The screen is a 1.8″ TFT LCD display that appears to only be using the color green. This gives the vintage monochromatic look and really sells the 70’s vibe. There is also a SOMO II sound module and speaker to allow audio feedback. The watch does tell time but unfortunately does not run BASIC. The project is open source though, so if you’re up to the challenge then by all means add some more functionality.

As silly as this project is, it really helps to show how far technology has come since the Apple II. In 1977 a wristwatch like this one would have been the stuff of science fiction. In 2015 a single person can build this at their kitchen table using parts ordered from the Internet and a 3D printer. We can’t wait to see what kinds of things people will be making in another 35 years.

[Bob’s] Pac-Man clock is sure to appeal to the retro geek inside of us all. With a tiny display for the time, it’s clear that this project is more about the art piece than it is about keeping the time. Pac-Man periodically opens and closes his mouth at random intervals. The EL wire adds a nice glowing touch as well.

The project runs off of a Teensy 2.0. It’s a small and inexpensive microcontroller that’s compatible with Arduino. The Teensy uses an external real-time clock module to keep accurate time. It also connects to a seven segment display board via Serial. This kept the wiring simple and made the display easy to mount. The last major component is the servo. It’s just a standard servo, mounted to a customized 3D printed mounting bracket. When the servo rotates in one direction the mouth opens, and visa versa. The frame is also outlined with blue EL wire, giving that classic Pac-Man look a little something extra.

The physical clock itself is made almost entirely from wood. [Bob] is clearly a skilled wood worker as evidenced in the build video below. The Pac-Man and ghosts are all cut on a scroll saw, although [Bob] mentions that he would have 3D printed them if his printer was large enough. Many of the components are hot glued together. The electronics are also hot glued in place. This is often a convenient mounting solution because it’s relatively strong but only semi-permanent.

[Bob] mentions that he can’t have the EL wire and the servo running at the same time. If he tries this, the Teensy ends up “running haywire” after a few minutes. He’s looking for suggestions, so if you have one be sure to leave a comment.

[Nikhil] has been experimenting with human interface devices (HID) in relation to security. We’ve seen in the past how HID can be exploited using inexpensive equipment. [Nikhil] has built his own simple device to drop malicious files onto target computers using HID technology.

The system runs on a Teensy 3.0. The Teensy is like a very small version of Arduino that has built-in functionality for emulating human interface devices, such as keyboards. This means that you can trick a computer into believing the Teensy is a keyboard. The computer will treat it as such, and the Teensy can enter keystrokes into the computer as though it were a human typing them. You can see how this might be a security problem.

[Nikhil’s] device uses a very simple trick to install files on a target machine. It simply opens up Powershell and runs a one-liner command. Generally, this commend will create a file based on input received from a web site controlled by the attacker. The script might download a trojan virus, or it might create a shortcut on the user’s desktop which will run a malicious script. The device can also create hot keys that will run a specific script every time the user presses that key.

Protecting from this type off attack can be difficult. Your primary option would be to strictly control USB devices, but this can be difficult to manage, especially in large organizations. Web filtering would also help in this specific case, since the attack relies on downloading files from the web. Your best bet might be to train users to not plug in any old USB device they find lying around. Regardless of the methodology, it’s important to know that this stuff is out there in the wild.

It’s winter, and that means terrible weather and very few days where flying RC planes and helicopters is tolerable. [sjtrny] has been spending the season with RC flight simulators for some practice time. He had been using an old Xbox 360 controller, but that was really unsuitable for proper RC simulation – a much better solution would be to use his normal RC transmitter as a computer peripheral.

The usual way of using an RC transmitter with a computer is to buy a USB simulator adapter that emulates a USB game pad through a port on the transmitter. Buying one of these adapters would mean a week of waiting for shipping, so [sjtrny] did the logical thing and made his own.

Normally, a USB simulator adapter plugs in to a 3.5mm jack on the transmitter used for a ‘buddy box’, but [sjtrny] had an extra receiver sitting around. Since a receiver simply outputs signals to servos, this provides a vastly simpler interface for an Arduino to listen in on. After connecting the rudder, elevator, aileron, and throttle signals on the receiver to an Arduino, a simple bit of code and the UnoJoy library allows any Arduino and RC receiver to become a USB joystick.

[sjtrny] went through a second iteration of hardware for this project with a Teensy 3.1. This version has higher resolution on the joystick axes, and the layout of the code isn’t slightly terrible. It’s a great project for all the RC pilots out there that can’t get a break in the weather, and is also a great use for a spare receiver you might have sitting around.

Payphones used to be found on just about every street corner. They were a convenience, now replaced by the ubiquitous mobile phone. These machines were the stomping grounds for many early computer hackers, and as a result hold a place in hacker history. If you’ve ever wanted to re-live the good ol’ days, [hharte’s] project might be for you.

[hharte] has been working to make these old payphones useful again with some custom hardware and software. The project intends to be an interface between a payphone and an Asterisk PBX system. On the hardware side, the controller board is capable of switching various high voltage signals required for coin-line signaling. The controller uses a Teensy microcontroller to detect the hook status as well as to control the relays. The current firmware features are very basic, but functional.

[hharte] also wrote a custom AGI script for Asterisk. This script allows Asterisk to detect the 1700hz and 2200hz tones transmitted when coins are placed into the machine. The script is also in an early stage, but it will prompt for money and then place the call once 25 cents has been deposited. All of the schematics and code can be found on the project’s github page.

[Thanks mies]

Yesterday I gave myself the following to-do list:

• Check the V_DS voltage at 4A on the nFET. Is the on-resistance still much too high?

  Yes, with the 1.8Ω resistor I get 110mV across the FET with 8.372V across the resistor, so at 4.65A I’m seeing an on-resistance of 24mΩ, still much higher than the 10mΩ I was expecting, but closer than I was getting yesterday at 1A. The voltage across the nFET does go up as the nFET warms up, but the nFET does not get too hot (up to around 45°C).

• Try adding a 1kΩ gate resistance to slow down the transitions on the PWM, to see if that reduces the inductive spikes and the noise-coupling through the 9V power supply.

  Slowing the transitions definitely reduced the spikes, from about 13V to about 1V.  The bypass capacitors absorbed the highest-frequency spikes, and the 470µF polymer electrolytic capacitor seems to be enough—the 10µF ceramic doesn’t seem to add any extra suppression.  At about 94% duty cycle the noise on the power supply is about the following:

  gate resistor	bypass capacitor	peak-to-peak noise
  0Ω	none	20V
  1kΩ	none	3V
  0Ω	10µF	2.5V
  1kΩ	10µF	2.5V
  0Ω	470µF	1V
  1kΩ	470µF	0.3V

  The slew rate for the drain voltage with the 1kΩ gate resistor is about +7V/µs and -5V/µs.

• Write a simple control loop for the fan speed, so that the fan speed can be held constant even when the power-supply voltage changes.  This may be an opportunity to try the P/PI/PID tuning, since the control loop should be fairly fast.

  I wrote a simple PID controller with the control variable being the fan PWM and the measured variable being the time per pulse (in µsec).  I tried tuning the controller by adjusting the proportional gain until the control loop barely oscillated, then cutting the gain to 0.45 of that and setting the integration time to about period of the oscillation (very loosely estimated).  I then tweaked the parameters until it seemed to give good control without oscillation over the full range of fan speeds.I tried the differential control, but the noisiness of the speed measurement (which I was not filtering at all) makes the derivative far too touchy, even with tiny amounts of differential control, so I used a simple PI controller instead.  I don’t think that the optimal parameters are the same at the high speed and low speed for the fan, but it was not difficult to find parameters that worked fairly well across the range.  One thing that help was not accumulating integral error when the PWM signal was pinned at the lowest or highest values.

  The speed is almost linear with the PWM input, so I would probably get better control if I used speed (the reciprocal of the pulse duration) as the measured value in the controller.

  

  The fan speed is nearly linear with PWM, which is ideal for proportional control, but I had foolishly used the pulse duration as my measured value to control.

  I rewrote the controller as a simple PI controller, using 16*RPM as my measured variable, so that I could have an integer setpoint with sufficient resolution. I’m still using floating-point in the controller for simplicity of coding but I plan to switch to fixed-point soon. This controller was fairly easy to tune—I made the K_plarge enough that system oscillated, and counted how many samples were in the period, then set the integration time to about the period. I then reduced K_p until the oscillations went away. I ended up with K_p = 0.01 PWM/16RPM and T_I= 1/0.15 samples (with a sampling rate of 30ms, so T_I=0.2s).

  One thing that helped was to make a guess at the target PWM setting when the setpoint was changed (using d RPM/ d PWM =24 and the current PWM setting and RPM value), then setting the cumulative error to what it would be in steady state at that PWM. I then set the PWM to five times as far from current PWM as the target PWM to make the transition as fast as possible without increasing overshoot, making sure to clip to the legal 0..255 range.

• Write a simple control loop for controlling the temperature at the thermistor, by adjusting the PWM for the resistor.  This might get messy, as the fan speed probably affects the rate of transfer from the resistor to the thermistor (the thermistor is in the air stream blown over the resistor, not touching the resistor).

  When I started working on this, my power supply failed. I’m afraid it might have shorted when I was rewiring things (though I never saw evidence for a short). I’ll leave it overnight (in case there is a resettable poly fuse) and check it in the morning. If there is still no power, I’ll open the case and see if there is a replaceable fuse inside. I’m afraid that this may have a soldered-in non-resettable fuse, which would be a terrible design—setting me back a couple of weeks as I either order a replacement fuse or a replacement power supply.

• Put the whole thing into a styrofoam box, to see whether extra venting is needed to allow things to cool down, and to see how tightly temperature can be controlled.
• Design and build baffling for the fan to get better airflow in the box.
• Figure out how to get students to come up with workable designs, when they are starting from knowing nothing. I don’t want to give them my designs, but I want to help them find doable subproblems.  Some of the subproblems they come up with may be well beyond the skills that they can pick up in the time frame of the course.

Now that I have a power resistor and heatsink, and have verified that my power supply is capable of delivering 50W, I can try making a thermal control system for an incubator box as I hope to get the freshman design class to do.

Before building a complete control system and tuning a proportional, PI, or PID controller, I decided to check each of the components:

• 1.8Ω resistor and heatsink (already characterized in still air in the previous post). Initially I was going to use the 8.2Ω resistor, but it heated so slowly once bolted to the heatsink that I wasn’t sure that students would have the patience to wait for it—they might conclude that things weren’t working.
• NTD4858N-35G nFET for PWM control of the heater.
• fan.  I bought a SanAce 40 109P0412P3H013 fan with PWM control and tachometer feedback, and I wanted to be sure that I could control the fan speed and read the tachometer.
• thermistor. I had some NTCLE100E3103JB0 thermistors around that I had never used.  They’re not ideal for measuring temperature of resistors (they only go up to 125°C), but they should be find for measuring air temperature around 35°C, which is what the incubator will mainly be used at.
• Arduino board (actually a SparkFun RedBoard, which is plug-compatible with the Uno R3, but has has a more reliable USB interface and is slightly cheaper.

I started out hooking up the nFET and the 1.8Ω resistor and making sure that the nFET did not get too hot.  It seems to be ok.  When I was using the 8.2Ω resistor, I measured the voltage drop across the resistor and the across the nFET, getting a 57.6mV drop from drain to source, with a current of about 9.024V/8.21ohm = 1.099A.  That’s about a 52mΩ on-resistance, and I was expecting more like 7mΩ–10mΩ.  My gate voltage was around 5V (bigger than the 4.5V of the data sheet), which should have given me lower on-resistance.  The only things I can think of are that I had more wiring resistance than I realized (quite likely, but not likely enough to add over 40mΩ), and that I was measuring around 1A, not around 10A, so perhaps there is a small-voltage effect that I don’t know about.

I should probably test the voltage drop again with 1.8Ω resistor, and see whether the on-resistance is still so high.  Better probe placement may get me more accurate voltage measurements also.

The fan runs fine at 9.212V at about 6850 RPM.  Setting the PWM input line of the fan to 0 drops the speed to about 710RPM, and setting the PWM duty cycle to a half sets the speed at about 4120RPM.  The fan is a bit noisy for such a tiny fan at the highest speed setting, but reasonably quiet at lower speeds.  I suspect that bolting the fan to a piece of masonite as a baffle would reduce the fan noise, as I think quite a bit of it was from vibration between the case of the fan and the metal plate it was sitting on.

The tachometer on the fan provides an open-collector output that I read with an interrupt input on the Arduino (pin 2, interrupt 0). I recorded the time between interrupts and converted it an RPM measurement.  The tachometer worked fine when I was just using the fan, or when the resistor was either completely off or completely on, but when I tried using PWM on the resistor, the tachometer readings became nonsense.

I looked at the tachometer signal with my oscilloscope and saw that the PWM transitions for the resistor resulted in huge spikes in the tachometer output that triggered extraneous interrupts.  I suspected noise coupled through the power supply. Adding a 10µF bypass capacitor to the 9V power supply to the fan reduced the problem considerably, and a 470µF aluminum polymer electrolytic cleaned up the power supply even more.  The 10µF alone was enough to eliminate the extraneous spikes in the middle.

I think that I should try adding some gate resistance to the nFET to slow down the rise and fall of the PWM signal a little, to reduce the inductive spikes and make the bypass capacitors more effective.

I noticed that I was still getting some readings that were half the duration that I was expecting.  These could have been caused by ringing at the other transition of the tachometer pulse, so I tried eliminating the ringing by adding some capacitance to the line and changing the pullup resistor.  These attempts were not very successful, so I decided that hysteresis was needed.  I put a Schmitt trigger between the open-collector output and the Arduino interrupt input, and the signal got a lot cleaner.  There were occasional double pulses at one edge, though, but I found that adding a 1nF to 10nF capacitor in parallel with the pullup resistor for the open collector output smoothed out the high frequency noise enough to get clean, single transitions out of the Schmitt trigger.

I hooked up the thermistor in a voltage divider with 5.1kΩ on the other leg (which maximizes the dV/dT sensitivity at 40.1°C). I used the parameters on the data sheet to plot a calibration curve for the thermistor:

Calibration and sensitivity curves for the thermistor, based on the data sheet and a 5.1kΩ pulldown resistor.

The maximum sensitivity of the thermistor circuit is around 33.3 degrees C (~10.4 Arduino LSB/°C).  That’s not a very high sensitivity, particularly given the noise of the ADC.  Note that maximizing the slope at 40.1 °C is not the same thing and having the maximum of the slope at 40.1°C.  If the maximum of the slope was at 40.1°C, the slope there would be less than it is in this plot.

My son wonders why I’m using the Arduino board for this project, rather than the FRDM-KL25Z board that I use for the circuits class or the Teensy 3.1 ARM development board. The ARM processors have more power, more memory, and much better analog-to-digital converters—and the KL25Z board is cheaper.  If I were doing this project for myself, I would certainly prefer the KL25Z board. But it is a little harder to get a beginner started on that board—just getting the first program onto the board is a pain if you don’t have a Windows machine (due to the broken bootloader the P&E Micro wrote).  There are instructions now for replacing the firmware from a Linux system, but I’ve not checked yet whether these instructions work from a Mac.  Even once you get working firmware onto the boards, the development environments are not beginner-friendly.  Well, that is certainly true of the MBED environment or bare-metal ARM environment for the KL25Z boards, but the Teensy 3.1 board supposedly can be programmed from a plugin for the Arduino IDE, which might be simple enough for beginners.  This is something for me to look into more.

Of course, one reason I’m using the Arduino Uno or Sparkfun RedBoard is that they are 5V processors, and most of the power nFETs I’ve looked at need 4.5V on the gate to turn on fully.  There are power nFETs now with lower gate voltages, but most of them are only available as surface-mount devices.  I don’t want to have to add an extra transistor or buffer chip as a level changer for the PWM circuit.

The problem is that these students will be brand new to programming, brand new to electronics, and brand new to engineering—and the course is only a 2-unit course, not a full 5-unit course, so the total time students are expected to spend on the course is only 60 hours. I want them to be able to design stuff quickly, without spending all their time learning to use tools or trying to find workarounds for limitations of the devices they are using. It already bothers me that they’ll probably need to use a Schmitt trigger to clean up the tachometer input, but at least hysteresis was a topic I was planning to cover! (The need for bypass capacitors bothers me less—they are so ubiquitous in electronics that I’ll have to cover them no matter what.)

It’s after midnight now, so I’m going to call it a day.  Here is my to-do list on this project:

• Check the V_DS voltage at 4A on the nFET. Is the on-resistance still much too high?
• Try adding a 1kΩ gate resistance to slow down the transitions on the PWM, to see if that reduces the inductive spikes and the noise-coupling through the 9V power supply.
• Write a simple control loop for the fan speed, so that the fan speed can be held constant even when the power-supply voltage changes.  This may be an opportunity to try the P/PI/PID tuning, since the control loop should be fairly fast.
• Write a simple control loop for controlling the temperature at the thermistor, by adjusting the PWM for the resistor.  This might get messy, as the fan speed probably affects the rate of transfer from the resistor to the thermistor (the thermistor is in the air stream blown over the resistor, not touching the resistor).
• Put the whole thing into a styrofoam box, to see whether extra venting is needed to allow things to cool down, and to see how tightly temperature can be controlled.
• Design and build baffling for the fan to get better airflow in the box.
• Figure out how to get students to come up with workable designs, when they are starting from knowing nothing. I don’t want to give them my designs, but I want to help them find doable subproblems.  Some of the subproblems they come up with may be well beyond the skills that they can pick up in the time frame of the course.

Now that I have a power resistor and heatsink, and have verified that my power supply is capable of delivering 50W, I can try making a thermal control system for an incubator box as I hope to get the freshman design class to do.

Before building a complete control system and tuning a proportional, PI, or PID controller, I decided to check each of the components:

• 1.8Ω resistor and heatsink (already characterized in still air in the previous post). Initially I was going to use the 8.2Ω resistor, but it heated so slowly once bolted to the heatsink that I wasn’t sure that students would have the patience to wait for it—they might conclude that things weren’t working.
• NTD4858N-35G nFET for PWM control of the heater.
• fan.  I bought a SanAce 40 109P0412P3H013 fan with PWM control and tachometer feedback, and I wanted to be sure that I could control the fan speed and read the tachometer.
• thermistor. I had some NTCLE100E3103JB0 thermistors around that I had never used.  They’re not ideal for measuring temperature of resistors (they only go up to 125°C), but they should be find for measuring air temperature around 35°C, which is what the incubator will mainly be used at.
• Arduino board (actually a SparkFun RedBoard, which is plug-compatible with the Uno R3, but has has a more reliable USB interface and is slightly cheaper.

I started out hooking up the nFET and the 1.8Ω resistor and making sure that the nFET did not get too hot.  It seems to be ok.  When I was using the 8.2Ω resistor, I measured the voltage drop across the resistor and the across the nFET, getting a 57.6mV drop from drain to source, with a current of about 9.024V/8.21ohm = 1.099A.  That’s about a 52mΩ on-resistance, and I was expecting more like 7mΩ–10mΩ.  My gate voltage was around 5V (bigger than the 4.5V of the data sheet), which should have given me lower on-resistance.  The only things I can think of are that I had more wiring resistance than I realized (quite likely, but not likely enough to add over 40mΩ), and that I was measuring around 1A, not around 10A, so perhaps there is a small-voltage effect that I don’t know about.

I should probably test the voltage drop again with 1.8Ω resistor, and see whether the on-resistance is still so high.  Better probe placement may get me more accurate voltage measurements also.

The fan runs fine at 9.212V at about 6850 RPM.  Setting the PWM input line of the fan to 0 drops the speed to about 710RPM, and setting the PWM duty cycle to a half sets the speed at about 4120RPM.  The fan is a bit noisy for such a tiny fan at the highest speed setting, but reasonably quiet at lower speeds.  I suspect that bolting the fan to a piece of masonite as a baffle would reduce the fan noise, as I think quite a bit of it was from vibration between the case of the fan and the metal plate it was sitting on.

The tachometer on the fan provides an open-collector output that I read with an interrupt input on the Arduino (pin 2, interrupt 0). I recorded the time between interrupts and converted it an RPM measurement.  The tachometer worked fine when I was just using the fan, or when the resistor was either completely off or completely on, but when I tried using PWM on the resistor, the tachometer readings became nonsense.

I looked at the tachometer signal with my oscilloscope and saw that the PWM transitions for the resistor resulted in huge spikes in the tachometer output that triggered extraneous interrupts.  I suspected noise coupled through the power supply. Adding a 10µF bypass capacitor to the 9V power supply to the fan reduced the problem considerably, and a 470µF aluminum polymer electrolytic cleaned up the power supply even more.  The 10µF alone was enough to eliminate the extraneous spikes in the middle.

I think that I should try adding some gate resistance to the nFET to slow down the rise and fall of the PWM signal a little, to reduce the inductive spikes and make the bypass capacitors more effective.

I noticed that I was still getting some readings that were half the duration that I was expecting.  These could have been caused by ringing at the other transition of the tachometer pulse, so I tried eliminating the ringing by adding some capacitance to the line and changing the pullup resistor.  These attempts were not very successful, so I decided that hysteresis was needed.  I put a Schmitt trigger between the open-collector output and the Arduino interrupt input, and the signal got a lot cleaner.  There were occasional double pulses at one edge, though, but I found that adding a 1nF to 10nF capacitor in parallel with the pullup resistor for the open collector output smoothed out the high frequency noise enough to get clean, single transitions out of the Schmitt trigger.

I hooked up the thermistor in a voltage divider with 5.1kΩ on the other leg (which maximizes the dV/dT sensitivity at 40.1°C). I used the parameters on the data sheet to plot a calibration curve for the thermistor:

Calibration and sensitivity curves for the thermistor, based on the data sheet and a 5.1kΩ pulldown resistor.

The maximum sensitivity of the thermistor circuit is around 33.3 degrees C (~10.4 Arduino LSB/°C).  That’s not a very high sensitivity, particularly given the noise of the ADC.  Note that maximizing the slope at 40.1 °C is not the same thing and having the maximum of the slope at 40.1°C.  If the maximum of the slope was at 40.1°C, the slope there would be less than it is in this plot.

My son wonders why I’m using the Arduino board for this project, rather than the FRDM-KL25Z board that I use for the circuits class or the Teensy 3.1 ARM development board. The ARM processors have more power, more memory, and much better analog-to-digital converters—and the KL25Z board is cheaper.  If I were doing this project for myself, I would certainly prefer the KL25Z board. But it is a little harder to get a beginner started on that board—just getting the first program onto the board is a pain if you don’t have a Windows machine (due to the broken bootloader the P&E Micro wrote).  There are instructions now for replacing the firmware from a Linux system, but I’ve not checked yet whether these instructions work from a Mac.  Even once you get working firmware onto the boards, the development environments are not beginner-friendly.  Well, that is certainly true of the MBED environment or bare-metal ARM environment for the KL25Z boards, but the Teensy 3.1 board supposedly can be programmed from a plugin for the Arduino IDE, which might be simple enough for beginners.  This is something for me to look into more.

Of course, one reason I’m using the Arduino Uno or Sparkfun RedBoard is that they are 5V processors, and most of the power nFETs I’ve looked at need 4.5V on the gate to turn on fully.  There are power nFETs now with lower gate voltages, but most of them are only available as surface-mount devices.  I don’t want to have to add an extra transistor or buffer chip as a level changer for the PWM circuit.

The problem is that these students will be brand new to programming, brand new to electronics, and brand new to engineering—and the course is only a 2-unit course, not a full 5-unit course, so the total time students are expected to spend on the course is only 60 hours. I want them to be able to design stuff quickly, without spending all their time learning to use tools or trying to find workarounds for limitations of the devices they are using. It already bothers me that they’ll probably need to use a Schmitt trigger to clean up the tachometer input, but at least hysteresis was a topic I was planning to cover! (The need for bypass capacitors bothers me less—they are so ubiquitous in electronics that I’ll have to cover them no matter what.)

It’s after midnight now, so I’m going to call it a day.  Here is my to-do list on this project:

• Check the V_DS voltage at 4A on the nFET. Is the on-resistance still much too high?
• Try adding a 1kΩ gate resistance to slow down the transitions on the PWM, to see if that reduces the inductive spikes and the noise-coupling through the 9V power supply.
• Write a simple control loop for the fan speed, so that the fan speed can be held constant even when the power-supply voltage changes.  This may be an opportunity to try the P/PI/PID tuning, since the control loop should be fairly fast.
• Write a simple control loop for controlling the temperature at the thermistor, by adjusting the PWM for the resistor.  This might get messy, as the fan speed probably affects the rate of transfer from the resistor to the thermistor (the thermistor is in the air stream blown over the resistor, not touching the resistor).
• Put the whole thing into a styrofoam box, to see whether extra venting is needed to allow things to cool down, and to see how tightly temperature can be controlled.
• Design and build baffling for the fan to get better airflow in the box.
• Figure out how to get students to come up with workable designs, when they are starting from knowing nothing. I don’t want to give them my designs, but I want to help them find doable subproblems.  Some of the subproblems they come up with may be well beyond the skills that they can pick up in the time frame of the course.

[Paul Stoffregen], known as father of the Teensy, has leveraged the Teensy 3.1’s hardware to obtain some serious speed gains with SPI driven TFT LCDs. Low cost serial TFT LCDs have become commonplace these days. Many of us have used Adafruit’s TFT LCD library  to drive these displays on an Arduino. The Adafruit library gives us a simple API to work with these LCDs, and saves us from having to learn the intricacies of various driver chips.

[Paul] has turbocharged the library by using hardware available on Teensy 3.1’s 32 Freescale Kinetis K20 microcontroller. The first bump is raw speed. The Arduino’s ATmega328 can drive the SPI bus at 8MHz, while the Teensy’s Kinetis can ramp things up to 24MHz.

Speed isn’t everything though. [Paul] also used the Freescale’s 4 level FIFO to buffer transfers. By using a “Write first, then block until the FIFO isn’t full” algorithm, [Paul] ensured that new data always gets to the LCD as fast as possible.

Another huge bump was SPI chip select. The Kinetis can drive up to 5 SPI chip select pins from hardware. The ATmega328 doesn’t support chip selects. so they must be implemented with GPIO pins, which takes even more time.

The final result is rather impressive. Click past the break to see the ATmega based Arduno race against the Kinetis K20 powered Teensy 3.1.

Paul’s library is open source and available on Github.