Show Posts
Pages: [1] 2 3
1  Using Arduino / Sensors / Re: Turn power on and off to ultrasonic sensor (HC-SR04) on: July 18, 2014, 10:24:48 pm
Some of my latest findings:

I used a MOSFET (BS170) to switch the SR04 on the low side (connected to GND). The BS170 is not an ideal low voltage MOSFET for this purpose, but it will do. When disabled by bringing the gate pin low and going into low power mode, the power draw is beneath the ability of my multimeter to measure, as opposed to ~11 mA when the sensor is connected but not otherwise busy. I don't know where the "<2mA quiescent current" from the datasheet comes into play.

As I said above, I was not able to power it directly from a digital pin; I don't understand why other people appear to be able to do so. I did read on one site that it depended on the unit, some could and some couldn't.

When using a MOSFET, don't forget to put a pulldown resistor on the gate to avoid issues during power up when the pins are high impedance, as well as a current limiting resistor.

Switching low side does seem to introduce another issue. Several of the "datasheets" on the SR04 mention that it is necessary to connect GND first before VCC, or unspecified issues will arise. I think I ran into one of them. The echo pin after it comes up is high, and results in a short read. My "solution" to this is to do a sacrificial ping after enabling the sensor after a small delay, which resets things.

You must also make the trigger pin an input pin when disabling, or the sensor will find ground through it and continue to draw power.

Here is some code:
void disable_sr04() {
  digitalWrite(PING_ENABLE, LOW);
  // As well as disconnecting GND with a low side MOSFET, we have to disconnect
  // the trigger pin, or the sensor will find ground through it and remain powered up.

void enable_sr04() {
  // Reset the trigger pin mode to output.

  // Connect GND to the sensor.
  digitalWrite(PING_ENABLE, HIGH);

  // Various data sheets exhort you connect GND before VCC, but never say what will happen if you don't.
  // What appears to happen is that the echo pin stays high, and you get a short read on the first ping.
  // A sacrificial ping after a short delay after power up appears to make everything happy again.

  // Enforce a settling delay.
2  Using Arduino / Sensors / Re: Turn power on and off to ultrasonic sensor (HC-SR04) on: June 27, 2014, 07:26:31 am
Would anyone have a suggestion as to a suitable SMD MOSFET? The IRF530 mentioned is a large power MOSFET, and I don't think I need something that big. Also, does it matter if I switch VCC or GND for the sensor?
3  Using Arduino / Sensors / Re: Turn power on and off to ultrasonic sensor (HC-SR04) on: June 27, 2014, 06:46:16 am
I'm going through the exact same issues with my own SR04 project ( The first version powered the sensor from VCC, and worked, but drew 11 mA at idle with the sensor plugged in but not ranging, measured at the batteries (I don't know where the 2 mA "quiescent current" draw is supposed to come in; maybe the boost converter increases the draw?). First revision tried drawing power from a digital output pin, but that didn't work at all, although one of the above responses indicated that it did? There was a thread on AVRFreaks that indicated that these sensors will draw 100 mA peak current, even though the average current draw is ~10 mA, so powering it from a digital pin is not an option. Doing some more looking around found another instance of trying to power it from a digital pin that said it only worked for a fraction of the modules that they tried it with.

I soldered a 330 uF capacitor across the GND and VCC pins on the sensor to try to up the power available. It worked when being powered continuously, but returned nonsense values when I tried to switch it on and off, even with large delays to fill up the capacitor. Maybe it doesn't like power being ramped up?

So I guess a MOSFET switch is the answer?
4  Using Arduino / Microcontrollers / Re: Arduino controlling a relay. on: June 09, 2014, 03:17:42 pm
Connect the relay coil to an output pin and try it. Many servos will work with the 40 mA a pin can put out, even if it is technically too low. If it works, you're good to go. There is no issue with driving a 6V relay with 5V, if it works.

If it doesn't, then switch the relay through a transistor from VCC.

Don't forget to put a diode in parallel to the relay coil pointing the "wrong" way to dissipate the inductive energy.
5  Using Arduino / Microcontrollers / Re: Atmega8+Arduino Bootloader via ISP Header + USB flashing Sketches on: June 02, 2014, 11:45:48 am
I'm glad one person has found it useful.

As I said, you will find it helpful to get an FTDI serial breakout board from Sparkfun. It handles the USB interfacing without you having to put the USB stuff on your board, just a six pin header.

Oh, and in regards to your comment about ICSP and burning hex files: the Arduino IDE can burn sketches through ISP by itself through a programmer, no need to use a separate program. The easiest way is to add your own boards.txt entry. See my project writeup linked to in the beforementioned thread. The workflow is then identical to burning through USB/serial, you just won't have a serial console.
6  Using Arduino / Microcontrollers / Re: Atmega8+Arduino Bootloader via ISP Header + USB flashing Sketches on: June 01, 2014, 03:40:53 pm
Luke, you may be interested in my sample board layout:

It is for an ATmega328P, but otherwise is similar to what you are looking for, a board design with a TQFP Atmel, ISP, and serial headers. I highly recommend you get Sparkfun's FTDI serial breakout, as it greatly simplifies serial communications in your own projects; no need to deal with USB to serial conversion yourself, and auto resets on upload.

Many of the components are actually optional if you know what you are doing. You don't need a resonator, and you don't need the serial header (you can upload sketches through ISP), although it helps with debugging, or if you need serial output from your project. The power supply is designed for running off AA batteries for low power standalone projects.

The bottom third of the schematic is project specific, so you can remove those and replace them with your own components.

An alternative solution would be to get an Arduino Pro Mini, which can be had very cheaply, and design a board around that.

Just to get an idea for expected cost, you can get 5 boards for $17 shipped from a hobbyist fab like Seeedstudio.
7  Using Arduino / Microcontrollers / Re: Wiring up the Atmega328P on: May 29, 2014, 04:14:58 pm
If you have a working prototype and are sure that your sketch will work and won't be needing serial to debug or otherwise communicate, you can get away with just putting a 3x2 ICSP header on your board, and using another Arduino or a USBTinyISP to program your board.

If you do have need for serial, then I suggest you look into the FTDI serial breakout board by Sparkfun. It contains an FTDI chip to convert USB to serial and provides six header holes. You just put in a matching set of holes on your board and now you can talk to it/program it just like a regular Arduino. The DTR pin should be connected to RST on the ATMega through a capacitor pulled up to VCC to enable auto reset. Unless you are using chips with a preloaded bootloader, you will also want an ICSP header to get the bootloader on there.

You can check out the schematic at for an example of both (just the central section, with the chip and J1/J2). I reproduce it below.
8  Using Arduino / Microcontrollers / Re: Urgent issue on encoder interruptions and PID timing on: May 29, 2014, 12:50:34 am
How did it go?

If you are using pin change interrupts on your rotary encoders, why do you need to do a digitalRead? Aren't you just interested in the transitions?

Every time your timer interrupt runs, it will lock out the encoder interrupts so you will miss steps. What about a busy wait loop instead?
9  Using Arduino / Microcontrollers / Re: Program 328 32TQFP inside project? on: May 28, 2014, 11:51:33 pm
Depends on what else is connected to the ICSP pins. If the "something else" are output pins, then no, you shouldn't also use them as programming pins. If they are input pins, then you should be able to reuse those lines, unless the programming is liable to upset the NRF24L01 modules.

You can isolate the ICSP pins for use during programming by a switch or jumper. If the module you are using has a reset pin and it tristates its output pins during reset, you can use a different 328 pin to disable reset, and pullup or pulldown the reset pin on the module to isolate it during programming.
10  Using Arduino / Microcontrollers / Sample barebones ATMega328P SMD layout board available on: May 25, 2014, 10:15:51 pm
I have written up a recently completed project that I thought might be helpful to others. It may be old hat to many of you, but something like it would have been of great use to me when I started on it, so I present it here in the hopes that it may be of interest to someone else. It is basically a barebones Arduino PCB layout using SMD parts, efficiently powered off AA batteries for wallwart-free installation. It is in the same vein as a "breadboarduino", except you do it in Eagle instead of with wires.

Once you have a prototype Arduino-based project working, what do you do next? A lot of projects that I see just stop there, and that is fine. But the downside is that you have to dedicate your Arduino to that one function, and provide it with a steady diet of DC power. I wanted to do a simple project that would end with a nice enclosed board, self powered with AA batteries, that would run for months at a time.

Most of the available mini Arduino boards (say, the Arduino Pro Mini) use an LDO and most have a power LED. Both of those draw continuous power, and would need to go. I found had done a lot of work on mobile low-power Arduino systems, so I used the boost converter that he uses for an AA power board, the LTC3525. It comes in 3.3V and 5V versions; I opted for the 5V because the sensor I am using requires it, but for the lowest power draw the 3.3V would be preferable.

I was unable to find any sample layouts for a barebones Arduino SMD setup, although there are plenty of bread board examples. I cribbed the essential circuit schematics from the Arduino Pro Mini board, removing all the extraneous pin routing to headers, and from the LTC3525 datasheet. A friend of mine helped me with the layout (staring at a mass of tangled air wires is the hardest part to work through, even for such a simple board), and threw in an ICSP 3x2 header and a serial header with DTR brought out for auto-reset using SparkFun's FTDI breakout board. All parts are 0805 or larger, except for the TQFP ATMega328P, and the whatever-it-is (but very tiny) LTC3525.

Some helpful notes to anyone who wishes to go down this path:

  • Hand soldering fine pitch SMD parts isn't that hard, and you don't need an expensive Hakko. I used my trusty 30W Radio Shack iron. Get some flux, some copper braid, and google "drag soldering".
  • What is hard is soldering the SMD ceramic resonator. I used the SparkFun footprint, which places the pads completely underneath the package. I was able to solder it by offsetting it slightly on the pads to be able to reach them. This was only after ruining my first board when I didn't have it soldered correctly, then tried to burn a bootloader. If you set the fuses to require an external oscillator, and the oscillator is not installed properly, you will not be able to recover. In the future, I will redraw the pads, or use a through hole resonator.
  • Another error I made was not checking the microcontroller data sheet before routing my project pins. I mistakenly used pin 19, ADC6, expecting to address it as an output. Turns out, it is a read only pin.
  • For a truly barebones setup, you can delete the external resonator and the serial pins/header/pullup, leaving just the ICSP for programming. The USBTinyISP programmer is cheap, and I can recommend it. You can also set up an Arduino as an ICSP programmer. Having a serial port really makes for easier debugging, which is not necessary if you already have a working sketch. If you remove the resonator, you must be familiar with (or learn about) setting fuses to use the internal clock. Or you can use it as-is, but it will run 8 times slower than you expect.
  • I used an 8 MHz oscillator because I didn't need the faster speed, and wanted the least amount of power use. 16 MHz is as simple as using a different oscillator and a slightly different boards.txt entry. I cribbed mine off the 8 MHz Arduino Pro Mini board spec (pro328), use pro5v328 for 16 MHz.

To reuse the files for your own project, simply delete the three LEDs and their resistors. Plop down your own components/headers in the schematic, and route them. Some basic familiarity with Eagle is required, but having something minimal to start with is (would have been) a great help. Minimum incremental cost for a new project is ~$25: $4 for microcontroller, $4 for boost chip, $17 for 5 PCBs (including shipping) from or similar hobbyist fab, a bit more for resistors/capacitors/etc., then whatever else your project needs.

Some project-specific points of interest: the project is a parking aid, to tell you when to stop when parking, using the cheap HC-SR04 module ($2/each on ebay). It uses the jeelib library from jeelabs to enter deep sleep between ping attempts. It uses the NewPing library to interface to the sensor module. There are three LEDs, green, yellow and red; the green and red LEDs are either on or off, but the yellow one blinks at a rate proportional to the sensed distance. The blinking is handled through an interrupt handler using TIMER1 in CTC mode, so that the main loop does not have to account for it. There is a simple state machine to determine the ping cycle: 100 ms for active sensing during parking, 1 minute for a parked car, and 2 s for an empty bay.

The project writeup is here:
Eagle source files, project specific firmware, and STL files for the 3D printed project enclosure are here:
Project test video:

I have not tested the actual power drawn, but given the low duty cycle, I expect "months" is not an unreasonable estimate.
11  Forum 2005-2010 (read only) / Development / Re: NewSoftSerial Library: An AFSoftSerial update on: March 01, 2009, 12:26:38 pm
The soft serial interrupt will run (and exit quickly) any time any of the pins in the same block change. You might try putting all the servo pins on a different port if you can rewire it and see if that helps. If you need the PWM pins, try putting the serial on one of the analog pins.
12  Forum 2005-2010 (read only) / Development / Re: NewSoftSerial Library: An AFSoftSerial update on: February 27, 2009, 01:13:42 pm
How is it that the Windows version of the compiler doesn't have the register problem? I thought they were both on the same version and based on the same code, no?
13  Forum 2005-2010 (read only) / Development / Re: NewSoftSerial Library: An AFSoftSerial update on: February 26, 2009, 09:46:27 pm
Hah. I actually wrote a version that uses Timer1 and Timer2 to do that, when I was having some problems with NewSoftSerial. Turns out those were all interrupt related, so I didn't do anything with it. It has some problems at higher baud rates, but I've run it at 19200 with no problems. You're welcome to take a look if you like:

The code is based on an earlier version of NewSoftSerial, version 2 or 3. It also contains code for RTS/CTS flow control, which I found I needed for my project.
14  Forum 2005-2010 (read only) / Development / Re: NewSoftSerial Library: An AFSoftSerial update on: February 26, 2009, 03:20:19 pm
Is it fairly easy to update the compiler for arduino-0013? Do you have to build it, or is there a binary distribution you can just untar in the right place?
15  Forum 2005-2010 (read only) / Development / Re: NewSoftSerial Library: An AFSoftSerial update on: February 04, 2009, 11:11:34 pm
I've been playing around with NewSoftSerial and it's been working pretty well for me, with only a few difficulties so far. Thanks for your great work packaging up a bunch of different ideas, mikalhart.

A few notes:
  • I've experienced some problems doing the same sort of serial pass-through, where you just echo characters between the softserial pins and the UART. If the device I'm speaking to on the softserial port is set to echo, no matter how slowly I type I am liable to get garbage characters interspersed with what I'm typing. Turning off echo and having everything run half duplex gives pretty good results. Could this be because pins 2 and 3 (used very often in the soft serial examples I've seen) share an interrupt with the UART on pins 0 and 1? Unfortunately, my device requires a specially designed shield so I can't move pin assignments around easily, but if someone who is having interrupt problems could try using, say, pins 8 and 9 for the soft serial and see if they continue to have problems, that would be an interesting experiment.
  • Another problem I've had is when I get a whole slew of characters sent back from the serial device, it quickly fills the buffer and I lose the rest of the data, even when I'm not doing hardly anything else in the main loop other than trying to handle the input. I'm looking into adding proper RTS/CTS handling as an option to NewSoftSerial to see if that helps. There's an attempt at CTS handling in the AF_XPort code, but it doesn't seem to work properly for me.
Pages: [1] 2 3