ASOM (sensor library): now supporting MCP7941X

Another great contribution of Daniele Ratti (aka ilFuria) who added support for SRAM and EEPROM for MCP7941X. Hope it may help. Many thanks to him.

The new version of the sensor library can be downloaded from GitHub here.

Some other developments are in preparation (September 2016). Please come back soon!

Enjoy!

ASOM (sensor library): update and bug fixes

Many many thanks to Daniele Ratti who made a lot of improvements to the section concerning the RTC module. He made also some bug fixes and tested all the procedures.

The new version of the sensor library can be downloaded from GitHub here.

Enjoy!

PIR sensors: exploiting passivity

We have already spoken about the PIR sensor in these pages (see here) and many other pointers can be found on the web. However, the example sketches does never consider the main aspect of this sensor: passivity! The sketches always employ busy waiting (ie they continuously loop on the test for changes over the alarm pin).

The PIR sensor used in the sketch.

The idea

Use interrupts! The idea is that the alarm function is activated by the state change of the signal pin of the sensor. In this way the CPU can perform other tasks when the alarm is not activated.

Remark

When the alarm is triggered on the PIR sensor it remains in this state for a certain amount of time. Since we chose to implement the CHANGE option for the interrupt routine we have to prevent that the service routine is run twice instead of once. This is implemented using a simple flag.

The sketch

Since the sketch has only prototyping purposes, the only effect of the alarm trigger is to print a message to the serial monitor. To see the message open the serial monitor, choose the right port and communication speed.

/**
 * PIRpassExploit
 *
 * A convenient way to use PIR sensors
 *
 * \author Enrico Formenti
 * \version 1.0
 * \date 15 March 2015
 * \copyright BSD license, check the License page on the blog for
 * more information. All this text must be included in any 
 * redistribution.
 * <br><br>
 * See macduino.blogspot.com for more details.
 *
 * Remarks:
 * - OUT pin is connected to digital pin 2 of Arduino, change this
 *   if needed
 * - DELAY times depend on the type of module and/or its 
 *   configuration.
 */

// OUT pin on PIR sensor connected to digital pin 2
// (any other digital pin will do, just change the value below)
#define PIRSensorPin 2

// This is the amount that the sensor takes to setup internals
// Check your sensor datasheet for the correct value
// Mine is about 17 seconds
#define PIR_INIT_DELAY 17000

// This is used to avoid triggering alarm twice when signal returns
// to normal state
volatile bool alarmUnarmed;

void doAlarm() {
  if(alarmUnarmed) {
    alarmUnarmed = false;    
    Serial.println("Alarm triggered!");
  }
  else
    alarmUnarmed = true;
}

void setup() {
  Serial.begin(9600);
  
  pinMode(PIRSensorPin, INPUT);
  delay(PIR_INIT_DELAY);
  
  alarmUnarmed = true;
  attachInterrupt(0, doAlarm, CHANGE);
}

void loop() {

  // do some good work here ;-)
}

See also

The PIR sensor
Using HC-SR04 as a motion sensor

Enjoy!

HC-SR04: beats phenomenon?

In this post we argued that the beats phenomenon takes place when using the HC-SR04 sensor. We start from the initial experiments and we plot the measures obtained from the sensor against their occurrence time (see Figure 1 below). 

Figure 1. Recollecting data from the previous experiments.

What we remark from the figure is that for the first about 1700 time units the measured value oscillates between the value 982 and 984 (with very few errors). After 1700 time units, the sensor starts oscillating mainly between values 1002  and 1003 in most cases (remark that there are still many oscillations between 982 and 984).

So we have two thing to explain:

1. why the measures oscillate (mainly) between two values?
2. is there a truly beats phenomenon for explaining the oscillations after time 1700? Or is it simply due to some characteristics of the sensor ? Or is due to some interference with Arduino, for example with IRQ service?

Answering the first question is easy. Indeed, according to Arduino specs, the precision is up to 3us. Answering the second question is more complicated and requires a series of experiments. We start from the very last one since it is the easiest one. We just restart our main experiment (see this post) disabling interrupts.

Figure 2 below illustrates the results of this second batch of experiments.

Figure 2. The second batch of experiments.

And here is the surprise! We only remark oscillations between the value 984 (the correct value) and 982 with practically negligible exceptions!

Conclusions.
There is no beats phenomenon going on. The second oscillation observed in early experiments (see Figure 1) is due to the interaction between IRQ service and the HC-SR04 sensor. The oscillations between value 984 and 982 (see Figure 2) are compatible with the approximation error in Arduino specs.

What's next
We are going to test the US-020 ultrasonic sensor. So, as usual, stay tuned!

See also

HC-SR04: what is the distribution law for the frequencies of values? (Part 2)
HC-SR04: what is the distribution law for the frequencies of values? (Part 1)

HC-SR04 : using multiple ultrasonic modules

Introduction to HC-SR04

HC-SR04: avoiding oversampling errors

We have seen in previous posts (here and here) that if the time between two measurements is too short then the sensor outputs a 0 to signal a measurement error. We call these kind of errors ‘oversampling’, i.e. sampling too frequently beyond the capacity of the sensor.

From data collected in this post, we have seen that a delay of 26ms is enough to solve the problem. This note tries to answer the following question:

        can we minimize this time?

The idea

We have conceived a bisection procedure which will try to determine the minimal delay to use in order to avoid oversampling. The idea is to start with delay D=26ms. Therefore the search interval will be

I₀=(a₀,b₀)=[0,D]

Then, if there are no oversampling errors, I_0 is halved and a new sample batch is run. If at some stage i oversampling errors are more than a certain threshold ε, we search in the interval

(a_i+1,b_i+1)=[b,(b-a_i)/2]   for i>1

otherwise we keep on halving the interval. The procedure is repeated until |a_i-b_i|=1ms.

At this point, a second procedure will search for the right number of us. According to Arduino specifications (see here), this second procedure is stopped if the length of the interval is less than 3us (i.e. |a_i-b_i|<=3us).

The program
The program which performs the experiment is given at the end of this post. Let us comment its parts. First of all, the constants

#define SAMPLESIZE 1000
#define NUMTESTS 5

are to indicate that we are going to perform 5 (NUMTESTS) batches and that each batch will consist of 1000 (SAMPLESIZE) tests. A test fails if the percentage of errors (zeroes) which are measured in a batch is greater than a TOLERANCE. Here the tolerance is fixed at 1% (see below).

#define TOLERANCE .01

Finally the following two constants define the initial length of the search interval for milliseconds and for microseconds.

#define INITDELAYMS 26
#define INITDELAYUS 1000

As we have already said, the value for INITDELAYMS is fixed to 26ms because of previous experiences. INITDELAYUS is naturally fixed to 1000us since it is the amount of micros in a millisecond.
The following portion of code is taken directly for here and just performs one read of the sensor. Remark that echo pin is connected to Arduino pin 2 and trigger pin is connected to Arduino pin 4.

HC-SR04: what is the distribution law for the frequencies of values? (Part 2)

Recalling the conclusions of our last experiment with the HC-SR04 (you can find it here), we shall repeat the sampling batch leaving enough time to the HC-SR04 so to avoid errors given by oversampling. Recalling the computations made here, we know that maximal time for a round trip is 25000us, that is to say 25 milliseconds. We can overestimate to 26 millis to be absolutely sure.

Therefore we modify the setup function in our former program as follows:

void setup() {
  
  uint16_t i;
  
  // Open serial communications and wait for port to open:
  Serial.begin(9600);
  // wait for serial port to connect. Needed for Leonardo only
  while (!Serial); 

  Serial.println("*******************************");
  
  for(i=1; i<SAMPLESIZE;i++) {
    delay(26);
    Serial.println(readoutSensor());
  }
  Serial.println("*******************************");

  Serial.println("Sample generation terminated.");
}

(Remark that here output is on the Serial Monitor and no more on the SD card.)

HC-SR04: what is the distribution law for the frequencies of values? (Part 1)

In this small note we are going to study the distribution of the values returned by our preferred ultraso-nic sensor, namely, the HC-SR04. We suspect that it is a normal distribution. As suggested in [1, pag. 18 and ff], we use the following steps to verify this hypothesis:

1) generate sample data
2) compute the mean and standard deviation of sampled data
3) compute the kurtosis and skewness
4) compute standard error of kurtosis and skewness
5) compute the z-score for kurtosis and skewness
6) compare the above values with the corresponding ones of the normal distribution

Generate the sample data

The first operation is to obtain a large enough sample data. The idea to fix the obstacle at 1 meter from the sensor and then take ten thousand measurements (this is hopefully large enough). Since one cannot open files directly on a PC using Arduino, we are going to user the card reader (see THIS post) and store data on the SD card. The following short program will do the job.

PIR sensor - Motion sensor

Yet another sensor! This time it's a PIR (Passive InfraRed) sensor: it reacts to infrared light emitted by warm objects or beings. It is called passive since it does not emit anything, just signals whenever it sense a variation of infrared light in its range.

Technical data (from the seller):

Range: 3m - 7m

Angle: 140° (approx.)

Trigger state duration: 3s - 200s

Power supply: 4.5V - 15V DC current

Output signal: 3V (alarm status), 0V (normal state)

Power consumption: <60uA (normal state)

Working temperature: [-15°C,+70°C]

Trigger mode: repeated sensing/non-repeated sensing

HC-SR04 : using multiple ultrasonic modules

In this note we are going to illustrate how three (or more) HC-SR04 modules can be used to add further "intelligent" vision to your bots. Basic usage of HC-SR04 and the principles on which it is based have already be given in this note.

The idea is to position the three sensors at fixed angles one another. Each module will give its own measure. Then, we use the three measures to try to induce some "safe/unsafe" state for our bot. In a safe state you can, for example, keep running forward. In an unsafe state, you can turn left or right according to the informations of the two other sensors. Indeed, consider the situation illustrated in Figure 1.

Figure 1. The general situation.

HC-SR04: ultrasonic sensor for Arduino

This week I will present one of the main ingredients of robotic constructions: ultrasonic sensors.

The physics

The sensor is based on a simple principle, sound echo phenomenon. A membrane emits an ultrasonic sound and a second membrane will catch the echo signal reflected by the obstacle.

Temperature & umidity sensor (DHT11)

According to LadyAda this is an extremely low-cost temperature and humidity sensor. Bah, for me 6 Euros are not nothing. Probably, other more sophisticated sensors are much more expensive… or they simply robbed me :-( 

From the data sheet I found that the pin out is as follows (from left to right w.r.t. the photo above):

1- Vcc (3.3V to 5.5V)

2- Data signal

3- Not connected (some people advice to connect it to GND)

4- GND