Hardware Reference
In-Depth Information
The Arduino program waits till the last sensor is received before writing the data to the SD card as a single buffer
line. The simple packet-correction method sometimes drops data instead of trying figure out what packets might be
missing. The amount of lost data needs to be determined; as a function of the requirements of some projects, it may
be more critical that all the data is received.
Listing 8-3 is divided into eight parts. Part 1 sets up most of the variables and libraries needed. Both SD.h and
AndroidAccessory.h are used to create the connection to the corresponding SPI devices. Input and output buffers are
set for both the serial XBee connection and the SD card read and write. The reply packet that signifies that a packet
was not received properly is set as a static byte array, as this packet will be the standard reply for malformed packets.
The “BAD” packet is not required to be generated every time it needs to be sent, unlike the “OK” reply packet, which is
generated dynamically every time. The SD card output buffer has a set amount of preformatting.
The data contained in the log file is essentially a four-byte string for each sensor: it contains the sensor name,
the location of the data in the array of the openFrameworks program, and the actual sensor data. The sensor data is
separated by a colon, and a double-colon separates each sensor. The data lines are ended with a carnage return and
linefeed character. Each of the remote sensors are designated as S1 through S3, and a local sensor location called L1
has been left in the array to allow for an optimal local sensor attached to the Mega ADK to be processed. A series of
Boolean flags are declared for program flow control: one flag contains a blink state to blink the LED and two flags are
for ADK connection status.
The last object created is the AndroidAccessory object and uses the same declaration as we used in Chapter 4.
As long as the default program has not been set on the Android device, programs associated with a particular
accessory name and ID will be given as an autorun option when connected. Using the same accessory lets you avoid
an unnecessary upload when starting to integrate the Android device into the sensor network, by allowing the ADK
monitor to easily be used as an option for debugging.
Listing 8-3. Data Logger and ADK Handler, Part 1 of 8
#include <SD.h> // must be included before AndroidAccessory.h
#include <AndroidAccessory.h>
static byte badPacket[21] = {0x7E ,0x00 ,0x11 ,0x10 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,0x00 ,
0x00 ,0xFF ,0xFF ,0xFF ,0xFE ,0x00 ,0x00 ,0x42 ,0x41 ,0x44 ,0x2D };
byte OutPacketBuffer[80];
byte incomingBuffer[80];
int incomingByteLen;
byte incomingPacketChecksum;
byte sourceADR[10]; // source addresses holding
byte incomeData [64]; // phrased data holder
int dataLength; // length of data received
byte SDinBuffer[34]; // SD buffer is 34 bytes to capture a whole data line
byte SDoutBuffer[34] =
// pre-format used to contain the data to log
{'S','1',':',0xFF,':',0xFF,':',':',
'S','2',':',0xFF,':',0xFF,':',':',
'S','3',':',0xFF,':',0xFF,':',':',
'L','1',':',0xFF,':',0xFF,':',':', 0x0A,0x0D};
int ERRcount = 0;
int IcomingTime = 0;
boolean Blink = LOW; // blink state holder
bool lastReply = false; // false bad, true good
boolean ADKisConnected = false; // so the rest of the code does not have to pull the USB
boolean LogFileSyncADK = false;
File LogFile;
 
Search WWH ::




Custom Search