Show Posts
Pages: [1]
1  Community / Gigs and Collaborations / Re: Several HC-SR04 Sonar Sensors on one board on: February 24, 2013, 02:24:04 am
These sonar sensors don't use a serial protocol or any kind of addressing. Just a high pulse on one pin and a return pulse on the other. If you want to use multiples, you'll need a pair of pins for each sensor, or a driver board for each sensor that will let you use a serial protocol.

2  Using Arduino / Project Guidance / Re: Autonomous Robot, motor driver on: February 23, 2013, 12:50:37 pm
I built a RepRap 3D printer using Pololu stepper drivers with heat-sinks.  Even with the heat-sink, the motors would draw enough current to overheat the driver chips, causing them to go into fail-safe mode... they stopped operating until they'd cooled down.  While this was only a second or two at a time, this caused the motors to randomly skip steps, which is a real problem with 3D printing.  The heat-sinks, on top of chips barely 1/4" square, got nearly hot enough to burn my finger.

A tiny CPU fan over the controller board solved that problem.  So yes...  a fan can quite literally make your robot's motors run more smoothly.
3  Using Arduino / Sensors / Re: Problems with RTC module on: February 23, 2013, 11:54:37 am
I have got me a used RTC clock that looks like this one:

Sadly the example in the rtclib only shows 2165/165/165 165:165:85 as output.

From my Arduino Uno I wired A4 to SDA and A5 to SCL . Is there a way I can check what I have
made wrong? Or to check if the RTC module is damaged?

I've worked with that chip... even made my own little board similar to the SparkFun one.  I'm only using the Wire library for I2C and handling all of the clock decoding myself.  Your pin connections sound right.  You have hooked up Vcc and Gnd to the module, right?

The chip runs fine off USB with a back-lit LCD... I've got that set up on the breadboard now.

If you're using the serial monitor for output, be sure your baud rate matches.  (Though I'd expect something less readable.)

You can skip the RTC library and try this code to verify that the module works, then go back and figure out the RTC library.  If the time has never been set, uncomment the initialization section in setup().  There's a bunch of sloppy debug code you can uncomment if you want to see the individual pieces as it decodes them.

// experimenting with I2C and the DS1307 RTC

#include <Wire.h>

// address of DS1307: 110 1000 = 0x68
#define RTC 0x68

// SDA pin a4 (DAta)
// SCL pin a5 (CLock)

#define SECONDS 0
#define MINUTES 1
#define HOURS   2
#define WDAY    3
#define MDAY    4
#define MONTH   5
#define YEAR    6

char* dow[] = {
  "", // Sunday is day 1

void setup() {
  Serial.begin(9600);  // communicate clock info back to the monitor

  Wire.begin(); // join i2c bus (address optional for master)
  // initialize clock...
 // Wire.beginTransmission(RTC);
 // Wire.write(0x00); // send register address to move to
 // Wire.write(0x00); // clear bit 7 to start clock, + 0 seconds
 // Wire.write(0x24); // 29 minutes
 // Wire.write(0x18); // 10 hours
 // Wire.write(0x06); // 5 = Thursday
 // Wire.write(0x20); // 28th
 // Wire.write(0x07); // June
 // Wire.write(0x12); // 12th year (2012)
 // // ... and set seconds to 0 unavoidably
 // Wire.endTransmission();

void loop() {
  Wire.write(0x00); // send register address to move to
  // then send data if we desire to actually write...
  // otherwise it just updates the pointer for read.

  uint8_t buf[7]; // registers 0x00 to 0x06
  uint8_t idx=0;  // pointer to current array

  Wire.requestFrom(RTC,7); // request all 7 time registers
  while( Wire.available()) {
    buf[idx++] =;  // receive byte

  uint8_t b;

  b = buf[SECONDS];
//  Serial.print( b, BIN );
//  Serial.print( " : " );
  uint8_t seconds = (b & 0x0f) + ((b & 0x70) >> 4)*10;
//  Serial.println( seconds );

  b = buf[MINUTES];
//  Serial.print( b,BIN );
//  Serial.print( " : " );
  uint8_t minutes = (b & 0x0f) + ((b & 0x70) >> 4)*10;
//  Serial.println( minutes );

  b = buf[HOURS];
//  Serial.print( b,BIN );
//  Serial.print( " : " );
  uint8_t hours = (b & 0x0f) + ((b & 0x30) >> 4)*10;
//  Serial.println( hours );

//  Serial.println( dow[buf[WDAY]] );

  b = buf[MDAY];
//  Serial.print( b,BIN );
//  Serial.print( " : " );
  uint8_t mday = (b & 0x0f) + ((b & 0x30) >> 4)*10;
//  Serial.println( mday );

  b = buf[MONTH];
//  Serial.print( b,BIN );
//  Serial.print( " : " );
  uint8_t month = (b & 0x0f) + ((b & 0x10) >> 4)*10;
//  Serial.println( month );

  b = buf[YEAR];
//  Serial.print( b,BIN );
//  Serial.print( " : " );
  uint16_t year = 2000 + (b & 0x0f) + ((b & 0xf0) >> 4)*10;
//  Serial.println( year );

  char bufout[100]; // plenty of room for output

  sprintf( bufout, "%02i:%02i:%02i %s %02i/%02i/%i",
           hours, minutes, seconds,
           month, mday, year );
4  Using Arduino / Sensors / Re: Problem with HC-SR04 on: February 23, 2013, 01:51:08 am
The HC-SR04 requires a 10 uSec pulse to trigger... your 5 uSec pulse probably isn't long enough.  [Edit: NewPing comment says that testing shows initial LOW has to be 4 uSec to be reliable as well.]

There's a Ping library to simplify this, but I recommend the NewPing library... it's easier to use and has a timer mode that allows you to continue with other processing while waiting for the echo.  It works with my HC-SR04 just fine.  (I've been working on a similar robot this week... had the HC-SR04 up and running in minutes with NewPing.)
5  Using Arduino / Sensors / Re: NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.5 on: February 22, 2013, 11:22:41 pm
Ultrasonic sensors don't work well with petrol/gasoline.
Was the problem simply one of calibration, i.e. the speed of sound in vapour-laden air vs. speed of sound in air?

A bit of searching suggests you may be on the right track, but it's apparently not as simple as a one-time calibration.  The speed of sound changes with the density of the fuel vapor, which varies with temperature.  If the only significant variable is temperature, knowing the temperature inside the tank would make compensation relatively simple.  But the temperature at the sensor  may not be representative of the rest of the tank, so may require a remote sensor.

It had an experienced sensor design engineer stumped, at least for awhile.

I asked my wife, and she said vapor was one issue, and another is that gasoline has a high thermal expansion ratio... to get an accurate volume measurement, you have to know the temperature of the fuel as well as its level.  But that wouldn't be an issue if you're only concerned with "the tank's getting low".    Apparently a float was a cheaper and more reliable method, at least at the time.
6  Using Arduino / Sensors / Re: NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.5 on: February 22, 2013, 06:39:48 pm
I'm building a little robot with an HC-SR04 for obstacle avoidance, and I'm finding NewPing to be very nice.  Thanks for your hard work, Tim.

I'm using NewPing in timer-mode, but I don't really need to do anything inside my echoCheck() function... I just want a distance value to be available to other parts of the code.

Here's where I run into a problem... I'm not seeing a good way to directly determine the difference between "timed out without an echo" and "still waiting for an echo" conditions.  check_ping() returns false in both cases, and x.ping_result is only updated on receiving an echo.  So x.ping_result always indicates the distance of the last successful ping, but it will always be a positive value even when pings are timing out without an echo.

So inside my echoCheck(), I have to assign the value of ping_result to a global variable, and then when I read the global variable elsewhere in the code, I have to remember to set it to zero.  This is effectively doing the same job as ping_result, except it's happening in my code instead of inside NewPing.

Would it make sense for the timeout reset portion of check_ping() to set ping_result back to 0?  ping_result isn't used anywhere else in NewPing, so it wouldn't affect internal behavior.  I don't know how it might affect behavior of existing programs, but I suppose it could.

With this minor change, I could eliminate my global variable and just look at ping_result any time I want to know the status of the last ping.

On one level, I'd like the option for the timer-driven model to be even less involved.  I'd like to start the "ping engine" in setup() and have it ping every 50 usec "forever" without calling ping_timer() again, and be able to just check ping_result any time I like.  I can't call ping_timer(echoCheck) from within echoCheck(), because again, check_timer()'s return value doesn't differentiate between "timed out" and "still waiting".  (And despite being a career developer / system architect, I'll admit that I may be missing something here and that the problem is easily solved.)

If check_timer() returned an int... -1 for "still waiting", 0 for "timed out" and a positive value (distance) for an "echo received", it would be a lot more flexible.  And it would break existing code, since its' an API change.

I suppose I could peek at the timer value itself to see if it's still enabled, but having the library help with that would be ideal.  Maybe a function or variable I could call/look at to find out why check_timer() returned false?  Of course, an alternative function to ping_timer(), say, ping_forever(), that didn't (or optionally) require a echoCheck() and handled running the ping over and over on its own might be ideal.  (And I'll admit, this is what I expected when I first dug into the timer-driven mode.)

I may make some tweaks to the library and see which ideas pan out.
7  Using Arduino / Sensors / Re: NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.5 on: February 22, 2013, 06:12:50 pm
I need this because i want to get the height of a petrol tank, so now i can have more better results because of you :-)

Tasos, just a word of caution before you get too far into your project:

Ultrasonic sensors don't work well with petrol/gasoline.  I seem to recall it was due to vapor in the tank giving false readings.

My wife used to work for ESI in Wichita, KS, which specialized in designing and installing liquid storage tank level sensors.  They provided a business-to-business link where their hardware would monitor tanks of, say, liquid chicken feed additive, and automatically call the tank-filling-company and schedule a delivery when the tank was low.

I recall my wife talking specifically about a big sale hanging on their ability to monitor fuel tank levels, and the lead engineer was under a lot of pressure to develop a sensor that worked, but a solution eluded him and it was causing a lot of friction at work.  This was many years ago, and it's now a solved problem, but the problem still stands for generic ultrasonic sensors.  (It may have been a solved problem then, and maybe the boss didn't want to use a third-party product.)

There are commercial sensors available for measuring petrol/gasoline, but I'm sure they're at least a magnitude more expensive than the hobby ultrasonic sensors.
Pages: [1]