reference:
{Description of pulseIn()
Reads a pulse (either HIGH or LOW) on a pin. For example, if value is HIGH, pulseIn() waits for the pin to go HIGH, starts timing, then waits for the pin to go LOW and stops timing. Returns the length of the pulse in microseconds. Gives up and returns 0 if no pulse starts within a specified time out.
The timing of this function has been determined empirically and will probably show errors in longer pulses. Works on pulses from 10 microseconds to 3 minutes in length. } end description
Does this code handle the case when pulse X in one axis and pulse Y in another, overlap. That is, does the code pulseX = pulseIn(xPin,HIGH);
pause the CPU until xPin goes HIGH ? Or is the CPU still waiting for xPin to go HIGH while it simultaneously begins to execute the next line re pulseY ? If yes then what happens when the CPU returns thru the loop and tries to execute the same two lines of code that are already still waiting ?
/*
Memsic2125
Read the Memsic 2125 two-axis accelerometer. Converts the
pulses output by the 2125 into milli-g's (1/1000 of earth's
gravity) and prints them over the serial connection to the
computer.
The circuit:
* X output of accelerometer to digital pin 2
* Y output of accelerometer to digital pin 3
* +V of accelerometer to +5V
* GND of accelerometer to ground
http://www.arduino.cc/en/Tutorial/Memsic2125
created 6 Nov 2008
by David A. Mellis
modified 30 Aug 2011
by Tom Igoe
This example code is in the public domain.
*/
// these constants won't change:
const int xPin = 2; // X output of the accelerometer
const int yPin = 3; // Y output of the accelerometer
void setup() {
// initialize serial communications:
Serial.begin(9600);
// initialize the pins connected to the accelerometer
// as inputs:
pinMode(xPin, INPUT);
pinMode(yPin, INPUT);
}
void loop() {
// variables to read the pulse widths:
int pulseX, pulseY;
// variables to contain the resulting accelerations
int accelerationX, accelerationY;
// read pulse from x- and y-axes:
pulseX = pulseIn(xPin,HIGH);
pulseY = pulseIn(yPin,HIGH);
// convert the pulse width into acceleration
// accelerationX and accelerationY are in milli-g's:
// earth's gravity is 1000 milli-g's, or 1g.
accelerationX = ((pulseX / 10) - 500) * 8;
accelerationY = ((pulseY / 10) - 500) * 8;
// print the acceleration
Serial.print(accelerationX);
// print a tab character:
Serial.print("\t");
Serial.print(accelerationY);
Serial.println();
delay(100);
}
Does that mean that the pulse in the y axis is ignored until the x has gone high ?
Then if the accelerometer only moved in the y axis, the output would be 0 since the CPU is waiting for the x axis high.
I am trying to record the tremor of a human being. Put the instrument on the index finger. We do not know the sequence of planes the finger will move in. Likely every motion will be in multiple planes. How much data are we losing due to pulseIn blocking ? Maybe little since the likelihood of a pure x or y axis motion is low.
jad1715,
The duty cycle on that chip is about 100 milliseconds. Since you only need to measure the HIGH state, you have a worst-case blocking time of just under 100 ms. That time would represent about a 3 G acceleration. I wonder what the G force of a worst case finger tremor is. It might be worthwhile doing some testing to see whatthe worst-case tremor would produce, and what sort of time is involved. If it turns out to be, say, 5 to 40 milliseconds or so, perhaps it would be sufficient to read the pins sequentially.
The duty cycle on that chip is about 100 milliseconds.
Duty cycle would seem to me to be the wrong term (normally a ratio or percentage), but a 100 millisecond period would make it tough to achieve the claimed 100 Hz update rate.
The duty cycle on that chip is about 100 milliseconds.
Duty cycle would seem to me to be the wrong term (normally a ratio or percentage), but a 100 millisecond period would make it tough to achieve the claimed 100 Hz update rate.
Yes, the total period is 100 ms, and the nominal at-rest HIGH is 5000 microseconds. The update rate is 10 Hz, not 100 Hz.
That being said, I realize now that, since we do not determine the start of the HIGH pulse in our code, but that it free runs from the sensor, the latency would likely average somewhere near 50 ms, and interrupts are probably the best way to proceed.
Yes, the total period is 100 ms, and the nominal at-rest HIGH is 5000 microseconds.
Have you confused your "mu"s (micros) with your "m"s (millis)?
Welll I didn't. The article I read did. Of course, I should have known, because the 5000 usec nominal at-rest pulse logically shoulle be half the total cycle time in order to get an equal swing on each side on it. I found a better source of info.
So, to correct it all... the total cycle time is 10 ms, and the nominal centre at-rest is 5 ms. (more if it's ariented to sense normal gravity).