Posts with «uncategorized» label

OpenPCR a $600 PCR Machine

One of our grad students just pointed me to the OpenPCR project at OpenPCR – the $599 Thermal Cycler / PCR Machine.

The machine is a thermal cycler that is controlled via a USB cable from a computer (PC or Mac, probably Linux as well, if you can figure out how to modify the code to talk to the USB port on your version of Linux).  It comes as a kit that you assemble yourself (from laser-cut wooden parts, which are probably not very sturdy, but give a nice homebrew feel to the machine.  You’d have to add some brass gears if you want a steampunk look.

Since commercial PCR machines are in the $3000 range, a $600 option seems like a good choice, even if you do have to tie up a computer to run the machine.  (Almost every school or lab that would want a thermal cycler has computers sitting around, especially since an old slow computer is all you need for this application.)

From a quick look at the information on the Downloads site, it seems that the machine has an Arduino as the controller, with an H-bridge (to power a Peltier-junction heater/cooler) and a high-resolution analog-to-digital converter (to read the block temperature).  The lid also has a heater and a temperature sensor, but no cooler.  The lid heater is controlled by the Arduino with a simple MOS transistor, and the temperature sensor is read directly by the Arduino—high precision is not as important for the lid as for the block.  There is a big heat sink and a fan for the back side of the Peltier junction—they take up most of the room in the box.

They provide detailed assembly instructions for download that have not been properly compressed—it’s a 109-Mbyte file that takes forever to download from their slow site, with pictures that seem designed for book-quality printing.  It would have been nice for them to provide lower-resolution pictures in under 20Mbytes as an option, or even HTML instructions that could be viewed a page at a time without needing to download everything.

The machine holds 16 200-microliter tubes, but does not appear to come with any, nor with any reagents.  There also do not seem to be any use instructions—once you’ve verified that the thermal cycler is working, you seem to be on your own for figuring out how to use it. I assume that the OpenPCR people expect the forum to handle questions like that (or they are hardware hackers who can’t be bothered to deal with messy wet protocols), but there are no useful messages on the forums yet.   The best sources for PCR protocols seem to be from the vendors of the polymerase and other reagents.  Googling “PCR protocol” finds several such sources.

I have no intention of getting a PCR machine myself (my eye-sight, hand-eye coordination, and patience with boring tasks are all too poor for me to do wet-lab work), but this looks like a good option for high school labs.


Tagged: Arduino, bio-hacking, open-source hardware, OpenPCR, PCR, thermal cycler

Optical Magnet, Arduino project next in a series Laser Tracking 3D

This blog considered to be next stage in the series published earlier, concentrated around the idea tracking object in the space. There are an enormous quantity of similar projects could be developed on this platform. I’ll name a few:

- star / rocket / vehicle tracking;
- follow me / robot / hands / cap etc;
- navigation to charging station / landing pad / around area;
- contact-less measurements rotational speed / angle to surface / shifting.

All of this on a few dollars micro-controller and cheap CMOS camera! Real-time, up to 60 Hz update rate!
Please, check on the first and second version, as I’d skip explanation basic design concept here.

  Most important features in this series of projects:

* 1. LOCALIZATION XY.
* 2. RANGE FINDER Z.
* 3. TRACKING 3-D.
* 4. TRACE TOOL.
* 5. TRACKING 6-D.
* 6. OPTICAL MAGNET.

Feature considered to be independent, so you can star  from  project 1:
http://fftarduino.blogspot.com/2011/12/arduino-laser-3d-tracking-range-finder.html
than move on next stage, and so on depends on a budget, parts availability or your interest!

This version of hardware/software system design capable to track object in

6 – D ++ space:

*   -  Linear motion along X, Y, Z coordinates (3D);
*   -  Rotation around fixed axis (6D);

I put two ++ plus signs, in order to underline capability of the hardware design to track Rotation of the object based not only on distance measurements, but also Reflectivity. As Power Control Loop strictly hold lasers radiation under control, simple calculation in periodicity of the emitted power would provide information about angular speed round / cylindrical object. Phase difference in 4 signals gives rotational center for Z. It’s also apply for linear motion, tracking of the object could be based on reflectivity or distance or BOTH simultaneously ,  which opens enormously great amount of possibilities.

Optical Magnet:
*  – Attract closest surface;
*  – Repel;
*  – Attract or repel surface with specific reflectivity (BLACK, WHITE, OR COLOR)!!!
*    * work in progress, Reflectivity math are not implemented yet       *
*    * algorithm to track rotation is not included, this is version for demonstration purposes  mainly.*

Link to download Arduino Uno sketch:  Optical_Magnet_6D

8 January, 2012.
Release notes of the version 3.2 software:

-  Video is De-interlaced, full image size 512 (active 492) lines;
-  digitalWrite, analogWrite functions of the arduino IDE were replaced by direct port manipulation, in order  to improve time performance of critical section of the code – interrupt subroutine and to avoid blocking interruption call (functions have locking mechanism in theirs body);
- minor changes in Power Control Loop algorithm, to prevent oscillation;

Link to download Arduino Uno sketch:  Optical_Magnet_6D_V3

 finished…


ARDUINO Laser 3D Tracking / Range Finder

 The idea of using triangulation for distance measurements is well known since Pythagorean time, when his brilliant formula become available for mathematicians.
What is new in this design, is lasers power control via “blooming” effect of CMOS camera. Here this “negative” effect was put to work instead of ADC. No need high price “no-blooming” camera! (More information on this link: http://dpanswers.com/content/tech_defects.php ) There are few others design approach, that I was trying to make in hardware/software, and some of them not fully implemented yet ( project just started ).
Power Control Loop (PCL) allows to get stable  readings of the reflected back light beams, doesn’t matter what is reflectivity of the object’s surface, how well illuminated background and what distance range !!! edited: / (Regarding stability measurements in varying illumination conditions, right now there is a resistor for manual adjustment comparator trigger level, depends on average  “black-fixed” video. Gonna get rid off it shortly)./
Probably, someone could “hack” a camera, and redesign build-in AGC to provide stable, “fixed-white” level of video signal. But it would be extremely difficult to do with this SMD components, lack of documentation and too complicated for average hobbyist. Plus after that camera is not “in use” anymore for it’s main purpose.

Arduino has low size of RAM memory and 8-bit low power microprocessor, so full image processing could not be done. Instead, “build-in” 1-bit comparator forms visual map, where each cell stores time stamp, when events was captured. As video frame created from top to bottom line by line, line number corresponds to Y coordinate, and time of events on this line – X consequently. At this stage project is more like test bench, than final solution -);.
Right now I’m looking for optical zooming devices, to cover long / short distances automatically. Green lasers, I’m sure ‘d bring better resolution, just have to find couple of them for affordable price.
Approximate range with low cost CMOS camera and w/o optical zoom: 0.2 – 10 meters. Accuracy would greatly depends on lasers base/spacing. Lasers base also defines minimum size of the tracking object in Z coordinate.  NTSC camera:
Velleman CAMCOLMBLAHU MINI COLOR CMOS CAMERA WITH AUDIO + POWER ADAPTER
has viewing angle 52 degrees. Forget about pixels resolution for a moment, we are in analog television world -);   Math to calculate the distance (I call it Z coordinate) is pretty simple:   D =  B / tan ( phi ),  where D is distance, B is lasers base, and phi is an angle what camera reports.  Phi = 52 degree / 832 = 0.0625 degree per coordinate difference.(See below where 832 comes from).  D = B / tan (( X1 – X2 ) * 0.0625).  For example, B = 6 cm, X1 = 500, X2 = 512, than: D = 0.06 / tan ( ( 512 – 500) * 0.0625) = 4.58 meters.
( http://en.wikipedia.org/wiki/Tangent_(trigonometric_function)

Basically, one laser would be sufficient to measure distance. I installed two of them, because it looks cool! If seriously, there are a few advantages:
- redundancy;
- better accuracy;
- no interruption in distance measurements, even when object is in “vision field” area. I defined this area, for PCL operation. Width of vision field area is adaptive, it’s  narrowing to a few lines! after start-up system.

This version of software capable to follow 1 object in X axes. edited: see below Version 2 release notes. Object has to be visible by itself (rocket, vehicle, any source of light in general) OR highlighted by external light source – not focused to cover bigger space area. Reflectivity of object would define necessary power of the light source in this case, for specific distance range. Optical zoom would significantly improve systems performance.
Tracking in Vertical (Y axes) is not implemented yet, but coordinate reported on serial monitor. Math calculus of Z dimension is not included, simple trigonometry formula could be used. Calibration of mechanical setup would be necessary in order to get meaningful measurements results.

Some technical specification: edge detection resolution -  52 microsecond / per line x 16 MHz  = 832 pixel; 235 lines / per frame;    235 x 832 overall. Speed 60 frame / second. There is no issue to get 486 vertical lines with lower speed 30 fps.

52 microsecond is essential characteristic of the NTSC standard, which represents active line duration.  I used NTSC cam, and for PAL/SECAM it’s the same. 16 MHz oscillators frequency Arduino Uno board. I’m saying edge detection instead of spacial resolution as in current setup left edge is only detected with highest possible time accuracy 16 MHz. Technically it easy to modify settings to detect right side edge as well, and measure size of object, shape, and track few of them the same time. It wouldn’t be 832 pixels, as interrupt routine timing overhead will slow down time response, and there is not much memory in Arduino to do  a complex analysis of the picture anyway. This is why decision was made not to bother with right side. In current design, capture timing of event completely done by hardware. There is a link with details on video format: http://en.wikipedia.org/wiki/Analog_television#Synchronization

If you can imagine a balloon brightly highlighted from left side, with right edge invisible in shadow, it’d be close approximation.  For time sync extraction: LM1881. Two sync signal vertical/horizontal are attached on pins 2 and 3. Hardware interrupt feature of AtMega 328 continuously updates synchronization information – current line number. Time capture done by analog comparator and timer 1. DC voltage has to be adjusted in order to trigger comparator reliable at specific level of the video signal.
And one more things to mention, servo motor driving. In order to avoid interrupt routines racing , between lines/frame syncs and servo motor software library, which generate a jitter in position of the servo, plus timing noise on video raster, I didn’t use a standard Arduino Servo library, and generate servo-sync synchronously with frame sync. Frequency is up to 60 Hz instead of regular 50 Hz, but there is no complain from my Parallax servo, and I think it would the same with any other motors as well.

Link to download sketch:  Arduino_Laser_TRF

12 December 2011   *****  VERSION 2  *****


*     There are 4 main features in the project:
*
* 1. LOCALIZATION XY. CMOS Camera, LM1881.
* 2. RANGE FINDER Z.  Two Lasers plus Camera.
* 3. TRACKING 3D.        2 Servo Motors, plus all of the above.
* 4. TRACE TOOL.      Doesn’t require hardware, software only.
*
Feature considered to be independent, so you can star to build from first one, than move on next stage, and so on depends on a budget, parts availability or your interest! This version of software capable to track object in 3D space, X, Y and Z coordinates. Tracking feature requires
object to be visible in normal “visible” spectrum or near IR. Spectral range could be extended to thermal vision with different Image sensors. Emitting light by itself Object (rocket, star, any source of light in general) OR highlighted by external light source – not focused to cover bigger space area. For distance measurements Reflectivity of object and distance would define necessary power of the external light source in this case.
Z coordinate / distance is calculated in real time, based on simple trigonometry formula D = B * tan (phi).
Calibration of mechanical setup would be necessary in order to get accurate measurements results, especially
on long distances, when angle phi becomes really small. 

Link to download sketch:  Arduino_Laser_TRF_V2
* I’m not removing first version from download section, as it’s smaller and easier to understand logic
behind some software sub-module. Please, be advised that  V1 has bugs in servo motor position calculation. V1 is preferable to hobbyist, who want only localization and distance measurements features.

NEXT LEVEL DEGREES OF FREEDOM :   6 D++ 
http://optical-magnet-laser-6d-tracking.blogspot.com/


Arduino Musical Note Recognition – Pushing the limits.

Second project based on Arduino Uno and FFT code.    (First one : Project 1.)
Short description ( EDITED: Project stopped. I lost my inspiration and working on visual recognition now, I decided to publish a code, so someone else could find it useful and continue research. ).

Main array size is 1024 bytes, real / imaginary 512 / 512, output 256 bins (only half real part, other half is mirror).  Sampling rate 4 kHz, upper note B6 (1975.5 Hz) on yellow line – right side led, lower note C3 (130.8 Hz) on red line – left side led.  Frequency resolution is approximately 7.8 Hz per bin. Processing and sampling are running in parallel. Sampling array size is 256. After data captured (256 x 0.25 msec = 64 msec) they transfered to processing array 1024, missing 256 real samples is “zero padded”, and sampling continue w/o interruption.  I did zero padding on a purpose to get “response time” of led matrix as fast as possible, so real-time 1/16 notes could be visually distinguished the same time,  as they played.

After computational cycle is completed (~36 msec), main program executes “cognitive core function” to differentiate between notes / tones, that have to be displayed on LED matrix.

 In order to minimize error rate of this process, Masking Shadow Theory (MST) was developed. Masking shadow for each note is calculated in several steps and result is compared with notes magnitude in the cycle. If magnitude is less than shadow, than led corresponding to this note wouldn’t  lights up. There are five steps for now, but as I say, work in progress. 
Step 1 (masking shadow 0):  noise floor, which is common for all notes. 
Step 2 (masking shadow 1):  shadow from neighboring notes, that includes 8   notes on left and right side, in inverse proportion to their distances. 
Step 3 (masking shadow 2):  shadow from the note, which is located 1 octave below. Or in other words, cross check if current bins value isn’t second harmonic from sounding note 1 octave below  it. 
Step 4 (masking shadow 3):  similar to step 3, the only difference is, cross check if current bin (note) isn’t third harmonic from sounding note below  it. 
Step 5 (masking shadow 5):  similar to step 3 and 4,  cross check if current note isn’t fifth harmonic from sounding note below  it.

Masking shadow is multiplied by notes specific coefficients after steps 3 – 5, to accommodate significantly richer spectral content for lower octaves.  Formula for calculation of the coefficients, is the trickiest   part of all project. What I’ve discovered, coefficient not just varying between notes / tones, they dynamically varying during “life-time” of the tone.

25 Sept. 2011 

There are two variables have been considered: speed, octave range. Third one, “not technical” – is a price for the project. 
 Octave range is defined by  RAM memory available on chip. 2K on UNO. As maximum processing array size is must be power of 2 ( FFT Radix-2 ), array couldn’t be more than  1024 bytes, next value – 2048 is size of all RAM, that obviously couldn’t be taken. Size of array defines maximum quantity of frequency bins at the output 1024 / 4 = 256. Divided by 4 as there is real / imaginary part, and only half real part is present data. What is interesting, that musical octave is nothing else than doubling of the tones frequency, so it follows binary arithmetic rules… If I will count from high side, the upper octave would occupied half of all 256 bins, from bin 256 to bin 128. Simply because frequency / musical tone spaced logarithmically (LOG_2), and bins spaced equally. Next octave takes half what left over, from bin 128 to bin 64. Third octave 64 to 32, and fourth 32 to 16. Can I go more down ? No. There are 12 notes in each octave. It means, that after fourth octave counting down , I arrived to location where bins and tones spaced almost in sequence, bin 16 – C3, bin 17 – C3#, bin 18 – D3. Well there is four more ( 15, 14, 13, and 12 ), but it doesn’t change much, as it only 1/3 of octave and only would complicate multiplexing LED display.
This is why variable octave range = 4. Summing up, increasing octave range by 1 ( to 5 octaves ) would require double memory size (2K processing array, still possible with chip 4K), by 2 ( to 6 octaves ) – four times more memory (4K processing array).

Arduino mega board has 8K RAM, would it be better to design project with it? In first, it cost more money. In second, it has the same CPU performance, and as you will see below, to have more memory w/o faster CPU doesn’t make any sense. CPU wouldn’t be able to process bigger volume of data in time.

Now lets have a look at speed variable. Following math (and design itself), is greatly depends on it. In order to get at least 1/16 note to be visually “alive”, all cycle ( sampling , pre-processing, FFT, post-processing ) has to be completed for less than 64 msec. My impression is, when timing a little bit longer, LED display looks like it shows something, that was played last Saturday night. Invisible real-time connection between “light” and “music” become broken.
Octave range variable ( 4 octave to be specific ), especially low notes starting from C3, begging for 8 Hz resolution, as it equals to distance between C3 and C3#. And consequently, for 128 msec sampling frame duration. So, there is a contradiction. To solved this , zero padding was introduced, which help to keep sampling window down to 64 msec, the same time frequency resolution not very far from 8 Hz. To make real-time life show, sampling must continue w/o interruption. Even more, it has to be “overlapped”, as pre-processing (windowing) would cut off beginning and ending of the sampling pull. All three other functions ( FFT, pre- and post-processing ) have to go in parallel and must be completed in the same time frame 64 msec. Arduino platform has 8-bit microprocessor, with low horse power engine under hood. This is why 8-bit math was selected instead of 16-bits ( which would save me a lot of troubles ). Troubles, I’m talking about, are very low dynamic range when integer math and 8 – bit comes together in FFT. Integer math, which gives nice time performance, puts really hard constrain on dynamic range, just because it performs “scaling” before and after every “butterfly”. And every scaling procedure brings in rounding error, which grows enormously, as there are 2304 butterfly (9216 round operation) for N = 512 FFT. Special attention must be payed, to keep rounding error under control, the same time not to increase calculation time too much or integer math would not make any sense. What I find out, there is  an excellent algorithm to make “symmetrical” 1/2 bit rounding, but it almost doubles calculation FFT timing, which I obviously, could not afford. So, I choose other path, to increase dynamic range. Compression algorithm on the input data. The easiest way to do it, is “clipping”. Set couple lines in the code:
             if ( x[i] >  127 )  x[i] =  127; 
             if ( x[i] < -127 )  x[i] = -127; 

and all good. Not quite. It will do a great job for any other signal (vibration from accelerometer for example), except music…..
Clipping generates a very high level of harmonics, and ones again , it couldn’t be afford, as it just undermine basic idea of the project – MUSICAL note recognition.
 
 Summary: Scaling extends dynamic range of integer FFT on 24 dB ( 4 bits ).

8- bit FFT dynamic range is +36 dB;
scaling                               +24 dB;
noise                                 -   3 dB;     
———————————————————–
Overall                                 57 dB.   


Link to download a scketch:


Arduino_Musical_Notes_Recognition


Possibly salvage the boards

My son and I were looking together about whether we could salvage the board design by using the TLE-5206-2 parts that are available.

The pinout is identical, but the functionality is different.

In1 In2 5205 out1/out2 5206 out1/out2
0 0 1/0 0/0
0 1 0/1 0/1
1 0 0/0 1/0
1 1 Z/Z 1/1

The arrangements of signals that I have available to jumper to were S, PWM, and S+PWM.  The easy jumper arrangements I had were (IN1=S, IN2=PWM) and (IN1=PWM, IN2=S+PWM), which with the TLE-5205 were supposed to give me lock anti-phase drive and sign-magnitude drive.

With the 5206, lock anti-phase would require (IN1=PWM, IN2=not PWM), which I don’t have available, but the jumper setting (IN1=S, IN2=PWM) now almost makes sense as active collapse (run/brake) mode (except that it is not quite sign magnitude, since the interpretation of the pulse width is flipped depending which way the motor is supposed to turn).  The other jumper setting makes no sense.

So now I have choice:

  1. Populate a board with TLE-5206 chips and have only the run/brake mode (I could solder in jumpers, since there are no choices).  I could also omit the now-useless OR gates.
  2. Design a new board with the TLE-5206 chips in mind, with jumpering between two modes:
    • (IN1=S, IN2=S xor PWM)   run/brake with consistent magnitude interpretation
    • (IN1=PWM, IN2=S xor PWM)  lock anti-phase if S=1, brake if S=0

Wait a second!  I don’t need a new board for that! If I replace the 74HC32 quad nor-gate with a 74HC86 quad Xor, then the 5-pin headers will be

S IN1 PWM IN2 S xor PWM

I can solder the IN2 pin to S xor PWM, and just have a 3-pin header to connect IN1 to either S (for run/brake) or PWM (for lock anti-phase). The labeling on the silk screen will be wrong, but the board will be fully usable!

The interpretation of the pulse width modulation if  IN1 is set to PWM is that 0 means always on and 255 means always braking, which is kind of weird, but easily compensated for in the software. S determines the direction the motor turns.

If IN1 is set to S, then S is interpreted as RUN if it is high, STOP if it is low, and PWM gives the direction and magnitude when running (with 0 being full on in one direction and 255 being full on in the opposite direction).  PWM should probably be set to constant 0 when braking.

I think the board can be saved, and still have all the functions we needed, though we switched from sign-magnitude to active collapse as one of the modes.  The next revision of the board (if I need to make more) would fix the silk screen and replace the 5-pin header with a 3-pin header for each chip.


Filed under: Hexmotor H-bridge board, Printed Circuit Boards, Uncategorized Tagged: Arduino, design errors, motor controller, Printed circuit board, robotics

Changing teaching plans

It turns out that I won’t be teaching an introduction to programming for biologists, as I announced in February.  Funding was found for that class to be taught by the instructor who has been teaching it, freeing me up to take on a different class as overload.  (I already pretty much committed myself to teaching an overload this year.)

I decided that the most pressing need was for an applied electronic circuits course for our bioengineering majors (the current EE circuits class is way too theoretical).  The School of Engineering’s best EE instructor (Steve P.) and I had discussed doing such a course before I went on sabbatical, and our respective department chairs were enthusiastic, but funding was not found for it.  Everyone was even more enthusiastic this time around, so Steve and I are going to design the course this summer and try teaching it together in Winter (at least, if all the enthusiasm converts into a secure position for him—otherwise he’s going to have to pick up another couple of courses from a different department and not teach the new one).  We probably won’t know for sure about the funding until November, so we’re going to go ahead and design the course on spec, hoping that we get to teach it.

If Steve becomes unavailable, I don’t think I have the confidence to teach circuits by myself, since I’ve never taken a circuits course, being almost entirely self taught (my Dad taught me a little, including a German joke about a Wien bridge, when I was in high school).  After we co-teach it once, I think either of us could do the course alone, though co-teaching with a master teacher like Steve is fun.  (If the applied circuits course falls through for this year, I’ll probably try to cobble together a graduate genome assembly and annotation course, based in part on the Banana Slug Genomics class but adding a bunch of new material, so I’ll end up with a teaching overload and working on a new course this year no matter what happens.)

I’m looking forward to designing a course with Steve. We’ve both designed many courses before, and co-taught senior design project courses, but we’ve not designed a course together before. I’ve lost track of how many I’ve designed—something like 15–20, depending how you count the courses that someone else started but I extensively modified.

The approach that Steve and I are taking to the course design is to start by looking for lab projects for the students to do.  We need 10 labs (one a week for 10 weeks) ranging from very basic getting-to-know-the-equipment labs up to real (but small) design challenges.  We will try out the labs ourselves separately, then compare notes on how things went before writing up the lab handouts.  After we have the labs figured out, we’ll make sure that we cover the theory needed to understand the labs and do the designs, pacing the lectures to stay just a little ahead of the labs.  At least, that is how we both envision the process currently.

Here are a few labs that I’ve been thinking about—I’d appreciate a lot more suggestions.

  • Skin conductance meter.  There are a lot of do-it-yourself lie detector circuits for measuring skin resistance (“electrodermal response” if you want to sound medical).  I like the “Lego” sensor that just uses the inputs of a Lego RCX brick to read the resistance between two fingers. But getting RCX bricks for the lab just to measure resistance is silly.
    I wonder if we should give them something that reads and records voltage (like an Arduino or other microprocessor with an A/D converter) and have them make a voltage divider to read resistance.  This could be a good first lab, with them making a single measurement with a multimeter, choosing an appropriate resistor for the voltage divider, then recording a few minutes of skin resistance, perhaps on the inside of the wrist.  We could have them use fancy silver chloride gel electrodes at 500/$80, rather than Al foil and velcro—it’d probably end up cheaper.
  • When I told my son that we wanted to design the labs so that they could be done by the students without hand holding, he suggested the experiment where you pass a (small) current through a chain of people holding hands.  This might not be a bad idea also for a lecture demo.
  • Electrical field measurements in an electrophoresis gel.  The students would cast a gel (possibly agarose, but maybe just agar, to make it cheaper) with a standard buffer, apply a small voltage (much less than usually used in electrophoresis, since we’ll be working without the safety shield of a closed electrophoresis box), then use a handheld voltmeter to measure the voltage at different points in the gel.  We would also have them measure voltage and current.  We might even have them time the movement of a loading dye at different voltages, but I think that would take too long.
    One problem with this lab is that it requires using the wet lab, and neither Steve nor I are really wet-lab people.  I wonder if we could borrow a TA for a week from another course.  Perhaps a bioengineering senior undergrad could be hired, as many of them have some experience at casting gels.
  • Conductivity of saline solutions.  It is standard to measure the ionic content of fresh water and even sea water by measuring its conductivity—Wikipedia has a decent article on the theory of electrolyte conductivity.  A conductivity calculator gives an equivalence of 1 ppm total dissolved solids as 1.56 µS/cm, though they don’t specify the temperature or include a temperature correction.  The City of Santa Cruz 2011 Consumer Confidence Report lists the drinking water in town as 280–760 µS/cm (though they use the charming older name: µmhos/cm), while a 2004 San Lorenzo River Watershed Management Plan gives the conductivity in the estuary as 260–44,860 µS/cm, depending when and where the sample is taken (though they label their table wrong)
    The tricky part here is that the conductivity testing has to be done with an AC signal, not a DC one, to avoid problems at the electrodes. If we trust the students not to spill salt water into the equipment, we could probably do this lab in the electronics lab, and use the bench oscillator and meters.  Later in the quarter we might have them design their own rectifier circuit to communicate with a microprocessor, but I suspect that doing an oscillator may be beyond the scope of the class.
    We may also want to get silver/silver chloride electrodes (or fine silver wire at $0.90/foot and soak it in bleach).    Using thin wires as the electrodes may cause problems with the resistance being very high.  I wonder if we should try doing something cheaper first, like using a pair of pennies cleaned in vinegar and rinsed.  They wouldn’t last long in salt water, but even demonstrating the problem might be instructive.
  • A good project for late in the quarter would be a do-it-yourself EKG, which requires a simple amplifier (and gets another use for the silver/silver-chloride gel electrodes).
  • We could also do an optical pulse detector, using an LED and a light sensor, though we’d probably end up making our own, rather than buying one for $20.
  • Breathalyzer.  A resistance-output sensor for alcohol on the breath looks like it only costs about $5.  This may be too simple.

Several of these labs look like they would be most interesting if they involved hooking up to an Arduino or other cheap microprocessor that can record time-course data.  Since programming is outside the scope of the circuits course, we could have the students buy an Arduino for about $20–30 online and give them a simple recording program (perhaps I can get my son to write them a versatile one, based on the one he wrote for our super pulley recording).  The students could sell the Arduino used if they weren’t interested in doing anything with it (the Digital Arts and New Media students use them and probably would be glad of cheap ones).

Obviously, we’re going to need more lab ideas.  Does anyone have any?