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.

My son presented the Arduino Data Logger he wrote for my circuits class to the Global Physics Department on 2013 May 15.  The sessions are recorded, and the recording is available on the web (though you have to run Blackboard Collaborate through Java Web Start to play the recording).

I thought he did a pretty good job of presenting the features of the data logger.

Now that school is beginning to wind down, he’s started looking at making modifications to the data logger code again, and has updated it at https://bitbucket.org/abe_k/arduino-data-logger/

He’s down to only three classes now (US History, Physics, and Dinosaur Prom Improv), though he still has homework to catch up on in Dramatic Literature and his English class.  He’s still TAing for the Python class also.

On Thursday and Friday this week, he’ll be taking the AP Computer Science test and the AP Physics C: Electricity and Magnetism test.  He’s having to take both tests in the “make-up” time slot, because we couldn’t get any local high school to agree to proctor the tests for him during the regular testing time.  Eventually his consultant teacher convinced the AP coordinator to let her proctor the tests, but by then it was too late to register for anything but the makeup tests. We’re way behind schedule on the physics class, so he’s just going to read the rest of the physics book without working any problems before Friday’s exam—we’ll finish the book in a more leisurely fashion after the exam. He won’t be as prepared for the physics exam as I had hoped, but at least the CS exam looks pretty easy to him.

One thing I didn’t realize is that schools can charge homeschoolers whatever the market will bear for proctoring the tests:

• Depending on the reasons for late testing, schools may be charged an additional fee ($40 per exam), part or all of which the school may ask students to pay. Students eligible for the College Board fee reduction will not be charged the $40-per-exam late-testing fee, regardless of their reason for testing late.
• Schools administering exams to homeschooled students or students from other schools may negotiate a higher fee to recover the additional proctoring and administration costs.

[ http://professionals.collegeboard.com/testing/ap/about/fees ]

We’re paying $145 per exam (not just the $89 standard fee and the $40 late fee), but I’m glad he gets to take the exams at all this year.

Tomorrow he and I are doing another campus tour—this time at Stanford. He managed to get an appointment with a faculty member, but we noticed that the faculty member is scheduled to be teaching a class at the time of the appointment—I wonder what is going to happen with that. I’ll report on the visit later this week.

My son presented the Arduino Data Logger he wrote for my circuits class to the Global Physics Department on 2013 May 15.  The sessions are recorded, and the recording is available on the web (though you have to run Blackboard Collaborate through Java Web Start to play the recording).

I thought he did a pretty good job of presenting the features of the data logger.

Now that school is beginning to wind down, he’s started looking at making modifications to the data logger code again, and has updated it at https://bitbucket.org/abe_k/arduino-data-logger/

He’s down to only three classes now (US History, Physics, and Dinosaur Prom Improv), though he still has homework to catch up on in Dramatic Literature and his English class.  He’s still TAing for the Python class also.

On Thursday and Friday this week, he’ll be taking the AP Computer Science test and the AP Physics C: Electricity and Magnetism test.  He’s having to take both tests in the “make-up” time slot, because we couldn’t get any local high school to agree to proctor the tests for him during the regular testing time.  Eventually his consultant teacher convinced the AP coordinator to let her proctor the tests, but by then it was too late to register for anything but the makeup tests. We’re way behind schedule on the physics class, so he’s just going to read the rest of the physics book without working any problems before Friday’s exam—we’ll finish the book in a more leisurely fashion after the exam. He won’t be as prepared for the physics exam as I had hoped, but at least the CS exam looks pretty easy to him.

One thing I didn’t realize is that schools can charge homeschoolers whatever the market will bear for proctoring the tests:

• Depending on the reasons for late testing, schools may be charged an additional fee ($40 per exam), part or all of which the school may ask students to pay. Students eligible for the College Board fee reduction will not be charged the $40-per-exam late-testing fee, regardless of their reason for testing late.
• Schools administering exams to homeschooled students or students from other schools may negotiate a higher fee to recover the additional proctoring and administration costs.

[ http://professionals.collegeboard.com/testing/ap/about/fees ]

We’re paying $145 per exam (not just the $89 standard fee and the $40 late fee), but I’m glad he gets to take the exams at all this year.

Tomorrow he and I are doing another campus tour—this time at Stanford. He managed to get an appointment with a faculty member, but we noticed that the faculty member is scheduled to be teaching a class at the time of the appointment—I wonder what is going to happen with that. I’ll report on the visit later this week.

One of the best capabilities provided by Arduino regards its very high modularity, which helps users to quickly translate ideas into physical artifact, as practically demonstrated by Mauro, which shows on his blog how to build a simple data-logger by properly combining different shields. By using few additional components (mainly resistors and buttons) a fully-functional data logger can be easily implemented.

More information can be found here.

[Via: Mauro Alfieri's blog]

Over winter break, my son has been working nearly full time on writing data logging software for my students to use in the Applied Circuits for Bioengineers course. He has made the first public beta release (v1.0.0b1) today on BitBucket. (Note: you may have to click on the “tags” tab to get to the view that shows the v1.0.0b1 link. The BitBucket link directly to that view seems to be broken—that’s open issue 5504 in BitBucket’s own issue tracker.)

We’ve only tested the code on Mac OS X computers with Arduino Duemilanove and Uno boards, though we’ve tested a slightly earlier version on Windows.  The code should also run on Linux and with Leonardo and Mega boards, but has not been tested on these platforms. We welcome users testing the code for us—report any problems using the BitBucket issue tracker for the project.  The documentation is still in a fairly primitive state—report issues with that also, so that they can be fixed.

The overall goal is fairly simple: to have an easy-to-use way to record timestamps, voltages, and digital values from the Arduino into files on a host computer, without needing auxiliary hardware (like the Adafruit data logger shield that I bought for myself and assembled yesterday).

The user can specify what analog and digital pins to record and when to record the values.  When to record can be specified either   as interrupts on pins or as fixed timing intervals:

View of the two windows of the user interface.

The “volts measured” for the reference is stored as metadata in the output file and can be used for scaling the Arduino numbers (if “Convert to Volts” is checked).  The scaling can be an arbitrary value for the full-scale reading or can be the voltage measured with an external multimeter at the AREF pin.

This software has been through several versions:

1. The first version of the code was one I wrote last spring that just recorded interrupt times in an Arduino array and dumped them out over the USB cable after it was done (see Homemade super pulley).
2. My son was not happy with that crude program of mine and rewrote it in June to have use the Arduino memory as a queue and send the time stamps to a Python program on the laptop (see Improved super pulley code).  That program introduced him to three new concepts: circular buffers for queues, interrupts, and multi-threading, all of which he researched for himself. That version of the code mainly used a command line interface, but he used the curses package for a crude user interface.
3. He added a PyGUI graphical user interface, but that slowed down the code on the laptop and eventually grew to be difficult to maintain.
4. He decided to try to make the software by portable between three platforms (Mac OS X, Windows, and Linux) despite their very different ways of dealing with the USB serial ports, to run under both Python2.7 and Python3, and to require only minimal non-standard packages (mainly PySerial and the Arduino package Timer1).  He refactored the code completely and built the GUI using Tkinter. This has lead to the current version of the code, which is finally working robustly enough to let the bioengineering students use it.

It has been a good software-engineering experience for my son, and he has learned a lot.  In the process of developing this code, he has learned a lot about interrupts, using queues to communicate between processors and between threads, platform-independence, a couple of different GUI libraries, the value of version control and bug-tracking, race conditions, interface design for non-expert users, and even some things about documentation.

I’ve been acting mainly as a customer for this code, entering bug reports and suggesting new features, though I have occasionally helped him debug.  For example, we just spent fifteen minutes reading Section 15 “16-bit Timer/Counter1 with PWM” of the ATMega328 data sheet, trying to figure out why the first time interval was wrong.  It turns out that timer interrupt is raised immediately when the interrupt is enabled, unless the timer-overflow flag is turned off first.

My son may use this project as a science fair entry this year, though it was not started with that idea, and we discussed that possibility for the first time today.  The big problem is that this is purely an engineering project, not a “science” project, and trying to fake a hypothesis is not something we’ll consider.

Over winter break, my son has been working nearly full time on writing data logging software for my students to use in the Applied Circuits for Bioengineers course. He has made the first public beta release (v1.0.0b1) today on BitBucket. (Note: you may have to click on the “tags” tab to get to the view that shows the v1.0.0b1 link. The BitBucket link directly to that view seems to be broken—that’s open issue 5504 in BitBucket’s own issue tracker.)

We’ve only tested the code on Mac OS X computers with Arduino Duemilanove and Uno boards, though we’ve tested a slightly earlier version on Windows.  The code should also run on Linux and with Leonardo and Mega boards, but has not been tested on these platforms. We welcome users testing the code for us—report any problems using the BitBucket issue tracker for the project.  The documentation is still in a fairly primitive state—report issues with that also, so that they can be fixed.

The overall goal is fairly simple: to have an easy-to-use way to record timestamps, voltages, and digital values from the Arduino into files on a host computer, without needing auxiliary hardware (like the Adafruit data logger shield that I bought for myself and assembled yesterday).

The user can specify what analog and digital pins to record and when to record the values.  When to record can be specified either   as interrupts on pins or as fixed timing intervals:

View of the two windows of the user interface.

The “volts measured” for the reference is stored as metadata in the output file and can be used for scaling the Arduino numbers (if “Convert to Volts” is checked).  The scaling can be an arbitrary value for the full-scale reading or can be the voltage measured with an external multimeter at the AREF pin.

This software has been through several versions:

1. The first version of the code was one I wrote last spring that just recorded interrupt times in an Arduino array and dumped them out over the USB cable after it was done (see Homemade super pulley).
2. My son was not happy with that crude program of mine and rewrote it in June to have use the Arduino memory as a queue and send the time stamps to a Python program on the laptop (see Improved super pulley code).  That program introduced him to three new concepts: circular buffers for queues, interrupts, and multi-threading, all of which he researched for himself. That version of the code mainly used a command line interface, but he used the curses package for a crude user interface.
3. He added a PyGUI graphical user interface, but that slowed down the code on the laptop and eventually grew to be difficult to maintain.
4. He decided to try to make the software by portable between three platforms (Mac OS X, Windows, and Linux) despite their very different ways of dealing with the USB serial ports, to run under both Python2.7 and Python3, and to require only minimal non-standard packages (mainly PySerial and the Arduino package Timer1).  He refactored the code completely and built the GUI using Tkinter. This has lead to the current version of the code, which is finally working robustly enough to let the bioengineering students use it.

It has been a good software-engineering experience for my son, and he has learned a lot.  In the process of developing this code, he has learned a lot about interrupts, using queues to communicate between processors and between threads, platform-independence, a couple of different GUI libraries, the value of version control and bug-tracking, race conditions, interface design for non-expert users, and even some things about documentation.

I’ve been acting mainly as a customer for this code, entering bug reports and suggesting new features, though I have occasionally helped him debug.  For example, we just spent fifteen minutes reading Section 15 “16-bit Timer/Counter1 with PWM” of the ATMega328 data sheet, trying to figure out why the first time interval was wrong.  It turns out that timer interrupt is raised immediately when the interrupt is enabled, unless the timer-overflow flag is turned off first.

My son may use this project as a science fair entry this year, though it was not started with that idea, and we discussed that possibility for the first time today.  The big problem is that this is purely an engineering project, not a “science” project, and trying to fake a hypothesis is not something we’ll consider.

My son and I bicycled up to campus today to test out his data logger code (that will be used in the circuits course) on the Windows computers in the lab.  The lab support staff had told me yesterday that they had gotten Python 2.7.3 installed and the Arduino 1.0.3 development environment, as well as the PySerial module that the data logger code requires.

My son has been working pretty intensely on the code lately, doing a complete refactoring of the code to use TKinter (instead of PyGUI, which is difficult to install and quite slow) and to have a more user-friendly GUI.  He also wanted to make the code platform independent (Windows, Mac, and Linux), though he’d only tested on our Macs at home before today.  He’s also trying to make the Python part of the code (the user interface) work in both Python 2.7.3 and Python 3.3, though the languages are not precisely compatible.

We found three problems today:

1. Python 2.7.3 was not quite completely installed.  They’d forgotten to update the path to include C:\Python27\  (The path should also include where the Arduino software was installed—I forget where that was now.)
2. The device drivers for the Arduinos were not installed.  On Macs, there are no drivers to install, but on Windows, you need different drivers for different Arduino boards, and it seems you need to have the board plugged into the USB port in order to install the drivers. (Instructions at http://arduino.cc/en/Guide/Windows#t0c4)
3. My son had forgotten to include one of the dependencies in his list of what needed to be installed—the Arduino Timer1 module from http://playground.arduino.cc/code/Timer1/ .

Because they had given me administrator privileges on the machines, my son was able to fix one of the machines to run the data logger code (though he had a couple of minor changes to make in his code for Windows compatibility also).

For the data logger debugging, about all I did was type in my password for him, and once do a search to see where the Arduino code was hidden.

When he has finished debugging and documenting the code, my son will be releasing it with a permissive license on bitbucket, and I’ll be putting links to it here and on the course web page.

A few years ago, [Phang Moh] and his compatriots were asked by a client if they could make a vehicle tracking device for oil tankers all around Indonesia. The request of putting thousands of trackers on tanks of explosives was a little beyond [Phang Moh]‘s capability, but he did start tinkering around with GPS and GSM on an Arduino.

Now that tinkering has finally come to fruition with [Phang]‘s TraLog shield, a single Arduino shield that combines GPS tracking with a GSM and GPRS transceiver. There’s also an SD card thrown in for good measure, making this one of the best tracking and data logging shields for the Arduino.

The shield can be configured to send GPS and sensor data from devices attached to an I2C bus to remote servers, or a really cool COSM server. [Phang] is selling his TraLog for $150, a fairly good deal if you consider what this thing can do.

Seems like the perfect piece of kit for just about any tracking project, whether you want to know the location of thousands of oil tankers or just a single high altitude balloon.

Tip ‘o the hat to [Brett] for finding this one.

And while this project is readymade for recording levels of sunlight, the Arduino has a total of six analog inputs (labeled A0 – A5) and could easily record other variables. For example temperature, motion, or barometric pressure. Makers looking for a mid-level Arduino build, or knowledgeable coders looking to solder together their first homemade shield, the Sun Logger is a great project to build!