You can get a lot of quick info from a business card — name, job title, contact info — and now you can also see your heart beat.
The post Hold This Smart Business Card to See Your Heart Beat appeared first on Make: DIY Projects and Ideas for Makers.
Continuing the series of posts on measuring salinity with a couple of resistors and microprocessor
Today I started over on using the KL25Z board. Since I wasn’t interested in precise frequencies, I didn’t use the PWM output this time, but used the same trick I used on the Arduino board: flipping the output bit, reading a sample, and repeating in a burst.
I record the sum of the differences between the high and low readings, and report the average at the end of each burst. By using 40,000 cycles of warmup in each burst (discarded), then averaging over the next 10,000 cycles, I get a voltage reading that has a standard deviation of about 0.1mV on a reading of 2.843V, which is about 14–15 bits of accuracy. The voltage reading is not constant, though, but drifts downward.
(click to embiggen) Voltage difference at undriven electrode as a function of time. The two sudden steps were probably the result of my jostling the table by putting down my teacup too hard.
I don’t have an explanation of the gradual drift in the voltage. I don’t think that this is a change in the salinity of the solution (which should be unchanged or increasing slowly due to evaporation). but a change in the characteristics of the electrodes. More likely, it is a change in the characteristics of the electrodes. The sudden shifts when the table was jostled may be due to electrodes shifting their position in the cup or the release of a bubble. Releasing a bubble should increase the surface area of the electrode and hence increase the conductivity and the voltage difference at the undriven electrode. The gradual downward shift could be due to building up tiny hydrogen bubbles (too small to see) on the negative electrode. The changes in voltage observed here are less than 0.1%, which is fairly respectable for a homebrew instrument.
Here is the (undocumented, throw-away) code that I wrote today to test out the ideas of an automatic salinity measurement system using a KL25Z:
#include "mbed.h"
DigitalInOut square_out(PTB0); // PTB0=arduino A0
//PTB0, PTB1, PTD6, and PTD7 I/O have both high drive and normal drive capability selected by the associated PTx_PCRn[DSE] control bit.
AnalogIn IN(PTB1); // PTB1=Arduino A1
Serial USB_io(USBTX, USBRX); // defaults to 9600 8N1 (reset in main to 115200 baud)
Timer since_start;
#define WARMUP (40000) // number of cycles of toggling output before collecting data
#define COLLECT (10000) // number of cycles of data to sum for each output
#define Vdd (3.3) // High voltage at output
int main()
{
USB_io.baud(115200);
USB_io.printf("\nusec\tvolts\nN\tN\n");
//DEFAULT configuration of analog input
ADC0->CFG1 = ADC_CFG1_ADLPC_MASK // Low-Power Configuration
| ADC_CFG1_ADIV(3) // Clock Divide Select: (Input Clock)/8
| ADC_CFG1_ADLSMP_MASK // Long Sample Time
| ADC_CFG1_MODE(3) // (16)bits Resolution
| ADC_CFG1_ADICLK(1); // Input Clock: (Bus Clock)/2
ADC0->CFG2 = ADC_CFG2_MUXSEL_MASK // ADxxb channels are selected
| ADC_CFG2_ADACKEN_MASK // Asynchronous Clock Output Enable
| ADC_CFG2_ADHSC_MASK // High-Speed Configuration
| ADC_CFG2_ADLSTS(0); // Long Sample Time Select
ADC0->SC2 = ADC_SC2_REFSEL(0); // Default Voltage Reference
ADC0->SC3 = ADC_SC3_AVGE_MASK // Hardware Average Enable
| ADC_SC3_AVGS(0); // 4 Samples Averaged
// FAST analog input
ADC0->CFG1 =
ADC_CFG1_MODE(3) // (16)bits Resolution
| ADC_CFG1_ADLSMP_MASK // Long Sample Time
| ADC_CFG1_ADICLK(0); // Input Clock: (Bus Clock)
ADC0->CFG2 = ADC_CFG2_MUXSEL_MASK // ADxxb channels are selected
| ADC_CFG2_ADACKEN_MASK // Asynchronous Clock Output Enable
| ADC_CFG2_ADHSC_MASK // High-Speed Configuration
| ADC_CFG2_ADLSTS(0); // longest "long" Sample Time Select
// | ADC_CFG2_ADLSTS(3); // shortest "long" Sample Time Select
ADC0->SC2 = ADC_SC2_REFSEL(0); // Default Voltage Reference
ADC0->SC3 = 0; // No hardware averaging
// set PORTB pin 0 to high drive here
PORTB->PCR[0] |= PORT_PCR_DSE_MASK;
since_start.start();
while(1)
{
square_out.output();
for (int i=0; i
{
square_out=1;
wait_us(1);
volatile uint16_t rise_read=IN.read_u16();
square_out=0;
wait_us(1);
volatile uint16_t fall_read=IN.read_u16();
}
int32_t sum=0;
for (int i=0;i<COLLECT; i++)
{
square_out=1;
wait_us(1);
int32_t rise_read=IN.read_u16();
square_out=0;
wait_us(1);
sum += rise_read - IN.read_u16();
}
square_out.input(); // hiZ state when not driving pulses
USB_io.printf("%10d\t%7.5f\n", since_start.read_us(), sum*(Vdd/COLLECT/(1<<16))); // scale output to volts
}
}
There is still a lot that needs to be done to make this a finished project, but I’ve convinced myself that it is doable as freshman design project, which is all I really needed to do.
Continuing the series of posts on measuring salinity with a couple of resistors and microprocessor
Today I started over on using the KL25Z board. Since I wasn’t interested in precise frequencies, I didn’t use the PWM output this time, but used the same trick I used on the Arduino board: flipping the output bit, reading a sample, and repeating in a burst.
I record the sum of the differences between the high and low readings, and report the average at the end of each burst. By using 40,000 cycles of warmup in each burst (discarded), then averaging over the next 10,000 cycles, I get a voltage reading that has a standard deviation of about 0.1mV on a reading of 2.843V, which is about 14–15 bits of accuracy. The voltage reading is not constant, though, but drifts downward.
(click to embiggen) Voltage difference at undriven electrode as a function of time. The two sudden steps were probably the result of my jostling the table by putting down my teacup too hard.
I don’t have an explanation of the gradual drift in the voltage. I don’t think that this is a change in the salinity of the solution (which should be unchanged or increasing slowly due to evaporation). but a change in the characteristics of the electrodes. More likely, it is a change in the characteristics of the electrodes. The sudden shifts when the table was jostled may be due to electrodes shifting their position in the cup or the release of a bubble. Releasing a bubble should increase the surface area of the electrode and hence increase the conductivity and the voltage difference at the undriven electrode. The gradual downward shift could be due to building up tiny hydrogen bubbles (too small to see) on the negative electrode. The changes in voltage observed here are less than 0.1%, which is fairly respectable for a homebrew instrument.
Here is the (undocumented, throw-away) code that I wrote today to test out the ideas of an automatic salinity measurement system using a KL25Z:
#include "mbed.h"
DigitalInOut square_out(PTB0); // PTB0=arduino A0
//PTB0, PTB1, PTD6, and PTD7 I/O have both high drive and normal drive capability selected by the associated PTx_PCRn[DSE] control bit.
AnalogIn IN(PTB1); // PTB1=Arduino A1
Serial USB_io(USBTX, USBRX); // defaults to 9600 8N1 (reset in main to 115200 baud)
Timer since_start;
#define WARMUP (40000) // number of cycles of toggling output before collecting data
#define COLLECT (10000) // number of cycles of data to sum for each output
#define Vdd (3.3) // High voltage at output
int main()
{
USB_io.baud(115200);
USB_io.printf("\nusec\tvolts\nN\tN\n");
//DEFAULT configuration of analog input
ADC0->CFG1 = ADC_CFG1_ADLPC_MASK // Low-Power Configuration
| ADC_CFG1_ADIV(3) // Clock Divide Select: (Input Clock)/8
| ADC_CFG1_ADLSMP_MASK // Long Sample Time
| ADC_CFG1_MODE(3) // (16)bits Resolution
| ADC_CFG1_ADICLK(1); // Input Clock: (Bus Clock)/2
ADC0->CFG2 = ADC_CFG2_MUXSEL_MASK // ADxxb channels are selected
| ADC_CFG2_ADACKEN_MASK // Asynchronous Clock Output Enable
| ADC_CFG2_ADHSC_MASK // High-Speed Configuration
| ADC_CFG2_ADLSTS(0); // Long Sample Time Select
ADC0->SC2 = ADC_SC2_REFSEL(0); // Default Voltage Reference
ADC0->SC3 = ADC_SC3_AVGE_MASK // Hardware Average Enable
| ADC_SC3_AVGS(0); // 4 Samples Averaged
// FAST analog input
ADC0->CFG1 =
ADC_CFG1_MODE(3) // (16)bits Resolution
| ADC_CFG1_ADLSMP_MASK // Long Sample Time
| ADC_CFG1_ADICLK(0); // Input Clock: (Bus Clock)
ADC0->CFG2 = ADC_CFG2_MUXSEL_MASK // ADxxb channels are selected
| ADC_CFG2_ADACKEN_MASK // Asynchronous Clock Output Enable
| ADC_CFG2_ADHSC_MASK // High-Speed Configuration
| ADC_CFG2_ADLSTS(0); // longest "long" Sample Time Select
// | ADC_CFG2_ADLSTS(3); // shortest "long" Sample Time Select
ADC0->SC2 = ADC_SC2_REFSEL(0); // Default Voltage Reference
ADC0->SC3 = 0; // No hardware averaging
// set PORTB pin 0 to high drive here
PORTB->PCR[0] |= PORT_PCR_DSE_MASK;
since_start.start();
while(1)
{
square_out.output();
for (int i=0; i
{
square_out=1;
wait_us(1);
volatile uint16_t rise_read=IN.read_u16();
square_out=0;
wait_us(1);
volatile uint16_t fall_read=IN.read_u16();
}
int32_t sum=0;
for (int i=0;i<COLLECT; i++)
{
square_out=1;
wait_us(1);
int32_t rise_read=IN.read_u16();
square_out=0;
wait_us(1);
sum += rise_read - IN.read_u16();
}
square_out.input(); // hiZ state when not driving pulses
USB_io.printf("%10d\t%7.5f\n", since_start.read_us(), sum*(Vdd/COLLECT/(1<<16))); // scale output to volts
}
}
There is still a lot that needs to be done to make this a finished project, but I’ve convinced myself that it is doable as freshman design project, which is all I really needed to do.
In More on automatic measurement of conductivity of saline solution, I suggested using a simple voltage divider and a microcontroller to make conductivity measurements with polarizable electrodes:
Simplified circuit for conductivity tester.
I found that putting in a 100kHz square wave worked well:
At 100kHz, both the voltage waveforms (input and output) look like pretty good square waves.
I have not yet figured out a good way on the KL25Z to provide the 100kHz signal, sample the outputs at fixed points, and communicate the result out the USB port. Using PWM for the output was handy for just generating the output (once I fixed mbed’s off-by-one bug in their pwmout_api.c file), but that makes connecting up the analog reads more difficult. I think that I may be better off not using PWM, but using a timer interrupt to read the analog value, change the output, and do the subtraction. It would be fairly easy to arrange that (though I’ll probably have to figure out all the registers for the sample-and-hold and the analog-to-digital converter, as the mbed AnalogIn routine is unlikely to have the settings I want to use). The hard part remains the interface to the host computer, as mbed does not include a simple serial interface and serial monitor like the Arduino IDE. [Correction 2013 Dec 25: my son points out that the mbed development kit has a perfectly usable serial USB interface—I had overlooked the inheritance from "Stream", which has all the functions I thought were missing. I should be able to use the Arduino serial monitor with the Freedom KL25Z board, as long as the serial interface is set up right.]
Because I’m more familiar with the Arduino environment, and because I already have Arduino Data Logger code for the host end of the interface, I started by making a simple loop that toggles the output and reads the value after each change in output. After repeating this several times (40 or 100), I take the last difference as the output and report that to the data logger. I couldn’t get the frequency up where I really want it (100kHz), because the Arduino analog-to-digital converter is slow, but I was able to run at about 4kHz, which would be adequate.
Because there needs to be time for the serial communication, I did bursts of pulses with pauses between bursts. The bursts were alternating as fast as the analog inputs were read for a fixed number of cycles, and the start of the bursts was controlled by the Arduino data logger software. Although the ends of the bursts looked the same on the oscilloscope, with the same peak-to-peak voltage, I got different readings from the Arduino depending on the spacing between the bursts. I’m not sure what is causing the discrepancy.
A difference at the beginnings of the bursts I would understand as the space between the bursts put a DC voltage across the electrodes which gradually charged them up, so that the first few pulses actually end up going outside the range of the ADC:
The bottom of the grid is 0v, and the first pulse goes up to 5.442v. The pulses are at about 4kHz, but the bursts start 50msec apart.
The differences at the ends of the bursts as I change the spacing between bursts are probably also due to the charging, though I don’t see that clearly on the oscilloscope. I really don’t like the idea of having a DC bias across the electrodes, as we get electrolysis, with hydrogen bubbles forming on the more negative electrode. No oxygen bubbles form, probably because any oxygen released is reacting with the stainless steel to form metal oxides. If I increase the voltage and current, I get a lot of hydrogen bubbles on the negative electrode, some rusty looking precipitate coming off the positive electrode (probably an iron oxide), and a white coating building up on the positive electrode (probably a chromium oxide).
By putting a 4.7µF capacitor between the Arduino output and the electrode, I can reduce DC bias on the electrodes and get a more consistent signal from the Arduino, almost independent of the spacing between the bursts:
By using a 25msec spacing between the beginnings of bursts, I can get both the end of the burst and the beginning of the burst on the oscilloscope at once.
Using a 4.7µF capacitor between the square wave output and the electrodes results in sharp peaks across the resistor, but a more consistent reading from the Arduino ADC.
The voltage across the electrodes still does not average to 0v, as the pair of resistors provides a bias voltage halfway between the rails, but the pulse does not really swing rail to rail, but from 0.28v to 4.28v. I think that the low-pass filter for setting the bias voltage that I suggested in More on automatic measurement of conductivity of saline solution may be a good idea after all, to make sure that there is no residual DC bias.
I can use the differential inputs of the Bitscope DP01 to look at the voltage across the electrodes and across the resistor to get voltage and current traces for the electrodes:
The central horizontal line is 0V for both traces here. The green trace is the voltage at the undriven electrode (@ 2v/division) and so corresponds to the current, and the yellow trace is the voltage between the electrodes (@0.2v/division).
Note that the voltage on the undriven electrode does run a little below 0V, outside the range of the Arduino ADC. The voltage ratio of 0.248v/4.16v, together with the 100Ω Thévenin equivalent resistance results in a 5.47Ω resistance between the electrodes. (Note: this is no longer a 1M NaCl solution—there has been evaporation, plus contamination from iron oxides, and the electrodes are not covered to the depth defined by the plastic spacer.)
I don’t know whether the conductivity meter is a good project for the freshman design seminar or not—I don’t expect the students to have the circuit skills or the programming skills to be able to do a design like this without a lot of coaching. Even figuring out that they need to eliminate DC bias to eliminate electrolysis may be too much for them, though I do expect all to have had at least high-school chemistry. It is probably worth doing a demo of putting a large current through electrodes in salt solution, to show both the hydrogen bubbles and the formation of the oxides. I could probably coach freshmen through the design, if they were interested in doing it, so I’ll leave it on the feasible list.
The square-wave analysis is not really suitable for a circuits course, so I think I’ll stick with sine-wave excitation for that course.
In More on automatic measurement of conductivity of saline solution, I suggested using a simple voltage divider and a microcontroller to make conductivity measurements with polarizable electrodes:
Simplified circuit for conductivity tester.
I found that putting in a 100kHz square wave worked well:
At 100kHz, both the voltage waveforms (input and output) look like pretty good square waves.
I have not yet figured out a good way on the KL25Z to provide the 100kHz signal, sample the outputs at fixed points, and communicate the result out the USB port. Using PWM for the output was handy for just generating the output (once I fixed mbed’s off-by-one bug in their pwmout_api.c file), but that makes connecting up the analog reads more difficult. I think that I may be better off not using PWM, but using a timer interrupt to read the analog value, change the output, and do the subtraction. It would be fairly easy to arrange that (though I’ll probably have to figure out all the registers for the sample-and-hold and the analog-to-digital converter, as the mbed AnalogIn routine is unlikely to have the settings I want to use). The hard part remains the interface to the host computer, as mbed does not include a simple serial interface and serial monitor like the Arduino IDE. [Correction 2013 Dec 25: my son points out that the mbed development kit has a perfectly usable serial USB interface—I had overlooked the inheritance from "Stream", which has all the functions I thought were missing. I should be able to use the Arduino serial monitor with the Freedom KL25Z board, as long as the serial interface is set up right.]
Because I’m more familiar with the Arduino environment, and because I already have Arduino Data Logger code for the host end of the interface, I started by making a simple loop that toggles the output and reads the value after each change in output. After repeating this several times (40 or 100), I take the last difference as the output and report that to the data logger. I couldn’t get the frequency up where I really want it (100kHz), because the Arduino analog-to-digital converter is slow, but I was able to run at about 4kHz, which would be adequate.
Because there needs to be time for the serial communication, I did bursts of pulses with pauses between bursts. The bursts were alternating as fast as the analog inputs were read for a fixed number of cycles, and the start of the bursts was controlled by the Arduino data logger software. Although the ends of the bursts looked the same on the oscilloscope, with the same peak-to-peak voltage, I got different readings from the Arduino depending on the spacing between the bursts. I’m not sure what is causing the discrepancy.
A difference at the beginnings of the bursts I would understand as the space between the bursts put a DC voltage across the electrodes which gradually charged them up, so that the first few pulses actually end up going outside the range of the ADC:
The bottom of the grid is 0v, and the first pulse goes up to 5.442v. The pulses are at about 4kHz, but the bursts start 50msec apart.
The differences at the ends of the bursts as I change the spacing between bursts are probably also due to the charging, though I don’t see that clearly on the oscilloscope. I really don’t like the idea of having a DC bias across the electrodes, as we get electrolysis, with hydrogen bubbles forming on the more negative electrode. No oxygen bubbles form, probably because any oxygen released is reacting with the stainless steel to form metal oxides. If I increase the voltage and current, I get a lot of hydrogen bubbles on the negative electrode, some rusty looking precipitate coming off the positive electrode (probably an iron oxide), and a white coating building up on the positive electrode (probably a chromium oxide).
By putting a 4.7µF capacitor between the Arduino output and the electrode, I can reduce DC bias on the electrodes and get a more consistent signal from the Arduino, almost independent of the spacing between the bursts:
By using a 25msec spacing between the beginnings of bursts, I can get both the end of the burst and the beginning of the burst on the oscilloscope at once.
Using a 4.7µF capacitor between the square wave output and the electrodes results in sharp peaks across the resistor, but a more consistent reading from the Arduino ADC.
The voltage across the electrodes still does not average to 0v, as the pair of resistors provides a bias voltage halfway between the rails, but the pulse does not really swing rail to rail, but from 0.28v to 4.28v. I think that the low-pass filter for setting the bias voltage that I suggested in More on automatic measurement of conductivity of saline solution may be a good idea after all, to make sure that there is no residual DC bias.
I can use the differential inputs of the Bitscope DP01 to look at the voltage across the electrodes and across the resistor to get voltage and current traces for the electrodes:
The central horizontal line is 0V for both traces here. The green trace is the voltage at the undriven electrode (@ 2v/division) and so corresponds to the current, and the yellow trace is the voltage between the electrodes (@0.2v/division).
Note that the voltage on the undriven electrode does run a little below 0V, outside the range of the Arduino ADC. The voltage ratio of 0.248v/4.16v, together with the 100Ω Thévenin equivalent resistance results in a 5.47Ω resistance between the electrodes. (Note: this is no longer a 1M NaCl solution—there has been evaporation, plus contamination from iron oxides, and the electrodes are not covered to the depth defined by the plastic spacer.)
I don’t know whether the conductivity meter is a good project for the freshman design seminar or not—I don’t expect the students to have the circuit skills or the programming skills to be able to do a design like this without a lot of coaching. Even figuring out that they need to eliminate DC bias to eliminate electrolysis may be too much for them, though I do expect all to have had at least high-school chemistry. It is probably worth doing a demo of putting a large current through electrodes in salt solution, to show both the hydrogen bubbles and the formation of the oxides. I could probably coach freshmen through the design, if they were interested in doing it, so I’ll leave it on the feasible list.
The square-wave analysis is not really suitable for a circuits course, so I think I’ll stick with sine-wave excitation for that course.
Introduction
Time for another kit review and in this instalment we have a look at the “3 digit counter” kit from Jaycar. This is part of a much larger series of kits that are described in a three volume set of educational books from Jaycar titled “Short Circuits”.
Aimed at the younger readers or anyone who has an interest in learning electronics, these books (volumes one, two and three) are well written and with some study and practice the reader will make a large variety of projects and learn quite a bit. They could be considered as a worthy 21st-century replacement to the old Dick Smith “Funway…” guides.
The purpose of this kit is to give you a device which can count upwards between zero and 999 – which can be used for various purposes and also of course to learn about digital electronics.
Assembly
The kit arrives in typical retail fashion:
Everything you need to make the counter is included except for the instructions – which are found in the “Short Circuits” volume two book – and IC sockets. Kits for beginners with should come with IC sockets.
The components are separated neatly in the bag above, and it was interesting to see the use of zero ohm resistors for the two links on the board:
The PCB is excellent. The silk screening and solder-mask is very well done.
Furthermore I was really, really impressed with the level of detail with the drilling. The designer has allowed for components with different pin spacing – for example the 100 nF capacitor and transistors as shown below:
The instructions in the book are very clear and are written in an approachable fashion:
There’s also a detailed explanation on how the circuit works, some interesting BCD to decimal notes, examples of use (slot cars!) and a neat diagram showing how to mount the kit in a box using various parts from Jaycar – so you’re not left on your own.
Construction went well, starting with the low-profile parts:
… then the semiconductors:
… then the higher-profile parts and we’re finished:
There wasn’t any difficulty at all, and the counter worked first time. Although I’m not a new user, the quality of PCB and instructions would have been a contributing factor to the success of the kit.
How it works
The input signal for the counter (in this case a button controlling current from the supply rail) is “squared-up” by an MC14093 schmitt-trigger IC, which then feeds a MC14553 BCD counter IC, which counts and then feeds the results to a 4511 BCD to 7-segment converter to drive the LED digits which are multiplexed by the MC14553. For the schematic and details please refer to the book. Operation is simple, and demonstrated in the following video:
However you can feed the counter an external signal, by simply applying it to the input section of the circuit. After a quick modification:
… it was ready to be connected to a function generator. In the following video we send pulses with a varying frequency up to 2 kHz:
Conclusion
This is a neat kit, works well and with the accompanying book makes a good explanation of a popular digital electronics subject. There aren’t many good “electronics for beginners” books on the market any more, howevert the “Short Circuits” range from Jaycar really fit the bill.
So if you’re looking to learn more about electronics or start someone else off, head in to Jaycar and have a look. Readers from outside Australia are also covered. Full-sized images are available on flickr.
And while you’re here – are you interested in Arduino? Check out my new book “Arduino Workshop” from No Starch Press.
In the meanwhile have fun and keep checking into tronixstuff.com. Why not follow things on twitter, Google+, subscribe for email updates or RSS using the links on the right-hand column? And join our friendly Google Group – dedicated to the projects and related items on this website. Sign up – it’s free, helpful to each other – and we can all learn something.
[Note – kit and book purchased without notifying the supplier]
The post Kit Review – Jaycar “Short Circuits” 3 Digit Counter appeared first on tronixstuff.
I’ve been thinking of expanding the pressure sensor lab for the Applied Circuits Course to do something more than just measure breath pressure. Perhaps something that conveys another physics or engineering concept.
One thing I thought of doing was measuring the back pressure and air flow on an aquarium air pump bubbling air into an aquarium. Looking at the tradeoff of flow-rate and back pressure would be a good characterization of an air pump (something I wish was clearly shown in advertisements for aquarium air pumps and air stones). Measuring flow rate is a bit of a pain—about the best I could think of was to bubble air into an inverted soda bottle (or other known volume) and time it.
This would be a good physics experiment and might even make a decent middle-school product-science science fair project (using a cheap mechanical low-pressure gauge, rather than an electronic pressure sensor), but setting up tanks of water in an electronics lab is a logistic nightmare, and I don’t think I want to go there.
I can generate back pressure with just a simple clamp on the hose, though, and without a flow rate measurement we could do everything completely dry.
Setup for measuring the back pressure for an aquarium air pump (needs USB connection for data logger and power).
Using the Arduino data loggger my son wrote, I recorded the air pressure while adjusting the clamp (to get the y-axis scale correct, I had to use the estimated gain of the amplifier based on resistor sizes used in the amplifier).
The peak pressure, with the clamp sealing the hose shut, seems to be about 14.5 kPa (2.1psi).
I was interested in the fluctuation in the pressure, so I set the clamp to get about half the maximum back pressure, then recorded with the Arduino data logger set to its highest sampling frequency (1ms/sample).
The fluctuation in back pressure seems to have both a 60Hz and a 420Hz component with back pressure at about half maximum.
Because the Arduino data logger has trouble dealing with audio frequency signals, I decided to take another look at the signals using the Bitscope pocket analyzer.
The waveform for the pressure fluctuations from the AQT3001 air pump, with the back pressure about 7.5kPa (half the maximum).
One advantage of using the Bitscope is that it has FFT analysis:
Spectrum for the back pressure fluctuation. One can see many of the multiples of 60Hz, with the particularly strong peak at 420Hz.
I was also interested in testing a Whisper40 air pump (a more powerful, but quieter, pump). When I clamped the hose shut for that air pump, the hi-gain output of the amplifier for the pressure sensor saturated, so I had to use the low gain output to determine the maximum pressure (24.8kPA, or about 3.6psi). The cheap Grafco clamp that I used is a bit hard to get complete shutoff with (I needed to adjust the position of the tubing and use pliers to turn the knob). It is easy to get complete shutoff if the tube is folded over, but then modulation of less than complete shutoff is difficult.
The fluctuation in pressure shows a different waveform from the AQT3001:
The Whisper40 air pump, with the clamp set to get a bit less than half the maximum back pressure, produces a 60Hz sawtooth pressure waveform, without the strong 420Hz component seen from the AQT3001. The peak-to-peak fluctuation in pressure seems to be largest around this back pressure. The 3kPa fluctuation is larger than for the AQT3001, but the pump seems quieter.
The main noise from the pump is not from the fluctuation in the pressure in the air hose, but radiation from the case of the pump. That noise seems to be least when the back pressure is about 1.1kPa (not at zero, surprisingly). The fluctuation is then all positive pressure, ranging from 0 to 2.2kPa and is nearly sinusoidal, with some 2nd and 3rd harmonic.
As the back pressure increases for the Whisper40, the 2nd, 3rd, and 4th harmonics get larger, but the 60Hz fundamental gets smaller. The 4th harmonic is maximized (with the 1st through 4th harmonics almost equal) at about 22.8kPa, above which all harmonics get smaller, until the air hose is completely pinched off and there is no pressure variation.
When driving the large airstone in our aquarium, the Whisper40 has a back pressure of about 7.50kPa (1.1psi) with a peak-to-peak fluctuation of about 2.6kPa.
I’m not sure whether this air-pump back-pressure experiment is worth adding to the pressure sensor lab. If I decide to do it, we would need to get a dozen cheap air pumps. The Tetra 77853 Whisper 40 air pump is $11.83 each from Amazon, but the smaller one for 10-gallon aquariums is only $6.88. With 12 Ts and 12 clamps, this would cost about $108, which is not a significant cost for the lab.
I’ve been thinking of expanding the pressure sensor lab for the Applied Circuits Course to do something more than just measure breath pressure. Perhaps something that conveys another physics or engineering concept.
One thing I thought of doing was measuring the back pressure and air flow on an aquarium air pump bubbling air into an aquarium. Looking at the tradeoff of flow-rate and back pressure would be a good characterization of an air pump (something I wish was clearly shown in advertisements for aquarium air pumps and air stones). Measuring flow rate is a bit of a pain—about the best I could think of was to bubble air into an inverted soda bottle (or other known volume) and time it.
This would be a good physics experiment and might even make a decent middle-school product-science science fair project (using a cheap mechanical low-pressure gauge, rather than an electronic pressure sensor), but setting up tanks of water in an electronics lab is a logistic nightmare, and I don’t think I want to go there.
I can generate back pressure with just a simple clamp on the hose, though, and without a flow rate measurement we could do everything completely dry.
Setup for measuring the back pressure for an aquarium air pump (needs USB connection for data logger and power).
Using the Arduino data loggger my son wrote, I recorded the air pressure while adjusting the clamp (to get the y-axis scale correct, I had to use the estimated gain of the amplifier based on resistor sizes used in the amplifier).
The peak pressure, with the clamp sealing the hose shut, seems to be about 14.5 kPa (2.1psi).
I was interested in the fluctuation in the pressure, so I set the clamp to get about half the maximum back pressure, then recorded with the Arduino data logger set to its highest sampling frequency (1ms/sample).
The fluctuation in back pressure seems to have both a 60Hz and a 420Hz component with back pressure at about half maximum.
Because the Arduino data logger has trouble dealing with audio frequency signals, I decided to take another look at the signals using the Bitscope pocket analyzer.
The waveform for the pressure fluctuations from the AQT3001 air pump, with the back pressure about 7.5kPa (half the maximum).
One advantage of using the Bitscope is that it has FFT analysis:
Spectrum for the back pressure fluctuation. One can see many of the multiples of 60Hz, with the particularly strong peak at 420Hz.
I was also interested in testing a Whisper40 air pump (a more powerful, but quieter, pump). When I clamped the hose shut for that air pump, the hi-gain output of the amplifier for the pressure sensor saturated, so I had to use the low gain output to determine the maximum pressure (24.8kPA, or about 3.6psi). The cheap Grafco clamp that I used is a bit hard to get complete shutoff with (I needed to adjust the position of the tubing and use pliers to turn the knob). It is easy to get complete shutoff if the tube is folded over, but then modulation of less than complete shutoff is difficult.
The fluctuation in pressure shows a different waveform from the AQT3001:
The Whisper40 air pump, with the clamp set to get a bit less than half the maximum back pressure, produces a 60Hz sawtooth pressure waveform, without the strong 420Hz component seen from the AQT3001. The peak-to-peak fluctuation in pressure seems to be largest around this back pressure. The 3kPa fluctuation is larger than for the AQT3001, but the pump seems quieter.
The main noise from the pump is not from the fluctuation in the pressure in the air hose, but radiation from the case of the pump. That noise seems to be least when the back pressure is about 1.1kPa (not at zero, surprisingly). The fluctuation is then all positive pressure, ranging from 0 to 2.2kPa and is nearly sinusoidal, with some 2nd and 3rd harmonic.
As the back pressure increases for the Whisper40, the 2nd, 3rd, and 4th harmonics get larger, but the 60Hz fundamental gets smaller. The 4th harmonic is maximized (with the 1st through 4th harmonics almost equal) at about 22.8kPa, above which all harmonics get smaller, until the air hose is completely pinched off and there is no pressure variation.
When driving the large airstone in our aquarium, the Whisper40 has a back pressure of about 7.50kPa (1.1psi) with a peak-to-peak fluctuation of about 2.6kPa.
I’m not sure whether this air-pump back-pressure experiment is worth adding to the pressure sensor lab. If I decide to do it, we would need to get a dozen cheap air pumps. The Tetra 77853 Whisper 40 air pump is $11.83 each from Amazon, but the smaller one for 10-gallon aquariums is only $6.88. With 12 Ts and 12 clamps, this would cost about $108, which is not a significant cost for the lab.
I feel pretty good about today’s lecture, though things got a little rushed at the end.
Three-resistor voltage divider for the first question.
I started with a “do now” question, similar to the one from Monday. Actually, I started with 2 questions. The first just asked what the output voltage would be for a 3-resistor voltage divider. The second repeated the question from Monday, but with the additional constraint that the power supply was 5 volts:
You have sensor whose resistance varies from 1kΩ to 4kΩ with the property it measures and a 5v power supply. Design a circuit whose output voltage varies from 1v (at 1kΩ) to 2v (at 4kΩ).
Several students realized that the first question was a hint for the second one and that the variable resistor had to be RB or RC, and could set up the equations and solve for RA and RC. This is a better performance than on Monday’s “do now”, but only about 1/3 of the class got it completely, and several of them were not confident of their results, so we again took time to go over the whole solution. I think that everyone (or almost everyone) understood the design process and how to set up and solve the equations by the end of the presentation, which I drew out of the students as much as possible. I also mentioned that we could have solved the problem with a different circuit (putting RC in parallel with RB instead of in series), but did not further elaborate on that point.
The do-now plus going over the solution took about 33 minutes, which is a little more time than I’d like to be spending on these questions. It would be good to get the time down to 15 minutes, but I don’t see how to do that without losing half the class. If the problems are easy enough that everyone gets them, then there is no point to taking up any class time with them, and if they are hard enough that 1/3 to 2/3 of the class don’t get them, then they need to be gone over in class.
After the do-now, we spent a little time discussing the “fit” command of gnuplot, since the students have to fit models to the data they collect tomorrow, and I’m not providing them a script this time (though they can modify the script that was provided in the first lab).
Finally, we got to the theoretical meat of the class—we discussed what sound was (ending up with variations in pressure for a fluid, though we discussed briefly transverse and shear waves in solids). Then I introduced microphones as transducers, trying to get the students to remember their elementary mechanics, so that we could do pressure→force→displacement→1/capacitance→voltage for electret mics. The hardest part was getting students to remember that a spring-mounted object had force proportional to displacement (a lot remembered the energy was somehow related to displacement squared and got stuck on that formula). I suspect that the local physics department would not be seeing a high score on the Force Concept Inventory for students coming out of their physics classes, as a lot of them seem to have concentrated on cramming formulas rather than learning fundamental concepts. Someone did remember Q=CV and someone else could reason from wanting voltage proportional to displacement to needing constant charge which let me introduce both conventional capacitance microphone (with a large resistor to voltage source) and electrets. I also explained that the electret had an enormous resistance, so we couldn’t get any measurable current out of it, and we needed an FET transistor to convert the voltage to a current.
Because both the do-now and extracting vague memories of physics from the students took longer than I had planned, we were a bit rushed for the last part of the lesson, which was a simple model of Ids vs Vds for the FET output stage of the electret mic. I asked for advice on drawing the plots for resistors and for current sources, and got the appropriate straight lines. I then drew a smooth transition between them and claimed that the simple FET models usually consisted of a linear region at low voltage (which my co-instructor refers to as the “triode” region, a usage I’ve seen in some other presentations) and a saturation region at high voltage, and that we usually try to stay out of the sublinear region in between.
I also said that the saturation region is not really constant, but has a slight upward slope, since they will be measuring the I-vs-V characteristic of the electret microphones tomorrow, and they will certainly be observing that. The lab handout gives them 4 models to fit: linear, constant current, an empirical blend of the two, and a model that allows current increase in the saturation region. Neither the 3rd nor the 4th model match the ones usually used in circuit simulators, but I had trouble fitting parameters to those models, even with voltage-modulated channel lengths, so I gave up and produced simple models with few parameters that can be fit pretty easily. We’ll be revisiting FETs again before the power-amp lab (where they’ll use pMOS and nMOS power FETs to make a class-D amplifier). Somewhere around then, I’ll have to give them some usable models for how saturation current varies with gate voltage, which I deliberately did not cover in this lecture.
I’m a bit worried about how big tomorrow’s lab is. There are again 2 parts:
On Friday, most of the lecture will be standard EE stuff by my co-instructor (probably current sources, Thévenin equivalents, and Norton equivalents). I may have a do-now question at the beginning of the class, if I can come up with one that I think is pedagogically useful.
I feel pretty good about today’s lecture, though things got a little rushed at the end.
Three-resistor voltage divider for the first question.
I started with a “do now” question, similar to the one from Monday. Actually, I started with 2 questions. The first just asked what the output voltage would be for a 3-resistor voltage divider. The second repeated the question from Monday, but with the additional constraint that the power supply was 5 volts:
You have sensor whose resistance varies from 1kΩ to 4kΩ with the property it measures and a 5v power supply. Design a circuit whose output voltage varies from 1v (at 1kΩ) to 2v (at 4kΩ).
Several students realized that the first question was a hint for the second one and that the variable resistor had to be RB or RC, and could set up the equations and solve for RA and RC. This is a better performance than on Monday’s “do now”, but only about 1/3 of the class got it completely, and several of them were not confident of their results, so we again took time to go over the whole solution. I think that everyone (or almost everyone) understood the design process and how to set up and solve the equations by the end of the presentation, which I drew out of the students as much as possible. I also mentioned that we could have solved the problem with a different circuit (putting RC in parallel with RB instead of in series), but did not further elaborate on that point.
The do-now plus going over the solution took about 33 minutes, which is a little more time than I’d like to be spending on these questions. It would be good to get the time down to 15 minutes, but I don’t see how to do that without losing half the class. If the problems are easy enough that everyone gets them, then there is no point to taking up any class time with them, and if they are hard enough that 1/3 to 2/3 of the class don’t get them, then they need to be gone over in class.
After the do-now, we spent a little time discussing the “fit” command of gnuplot, since the students have to fit models to the data they collect tomorrow, and I’m not providing them a script this time (though they can modify the script that was provided in the first lab).
Finally, we got to the theoretical meat of the class—we discussed what sound was (ending up with variations in pressure for a fluid, though we discussed briefly transverse and shear waves in solids). Then I introduced microphones as transducers, trying to get the students to remember their elementary mechanics, so that we could do pressure→force→displacement→1/capacitance→voltage for electret mics. The hardest part was getting students to remember that a spring-mounted object had force proportional to displacement (a lot remembered the energy was somehow related to displacement squared and got stuck on that formula). I suspect that the local physics department would not be seeing a high score on the Force Concept Inventory for students coming out of their physics classes, as a lot of them seem to have concentrated on cramming formulas rather than learning fundamental concepts. Someone did remember Q=CV and someone else could reason from wanting voltage proportional to displacement to needing constant charge which let me introduce both conventional capacitance microphone (with a large resistor to voltage source) and electrets. I also explained that the electret had an enormous resistance, so we couldn’t get any measurable current out of it, and we needed an FET transistor to convert the voltage to a current.
Because both the do-now and extracting vague memories of physics from the students took longer than I had planned, we were a bit rushed for the last part of the lesson, which was a simple model of Ids vs Vds for the FET output stage of the electret mic. I asked for advice on drawing the plots for resistors and for current sources, and got the appropriate straight lines. I then drew a smooth transition between them and claimed that the simple FET models usually consisted of a linear region at low voltage (which my co-instructor refers to as the “triode” region, a usage I’ve seen in some other presentations) and a saturation region at high voltage, and that we usually try to stay out of the sublinear region in between.
I also said that the saturation region is not really constant, but has a slight upward slope, since they will be measuring the I-vs-V characteristic of the electret microphones tomorrow, and they will certainly be observing that. The lab handout gives them 4 models to fit: linear, constant current, an empirical blend of the two, and a model that allows current increase in the saturation region. Neither the 3rd nor the 4th model match the ones usually used in circuit simulators, but I had trouble fitting parameters to those models, even with voltage-modulated channel lengths, so I gave up and produced simple models with few parameters that can be fit pretty easily. We’ll be revisiting FETs again before the power-amp lab (where they’ll use pMOS and nMOS power FETs to make a class-D amplifier). Somewhere around then, I’ll have to give them some usable models for how saturation current varies with gate voltage, which I deliberately did not cover in this lecture.
I’m a bit worried about how big tomorrow’s lab is. There are again 2 parts:
On Friday, most of the lecture will be standard EE stuff by my co-instructor (probably current sources, Thévenin equivalents, and Norton equivalents). I may have a do-now question at the beginning of the class, if I can come up with one that I think is pedagogically useful.
