Geo Data Logger: Arduino+GPS+SD+Accelerometer to log, time-stamp, and geo-tag sensor data
UPDATES
INTRODUCTION I thought it would be educational to build a prototype that I can take on the road to log, geo-tag, and time-stamp sensor data to be analyzed later with mapping and/or data analysis applications. So I figured why not start with a gadget that can log road conditions. This prototype, the Bump-O-Meter, measures road conditions by using an Arduino, a GPS receiver, an SD card, and an accelerometer sensor. This prototype is a generic sensor logging/geo-tagging gadget which means the accelerometer can be replaced with any other sensor(s) to log and map anything anywhere. As a matter or fact my next adventure with this logger is to replace the accelerometer with a pollution sensor to visualize levels of air quality around town. PROJECT SECTIONS This guide is divided into the following sections:
PROJECT OVERVIEW The Bump-O-Meter uses an Arduino to capture the X,Y,Z motion data generated by the ADXL335 accelerometer. In this case, we are measuring road "shakiness" as a result of road condition. Poor road conditions and uneven road surfaces generate lots of sudden acceleration in the car body up and down (z-axis). But before this data is saved to the SD card, it's tagged with location information from the LS20031 GPS receiver and also date/time stamped in real-time using the GPS satellites' atomic clock. More on this later. We want to capture and analyze the z-axis acceleration information visually to determine which road stretches are poorer and need attention. We can repeat this and compare our data over time. The possibilities are endless. Not just for road condition scanning, but for any sort of environmental geo data logging. HOW TO USE We can use this gadget by placing it in a car and driving over a given road stretch to assess its condition. We can even attach this prototype to a bike or skateboard to identify irregular and rough stretches of tracks. We can substitute the ADXL335 accelerometer sensor with any other sensor(s) such as temperature or pollution sensors with simple code modification. The data on the SD card can then be imported it into a spreadsheet for scrubbing, sub-setting, reformatting, analysis, and visualizing. We will also make use of a wonderful website GPSvisualizer.com to plot our data over a map using intelligent markers that change shape and color according to magnitude of road shakiness so we can visually detect road conditions in need of further inspection. I have published a guide titled "Connect your LS20031 GPS receiver to Google Earth via PC" explaining how to configure the LS20031 GPS receiver. You can refer to it for more details on how to use the LS20031 GPS receiver. HARDWARE & SOFTWARE COMPONENTS HARDWARE
* I have not tried this prototype with the Arduino Leonardo because of some known issues with the SD library . But according to the release notes of the Arduino IDE 1.02 software these issues have been addressed. ** In the future, I am phasing out the SN74AHC125 level-shifter (5V to 3.3V converter) in favor of the CD4050BE HEX Non-Inverting Buffer/Converter simply because it's more readily and cheaply available on Ebay.com. I purchased 10 ICs for $4.0. That's $0.4 per IC. The CD4050 is not pin compatible with the SN74AHC125 but there are plenty of examples on the net. SOFTWARE
DISCLAIMER
This is a prototype and prototypes by definition are drafts of products not finished yet. Your feedback is appreciated. CONTACT Hazim Bitar (techbitar) techbitar at gmail dot com WIRING THE GEO-LOGGER
WIRING THE ARDUINO
GND GND rail of the breadboard (usually the blue row) 5V To 5V VIN of the SD card 3.3V To the positive rail (red-lined row) of the breadboard PIN13 PIN5 (2A) of the SN74AHC125 IC PIN12 SD MISO PIN PIN11 PIN2 (1A) of the SN74AHC125 IC PIN8 LED POSITIVE PIN4 PIN12 (4A) of the SN74AHC125 IC PIN1(TX) PIN9 (3A) of the SN74AHC125 IC PIN0(RX) PIN TX of the LS20031 GPS Receiver ANALOG0 PIN X of the ADXL335 (or any analog sensor output) ANALOG1 PIN Y of the ADXL335 (or any analog sensor output) ANALOG2 PIN Z of the ADXL335 (or any analog sensor output) GND (bottom) GND rail bottom of the breadboard WIRING THE SN74AHC125 IC PIN1 (10E) GND rail of breadboard PIN2 (1A) Arduino PIN11 PIN3 (1Y) SD MOSI PIN PIN4 (20E) GND rail of breadboard PIN5 (2A) Arduino PIN13 PIN6 (2Y) SD SCK PIN PIN7 GND GND rail of breadboard PIN9 (3A) Arduino TX PIN1 PIN8 (3Y) GPS RX PIN PIN10 (30E) GND rail of breadboard PIN12 (4A) Arduino PIN4 PIN11 (4Y) SD CS PIN PIN13 (40E) GND rail of breadboard PIN14 (VCC) Arduino 3.3V pin WIRING THE SD CARD SOCKET GND GND rail of breadboard 3.3V No connection 5V Arduino 5V pin CS PIN11 (4Y) of the SN74AHC125 IC MOSI PIN3 (1Y) of the SN74AHC125 IC SCK PIN6 (2Y) of the SN74AHC125 IC MISO Arduino PIN12 GND GND rail of breadboard WIRING THE LS20031 GPS RECEIVER GND GND rail of breadboard GND GND rail of breadboard TX Arduino PIN0 (RX) RX PIN8 (3Y) of the SN74AHC125 IC VCC 3.3V rail of the breadboard WIRING THE ADXL335 ACCELEROMETER GND GND rail of breadboard Z Arduino ANALOG2 Y Arduino ANALOG1 X Arduino ANALOG0 3.3V 3.3V rail of breadboard ST No connection. LOGGING TO THE SD CARD
The SD card, or Secure Digital card, is a non-volatile solid-state flash memory. Meaning if we disconnect power, it will retain its data. With an SD card we can expand Arduino's permanent storage by gigabytes. This is useful for applications that store large amounts of data such as data loggers. A 4GB SD card can be had for only $5. POWERING THE SD CARD The LC STUDIO SD card socket used in this project can be powered with 5V or 3.3V power sources. There is an LM1117 3.3V regulator on board which can handle 800mA of current. The Arduino can provide 3.3V directly but it's limited to 50mA. That's not enough to power the SD card. So I powered the SD card socket from the Arduino Uno's 5V pin which can handle over 500mA of current. The 5V pin on the SD card socket will pass through the LM1117 regulator and come out a 3.3V with a current ceiling of 800mAh. Just because this SD card socket can be powered with 5V or 3.3V, we still can't connect 5V Arduino pins to the SD card socket's pins. We have to level-shift the Arduino's 5V signals to 3.3V before we can connect them to the SD card. This is where the SN74AHC125 IC comes in handy. This IC can convert (level-shift) a total of 4 signals from 5V to 3.3V. This is perfect because for this project, I only need to convert 4 Arduino pins from 5V to 3.3V: three to the SD card socket and one to the LGS20031 GPS receiver which is also a 3.3V module. ALTERNATIVES TO THE SN74AHC125 You can replace the SN74AHC125 with the more available CD4050. I recently bought 10 of those from Ebay for about $0.40 a piece. The CD4050 is not pin compatible with the SN74AHC125 but it's easy to use. You will find many useful wiring examples for the CD4050 on the web. THE ARDUINO SD LIBRARY The Arduino IDE comes bundled with an SD library that's easy to use. You can include the SD library in your Arduino program by selecting from the main menu:Sketch\Import Library\SD The library also comes with ready to use example programs to get you up and running. You can open those example programs from main menu:File\Examples\SD then pick any of the 6 example sketches. If you have the SD card socket connected and an SD card inserted, those examples will work on the spot. For this prototype, I am using an old XTREME MiniSD 1GB SD1 card with a standard SD adapter simply because I have one available. I did not run into any performance issues with this class and model. Most memory cards sold today are the faster SDHC variety. SD CARD I/O STATUS LED Since the SD card socket has no LED indicators, I have added a status LED wired to Arduino PIN8, via a 1K Ohms resistor in series. This LED stays on so long as the SD card is working properly. I wrote the Arduino code so that when a write or read of the SD card fails, the LED is turned off. This way we can just look at the prototype and tell if something is wrong, along with other Arduino and GPS receiver LED indicators. FORMATTING THE SD CARD Using my Windows 7 computer I fully formatted the SD card as FAT16 once. Then, I quick format the SD card after every trial just to be on the safe side. 
LS20031 GPS RECEIVER SPECIFICATIONS
I am using the LS20031 GPS receiver in this prototype to tag logged data with both geographic location and date/time stamp. The LS20031 is a bread and butter GPS receiver. It's very simple to operate. This receiver is made by LOCOSYS Technology. I have attached the LS20031 datasheet to this section for those interested in more detailed specifications.
GPS RECEIVERS & NMEA SENTENCES When the GPS receiver is powered up, it will start transmitting information via it serial (TX) pin in the form of standardized comma-delimited text lines. These standardized text messages are called NMEA sentences containing latitude, longitude, date/time, among other useful data. NMEA stands for National Marine Electronics Association. This is the industry body that comes up with standardized message formats for GPS receivers to simplify using this technology. NMEA sentences start with GP + a three-letter identifier that tells us what sort of data is contained in this NMEA sentence being transmitted by the GPS receiver. The LS20031 sends out the following NMEA sentences.
$GPRMC,053740.000,A,2503.6319,N,12136.0099,E,2.69,79.65,100106,,,A*53
POWERING AND WIRING THE LS20031 I mentioned earlier that I had published a guide to help configure the LS20031 GPS receiver. The LS20031 is a 3.3V module which means it's powered by a 3.3V source. This also means we cannot connect the Arduino output pins, such as the TX pin (5V), to the LS20031 RX pin (3.3V) without converting from 5V to 3.3V. In this prototype, I use the SN74AHC125 as level-shifter from 5V to 3.3V. We should be able to take the LS20031 GPS serial output pin, the TX pin (3.3V), and wire it directly to the Arduino's serial RX receive PIN1 (5V). The Arduino's 5V pins can handle a 3.3V signal and will treat it as a logical high. CONFIGURING THE LS20031 For this prototype I used MiniGPS 1.4 to configure the LS20031 GPS receiver as follow:
See the LS2003x GPS Datasheet for more info. 
FEELING THE ROAD: THE ADXL335 ACCELEROMETEThe ADXL335 is a 3-axis analog acceleration measurement sensor. That's a mouthful. Basically, this gizmo can detect speed of movement, also known as g-force, in three directions: up/down (z), forward/backward (x), and sideways (y). The axis directions change depending on how we position the sensor IC.
The ADXL335 has a measurement range of ±3 g minimum for each axis. When you are standing still, the earth exerts a gravitation force of 1g. This sensor outputs signals in the form of voltage changes ranging from 0 to 3.3V. At zero gravity, the voltage value of the Z pin is right in the middle between 0V and 3.3V = 1.65V. The accelerometer can measure the static acceleration of gravity (1g) as well as tilt-sensing applications and also dynamic acceleration resulting from motion, shock, or vibration. Which axis of the ADXL335 reports 1g is dependent on how you position the chip. THE ADXL335 GOES MOBILE I drive a Toyota Yaris, a good car as far as reliability and fuel economy but not known for its luxury suspension system. This is perfect for my purposes. A high-end suspension system may dampen road bumpiness possibly generating weaker and inconclusive ADXL335 sensor readings. POWERING THE ADXL335 This particular ADXL335 breakout board must be powered by a 3.3V source. It's also configured to provide updates 50 times per second. That's plenty of resolution for our road condition sensing device. Since the Arduino Uno can handle reading 3.3V signals without conversion, we can wire the ADXL335's X,Y,Z outputs pins (3.3V) to Arduino Uno's analog input pins (5V) directly. See the ADXL335 datasheet for more info.
THE ARDUINO PROGRAM THAT PULLS IT ALL TOGETHER
This program reads the LS20031 GPS receiver and saves the NMEA sentences generated by the receiver as-is to the SD card. The program also reads the X, Y, Z pins of the ADXL335 accelerometer and saves them with each NMEA line saved.
The Arduino program I developed for this prototype uses the SD library. I am not using TinyGPS to interact with the GPS receiver or SoftwareSerial. I did not need TinyGPS for this project since I am saving raw NMEA messages to the SD card. As for the SoftwareSerial library, after I ran into a few issues which were time consuming to resolve I decided to stick to the default Arduino serial library. The downside of not using SoftwareSerial in this project is that the GPS Receiver will be using the Arduino's RX/TX pins to read configuration commands and to send GPS data to the Arduino. This means we don't have the Arduino Serial Monitor available for debugging. More importantly, we will have to disconnect the Arduino Uno's PIN0 (RX) from the GPS receiver's TX pin before uploading an Arduino program. If we don't disconnect Arduino's PIN0 (RX) from the GPS receiver, it will most likely fail to upload the Arduino program from the PC to the Arduino because of serial conflict. I found this to be a small price for the gains in coding compactness and shortened development cycle. The data saved by this program to the SD will look like the list below. Theoretically, five lines of GPS and sensor data will be generated per second. This log can be imported as a comma-delimited file into a host of applications such as spreadsheets or databases for scrubbing, analysis, and charting:
HOW TO ADD/REMOVE SENSORS TO THE GEO DATA LOGGER This program will read up to 6 analog sensors and save their values to the SD card. There are two places in the program where you need to make changes to suit your needs: 1. DECLARING SENSOR VARIABLES In the declaration section, we create text variables that will hold the converted numeric values of the sensors before we write them to the SD card. Here, we are declaring for a maximum of 6 analog sensors. Reduce as needed. char an0[4], an1[4], an2[4]; an3[4]; an4[4]; an5[4]; 2. READING SENSORS In this part of the program, we convert the numeric sensor readings to text before we write them to the SD card. Change the next code segment in the program to add/remove sensors as needed. You can have up to 6 analog sensors read in this program: itoa (analogRead(A0), an0, 10); itoa (analogRead(A1), an1, 10); itoa (analogRead(A2), an2, 10); itoa (analogRead(A3), an0, 10); itoa (analogRead(A4), an1, 10); itoa (analogRead(A5), an2, 10); 3. WRITING SENSORS VALUES TO THE SD CARD After we read the sensor(s) above, we write their text values to the SD card. In the code segment below, we are adding a comma between each sensor value written to the SD card so we can separate them. This makes it easier to import them into a spreadsheet program as comma-delimited text: GPSlog.print(an0); // write ANALOG0 to SD card GPSlog.print(" , "); GPSlog.print(an1); // write ANALOG1 to SD card GPSlog.print(" , "); GPSlog.print(an2); // write ANALOG2 to SD card GPSlog.print(" , "); GPSlog.print(an0); // write ANALOG3 to SD card GPSlog.print(" , "); GPSlog.print(an1); // write ANALOG4 to SD card GPSlog.print(" , "); GPSlog.print(an2); // write ANALOG5 to SD card GPSlog.print(" , "); Code Editor
A PLAIN GPS LOGGER TO INTERFACE WITH GOOGLE EARTH
For those who want to use this prototype as a generic GPS logger, to track your path, just upload the Arduino code below. This program will generate raw NMEA RMC sentences to file GPS.LOG on the SD card without any sensor data.
We can then Import the GPS.LOG file into Google Earth and generate maps overlaid with your logged track points. Please refer to my LS20031 GPS tutorial on how to import a raw GPS NMEA log files into Google Earth. You can also import this NMEA log file into Excel as a comma-delimited text file and reformat it for GPSvisualizer.com to draw maps with track points and more. More on this in the next sections. Code Editor
SCRUBBING & FORMATTING DATA WITH A SPREADSHEETWith enough road data captured on the SD card, we now start the data scrubbing and re-formatting in preparation for analysis and visualization in Excel, GPSvisualizer, or our favorite data analysis and charting tool.
Remove the SD card from the socket and insert into PC SD card reader. Copy the GPS.log file to your PC and Run Excel (or your favorite spreadsheet application). The steps below are for Excel 2007
PLOTTING AND COLOR-CODING ROAD CONDITION DATA WITH GPSVISUALIZER.COMFirst, let's open GPSvisualizer and open the "Plot data points" page: http://www.gpsvisualizer.com/map_input?form=data
STEP 1: Find the scroll box titled "Or paste your data here" and delete everything in it then paste the data you have copied from Excel into it. You should get a clean three column content with the headers N Latitude Longitude. Make sure you don't change the headers in any way after you paste them and don't add commas or tabs in between. Just a straight paste from Excel. STEP 2: You can skip this step for now or you can make changes to "Data point options" to follow my settings as shown in the figure. STEP 3: Click "Draw the map" button and watch the magic. HOW TO READ THE MAP A Google Map will be displayed and overlaid with the route points captured by our geo data logger. In my case, I have selected stars as the icons for the data points. The larger and more blueish the data point or the smaller the more reddish the bigger the road bump or pothole. By clicking on a star, a balloon will pop up with the z-axis value read by the ADXL335 accelerometer. Long road stretches of comparable greenish colors and values (typically 520 in my case) mean the road is smoother. We can change the icon shapes, their minimum and maximum sizes, and other parameters from the "Data point options" section. TRANSLATING SENSOR DATA INTO ROAD CONDITION INFO I have simplified this part so almost no math will be needed to assess road conditions using the data generated by the ADXL335 sensor. So there will be no translation from raw accelerometer sensor outputs to g values. The whole trick wrests in road condition profiling and sensor data comparison. PROFILING ROAD DATA Different geo data loggers may produce different readings than mine for various reasons having to do with sensor type if a different accelerometer is used, suspension system differences from one car to another, orientation of the geo data logger, etc. So we need to profile normal road conditions and abnormal road condition before we can make sense of our data using your geo data logger in your particular environment. Profiling road conditions is simple. We record senor data generated by the ADXL335 sensor while we drive over a good road stretch then do the same with sensor data generated when we drive over a rough road stretch such a bump or pothole. In my case, I get an average of 520 for the z-axis on a good road stretch. I can use this as a frame of reference so if I get sample data of 520 plus or minus a few notches (you decide what's the acceptable range) then this is a good road. So 520 +/- some value of your choosing is the profile of a good road condition. But if I drive over a bump or pothole, I get sensor z-axis readings that hover around 500 on the low end and 535 on the high end. This will be my profile of a rough road. The basic assumption here is that I am using the same car, with the sensor placed in the same spot in the car, and driving at the same speed every time I profile the road with my geo data logger. In the "Data point options" by assigning the "Min" color field my my lower z-axis number and "Max" field my high z-axis number, now I can use GPSvisualizer.com to determine visually, by color or size of marker, where to find poor road stretches, potholes, and bumps. ANALYZING SENSOR DATA AND ROAD CONDITIONS When it comes to analyzing the sensor data, sometimes bumps my look like potholes and vice versa. It's possible to log what seems like a pothole condition when in reality we are just dropping back to normal street level right after a road bump. It's also possible to get a sensor reading the resembles that of a bump when the car starts climbing out of the pothole. We look for small or large z-axis readings, based on the min/max values withing the range of captured data, to identify abnormal road conditions. But classifying these road conditions might require more analysis. We can always play around with GPSvisualizer settings until we get the visual representation we need. The important thing is to record presence of a road condition in need of attention or to avoid it next time you are on the same road. FORMATTING GPS DATE/TIME OUTPUT FOR STAMPING DATASince time-stamping logged data is important for many projects, I will explain how to extract and format the GPS generated time/date data.
In this project, we hid all data columns in Excel except columns containing z-axis data, latitude, and longitude. If we wish to keep a date/time stamp to map and visualize along with the rest of the retained sensor and GPS data columns, we simply don't hide column E (time) and column M (date). The LS20031 GPS receiver, as with other GPS receivers of its class, updates its internal clock to sync with the GPS satellites' internal atomic clock which is accurate to 1 billionth of a second. The GPS receiver sends date/time stamped location fixes via a variety of NMEA text sentences. We have chosen the RMC NMEA message for this project. This is how an RMC sentence looks like. $GPRMC,093025.600,A,3157.8299,N,03551.5057,E,18.18,37.45,111112,,,A*6C The boldfaced number from the left end of the NMEA sentence is the UTC Time. It's interpreted according to this format string: hhmmss.sss. So 093025.600 can be displayed as: 09:30:25. The second boldfaced number from the left is the date. It's interpreted according to this format string:ddmmyy. So 111112 can be displayed as 11-November-2012 UTC Time (Zulu) is Coordinated Universal Time. You can calculate your local time as needed by adding or subtracting hours and minutes before or after UTC time. SPEED VS LOGGING ACCURACYNOTE: I have oversimplified the concepts in this section to keep this guide short and accessible. For those who are interested in a more detailed explanation, there are many helpful references on the web.
The accuracy and resolution of the geo data logger will depend on many facors such as:
So the bottleneck for our Bump-O-Meter will be the GPS receiver, at 5 updates per second (5Hz). Let's assume we are driving at 60 Km/h and the GPS is reporting 5 location fixes per second.
The key thing is to record a road bump or pothole even if we don't have its exact location. Because so long as we capture the bump's existence on our logger, we can find it if we go searching for it within +/- 2.5 meters (GPS accuracy) of the location reported by the logger. For smoother data such as the ones generated by outdoors temperature and humidity sensors, we can make use of fairly simple techniques for guessing in-between data, such as interpolation. INTERPOLATION OF MISSING DATA Interpolation is a method of guessing a mid data point within two recorded sensor data points. For examples, if we drive down the highway while logging temperatures, if our geo data logger is capturing temperature readings every 100 meters, it might be possible to interpolate (guess) the in-between temperature every 50 meters. The change in outdoors weather temperature within 100 meters is not typically abrupt but tend to be gradual. So if we log 32 degrees F at 0 meters and 33 degrees F at 100 meters. We can make a reasonable guess that at 50 meters or somewhere in between the temperature can be 32.5 degrees F. This is the simplified version of data interpolation. Some interpolation might be possible and meaningful between two logged temperature points over a certain distance. Interpolating road conditions, on the other hand, may not be as simple. Potholes and road bumps don't lend themselves to interpolation. Unlike the gradual change in many environmental conditions, potholes tend to be sudden. Potholes are not typically preceded by increasingly larger potholes. And they are not followed by increasingly smaller pot holes. For detecting pot holes, we have to drive slower to give our geo data logger time to catch those (<15 Km/h). Also, we can slow down when we see an approaching pothole or a road bump to make sure our geo data logger catches it. In real world situations, we tend to slow down anyway as we approach a bump or pothole so that works well for our purposes. Happy geo data logging, TechBitar |
Created Nov 18, 2012
| ||||
