Posts with «pressure sensor» label

Temperature, Altitude, Pressure Display

During a recent trip to Bhutan, [electronut] wished for a device that would show the temperature and altitude at the various places he visited in the Kingdom. Back home after his trip, he built this simple Temperature, Altitude and Pressure Display Device using a few off the shelf parts.

Following a brief search, he zeroed in on the BMP 180 sensor which can measure temperature and pressure, and which is available in a break-out board format from many sources. He calculates altitude based on pressure. The main parts are an Arduino Pro Mini clone, a BMP180 sensor and a Nokia 5110 LCD module. A standard 9V battery supplies juice to the device. A push button interface allows him to read the current parameters when pressed, thus conserving battery life.

Standard libraries allow him to interface the LCD and sensor easily to the Arduino. He wrapped it all up by enclosing the hardware in a custom laser cut acrylic box. The result is bigger than he would like it to be, so maybe the next iteration would use a custom PCB and a LiPo battery to shrink it in size. While at it, we think it would be nice to add a RTC and some sort of logging capability to the device so it can store data for future analysis. The schematic, code and enclosure drawing are available via his Github repository.


Filed under: Arduino Hacks

E-traces creates visual sensations from ballerinas

Electronic Traces is an interactive project designed to allow ballet dancers to recreate their movements in  digital pictures using a customizable mobile application. It was prototyped by product-designer Lesia Trubat mixing technological, artisanal skills and using Arduino Lilypad, force sensitive resistors and accelerometer:

The concept of Electronic Traces is based on capturing dance movements and transforming them into visual sensations through the use of new technologies. To do this we focused on the ballet shoes themselves, which through the contact with the ground, and thanks to Lilypad Arduino technology, record the pressure and movement of the dancer’s feet and send a signal to an electronic device. A special application will then allow us to show this data graphically and even customize it to suit each user, through the different functions of this app.

The user can then view all the moves made in video format, extract images and even print them. Dancers can interpret their own movements and correct them or compare them with the movements of other dancers, as graphs created with motion may be the same or different depending on the type of movements execute.

 

Sixteenth day: Arduino demo

Today’s class in the freshman design seminar went well. I started by returning the drafts of the design reports and giving some generic feedback. I realized on reading the reports that I had not given a good explanation of what I meant by describing the components of the system—two of the groups had given me long parts lists on the first page of their reports, something that would only really be appropriate in an appendix. I explained that what I wanted was what the main blocks in the block diagram were, and that they should use the block diagram to organize their report, writing a page for each block. I also suggested that they use the block diagram to partition the project among the group members, with each group member working on a different component, then getting back together to reconcile any discrepancies. Note that this is much more like real engineering group work than the usual K–12 group project, which is usually done most efficiently by turning the whole project over to the most competent member of the group.

After the feedback on design reports, I offered the students a chance to get a demo of building an Arduino program with sensing and motor control. This was a completely extemporaneous demo—I had gathered a number of possibly useful components, but had not tested anything ahead of time nor even figured out what order to do the demo in.  I asked the students if they wanted me to start with sensing or control—they asked for the motor control first.

I started by pulling a motor out of box of motors I had gotten when the elementary school my wife works at cleaned out their closets.  I told the students that I had no idea what the spec of the motor were, but since it came from an elementary school, it probably ran on 3v batteries.  I tested the motor by hooking it up first to the 3.3v, then to the 5v power on my Arduino Uno.  It spun just fine on 3.3v, but squealed a bit on 5v, so we decided to run it on 3.3v.

I then pulled out the Sainsmart 4-relay board that I had bought some time ago but never used.  I explained how a relay worked, what single-pole double-throw meant, and normally open (NO) and normally closed (NC) contacts. I used the board unpowered with the NC contacts to spin the motor, then moved the wire over to the NO contacts to turn the motor off.  I then hooked up power to the board and tried connecting input IN1 to power to activate the relay.  Nothing happened. I then tried connecting IN1 to ground, and the relay clicked and the motor spun.  The inputs to the Sainsmart board are active low, which I explained to the students (though I did not use the terminology “active low”—perhaps I should have).  I did make a point of establishing that the relay provides very good isolation between the control logic and the circuitry being controlled—you can hook up AC power from the walls to the relay contacts without interfering with the logic circuitry.

Having established that the relay worked, the next step was to get the class (as a group) to write an Arduino program to control the motor using the relay. With me taking notes on the whiteboard, they quickly came up with the pinMode command for the setup, the digitalWrite and delay for the loop, and with only a tiny bit of prompting with a second digitalWrite and delay to turn the motor back off.  They even realized the need to have different delays for the on and off, so we could tell whether we had the polarity right on the control.  Here is the program we came up with:

#define RELAY_PIN (3)

void setup()
{   pinMode(RELAY_PIN, OUTPUT);
}

void loop()
{
  digitalWrite(RELAY_PIN,LOW); // turn motor ON via relay (or off via transistor)
  delay(1000);  // on for 1 second
  digitalWrite(RELAY_PIN,HIGH); // turn motor OFF via relay (or on via transistor)
  delay(3000); // off for 3 seconds
}

I typed the code in and downloaded it to the Arduino Uno, and it worked as expected.  (It would be nice if the Arduino IDE would allow me to increase the font size, like almost every other program I use, so that students could have read the projection of what I was typing better.)

I then offered the students a choice of going on to sensing or looking at pulse-width modulation for proportional control.  They wanted PWM. I explained why PWM is not really doable with relays (the relays are too slow, and chattering them would wear them out after a while.  I did not have the specs on the relay handy, but I just looked up the specs for the SRD-05VDC-SL-C relays on the board: They have a mechanical life of 10,000,000 cycles, but an electrical life of only 100,000 cycles.  The relay takes about 7msec to make a contact and about 3msec to break a contact, so they can’t be operated much faster than about 60 times a second, which could wear them out in as little as half an hour.

So instead of a relay, I suggested an nFET (Field-Effect Transistor). I gave them a circuit with one side of the motor connected to 3.3V, the other to the drain of an nFET, with the source connected to ground.  I explained that the voltage between the gate and the source (VGS) controlled whether the transistor was on or off, and that putting 5v on the gate would turn it on fairly well. I then got out an AOI518 nFET and stuck it in my breadboard, explaining the orientation to allow using the other holes to connect to the source, gate, and drain.

I mentioned that different FETs have the order of the pins different, so one has to look up the pinout on data sheet. I pulled up the AOI518 data sheet, which has on the first page “RDS(ON) (at VGS = 4.5V) < 11.9mΩ”. I explained that if we were putting a whole amp through the FET (we’re not doing anywhere near that much current), the voltage drop would be 11.9mV, so the power dissipated in the transistor would be only 11.9mW, not enough to get it warm. I mentioned that more current would result in more power being dissipated (I2R), and that the FETs could get quite warm. I passed around my other breadboard which has six melted holes from FETs getting quite hot when I was trying to debug the class-D amplifier design. The students were surprised that the FETs still worked after getting that hot (I must admit that I was also).

I hooked up the AOI518 nFET using double-headed male header pins and female jumper cables, and the motor alternated on for 3 seconds, off for one second. We now had the transistor controlling the motor, so it was time to switch to PWM. I went to the Arduino reference page and looked around for PWM, finding it on analogWrite(). I clicked that link and we looked at the page, seeing that analog Write was like digitalWrite, except that we could put in a value from 0 to 255 that controlled what fraction of the time the pin was high.

I edited the code, changing the first digitalWrite() to analogWrite(nFET_GATE_PIN, 255), and commenting out the rest of the loop. We downloaded that, and it turned the motor on, as expected. I then tried writing 128, which still turned the motor on, but perhaps not as strongly (hard to tell with no load). Writing 50 resulted in the motor not starting. Writing 100 let the motor run if I started it by hand, but wouldn’t start the motor from a dead stop. I used this opportunity to point out that controlling the motor was not linear—1/5th didn’t run at 1/5th speed, but wouldn’t run the motor at all.

Next we switched over to doing sensors (with only 10 minutes left in the class). I got out the pressure sensor and instrumentation amp from the circuits course and hooked it up. The screwdriver I had packed in the box had too large a blade for the 0.1″ screw terminals, but luckily the tiny screwdriver on my Swiss Army knife (tucked away in the corkscrew) was small enough. After hooking up the pressure sensor to A0, I downloaded the Arduino Data Logger to the Uno, and started it from a terminal window. I set the triggering to every 100msec (which probably should be the default for the data logger), the input to A0, and convert to volts. I then demoed the pressure sensor by blowing into or sucking on the plastic tube hooked up to the sensor. With the low-gain output from the amplifier, the output swung about 0.5 v either way from the 2.5v center. Moving the A0 wire over to the high-gain output of the amplifier gave a more visible signal. I also turned off the “convert to volts” to show the students the values actually read by the Arduino (511 and 512, the middle of the range from 0 to 1023).

Because the class was over at that point, I offered to stay for another 10 minutes to show them how to use the pressure sensor to control the motor. One or two students had other classes to run to, but most stayed. I then wrote a program that would normally have the motor off, but would turn it full on if I got the pressure reading up to 512+255 and would turn it on partway (using PWM) between 512 and 512+255. I made several typos when entering the program (including messing up the braces and putting in an extraneous semicolon), but on the third compilation it downloaded successfully and controlled the motor as expected.

One student asked why the motor was off when I wasn’t blowing into the tube, so I explained about 512 being the pressure reading when nothing was happening (neither blowing into the tube nor sucking on it). I changed the zero point for the motor to a pressure reading of 300, so that the motor was normally most of the way on, but could be turned off by sucking on the tube. Here is the program we ended up with

#define nFET_GATE_PIN (3)

void setup()
{   pinMode(nFET_GATE_PIN, OUTPUT);
    pinMode(A0, INPUT);
}

void loop()
{ int pressure;
  pressure=analogRead(A0);
  if (pressure < 300)
  {    digitalWrite(nFET_GATE_PIN,LOW);  // turn motor off
  }
  else
  {   if (pressure>300+255)
      { digitalWrite(nFET_GATE_PIN,HIGH);  // turn motor on full
      }
      else
      {    analogWrite(nFET_GATE_PIN,pressure-300); // turn motor partway on
      }
  }
}

Note: this code is not an example of brilliant programming style. I can see several things that I would have done differently if I had had time to think about the code, but for this blog it is more useful to show the actual artifact that was developed in the demo, even if it makes me cringe a little.

Overall, I thought that the demo went well, despite being completely extemporaneous. Running over by 10 minutes might have been avoidable, but only by omitting something useful (like the feedback on the design reports). The demo itself lasted about 70 minutes, making the whole class run 80 minutes instead of 70. I think I compressed the demo about as much as was feasible for the level the students were at.

Based on how the students developed the first motor-control program quickly in class, I think that some of them are beginning to get some of the main ideas of programming: explicit instructions and sequential ordering. Because we were out of time by the point I got to using conditionals, I did not get a chance to probe their understanding there.


Filed under: freshman design seminar, Pressure gauge Tagged: Arduino, FET, motor, nMOS FET, pressure sensor, PWM, relay

Sixteenth day: Arduino demo

Today’s class in the freshman design seminar went well. I started by returning the drafts of the design reports and giving some generic feedback. I realized on reading the reports that I had not given a good explanation of what I meant by describing the components of the system—two of the groups had given me long parts lists on the first page of their reports, something that would only really be appropriate in an appendix. I explained that what I wanted was what the main blocks in the block diagram were, and that they should use the block diagram to organize their report, writing a page for each block. I also suggested that they use the block diagram to partition the project among the group members, with each group member working on a different component, then getting back together to reconcile any discrepancies. Note that this is much more like real engineering group work than the usual K–12 group project, which is usually done most efficiently by turning the whole project over to the most competent member of the group.

After the feedback on design reports, I offered the students a chance to get a demo of building an Arduino program with sensing and motor control. This was a completely extemporaneous demo—I had gathered a number of possibly useful components, but had not tested anything ahead of time nor even figured out what order to do the demo in.  I asked the students if they wanted me to start with sensing or control—they asked for the motor control first.

I started by pulling a motor out of box of motors I had gotten when the elementary school my wife works at cleaned out their closets.  I told the students that I had no idea what the spec of the motor were, but since it came from an elementary school, it probably ran on 3v batteries.  I tested the motor by hooking it up first to the 3.3v, then to the 5v power on my Arduino Uno.  It spun just fine on 3.3v, but squealed a bit on 5v, so we decided to run it on 3.3v.

I then pulled out the Sainsmart 4-relay board that I had bought some time ago but never used.  I explained how a relay worked, what single-pole double-throw meant, and normally open (NO) and normally closed (NC) contacts. I used the board unpowered with the NC contacts to spin the motor, then moved the wire over to the NO contacts to turn the motor off.  I then hooked up power to the board and tried connecting input IN1 to power to activate the relay.  Nothing happened. I then tried connecting IN1 to ground, and the relay clicked and the motor spun.  The inputs to the Sainsmart board are active low, which I explained to the students (though I did not use the terminology “active low”—perhaps I should have).  I did make a point of establishing that the relay provides very good isolation between the control logic and the circuitry being controlled—you can hook up AC power from the walls to the relay contacts without interfering with the logic circuitry.

Having established that the relay worked, the next step was to get the class (as a group) to write an Arduino program to control the motor using the relay. With me taking notes on the whiteboard, they quickly came up with the pinMode command for the setup, the digitalWrite and delay for the loop, and with only a tiny bit of prompting with a second digitalWrite and delay to turn the motor back off.  They even realized the need to have different delays for the on and off, so we could tell whether we had the polarity right on the control.  Here is the program we came up with:

#define RELAY_PIN (3)

void setup()
{   pinMode(RELAY_PIN, OUTPUT);
}

void loop()
{
  digitalWrite(RELAY_PIN,LOW); // turn motor ON via relay (or off via transistor)
  delay(1000);  // on for 1 second
  digitalWrite(RELAY_PIN,HIGH); // turn motor OFF via relay (or on via transistor)
  delay(3000); // off for 3 seconds
}

I typed the code in and downloaded it to the Arduino Uno, and it worked as expected.  (It would be nice if the Arduino IDE would allow me to increase the font size, like almost every other program I use, so that students could have read the projection of what I was typing better.)

I then offered the students a choice of going on to sensing or looking at pulse-width modulation for proportional control.  They wanted PWM. I explained why PWM is not really doable with relays (the relays are too slow, and chattering them would wear them out after a while.  I did not have the specs on the relay handy, but I just looked up the specs for the SRD-05VDC-SL-C relays on the board: They have a mechanical life of 10,000,000 cycles, but an electrical life of only 100,000 cycles.  The relay takes about 7msec to make a contact and about 3msec to break a contact, so they can’t be operated much faster than about 60 times a second, which could wear them out in as little as half an hour.

So instead of a relay, I suggested an nFET (Field-Effect Transistor). I gave them a circuit with one side of the motor connected to 3.3V, the other to the drain of an nFET, with the source connected to ground.  I explained that the voltage between the gate and the source (VGS) controlled whether the transistor was on or off, and that putting 5v on the gate would turn it on fairly well. I then got out an AOI518 nFET and stuck it in my breadboard, explaining the orientation to allow using the other holes to connect to the source, gate, and drain.

I mentioned that different FETs have the order of the pins different, so one has to look up the pinout on data sheet. I pulled up the AOI518 data sheet, which has on the first page “RDS(ON) (at VGS = 4.5V) < 11.9mΩ”. I explained that if we were putting a whole amp through the FET (we’re not doing anywhere near that much current), the voltage drop would be 11.9mV, so the power dissipated in the transistor would be only 11.9mW, not enough to get it warm. I mentioned that more current would result in more power being dissipated (I2R), and that the FETs could get quite warm. I passed around my other breadboard which has six melted holes from FETs getting quite hot when I was trying to debug the class-D amplifier design. The students were surprised that the FETs still worked after getting that hot (I must admit that I was also).

I hooked up the AOI518 nFET using double-headed male header pins and female jumper cables, and the motor alternated on for 3 seconds, off for one second. We now had the transistor controlling the motor, so it was time to switch to PWM. I went to the Arduino reference page and looked around for PWM, finding it on analogWrite(). I clicked that link and we looked at the page, seeing that analog Write was like digitalWrite, except that we could put in a value from 0 to 255 that controlled what fraction of the time the pin was high.

I edited the code, changing the first digitalWrite() to analogWrite(nFET_GATE_PIN, 255), and commenting out the rest of the loop. We downloaded that, and it turned the motor on, as expected. I then tried writing 128, which still turned the motor on, but perhaps not as strongly (hard to tell with no load). Writing 50 resulted in the motor not starting. Writing 100 let the motor run if I started it by hand, but wouldn’t start the motor from a dead stop. I used this opportunity to point out that controlling the motor was not linear—1/5th didn’t run at 1/5th speed, but wouldn’t run the motor at all.

Next we switched over to doing sensors (with only 10 minutes left in the class). I got out the pressure sensor and instrumentation amp from the circuits course and hooked it up. The screwdriver I had packed in the box had too large a blade for the 0.1″ screw terminals, but luckily the tiny screwdriver on my Swiss Army knife (tucked away in the corkscrew) was small enough. After hooking up the pressure sensor to A0, I downloaded the Arduino Data Logger to the Uno, and started it from a terminal window. I set the triggering to every 100msec (which probably should be the default for the data logger), the input to A0, and convert to volts. I then demoed the pressure sensor by blowing into or sucking on the plastic tube hooked up to the sensor. With the low-gain output from the amplifier, the output swung about 0.5 v either way from the 2.5v center. Moving the A0 wire over to the high-gain output of the amplifier gave a more visible signal. I also turned off the “convert to volts” to show the students the values actually read by the Arduino (511 and 512, the middle of the range from 0 to 1023).

Because the class was over at that point, I offered to stay for another 10 minutes to show them how to use the pressure sensor to control the motor. One or two students had other classes to run to, but most stayed. I then wrote a program that would normally have the motor off, but would turn it full on if I got the pressure reading up to 512+255 and would turn it on partway (using PWM) between 512 and 512+255. I made several typos when entering the program (including messing up the braces and putting in an extraneous semicolon), but on the third compilation it downloaded successfully and controlled the motor as expected.

One student asked why the motor was off when I wasn’t blowing into the tube, so I explained about 512 being the pressure reading when nothing was happening (neither blowing into the tube nor sucking on it). I changed the zero point for the motor to a pressure reading of 300, so that the motor was normally most of the way on, but could be turned off by sucking on the tube. Here is the program we ended up with

#define nFET_GATE_PIN (3)

void setup()
{   pinMode(nFET_GATE_PIN, OUTPUT);
    pinMode(A0, INPUT);
}

void loop()
{ int pressure;
  pressure=analogRead(A0);
  if (pressure < 300)
  {    digitalWrite(nFET_GATE_PIN,LOW);  // turn motor off
  }
  else
  {   if (pressure>300+255)
      { digitalWrite(nFET_GATE_PIN,HIGH);  // turn motor on full
      }
      else
      {    analogWrite(nFET_GATE_PIN,pressure-300); // turn motor partway on
      }
  }
}

Note: this code is not an example of brilliant programming style. I can see several things that I would have done differently if I had had time to think about the code, but for this blog it is more useful to show the actual artifact that was developed in the demo, even if it makes me cringe a little.

Overall, I thought that the demo went well, despite being completely extemporaneous. Running over by 10 minutes might have been avoidable, but only by omitting something useful (like the feedback on the design reports). The demo itself lasted about 70 minutes, making the whole class run 80 minutes instead of 70. I think I compressed the demo about as much as was feasible for the level the students were at.

Based on how the students developed the first motor-control program quickly in class, I think that some of them are beginning to get some of the main ideas of programming: explicit instructions and sequential ordering. Because we were out of time by the point I got to using conditionals, I did not get a chance to probe their understanding there.


Filed under: freshman design seminar, Pressure gauge Tagged: Arduino, FET, motor, nMOS FET, pressure sensor, PWM, relay

Pressure sensor with air pump

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.


Filed under: Circuits course, Data acquisition, Pressure gauge Tagged: air pump, Arduino, BitScope, circuits, data acquisition, data logger, instrumentation amp, oscilloscope, pressure sensor, science fair, USB oscilloscope

Pressure sensor with air pump

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.


Filed under: Circuits course, Data acquisition, Pressure gauge Tagged: air pump, Arduino, BitScope, circuits, data acquisition, data logger, instrumentation amp, oscilloscope, pressure sensor, science fair, USB oscilloscope

Supplemental sheet for lab, draft 1

In my previous post, I said that I would post drafts of my supplemental sheets describing the course here on my blog, to get feedback before submitting them. Since I’ve been thinking more about the labs than the lectures, I’ll try writing the sheet for the lab first. It will be based, in part, on my prior list of lab topics, somewhat updated.

Undergraduate Supplemental Sheet
Information to accompany Request for Course Approval
Sponsoring Agency Electrical Engineering
Course #
102L (I need to get a number from the department that they are not currently using. Since we are planning the course as an alternative prerequisite to EE 104 in place of EE101+L, I think that 102 would be a good number, with the L suffix for the lab course.)
Catalog Title
Applied Circuits Lab

Please answer all of the following questions using a separate sheet for your response.
1. Are you proposing a revision to an existing course? If so give the name, number, and GE designations (if applicable) currently held.

This is not a revision to any existing course.

2. In concrete, substantive terms explain how the course will proceed. List the major topics to be covered, preferably by week.

  1. Thermistor lab
    The lab will start with having students learn about the test equipment by having them use the multimeters to measure other multimeters. What is the resistance of a multimeter that is measuring voltage? of one that is measuring current? what current or voltage is used for the resistance measurement? The first lab will then have three parts, all involving the use of a Vishay BC Components NTCLE413E2103F520L thermistor or equivalent.

    First, the students will use a bench multimeter to measure the resistance of the thermistor, dunking it in various water baths (with thermometers in them to measure the temperature). They should fit a simple curve to this data (warning: temperature needs to be on an absolute scale).

    Second, they will add a series resistor to make a voltage divider. They have to choose a value to get as large and linear a voltage response as possible at some specified “most-interesting” temperature (perhaps body temperature, perhaps room temperature, perhaps DNA melting temperature). There will be a pre-lab exercise where they derive the formula for maximizing . They will then measure and plot the voltage output for the same set of water baths. If they do it right, they should get a much more linear response than for their resistance measurements.

    Finally, they will hook up the voltage divider to an Arduino analog input and record a time series of a water bath cooling off (perhaps adding an ice cube to warm water to get a fast temperature change), and plot temperature as a function of time.EE concepts needed: voltage, resistance, voltage divider, notion of a transducer.

    Lab skills developed: use of multimeter for measuring resistance and voltage, use of Arduino with data-acquisition program to record a time series, fitting a model to data points, simple breadboarding.

    Equipment needed: multimeter, power supply, thermistor, selection of various resistors, breadboard, clip leads, thermoses for water baths, secondary containment tubs to avoid water spills in the electronics lab. Arduino boards will be part of the student-purchased lab kit (separate from rest of kit, so that students can use Arduinos previously purchased). All uses of the Arduino board assume connection via USB cable to a desktop or laptop computer that has the data logger software that we will provide.

  2. Electret microphone

    First, we will have the students measure and plot the DC current vs. voltage for the microphone. The microphone is normally operated with a 3V drop across it, but can stand up to 10V, so they should be able to set the Agilent E3631A power supply to various values from 0V to 10V and get the voltage and current readings directly from the bench supply, which has 4-place accuracy for both voltage and current. There is some danger of the students accidentally delivering too much voltage and frying the mic, but as long as they get the polarity right, that isn’t too big a hazard. Ideally, they should see that the current is nearly constant as voltage is varied—nothing like a resistor.

    Second, we will have them do current-to-voltage conversion with a 5v power supply to get a 2.5v DC output from the microphone and hook up the output of the microphone to the input of the oscilloscope. Input can be whistling, talking, iPod earpiece, … . They should learn the difference between AC-coupled and DC-coupled inputs to the scope, and how to set the horizontal and vertical scales of the scope.

    Third, we will have them design and wire their own DC blocking RC filter (going down to about 1Hz), and confirm that it has a similar effect to the AC coupling on the scope.

    Fourth, they will play sine waves from the function generator through a loudspeaker next to the mic, observe the voltage output with the scope, and measure the voltage with a multimeter, plotting output voltage as a function of frequency. Note: the specs for the electret mic show a fairly flat response from 50Hz to 3kHz, so most of what the students will see here is the poor response of a cheap speaker at low frequencies.

    Those with extra time could look at putting the speaker and mic at opposite ends of tube and seeing what difference that makes.EE concepts: current sources, AC vs DC, DC blocking by capacitors, RC time constant, sine waves, RMS voltage, properties varying with frequency.

    Lab skills: power supply, oscilloscope, function generator, RMS AC voltage measurement.

    Equipment needed: multimeter, oscilloscope, function generator, power supply, electret microphone, small loudspeaker, selection of various resistors, breadboard, clip leads.

  3. Electrode measurements

    First, we will have the students attempt to measure the resistance of a saline solution using a pair of stainless steel electrodes and a multimeter. This should fail, as the multimeter gradually charges the capacitance of the electrode/electrolyte interface.

    Second, the students will use a voltage divider, with 10–100Ω load resistor and the function generator driving the voltage divider. The students will measure the RMS voltage across the resistor and across the electrodes for different frequencies from 3Hz to 300kHz (the range of the AC measurements for the Agilent 34401A Multimeter). They will plot the magnitude of the impedance of the electrodes as a function of frequency and fit an R2+(R1||C1) model to the data. A little hand tweaking of parameters should help them understand what each parameter changes about the curve.

    Third, the students will repeat the measurements and fits for different concentrations of NaCl, from 0.01M to 1M. Seeing what parameters change a lot and what parameters change only slightly should help them understand the physical basis for the electrical model.

    Fourth, students will make Ag/AgCl electrodes from fine silver wire. The two standard methods for this involve either soaking in chlorine bleach or electroplating. To reduce chemical hazards, we will use the electroplating method. Students will calculate the area of their electrodes and the recommended electroplating current, and adjust the bench supplies to get the desired current.

    Fifth, the students will measure and plot the resistance of a pair of Ag/AgCl electrodes as a function of frequency (as with the stainless steel electrodes).

    Sixth, if there is time, students will measure the potential between a stainless steel electrode and an Ag/AgCl electrode.EE concepts:magnitude of impedance, series and parallel circuits, variation of parameters with frequency, limitations of R+(C||R) model.

    Electrochemistry concepts: At least a vague understanding of half-cell potentials. Ag → Ag+ + e-, Ag+ + Cl- → AgCl, Fe + 2 Cl-→ FeCl2 + 2 e-.

    Lab skills: bench power supply, function generator, multimeter, fitting functions of complex numbers, handling liquids in proximity of electronic equipment.

    Equipment needed: multimeter, function generator, power supply, stainless steel electrode pairs, silver wires, frame for mounting silver wire, resistor, breadboard, clip leads, NaCl solutions in different concentrations, beakers for salt water, secondary containment tubs to avoid salt water spills in the electronics lab.

  4. Sampling and Aliasing

    Students will use a PC board that samples and digitizes an input with an 8-bit ADC, then reconstructs the waveform with a DAC. An existing lab has been used in other EE courses for explaining and demonstrating aliasing of sampled signals using this board, a signal generator, and a dual-trace oscilloscope. Note: this is a student-executed demo, rather than a design or measurement lab.EE concepts: quantized time, quantized voltage, sampling frequency, Nyquist frequency, aliasing.

    Lab skills: dual traces on oscilloscope.Equipment needed: ADC/DAC board, dual-trace oscilloscope, function generator.

  5. Audio amplifier

    Students will use an op amp to build a simple non-inverting audio amplifier for an electret microphone, setting the gain to around 6 or 7. Note that we are using single-power-supply op amps, so they will have to design a bias voltage supply as well.If this lab is too short, then students could feed the output of the amplifier into an analog input of the Arduino and record the waveform at the highest sampling rate they can with the software we provide (probably around 300–500 Hz). This would again demonstrate aliasing.EE concepts: op amp, DC bias, bias source with unity-gain amplifier, AC coupling, gain computation.

    Lab skills: complicated breadboarding (enough wires to have problems with messy wiring). If we add the Arduino recording, we could get into interesting problems with buffer overrun if their sampling rate is higher than the Arduino’s USB link can handle.

    Equipment needed: breadboard, op amp chip, assorted resistors and capacitors, electret microphone, Arduino board, optional loudspeaker.

  6. Capacitive touch sensor

    The students will build an op-amp oscillator (a square-wave one, not a sine wave) whose frequency is dependent on the parasitic capacitance of a touch plate, which the students can make from Al foil and plastic food wrap. Students will have to measure the frequency of the oscillator with and without the plate being touched.

    Instead of breadboarding, students will wire this circuit by soldering wires and components on a PC board designed for prototyping op amp and instrumentation amp circuits.
    We will also provide a simple Arduino program that is sensitive to changes in the period of the oscillator and turns an LED on or off, to turn the frequency change into an on/off switch.EE concepts: frequency-dependent feedback, oscillator, RC time constants, parallel capacitors.

    Lab skills: soldering. Frequency measurement with multimeter.

    Equipment needed: Power supply, multimeter, Arduino, clip leads, amplifier prototyping board, oscilloscope.

  7. Phototransistor

    The details of this lab have not been worked out yet. It will probably involve either making a photointerrupter switch or making and characterizing an optoisolater made from an infrared LED and a phototransistor.EE concepts: LEDs and phototransistors (maybe also photodiodes and photoresistors), optoisolators.

    Equipment needed: breadboard, LED, phototransistor, resistors, function generator, oscilloscope, multimeter.

  8. Pressure sensor 1—instrumentation amplifier

    Students will design an instrumentation amplifier with a gain of 300 or 500 to amplify the differential strain-gauge signal from a medical-grade pressure sensor (the Freescale MPX2300DT1), to make a signal large enough to be read with the Arduino A/D converter. The circuit will be soldered on the instrumentation amp/op amp protoboard.The sensor calibration will be checked with water depth in a small reservoir. Note: the pressure sensor comes in a package that exposes the wire bonds and is too delicate for student assembly by novice solderers. We will make a sensor module that protects the sensor and mounts the sensor side to a 3/4″ PVC male-threaded plug, so that it can be easily incorporated into a reservoir, and mounts the electronic side on a PC board with screw terminals for connecting to student circuits.

    EE concepts: differential signals, twisted-pair wiring, strain gauge bridges, instrumentation amplifier, DC coupling, gain.

    Equipment needed: Power supply, amplifier prototyping board, oscilloscope, pressure sensor mounted in PVC plug with breakout board for easy connection, water reservoir made of PVC pipe, secondary containment tub to avoid water spills in electronics lab.

  9. Pressure sensor 2—modeling fluidics with linear circuits
    Students will use the pressure sensors and amplifiers from the previous labs to characterize a pair of water reservoirs connected by a flexible hose. The details of the lab are still being worked out.Students will either induce a step change in pressure in one reservoir and record the step response in each reservoir, or will mount one reservoir on a homemade shaker table driven by a function generator and an audio amplifier.EE concepts: hydraulic analogy, frequency response (both amplitude and phase).

    Equipment needed: Power supply, amplifier prototyping board, oscilloscope, Arduino, pressure sensor mounted in PVC plug with breakout board for easy connection, 2 water reservoirs made of PVC pipe, hose connections, secondary containment tub to avoid water spills in electronics lab, possibly home-made shaker table. Note: the shaker table and power amplifier is the most expensive piece of equipment not already in the lab: it will cost about $50 to build.

  10. Electrocardiogram EKG

    Students will design and solder an instrumentation amplifier with a gain of 2000 and bandpass of about 0.1Hz to 100Hz. The amplifier will be used with 3 disposable EKG electrodes to display EKG signals on the oscilloscope and record them on the Arduino.Equipment needed: Instrumentation amplifier protoboard, EKG electrodes, alligator clips, Arduino, oscilloscope.

3. Systemwide Senate Regulation 760 specifies that 1 academic credit corresponds to 3 hours of work per week for the student in a 10-week quarter. Please briefly explain how the course will lead to sufficient work with reference to e.g., lectures, sections, amount of homework, field trips, etc. [Please note that if significant changes are proposed to the format of the course after its initial approval, you will need to submit new course approval paperwork to answer this question in light of the new course format.]

This is a 2-unit course. Three hours a week will be spent in scheduled labs, another 3 hours a week in pre-lab design activity and post-lab write-ups.

4. Include a complete reading list or its equivalent in other media.

Wikipedia book: http://en.wikipedia.org/wiki/User:Kevin_k/Books/applied_circuits
Because no existing textbook covers all the material of the course, collection of relevant Wikipedia articles has been made that covers all the major topics. The book is available online for free, but students can purchase a printed and bound version (about 350 pages), if they want. Some of the Wikipedia articles contain more detail than is needed for the course, but about 90% of the content is relevant and will be required.

Data sheets: Students will be required to find and read data sheets for each of the components that they use in the lab.

Op amps for everyone by Ron Mancini http://www.e-booksdirectory.com/details.php?ebook=1469 Chapters 1–6 This free book duplicates some of the material in the Wikipedia book, but provides more detail and a cleaner presentation of some of the op-amp material.

Op Amp Applications Handbook by Analog Devices http://www.analog.com/library/analogDialogue/archives/39-05/op_amp_applications_handbook.html has some useful material, particularly in Sections 1-1 and 1-4, but is generally too advanced for a first circuits course. Readings in this book will be optional for the more advanced students.

The classic book The Art of Electronics by Horowitz and Hill has one of the best presentations of op amps in Chapter 4. Chapters 1 and 4, and parts of Chapters 5 and 7 are relevant to this course. Unfortunately, the book is now 23 years old and much of the description of specific chips is obsolete, but the book is still quite expensive. We will provide page and section numbers for optional readings in this book that correspond to the readings in the main texts, but not require this book.

5. State the basis on which evaluation of individual students’ achievements in this course will be made by the instructor (e.g., class participation, examinations, papers, projects).

Students will be evaluated on in-lab demonstrations of skills and on the lab write-ups.

6. List other UCSC courses covering similar material, if known.

EE 101L covers some of the same basic electronic lab skills, but without the focus on sensors or design, and without instrumentation amps.

Physics 160 offers a similar level of practical electronics, but focuses on physics applications, rather than on bioengineering applications, and is only offered in alternate years.

7. List expected resource requirements including course support and specialized facilities or equipment for divisional review. (This information must also be reported to the scheduling office each quarter the course is offered.)

The course will need the equipment of a standard analog electronics teaching lab: power supply, multimeter, function generator,  oscilloscope, and computer plus soldering irons. The equipment in Baskin Engineering 150 (used for EE 101L) is ideally suited for this lab. There are 24 stations in the lab, but only 12 function generators. Adding a dozen $300 function generators would make all 24 stations simultaneously usable, but the lab could be run with only half the stations, if all labs requiring function generators are done only with student pairs rather than individuals.

In addition, a few special-purpose setups will be needed for some of the labs. The special-purpose equipment was designed to be easily constructed with simple tools and to cost around $50/setup. One of the teachers is prototyping all the lab setups at home, to make sure that they can be effectively made within budget without expensive parts or much shop time.

There are a number of consumable parts used for the labs (integrated circuits, resistors, capacitors, PC boards, wire, and so forth), but these are easily covered by standard School of Engineering lab fees.

The course requires a faculty member (simultaneously teaching the co-requisite Applied Circuits course) and a teaching assistant (for providing help in the labs and for evaluating student lab demonstrations).

8. If applicable, justify any pre-requisites or enrollment restrictions proposed for this course. For pre-requisites sponsored by other departments/programs, please provide evidence of consultation.

Students will be required to have single-variable calculus and a physics electricity and magnetism course. Both are standard prerequisites for any circuits course. Although DC circuits can be analyzed without calculus, differentiation and integration are fundamental to AC analysis. Students should have already been introduced to the ideas of capacitors and inductors.

9. Proposals for new or revised Disciplinary Communication courses will be considered within the context of the approved DC plan for the relevant major(s). If applicable, please complete and submit the new proposal form (http://reg.ucsc.edu/forms/DC_statement_form.doc or http://reg.ucsc.edu/forms/DC_statement_form.pdf) or the revisions to approved plans form (http://reg.ucsc.edu/forms/DC_approval_revision.doc or http://reg.ucsc.edu/forms/DC_approval_revision.pdf).

This course is not expected to contribute to any major’s disciplinary communication requirement.

10. If you are requesting a GE designation for the proposed course, please justify your request making reference to the attached guidelines.

No General Education code is proposed for this course, as all relevant codes will have already been satisfied by the prerequisites.

11. If this is a new course and you requesting a new GE, do you think an old GE designation(s) is also appropriate? (CEP would like to maintain as many old GE offerings as is possible for the time being.)

No General Education code is proposed for this course, as all relevant codes (old or new) will have already been satisfied by the prerequisites.


Filed under: Circuits course, Pressure gauge Tagged: Arduino, bioengineering, capacitive touch sensor, circuits, course design, ECG, EKG, electret mic, electret microphone, electrocardiogram, electrodes, electronics, multimeter, op amp, oscilloscope, phototransistor, pressure sensor, sensors, teaching, thermistor

Nerf gun progress

The Nerf gun prototype is coming along nicely.  The students have tested the launcher up to 120 psi, built a prototype tilt and pan mechanism in Lego, and today hooked up a small reservoir behind the solenoid valve on the barrel to a bigger reservoir using an air hose.

They hope to be able to keep the bigger reservoir up to pressure by occasionally turning on a 12v compressor.  The compressor takes 10A and can’t be run for very long at a time (it brings the system up to 120psi  from 0psi in about 15 seconds), so they’ll have to run it off a relay.  I couldn’t find cheap relays that looked easy to use with 5v control and 12v 10A contacts, but automotive relays are cheap (I found 5 relays and 5 sockets for $5 on Amazon AGT (5 Pack) 30/40 AMP Relay Harness Spdt 12V Bosch Style (40AMP-HRNS)—even with shipping that is only $2.25 each for relay plus socket).  The relay can be controlled by half an H-bridge of the Hexmotor board.  The other half of the H-bridge controlling the solenoid should be fine, as we never need to run the compressor and fire at the same time—we can stop the compressor for a fraction of a second while firing.

They want to have the running of the compressor be automatic, which would require a pressure sensor.  The Freescale MPX5999D would work and is one of the few sensors I’ve seen with a large enough range, but I’m not sure how to mount it.  Standard tire-pressure monitoring sensors and transmitters are cool, but I don’t know if they go up to high enough pressures and I don’t know how to interface to their transmitters—that is almost certainly a more expensive solution. Honeywell has a differential sensor with ports that will go to ±150psi, which may be easier to connect up, but it costs about twice as much and is uncompensated and unamplified: I suspect it would be a lot fussier to work with than the Freescale part.  I’ve ordered a sample of the Freescale part, and read their AN936 application note on mounting (epoxy is your friend).

It turns out that the relays may be useful for other functions, like a linear actuator for the tilt mechanism. Two relays can be controlled from one H-bridge to get forward-backward-stop action on motors up to 30 amps (but no PWM!). Unfortunately, 12v linear actuators seem to run $100 and up, which is more that I want to spend on a single part.  I may ask the students to redesign—either building their own lead-screw mechanism or coming up with a different tilt mechanism.  I don’t think a simple servo motor will do—the beefiest one I have claims only 69 oz-in (0.49 Nm) of torque, which I don’t think will be enough to tilt the gun, even if they can get the hinge very close to the center of gravity.

Another problem has come up: getting more darts.  We have 5 darts that fit the barrel perfectly (1.45cm diameter).  There are plenty of darts sold like that, but they almost all now have larger heads on the end, and the heads don’t slide down the barrel.  The new Nerf clip-system darts are all mini-darts, that have a 0.5″ (1.25cm) diameter instead.  These do not fire well from the ½” PVC, which I measured as having an ID of 1.485cm (0.585″). A chart of PVC sizes I found on line says that 1/2″ ID Schedule 40 PVC is supposed to have an inside diameter of 0.622″, which is almost 5/8″, but that ID can vary by 10%, even along a single piece of pipe—only OD is held to tight specs.  Thicker-walled Schedule 80 is supposed to have 0.546″ ID, which would still be too loose for clip-system darts.

I see four possible solutions:

  • Find a source of (probably non-Nerf) foam darts that are 1.45cm (9/16″) diameter with heads that are no wider than the body. I think that they came with an NXT generation crossbow, so replacement foam darts for that may be what we need. They’re nowhere near as cheap as clip-system darts, but this is still probably the cheapest solution.
  • Buy Nerf  (or other) darts with the right size bodies but oversize heads, remove the heads, and make new ones (out of what?). This would be cheap, but tedious, and the darts would probably fly poorly, unless we made the new heads have a decent weight.
  • Use clip-system darts for compatibility with the popular Nerf guns, but find a smaller diameter tube than the ½” PVC pipe (where? and how would it be connected to the solenoid valve?) It looks like Schedule 40 3/8″ steel pipe has a inside diameter of 0.49″, which is just right, but steel pipe is rather heavy.
  • Use clip-system darts, but convert to the Nerf-standard tube-inside-the-dart launching system.  This limits the effective barrel length to the inside length of the dart (about 4.5cm) and the barrel diameter to the inside diameter of ¼”, which will limit the top speed of the darts (OK for safety, but probably not as much fun).

Filed under: Pressure gauge, Robotics Tagged: Arduino, foam darts, linear actuator, Nerf darts, Nerf gun, nerf guns, pressure sensor, relay, rocket

Sensor board for underwater ROV

Since I had bought the robotics club an I2C accelerometer and magnetometer, I decided to make a new PC board for them to mount the accelerometer, the magnetometer, and the pressure gauge on the same board.  I don’t have the SMD soldering skills to solder all the chips onto one board, and I already had breakout boards for the accelerometer and magnetometer from Sparkfun, so I decided just to put connectors for those breakout boards onto the back of the pressure sensor board.  (The back, because the pressure sensor on the front has to be stuck through a hole in the dry box and glued in place.

The new boards are tiny (1.05″ × 1.425″), so I decided to try BatchPCB (which has pricing by the square inch) rather than 4pcb.com (which has fixed pricing per board, up to a fairly large size).  The price from BatchPCB was $10 per order plus $2.50/square inch plus $0.90 for shipping, so ordering 3 copies of the board (though I only needed one), cost me $22.12, substantially less than a single board from 4pcb.com, which is $33 plus $17.30 shipping and handling per board (plus an extra $50 if your board has multiple boards on it).  The 4pcb price is lower if your board is bigger than about 15.76 square inches, so even my HexMotor boards (at 12.44 square inches) would be cheaper from BatchPCB.  If you get multiple boards from 4pcb.com on a single panel and cut them apart yourself, the breakeven point is about 35.76 square inches for a single design (so three HexMotor boards from a single 4pcb.com panel is cheaper than from BatchPCB). For multiple designs on a single panel, the 4pcb.com deal is better: for 3 different designs, a total of 27.04 square inches would make 4pcb.com the cheaper way to go.

If you want a copy of the board, you can order it from BatchPCB, or pick up the Eagle files from my web site and order copies from elsewhere.  I’ve put the HexMotor Eagle files on line also, but not put them on the BatchPCB site.  I should probably upload them there sometime.

Bottom line: BatchPCB is better for small numbers of tiny boards, but 4pcb.com is better for larger boards and multiple designs.

The BatchPCB orders came back quite quickly (12 days from order to delivery by mail), though I had been worried because their design-rule check, which they say takes minutes had taken about 8 hours.  The problem was that each check takes a few minutes, but they had hundreds in the queue over the weekend, and it took a full day to clear the queue.

I had less trouble soldering the pressure gauge this time (this was my second attempt at soldering surface mount devices).  You can see in the pictures above that the results are much cleaner than in my first attempt.

The robotics club has tested the pressure sensor on the new board (using their own code on the Arduino) and it seems to work ok,  have drilled the hole in the dry box for the port, and glued the sensor board in place using superglue.  It seems to be waterproof (at least down to 1 foot—we’ve not tested in deep water yet).

Related articles

Tagged: accelerometer, Arduino, BatchPCB, magnetometer, pressure sensor, Printed circuit board, ROV, SparkFun Electronics

HexMotor 2.3 and pressure-sensor boards

Top view of my second PC board. 3 copies of HexMotor 2.3 and 2 copies each of 3 different breakout boards for a pressure sensor.

I got the boards back from 4pcb.com about a week ago.

The HexMotor rev2.3 boards have several new features: LEDs for +5v and +6.25v, a reset button, 16-bit shift register instead of 8-bit, servo outputs connected to pins 13, 7, 2, 9, 10 (rather than to the pins used for PWM).  The new board should be able to do either 6 PWM motors or 4 PWM motors, 5 servos, and 2 non-modulated reversible motors.  I was going to have the robotics club solder the board today, but they did not have time.

[Note: as of 1March 2012, I have put the HexMotor Eagle design files on the web.]

I made some breakout boards for the MPXHZ6250A pressure sensors from Freescale Semiconductor,  which gave me my first taste of SMD soldering.  At least the design uses gull-wing pins, which can be hand soldered.  The breakout board that I think that the robotics club will end up using puts a pressure sensor on one side and headers for a piggyback ADXL335 breakout board on the back.  that way there only need to be one set of wires for connecting the analog inputs and power to the sensors.

That is the board I soldered a sensor to.

Top view of the breakout board with the sensor and headers soldered in place.

The pressure sensors are tiny! I found it fairly difficult to solder the  sensor to the boards, even holding it with clamping tweezers. I did eventually get everything to stick with no shorts between the 3 signal wires, but I did have some trouble with the unused copper pads delaminating from the board.  For future reference: all pads should have wires going to them (even the unused pads) to have enough surface area for good adherence and so that some of the pad is tucked under the solder mask.

Here are the solder connections on the side where none of the pins are used.

Here are the solder connections for the power and signal pins (and an SMD capacitor).

Despite the rather sloppy soldering, the pressure sensor does work.  It turns out that the port size is just the right size for Lego pneumatics components, so testing was pretty easy.

Sensor attached to Lego pump and gauge for testing.

Here are the results of calibration tests with the (probably not very accurate) Lego gauge, done by my son and me.

Pressure (psi) Arduino analogRead
0 367
5 518
6 542
7 576
8 599
9 632
10 657
11 683
12 710
13 734
14 775
15 801
16 832
17 861
18 887
19 915
20 941
21 967
22 1000

The range is about right, since 22 psi plus one atmosphere is about 250kPa, which is supposed to be the high end of the sensor’s range. Also, 600″ (50′) of water is 21.67 psi, so the range from 367 to 1000 corresponds to about 50′, so the sensor should give the robotics team a resolution of about 1″ for measuring depth, as expected from the spec sheet.

The data are well fit by The club members will have to recalibrate the pressure sensor in water, to get calibration as depth in cm. They’ll probably have to re-zero the sensor every day they use it, to compensate for atmospheric pressure, since it is an absolute pressure gauge.


Tagged: Arduino, Lego pneumatics, pressure sensor, Printed circuit board, SMD soldering