Don’t forget the whole schematic. Here it is below.
In this design, I also saved some money by not using 2 Arduino because I only needed to read data (and I could have been able to send some too) using the XBee module on the computer side. In this case, the only XBee explorer interface was enough !
I saw too many projects like that using 2 boards (and even sometimes BIG boards). Please don’t use too many components if you don’t need them!
Continuing the firmware description, I created a function named setupAccelerometer() , this is only for a better vision of my code. I could have included the whole content of this function inside setup(). This function define and setup the whole ADXL345 behavior from the Arduino Fio’s firwmare point of view.
We define some threshold in order to track 5 events using one interrupt on the ADXL345 board:
- activity detection
- inactivity detection (which I defined as the lack of activity here)
- tap detection
- double tap detection
- freefall detection
Interrupt concept is quite well explain in my book. Basically, this is a way to interrupt the main flow of the global code and to trigger some action. These are very useful in our case. Why? One of the best way to understand what they are is the mouse case.
The mouse on our computer (or the trackpad in my case) uses interrupt. Why would our operating system check everytime a day if I touched the track pad ? It would loose time and wouldn’t be really available for anything else (actually, it would, but it would loose time, anyway). There is another architecture providing a way to handle what is done on the trackpad only when I’m using it. It is called interrupt. I touch it, then release it, the operating system is informed something happens and is able to handle this then continue what he was doing.
This is a briefly and a bit simple explanation of what an interrupt provide.
In loop(), which is the main part of our firmware and is running continuously at runtime, I first grab interrupt source and put his in interrupts byte type variable. There are then some conditional piece of code. In our case, if no event is detected amongst those 5 described above, the main part of our firmware run by looping quietly. If i let the accelerometer and the arduino Fio (and the battery) falling down, an interrupt is sent and the part of code testing the particular case ADXL345_FREE_FALL is suddenly verified. If I put something special inside this case, it will only be triggered if the device freely falls.
So, I currently only have some message written to the serial port, i.e to the XBee module. This latter pushes this message to the other XBee connected to the computer and my Max6’s patch is able to grab it :)
I used this code for testing purpose only.
You probably check this part of the code, all commented:
// measuring Accelerometer on 3-axis //int x,y,z; //adxl.readAccel(&x, &y, &z); //read accelerometer values store them in x,y,z //Serial.print(x); //Serial.print(y); //Serial.println(z);
If we uncomment the 4 last rows, at each loop() execution, we read each value of the acceleration measured by the ADC (Indeed, an Analog to Digital Converter samples values measured by the sensor component) and we store them in some variable as integer. Then we are writing them to the serial for sending them, in fine, to Max6’s patch.
This is done at each turn. Because I only wanted to track a fast movement, I decided to use only accelerometer values and put a small and cheap software filter also called debouncer. Next, let’s check how I handled that.