firebug-cvs Mailing List for FireBug: wireless wildfire monitoring (Page 17)
Brought to you by:
doolin
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(36) |
Jun
(45) |
Jul
(108) |
Aug
(31) |
Sep
(2) |
Oct
(4) |
Nov
(113) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(63) |
Feb
(37) |
Mar
(24) |
Apr
(6) |
May
(5) |
Jun
(5) |
Jul
(71) |
Aug
(42) |
Sep
(7) |
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(64) |
Jun
(71) |
Jul
(51) |
Aug
(89) |
Sep
(24) |
Oct
(1) |
Nov
(1) |
Dec
(2) |
2006 |
Jan
|
Feb
|
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
(21) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: David M. D. <do...@us...> - 2004-07-15 23:28:41
|
Update of /cvsroot/firebug/firebug/doc/chassis/figs In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv19599/figs Modified Files: Makefile Added Files: fdm_assembled.jpg fdm_back.jpg fdm_front.jpg Log Message: Added pictures of Alex's FDM chassis. --- NEW FILE: fdm_back.jpg --- (This appears to be a binary file; contents omitted.) --- NEW FILE: fdm_assembled.jpg --- (This appears to be a binary file; contents omitted.) Index: Makefile =================================================================== RCS file: /cvsroot/firebug/firebug/doc/chassis/figs/Makefile,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 *** Makefile 13 Jul 2004 12:54:02 -0000 1.1 --- Makefile 15 Jul 2004 23:28:31 -0000 1.2 *************** *** 7,11 **** EPSPLOTS = exploded_view_2.eps \ candy_bar_injection_moldable_front.eps \ ! candy_bar_injection_moldable_back.eps --- 7,14 ---- EPSPLOTS = exploded_view_2.eps \ candy_bar_injection_moldable_front.eps \ ! candy_bar_injection_moldable_back.eps \ ! fdm_back.eps \ ! fdm_front.eps \ ! fdm_assembled.eps --- NEW FILE: fdm_front.jpg --- (This appears to be a binary file; contents omitted.) |
From: David M. D. <do...@us...> - 2004-07-15 23:28:40
|
Update of /cvsroot/firebug/firebug/doc/chassis In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv19599 Modified Files: chassis.tex Log Message: Added pictures of Alex's FDM chassis. Index: chassis.tex =================================================================== RCS file: /cvsroot/firebug/firebug/doc/chassis/chassis.tex,v retrieving revision 1.9 retrieving revision 1.10 diff -C2 -d -r1.9 -r1.10 *** chassis.tex 13 Jul 2004 12:54:43 -0000 1.9 --- chassis.tex 15 Jul 2004 23:28:30 -0000 1.10 *************** *** 217,221 **** \subfigure[Back view.]{\label{subfig:candy_bar_injection_moldable_back}% \includegraphics[width=2.5in]{figs/candy_bar_injection_moldable_back.eps}} ! \caption{Injection mold design.} \label{fig:cbim} \end{center} --- 217,225 ---- \subfigure[Back view.]{\label{subfig:candy_bar_injection_moldable_back}% \includegraphics[width=2.5in]{figs/candy_bar_injection_moldable_back.eps}} ! \subfigure[FDM front view.]{\label{subfig:fdm_front}% ! \includegraphics[width=2.5in]{figs/fdm_front.eps}} ! \subfigure[FDM back view.]{\label{subfig:fdm_back}% ! \includegraphics[width=2.5in]{figs/fdm_back.eps}} ! \caption{Injection mold design, and prototype using FDM technology.} \label{fig:cbim} \end{center} *************** *** 225,228 **** --- 229,241 ---- Fig.~\ref{fig:cbim} was designed with the ??? software. + \begin{figure} + \begin{center} + \includegraphics[width=3in]{figs/fdm_assembled.eps} + \caption{Assembled mote using FDM prototype.} + \label{fig:fdm_assembled} + \end{center} + \end{figure} + + \section{Conclusions} |
From: David M. D. <do...@us...> - 2004-07-15 17:03:50
|
Update of /cvsroot/firebug/fireboard/tools/src/xlisten In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv9416 Added Files: Makefile test_timestamp.c timestamp.c timestamp.h xlisten.c xpacket.c xsensors.h xserial.c Log Message: Local copy of xbow xlisten code. --- NEW FILE: xpacket.c --- /** * Handles parsing of xsensor packets. * * @file xpacket.c * @author Martin Turon * @version 2004/3/10 mturon Initial version * * Copyright (c) 2004 Crossbow Technology, Inc. All rights reserved. * * $Id: xpacket.c,v 1.1 2004/07/15 17:03:39 doolin Exp $ */ #include "xsensors.h" static unsigned g_datastart = XPACKET_DATASTART; /** * Set the offset to the sensor data payload within the TOS packet. * * @param offset Start of sensor data packet * * @author Martin Turon * @version 2004/3/22 mturon Intial version */ void xpacket_set_start(unsigned offset) { g_datastart = offset; } /** * Converts escape sequences from a packetized TOSMsg to normal bytes. * * @author Martin Turon * @version 2004/4/07 mturon Intial version */ void xpacket_depacketize(unsigned char *tos_packet) { if (g_datastart > XPACKET_DATASTART) { int i = 0, o = 2; // index and offset while(i < XPACKET_SIZE) { // Handle escape characters if (tos_packet[o] == XPACKET_ESC) { tos_packet[i++] = tos_packet[++o] ^ 0x20; ++o; } else { tos_packet[i++] = tos_packet[o++]; } } } } /** * Returns a pointer into the packet to the data payload. * Also performs any required packetizer conversions if this * packet came from over the wireless via TOSBase. * * @author Martin Turon * @version 2004/4/07 mturon Intial version */ XbowSensorboardPacket *xpacket_get_sensor_data(unsigned char *tos_packet) { return (XbowSensorboardPacket *)(tos_packet + XPACKET_DATASTART); } /** * Display a raw packet. * * @param packet The TOS packet as raw bytes from the serial port * * @author Martin Turon * @version 2004/3/10 mturon Intial version */ void xpacket_print_raw(unsigned char *packet) { int i, cnt = XPACKET_SIZE; for (i=0; i<cnt; i++) { printf("%02x", packet[i]); } printf("\n"); } /** * Display a parsed packet as exportable data -- comma delimited text. * * @param packet The TOS packet as raw bytes from the serial port * * @author Martin Turon * @version 2004/3/12 mturon Intial version */ void xpacket_export_parsed(unsigned char *tos_packet) { int i; uint16_t *packet = (uint16_t *)xpacket_get_sensor_data(tos_packet); packet += 2; // Ignore sensorboard_id and packet_id for (i=0; i<8; i++) { if (i>0) printf(","); printf("%d",packet[i]); } printf("\n"); } /** * Display a parsed packet as raw ADC values for each sensor on the board. * * @param packet The TOS packet as raw bytes from the serial port * * @author Martin Turon * @version 2004/3/10 mturon Intial version */ void xpacket_print_parsed(unsigned char *tos_packet) { XbowSensorboardPacket *packet = xpacket_get_sensor_data(tos_packet); switch(packet->packet_id) { case XPACKET_TEXT_MSG: packet->reserved2 = '\0'; printf("msg from id=%d: %s\n", packet->node_id, packet->data); return; } switch(packet->sensorboard_id) { case XTYPE_MDA500: mda500_print_raw(packet); break; case XTYPE_MDA400: mda400_print_raw(packet); break; case XTYPE_MDA300: mda300_print_raw(packet); break; case XTYPE_MTS300: mts300_print_raw(packet); break; case XTYPE_MTS310: mts310_print_raw(packet); break; case XTYPE_MTS400: mts400_print_raw(packet); break; case XTYPE_MTS420: mts420_print_raw(packet); break; case XTYPE_MTS510: mts510_print_raw(packet); break; case XTYPE_MTS101: mts101_print_raw(packet); break; case XTYPE_MEP500: mep500_print_raw(packet); break; case XTYPE_MEP401: mep401_print_raw(packet); break; /* More sensor boards go here... */ } } /** * Display a packet as cooked values in engineering units. * * @param packet The TOS packet as raw bytes from the serial port * * @author Martin Turon * @version 2004/3/11 mturon Intial version */ void xpacket_print_cooked(unsigned char *tos_packet) { XbowSensorboardPacket *packet = xpacket_get_sensor_data(tos_packet); switch(packet->packet_id) { case XPACKET_TEXT_MSG: packet->reserved2 = '\0'; printf("MSG from id=%d: %s\n\n", packet->node_id, packet->data); return; } switch(packet->sensorboard_id) { case XTYPE_MDA500: mda500_print_cooked(packet); break; case XTYPE_MDA400: mda400_print_cooked(packet); break; case XTYPE_MDA300: mda300_print_cooked(packet); break; case XTYPE_MTS300: mts300_print_cooked(packet); break; case XTYPE_MTS310: mts310_print_cooked(packet); break; case XTYPE_MTS400: mts400_print_cooked(packet); break; case XTYPE_MTS420: mts420_print_cooked(packet); break; case XTYPE_MTS510: mts510_print_cooked(packet); break; case XTYPE_MTS101: mts101_print_cooked(packet); break; case XTYPE_MEP500: mep500_print_cooked(packet); break; case XTYPE_MEP401: mep401_print_cooked(packet); break; /* More sensor boards go here... */ } } --- NEW FILE: xsensors.h --- /** * Global definitions for Crossbow sensor boards. * * @file xsensors.h * @author Martin Turon * @version 2004/3/10 mturon Initial version * * Copyright (c) 2004 Crossbow Technology, Inc. All rights reserved. * * $Id: xsensors.h,v 1.1 2004/07/15 17:03:39 doolin Exp $ */ #ifndef __XSENSORS_H__ #define __XSENSORS_H__ #include <stdio.h> /** * A unique identifier for each Crossbow sensorboard. * * Note: The sensorboard id is organized to allow for identification of * host mote as well: * * if (sensorboard_id < 0x80) // mote is a mica2dot * if (sensorboard_id > 0x7E) // mote is a mica2 * * @version 2004/3/10 mturon Initial version */ typedef enum { // mica2dot sensorboards XTYPE_MDA500 = 0x01, XTYPE_MTS510, XTYPE_MEP500, // mica2 sensorboards XTYPE_MDA400 = 0x80, XTYPE_MDA300, XTYPE_MTS101, XTYPE_MTS300, XTYPE_MTS310, XTYPE_MTS400, XTYPE_MTS420, XTYPE_MEP401, } XbowSensorboardType; /** * Reserves general packet types that xlisten handles for all sensorboards. * * @version 2004/4/2 mturon Initial version */ typedef enum { // reserved packet ids XPACKET_ESC = 0x7D, //!< Reserved for serial packetizer escape code. XPACKET_START = 0x7E, //!< Reserved for serial packetizer start code. XPACKET_TEXT_MSG = 0xF8, //!< Special id for sending text error messages. } XbowGeneralPacketType; /** Encodes sensor readings into the data payload of a TOS message. */ typedef struct { uint8_t sensorboard_id; uint8_t packet_id; uint8_t node_id; uint8_t reserved; uint16_t data[12]; uint8_t reserved2; } XbowSensorboardPacket; #define XPACKET_SIZE 36 #define XPACKET_GROUP 3 //!< offset to group id of TOS packet #define XPACKET_LENGTH 4 //!< offset to length of TOS packet #define XPACKET_DATASTART 5 //!< UART offset to data payload #define XPACKET_DATASTART_WIRELESS 7 //!< Wireless offset to data payload /* Sensorboard data packet definitions */ void xpacket_print_raw (unsigned char *tos_packet); void xpacket_print_parsed (unsigned char *tos_packet); void xpacket_print_cooked (unsigned char *tos_packet); void xpacket_export_parsed (unsigned char *tos_packet); void xpacket_depacketize (unsigned char *tos_packet); void xpacket_set_start (unsigned offset); /* Serial port routines. */ int xserial_port_open (); int xserial_port_dump (); int xserial_port_sync_packet (int serline); int xserial_port_read_packet (int serline, unsigned char *buffer, int cnt); unsigned xserial_set_baudrate (unsigned baudrate); unsigned xserial_set_baud (const char *baud); void xserial_set_device (const char *device); void xserial_set_verbose (int verbose); /* Sensorboard specific conversion routines. */ /* From boards/mda500.c */ void mda500_print_raw (XbowSensorboardPacket *packet); void mda500_print_cooked (XbowSensorboardPacket *packet); void mda400_print_raw (XbowSensorboardPacket *packet); void mda400_print_cooked (XbowSensorboardPacket *packet); /* From boards/mda300.c */ void mda300_print_raw (XbowSensorboardPacket *packet); void mda300_print_cooked (XbowSensorboardPacket *packet); /* From boards/mts300.c */ void mts300_print_raw (XbowSensorboardPacket *packet); void mts300_print_cooked (XbowSensorboardPacket *packet); void mts310_print_raw (XbowSensorboardPacket *packet); void mts310_print_cooked (XbowSensorboardPacket *packet); /* From boards/mts400.c */ void mts400_print_raw (XbowSensorboardPacket *packet); void mts400_print_cooked (XbowSensorboardPacket *packet); void mts420_print_raw (XbowSensorboardPacket *packet); void mts420_print_cooked (XbowSensorboardPacket *packet); /* From boards/mts510.c */ void mts510_print_raw (XbowSensorboardPacket *packet); void mts510_print_cooked (XbowSensorboardPacket *packet); /* From boards/mts101.c */ void mts101_print_raw (XbowSensorboardPacket *packet); void mts101_print_cooked (XbowSensorboardPacket *packet); /* From boards/mep500.c */ void mep500_print_raw (XbowSensorboardPacket *packet); void mep500_print_cooked (XbowSensorboardPacket *packet); /* From boards/mep401.c */ void mep401_print_raw (XbowSensorboardPacket *packet); void mep401_print_cooked (XbowSensorboardPacket *packet); #endif /* __SENSORS_H__ */ --- NEW FILE: timestamp.c --- /** * Standard TinyOS license here. */ /** * Parts of this code were developed as part of * the NSF-ITR FireBug project. * * @author David M. Doolin * * @url http://firebug.sourceforge.net * */ /** * $Id: timestamp.c,v 1.1 2004/07/15 17:03:39 doolin Exp $ */ #include <time.h> #include <stdlib.h> #include <memory.h> #include <locale.h> #include "timestamp.h" #ifdef __cplusplus extern "C" { #endif #if 0 } #endif struct _timestamp { struct tm * time; }; Timestamp * timestamp_new (void) { Timestamp * ts = (Timestamp*)malloc(sizeof(Timestamp)); // Shred memory to indicate initialization status. memset((void*)ts,0xda,sizeof(Timestamp)); return ts; } void timestamp_delete (Timestamp * ts) { // Shred memory going out to indicate invalid access. memset((void*)ts,0xdd,sizeof(Timestamp)); free(ts); } /** @brief Get a timestamp in MySQL compatible format. * The innards could probably be slightly * improved. See header file to check/adjust * TIMESTRING_SIZE * * @author David M. Doolin */ void timestamp_get_ymdhms (Timestamp * ts, char timestring[TIMESTRING_SIZE]) { struct tm * l_time = ts->time; time_t timetype; timetype = time(NULL); l_time = localtime(&timetype); strftime(timestring, TIMESTRING_SIZE, "%Y%m%d%H%M%S", l_time); } #ifdef __cplusplus } #endif --- NEW FILE: Makefile --- CFLAGS = -Wall -O2 -Wno-format all: xlisten # Main xlisten sources SRCS = xlisten.c xserial.c xpacket.c # Add Mote Sensor board support SRCS += boards/mts300.c boards/mts400.c boards/mts510.c boards/mts101.c SRCS += boards/mep500.c boards/mep401.c timestamp.c # Add Mote Data Aquisition board support SRCS += boards/mda500.c boards/mda300.c xlisten: $(SRCS) gcc $(CFLAGS) -o $@ $(SRCS) clean: rm -rf *~ *.o *.exe *.stackdump --- NEW FILE: timestamp.h --- /** * Standard TinyOS license here. */ /** * Parts of this code were developed as part of * the NSF-ITR FireBug project. * * @author David M. Doolin * * @url http://firebug.sourceforge.net * */ /** * $Id: timestamp.h,v 1.1 2004/07/15 17:03:39 doolin Exp $ */ #ifndef FB_TIMESTAMP_H #define FB_TIMESTAMP_H #ifdef __cplusplus extern "C" { #endif #if 0 } #endif #define TIMESTRING_SIZE 128 /** Incomplete type, easier to extend later. */ typedef struct _timestamp Timestamp; Timestamp * timestamp_new (void); void timestamp_delete (Timestamp * ts); /** A handy format matching a mysql's time stamping syntax. * The date written as text can be imported directly into * a mysql table. */ void timestamp_get_ymdhms (Timestamp * ts, char * timestring); #ifdef __cplusplus } #endif #endif /* FB_TIMESTAMP_H */ --- NEW FILE: test_timestamp.c --- /** * Standard TinyOS license here. */ /** * Parts of this code were developed as part of * the NSF-ITR FireBug project. * * @author David M. Doolin * * @url http://firebug.sourceforge.net * */ /** * $Id: test_timestamp.c,v 1.1 2004/07/15 17:03:39 doolin Exp $ */ #include <stdio.h> #include "timestamp.h" /** Timestamp is easy to use. */ int main(int argc, char ** argv) { char timestring[TIMESTRING_SIZE]; Timestamp * ts = timestamp_new(); timestamp_get_ymdhms(ts,timestring); printf("Timestring: %s\n",timestring); // Clean up. timestamp_delete(ts); // Go home. return 0; } --- NEW FILE: xserial.c --- /** * Handles low-level serial communication. * * @file xserial.c * @author Martin Turon * @version 2004/3/10 mturon Initial version * * Copyright (c) 2004 Crossbow Technology, Inc. All rights reserved. * * $Id: xserial.c,v 1.1 2004/07/15 17:03:39 doolin Exp $ */ #include <stdio.h> #include <errno.h> #include <fcntl.h> #include <termios.h> #include <unistd.h> #ifdef __CYGWIN__ #include <windows.h> #include <io.h> #endif #define SERIAL_DEVICE "/dev/com1" // default port to use #define SERIAL_BAUDRATE B57600 // default baudrate = mica2 #define SERIAL_START_BYTE 0x7e #define SERIAL_END_BYTE 0x7c static unsigned g_verbose = 1; // verbose flag static unsigned g_baudrate = SERIAL_BAUDRATE; static const char *g_device = SERIAL_DEVICE; /** * Opens up a stream to the serial port. * * @return Handle to the serial port as an integer. * @author Martin Turon * @version 2004/3/10 mturon Intial revision * @n 2004/3/11 mturon Fixed cygwin reset problem * @n 2004/3/12 mturon Added improved cygwin fix by dgay */ int xserial_port_open() { /* open serline for read/write */ int serline; const char *name = g_device; unsigned long baudrate = g_baudrate; serline = open(name, O_RDWR | O_NOCTTY); if (serline == -1) { fprintf(stderr, "Failed to open %s\n", name); perror(""); fprintf(stderr, "Verify that user has permission to open device.\n"); exit(2); } if (g_verbose) printf("%s input stream opened\n", name); #ifdef __CYGWIN__ /* Cygwin requires some specific initialization. */ HANDLE handle = (HANDLE)get_osfhandle(serline); DCB dcb; if (!(GetCommState(handle, &dcb) && SetCommState(handle, &dcb))) { fprintf(stderr, "serial port initialisation problem\n"); exit(2); } #endif /* Serial port setting */ struct termios newtio; bzero(&newtio, sizeof(newtio)); newtio.c_cflag = CS8 | CLOCAL | CREAD; newtio.c_iflag = IGNBRK | IGNPAR; cfsetispeed(&newtio, baudrate); cfsetospeed(&newtio, baudrate); tcflush(serline, TCIFLUSH); tcsetattr(serline, TCSANOW, &newtio); return serline; } /** Syncronizes the serial port. */ void xserial_port_sync_packet(int serline) { unsigned char c = SERIAL_START_BYTE; while (c == SERIAL_START_BYTE) { read(serline, &c, 1); } } /** Reads one XSensorPacket from the serial port. */ int xserial_port_read_packet(int serline, unsigned char *buffer, int cnt) { // Use single byte reads for now as they are more stable. unsigned char c; int err, i=0; buffer[i] = SERIAL_START_BYTE; while(1) { err = read(serline, &c, 1); if (err < 0) { perror("error reading from serial port"); exit(2); } if (err == 1) { buffer[++i] = c; if (c == SERIAL_START_BYTE) return (--cnt <=0) ? 0 : 1; if (--cnt <= 0) return 0; } } } /** Dumps the raw serial traffic. Warning: Never exits! */ int xserial_port_dump() { int cnt, serline; serline = xserial_port_open(); while(1) { unsigned char c; cnt = read(serline, &c, 1); if (cnt < 0) { perror("error reading from serial port"); exit(2); } if (cnt == 1) { if (c == SERIAL_START_BYTE) printf("\n"); printf("%02x ", c); } } } unsigned xserial_set_baudrate(unsigned baudrate) { switch (baudrate) { #ifdef B50 case 50: baudrate = B50; break; #endif #ifdef B75 case 75: baudrate = B75; break; #endif #ifdef B110 case 110: baudrate = B110; break; #endif #ifdef B134 case 134: baudrate = B134; break; #endif #ifdef B150 case 150: baudrate = B150; break; #endif #ifdef B200 case 200: baudrate = B200; break; #endif #ifdef B300 case 300: baudrate = B300; break; #endif #ifdef B600 case 600: baudrate = B600; break; #endif #ifdef B1200 case 1200: baudrate = B1200; break; #endif #ifdef B1800 case 1800: baudrate = B1800; break; #endif #ifdef B2400 case 2400: baudrate = B2400; break; #endif #ifdef B4800 case 4800: baudrate = B4800; break; #endif #ifdef B9600 case 9600: baudrate = B9600; break; #endif #ifdef B19200 case 19200: baudrate = B19200; break; #endif #ifdef B38400 case 38400: baudrate = B38400; break; #endif #ifdef B57600 case 57600: baudrate = B57600; break; #endif #ifdef B115200 case 115200: baudrate = B115200; break; #endif #ifdef B230400 case 230400: baudrate = B230400; break; #endif #ifdef B460800 case 460800: baudrate = B460800; break; #endif #ifdef B500000 case 500000: baudrate = B500000; break; #endif #ifdef B576000 case 576000: baudrate = B576000; break; #endif #ifdef B921600 case 921600: baudrate = B921600; break; #endif #ifdef B1000000 case 1000000: baudrate = B1000000; break; #endif #ifdef B1152000 case 1152000: baudrate = B1152000; break; #endif #ifdef B1500000 case 1500000: baudrate = B1500000; break; #endif #ifdef B2000000 case 2000000: baudrate = B2000000; break; #endif #ifdef B2500000 case 2500000: baudrate = B2500000; break; #endif #ifdef B3000000 case 3000000: baudrate = B3000000; break; #endif #ifdef B3500000 case 3500000: baudrate = B3500000; break; #endif #ifdef B4000000 case 4000000: baudrate = B4000000; break; #endif default: baudrate = SERIAL_BAUDRATE; // Unknown baudrate, using default } g_baudrate = baudrate; return baudrate; } unsigned xserial_set_baud(const char *baud) { unsigned baudrate = atoi(baud); if (strcmp(baud, "mica2") == 0) return xserial_set_baudrate(57600); if (strcmp(baud, "mica2dot") == 0) return xserial_set_baudrate(19200); return xserial_set_baudrate(baudrate); } void xserial_set_device(const char *device) { g_device = device; } void xserial_set_verbose(int verbose) { g_verbose = verbose; } --- NEW FILE: xlisten.c --- /** * Listens to the serial port, and outputs sensor data in human readable form. * * @file xlisten.c * @author Martin Turon * @version 2004/3/10 mturon Initial version * * Copyright (c) 2004 Crossbow Technology, Inc. All rights reserved. * * $Id: xlisten.c,v 1.1 2004/07/15 17:03:39 doolin Exp $ */ #include <stdio.h> #include <stdlib.h> #include <signal.h> #include <string.h> #include "xsensors.h" #include "timestamp.h" FILE * logfile; char logfilename[256] = {0}; Timestamp * ts; const char *g_version = "$Id: xlisten.c,v 1.1 2004/07/15 17:03:39 doolin Exp $"; /** A structure to store parsed parameter flags. */ typedef union { unsigned flat; struct { // output display options unsigned display_raw : 1; //!< raw TOS packets unsigned display_parsed : 1; //!< pull out sensor readings unsigned display_cooked : 1; //!< convert to engineering units unsigned export_parsed : 1; //!< output comma delimited fields unsigned display_rsvd : 12; //!< pad first word for output options // modes of operation unsigned display_help : 1; unsigned display_baud : 1; //!< baud was set by user unsigned mode_quiet : 1; //!< suppress headers unsigned mode_wireless : 1; //!< use wireless network headers unsigned mode_debug : 1; //!< debug serial port } bits; struct { unsigned short output; //!< must have at least one output option unsigned short mode; } options; } s_params; /** A variable to store parsed parameter flags. */ s_params g_params; void catch_sigint(int signal) { if (logfile != NULL && logfile != stdout) { fflush(logfile); fclose(logfile); } exit(0); } /** * Extracts command line options and sets flags internally. * * @param argc Argument count * @param argv Argument vector * * @author Martin Turon * * @version 2004/3/10 mturon Intial version * @n 2004/3/12 mturon Added -b,-s,-q,-x */ void parse_args(int argc, char **argv) { unsigned baudrate = 0; g_params.flat = 0; /* default to no params set */ while (argc) { if ((argv[argc]) && (*argv[argc] == '-')) { switch(argv[argc][1]) { case '?': g_params.bits.display_help = 1; break; case 'q': xserial_set_verbose(0); g_params.bits.mode_quiet = 1; break; case 'p': g_params.bits.display_parsed = 1; break; case 'r': g_params.bits.display_raw = 1; break; case 'c': g_params.bits.display_cooked = 1; break; case 'x': g_params.bits.export_parsed = 1; break; case 'w': g_params.bits.mode_wireless = 1; xpacket_set_start(XPACKET_DATASTART_WIRELESS); break; case 'b': if (argv[argc][2] == '=') { baudrate = xserial_set_baud(argv[argc]+3); g_params.bits.display_baud = 1; } break; case 's': if (argv[argc][2] == '=') { xserial_set_device(argv[argc]+3); } break; case 'o': if (argv[argc][2] == '=') { strcpy(logfilename,argv[argc]+3); } break; case 'd': g_params.bits.mode_debug = 1; break; } } argc--; } if (!g_params.bits.mode_quiet) { // Summarize parameter settings printf("xlisten Ver:%s\n", g_version); printf("Using params: "); if (g_params.bits.display_help) printf("[help] "); if (g_params.bits.display_baud) printf("[baud=0x%04x] ", baudrate); if (g_params.bits.display_raw) printf("[raw] "); if (g_params.bits.display_parsed) printf("[parsed] "); if (g_params.bits.display_cooked) printf("[cooked] "); if (g_params.bits.export_parsed) printf("[export] "); if (g_params.bits.mode_wireless) printf("[wireless] "); if (g_params.bits.mode_debug) { printf("[debug - serial dump!] \n"); xserial_port_dump(); } printf("\n"); } if (g_params.bits.display_help) { printf( "\nUsage: xlisten <-?|r|p|x|c|d|q> <-b=baud> <-s=device>" "\n -? = display help [help]" "\n -r = raw display of tos packets [raw]" "\n -p = parse packet into raw sensor readings [parsed]" "\n -x = export readings in csv spreadsheet format [export]" "\n -c = convert data to engineering units [cooked]" "\n -d = debug serial port by dumping bytes [debug]" "\n -b = set the baudrate [baud=#|mica2|mica2dot]" "\n -s = set serial port device [device=com1]" "\n -w = read wireless network packets from TOSBase" "\n -q = quiet mode (suppress headers)" "\n" ); exit(0); } /* Default to displaying packets as raw, parsed, and cooked. */ if (g_params.options.output == 0) { g_params.bits.display_raw = 1; g_params.bits.display_parsed = 1; g_params.bits.display_cooked = 1; } } /** * The main entry point for the sensor listener console application. * * @param argc Argument count * @param argv Argument vector * * @author Martin Turon * @version 2004/3/10 mturon Intial version */ int main(int argc, char **argv) { parse_args(argc, argv); //char c; //int i, partial = 0; int serline; unsigned char buffer[64]; ts = timestamp_new(); if (*logfilename == 0) { logfile = stdout; } else { logfile = fopen(logfilename,"w"); } signal(SIGINT, catch_sigint); serline = xserial_port_open(); while (1) { if (xserial_port_read_packet(serline, buffer, XPACKET_SIZE)) continue; // ignore patial packets and packetizer frame end //if (g_params.bits.display_raw) xpacket_print_raw(buffer); if (g_params.bits.mode_wireless) xpacket_depacketize(buffer); if (g_params.bits.display_parsed) xpacket_print_parsed(buffer); if (g_params.bits.export_parsed) xpacket_export_parsed(buffer); if (g_params.bits.display_cooked) xpacket_print_cooked(buffer); } } //####################### User Manual Follows ############################## /** @mainpage XListen Documentation @section version Version $Id: xlisten.c,v 1.1 2004/07/15 17:03:39 doolin Exp $ @section usage Usage Usage: xlisten <-?|r|p|x|c|d|q> <-b=baud> <-s=device> @n @n -? = display help [help] @n -r = raw display of tos packets [raw] @n -p = parse packet into raw sensor readings [parsed] @n -x = export readings in csv spreadsheet format [export] @n -c = convert data to engineering units [cooked] @n -d = debug serial port by dumping bytes [debug] @n -b = set the baudrate [baud=#|mica2|mica2dot] @n -s = set serial port device [device=com1] @n -w = read wireless network packets from TOSBase @n -q = quiet mode (suppress headers) @n @section params Parameters @subsection help -? [help] XListen has many modes of operation that can be controlled by passing command line parameters. The current list of these command line options and a brief usage explanation is always available by passing the -? flag. @n @n A detail explanation of each command line option as of version 1.7 follows. @subsection baud -b=baudrate [baud] This flag allows the user to set the baud rate of the serial line connection. The default baud rate is 57600 bits per second which is compatible with the Mica2. The desired baudrate must be passed as a number directly after the equals sign with no spaces inbetween, i.e. -b=19200. Optionally, a product name can be passed in lieu of an actual number and the proper baud will be set, i.e. -b=mica2dot. Valid product names are: mica2 (57600 baud) mica2dot (19200 baud) @subsection serial -s=port [serial] This flag gives the user the ability to specify which COM port or device xlisten should use. The default port is /dev/ttyS0 or the UNIX equivalent to COM1. The given port must be passed directly after the equals sign with no spaces, i.e. -s=com3. @subsection raw -r [raw] Raw mode displays the actual TOS packets as a sequence of bytes as seen coming over the serial line. Sample output follows: @n $ xlisten -r @n xlisten Ver: Id: xlisten.c,v 1.7 2004/03/23 00:52:28 mturon Exp @n Using params: [raw] @n /dev/ttyS0 input stream opened @n 7e7e000033000000c8035f61d383036100000000e4510d610000000080070000d4b5f577 @n 7e00007d1d8101060029091e09ef082209e7080b09b40800000000000000000000000100 @n 7e00007d1d81020600f007de07da07d507c3064706540500000000000000000000000100 @subsection parsed -p [parsed] Parsed mode attempts to interpret the results of the incoming TOS packets and display information accordingly. The first stage of the parsing is to look for a valid sensorboard_id field, and display the part number. The node_id of the packet sender is also pulled out and displayed. Finally, raw sensor readings are extracted and displayed with some designation as to their meaning: @n $ xlisten -p -b=mica2dot @n xlisten Ver: Id: xlisten.c,v 1.7 2004/03/23 00:52:28 mturon Exp @n Using params: [baud=0x000e] [parsed] @n /dev/ttyS0 input stream opened @n mda500 id=06 bat=00c1 thrm=0203 a2=019c a3=0149 a4=011d a5=012b a6=011b a7=0147 @n mda500 id=06 bat=00c2 thrm=0203 a2=019d a3=014d a4=011e a5=0131 a6=011b a7=0140 @n mda500 id=06 bat=00c2 thrm=0204 a2=0199 a3=014c a4=0125 a5=012a a6=011f a7=0147 @n mda500 id=06 bat=00c2 thrm=0204 a2=0198 a3=0148 a4=0122 a5=0131 a6=012d a7=0143 @n mda500 id=06 bat=00c2 thrm=0203 a2=019e a3=014e a4=0124 a5=012b a6=011c a7=0143 @n mda500 id=06 bat=00c2 thrm=0204 a2=019d a3=014c a4=011f a5=0135 a6=0133 a7=011d @n mda500 id=06 bat=00c2 thrm=0205 a2=019a a3=014c a4=011e a5=0131 a6=012d a7=011c @subsection cooked -c [cooked] Cooked mode actually converts the raw sensor readings within a given packet into engineering units. Sample output follows: @n $ xlisten -c -b=mica2dot @n xlisten Ver: Id: xlisten.c,v 1.7 2004/03/23 00:52:28 mturon Exp @n Using params: [baud=0x000e] [cooked] @n /dev/ttyS0 input stream opened @n MDA500 [sensor data converted to engineering units]: @n health: node id=6 @n battery: volts=3163 mv @n thermistor: resistance=10177 ohms, tempurature=24.61 C @n adc chan 2: voltage=1258 mv @n adc chan 3: voltage=1001 mv @n adc chan 4: voltage=893 mv @n adc chan 5: voltage=939 mv @n adc chan 6: voltage=875 mv @n adc chan 7: voltage=850 mv @subsection quiet -q [quiet] This flag suppresses the standard xlisten header which displays the version string and parameter selections. @subsection export -x [export] Export mode displays raw adc values as comma delimited text for use in spreadsheet and data manipulation programs. The user can pipe the output of xlisten in export mode to a file and load that file into Microsoft Excel to build charts of the information. Sample output follows: @n $ xlisten -b=mica2dot -q -x @n 51200,24323,54113,899,97,0,58368,3409 @n 6,193,518,409,328,283,296,298 @n 6,194,517,410,330,292,310,300 @n 6,194,518,409,329,286,309,288 @n 6,194,517,411,331,287,297,300 @n 6,194,516,413,335,288,301,287 @subsection wireless -w [wireless] Passing the wireless flag tells xlisten to use a different offset when parsing packets that are being forwarded by TOSBase. This flag is required to see parsed and cooked values from motes over a wireless network. @subsection debug -d [debug] This flag puts xlisten in a mode so that it behaves exactly like the TinyOS raw listen tool (tinyos-1.x/tools/src/raw_listen.c.) All other command line options except -b [baud] and -s[serial] will be ignored. This mode is mainly used for compatibility and debugging serial port issues. Individual bytes will be displayed as soon as they are read from the serial port with no post-processing. In most cases -r [raw] is equivalent and preferred to using debug mode. @subsection display Display Options The -r, -p, and -c flags are considered display options. These can be passed in various combinations to display multiple views of the same packet at once. The default display mode when xlisten is invoked with no arguments is -r. What follows is sample output for all three display options turned on at once: @n $ xlisten -b=mica2dot -r -p -c @n xlisten Ver: Id: xlisten.c,v 1.7 2004/03/23 00:52:28 mturon Exp @n Using params: [baud=0x000e] [raw] [parsed] [cooked] @n /dev/ttyS0 input stream opened @n 7e7e000033000000c8035f61d383036100000000e4510d610000000080070000d4b5f577 @n 7e00007d1d01010600c200050293014401210135012f0122010000000000000000000100 @n mda500 id=06 bat=00c2 thrm=0205 a2=0193 a3=0144 a4=0121 a5=0135 a6=012f a7=0122 @n MDA500 [sensor data converted to engineering units]: @n health: node id=6 @n battery: volts=3163 mv @n thermistor: resistance=10217 ohms, tempurature=24.53 C @n adc chan 2: voltage=1246 mv @n adc chan 3: voltage=1001 mv @n adc chan 4: voltage=893 mv @n adc chan 5: voltage=955 mv @n adc chan 6: voltage=936 mv @n adc chan 7: voltage=896 mv @section building Build Process The source code for the xlisten tool is located at: /opt/tinyos-1.x/contrib/xbow/tools/src/xlisten. @n@n To build the tool, change to the xlisten source directory and run `make`. @n@n To get the latest version of the source, change to the xlisten source directory and run `cvs update`. @section setup Setup XListen is a command line tool that can be run from a cygwin shell by simply typing `xlisten`. The executable needs to be in your working path to use it. A simple way to add xlisten to your working path is to create a soft link to it by running the following command: @n$ ln -s /opt/tinyos-1.x/contrib/xbow/tools/src/xlisten /usr/local/bin/xlisten @n@n You can use xlisten to read sensor data from either one mote over a serial link, or a wireless network of motes. In both configurations, you need to have a MIB510 board connected via a serial cable to your PC. @n@n For a single mote configuration, the mote must be programmed with a XSensorMXX### application and plugged into the MIB510. The mote will stream packets over the UART whenever it has power. @n@n For the network of motes configuration, a base station mote needs to be programmed with TOSBase and plugged into the MIB510. All other motes need to be installed with an XSensorMXX## application and put within range of the base station or a valid multi-hop peer. Xlisten must then be run with the -w flag to properly parse the wireless packets. Take care to program all the motes to the same frequency and group id. */ |
From: David M. D. <do...@us...> - 2004-07-15 17:02:21
|
Update of /cvsroot/firebug/fireboard/tools/src/xlisten/boards In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv9195/boards Log Message: Directory /cvsroot/firebug/fireboard/tools/src/xlisten/boards added to the repository |
From: David M. D. <do...@us...> - 2004-07-15 17:02:04
|
Update of /cvsroot/firebug/fireboard/tools/src/xlisten In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv9101/xlisten Log Message: Directory /cvsroot/firebug/fireboard/tools/src/xlisten added to the repository |
From: David M. D. <do...@us...> - 2004-07-15 17:01:41
|
Update of /cvsroot/firebug/fireboard/tools/src In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv9032/src Log Message: Directory /cvsroot/firebug/fireboard/tools/src added to the repository |
From: David M. D. <do...@us...> - 2004-07-15 17:00:48
|
Update of /cvsroot/firebug/fireboard/tools In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv8816/tools Log Message: Directory /cvsroot/firebug/fireboard/tools added to the repository |
From: David M. D. <do...@us...> - 2004-07-15 16:41:14
|
Update of /cvsroot/firebug/firebug/web In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv5531 Modified Files: gps_tests.htm Log Message: Added tables of GPS results. Index: gps_tests.htm =================================================================== RCS file: /cvsroot/firebug/firebug/web/gps_tests.htm,v retrieving revision 1.7 retrieving revision 1.8 diff -C2 -d -r1.7 -r1.8 *** gps_tests.htm 15 Jul 2004 16:33:27 -0000 1.7 --- gps_tests.htm 15 Jul 2004 16:41:04 -0000 1.8 *************** *** 42,47 **** --- 42,50 ---- <img src="./images/numsats.png" alt="Number of satellites" /> + + <center> <pre> + ----------------------------- Mote Mean StdDev ============================= |
From: David M. D. <do...@us...> - 2004-07-15 16:33:38
|
Update of /cvsroot/firebug/firebug/web In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4363 Modified Files: gps_tests.htm Log Message: Added tables of GPS results. Index: gps_tests.htm =================================================================== RCS file: /cvsroot/firebug/firebug/web/gps_tests.htm,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -d -r1.6 -r1.7 *** gps_tests.htm 15 Jul 2004 16:11:38 -0000 1.6 --- gps_tests.htm 15 Jul 2004 16:33:27 -0000 1.7 *************** *** 42,45 **** --- 42,77 ---- <img src="./images/numsats.png" alt="Number of satellites" /> + <center> + <pre> + Mote Mean StdDev + ============================= + 1 (Lat) 37.9018 0.03113 + 1 (Long) 122.3042 0.04855 + 2 (Lat) 37.8992 0.10373 + 2 (Long) 122.2591 1.7530 + ============================= + </pre> + Table 1. Unfiltered GPS data from 2 motes 1 meter apart on an east-west line. + </center> + + <center> + <pre> + --------------------------------------------------------------------------------------------------- + satellites | 3 | 4 | 5 + --------------------------------------------------------------------------------------------------- + Mote | Count Mean StdDev | Count Mean StdDev | Count Mean StdDev + =================================================================================================== + 1 (Lat) | 615 37.9018 0.03986 | 323 37.9028 0.004614 | 62 37.9029 6.085e-5 + 1 (Long) | 615 122.3042 0.06076 | 323 122.3025 0.01956 | 62 122.3045 7.441e-5 + 2 (Lat) | 678 37.8992 0.1412 | 397 37.9015 0.01290 | 147 37.9028 1.221e-3 + 2 (Long) | 678 122.2591 2.3919 | 397 122.3034 0.02113 | 147 122.3047 2.084e-3 + =================================================================================================== + </pre> + Table 2. Statistics of GPS data arranged by number of + satellites from 2 motes 1 meter + apart on an east-west line. The means and + standard deviations are in decimal degrees. + </center> + <h1> |
From: David M. D. <do...@us...> - 2004-07-15 16:16:19
|
Update of /cvsroot/firebug/firebug/web In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv662 Modified Files: publications.html Log Message: Listed publications most recent first. Index: publications.html =================================================================== RCS file: /cvsroot/firebug/firebug/web/publications.html,v retrieving revision 1.8 retrieving revision 1.9 diff -C2 -d -r1.8 -r1.9 *** publications.html 15 Jul 2004 14:43:15 -0000 1.8 --- publications.html 15 Jul 2004 16:16:04 -0000 1.9 *************** *** 15,18 **** --- 15,76 ---- <li> + S. D. Glaser. + <a href="glaser_spie_2004_paper.pdf">Some real-world applications of wireless sensor nodes</a> + Proceedings of SPIE Symposium on Smart Structures & Materials/ NDE 2004, San Diego, + California, March 14-18, 2004 + <p> + ABSTRACT: This paper presents two case histories of the use of + wireless sensor Mote technologies. These are devices that + incorporate communications, processing, sensors, sensor fusion, + and power source into a package currently about two cubic inches in + size - networked autonomous sensor nodes. The first case discussed + is the November, 2001, instrumentation of a blastinduced + liquefaction test in Tokachi Port, Japan. The second case discussed + is the dense-pak<sup>TM</sup> instrumentation of the seismic shaking test of a + full-scale wood-frame building on the UCB Richmond shake table. The + utility of dense instumentation is shown, and how it allows location + of damage globally unseen. A methodology of interpreting structural + seismic respose by Bayesian updating and extended Kalman filtering is + presented. It is shown that dense, inexpensive instrumentation is + needed to identify structural damage and prognosticate future behavior. + The case studies show that the current families of Motes are very + useful, but the hardware still has difficulties in terms of reliability + and consistancy. It is apparent that the TinyOS is a wonderful tool + for computer science education but is not an industrual quality + instrumentation system. These are, of course, growing pains of the + first incarnations of the Berkeley Smart Dust ideal. We expect the + dream of easy to use, inexpensive, smart, wireless, sensor networks + to become a reality in the next couple of years. + </p> + </li> + + <li> + D. M. Doolin, S. D. Glaser and N. Sitar. + <a href="interface_poster.pdf" alt="TOS Tech Exchange Poster"> + Software Architecture for GPS-enabled Wildfire Sensorboard</a>. + TinyOS Technology Exchange, February 26, 2004, University of California, + Berkeley CA. + <p> + ABSTRACT: Wireless sensors for conducting wildfire + monitoring share many of the capabilities of + other environmental sensors, collecting + data such as humidity, temperature and barometric pressure. + On-board GPS location finding allows rapid, remote + deployment. In this poster, a scheme for + developing driver and interface software for + employing the Crossbow MTS420CA sensorboard + is described. A high-level, generalized + sensor interface is presented. Data collection + algorithms implemented over implementations + of this sensor interface do not require + programming changes to the underlying + sensor driver code. + </p> + </li> + + + + + <li> M. M. Chen, C. Majidi, D. M. Doolin, S. Glaser and N. Sitar. *************** *** 50,107 **** - <li> - D. M. Doolin, S. D. Glaser and N. Sitar. - <a href="interface_poster.pdf" alt="TOS Tech Exchange Poster"> - Software Architecture for GPS-enabled Wildfire Sensorboard</a>. - TinyOS Technology Exchange, February 26, 2004, University of California, - Berkeley CA. - <p> - ABSTRACT: Wireless sensors for conducting wildfire - monitoring share many of the capabilities of - other environmental sensors, collecting - data such as humidity, temperature and barometric pressure. - On-board GPS location finding allows rapid, remote - deployment. In this poster, a scheme for - developing driver and interface software for - employing the Crossbow MTS420CA sensorboard - is described. A high-level, generalized - sensor interface is presented. Data collection - algorithms implemented over implementations - of this sensor interface do not require - programming changes to the underlying - sensor driver code. - </p> - </li> - <li> - S. D. Glaser. - <a href="glaser_spie_2004_paper.pdf">Some real-world applications of wireless sensor nodes</a> - Proceedings of SPIE Symposium on Smart Structures & Materials/ NDE 2004, San Diego, - California, March 14-18, 2004 - <p> - ABSTRACT: This paper presents two case histories of the use of - wireless sensor Mote technologies. These are devices that - incorporate communications, processing, sensors, sensor fusion, - and power source into a package currently about two cubic inches in - size - networked autonomous sensor nodes. The first case discussed - is the November, 2001, instrumentation of a blastinduced - liquefaction test in Tokachi Port, Japan. The second case discussed - is the dense-pak<sup>TM</sup> instrumentation of the seismic shaking test of a - full-scale wood-frame building on the UCB Richmond shake table. The - utility of dense instumentation is shown, and how it allows location - of damage globally unseen. A methodology of interpreting structural - seismic respose by Bayesian updating and extended Kalman filtering is - presented. It is shown that dense, inexpensive instrumentation is - needed to identify structural damage and prognosticate future behavior. - The case studies show that the current families of Motes are very - useful, but the hardware still has difficulties in terms of reliability - and consistancy. It is apparent that the TinyOS is a wonderful tool - for computer science education but is not an industrual quality - instrumentation system. These are, of course, growing pains of the - first incarnations of the Berkeley Smart Dust ideal. We expect the - dream of easy to use, inexpensive, smart, wireless, sensor networks - to become a reality in the next couple of years. - </p> - </li> </ul> --- 108,112 ---- |
From: David M. D. <do...@us...> - 2004-07-15 16:11:47
|
Update of /cvsroot/firebug/firebug/web/images In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv32191/images Modified Files: numsats.png Log Message: Changed order of presentation of results Index: numsats.png =================================================================== RCS file: /cvsroot/firebug/firebug/web/images/numsats.png,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvsfnzkpQ and /tmp/cvs3VxllJ differ |
From: David M. D. <do...@us...> - 2004-07-15 16:11:46
|
Update of /cvsroot/firebug/firebug/web In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv32191 Modified Files: gps_tests.htm Log Message: Changed order of presentation of results Index: gps_tests.htm =================================================================== RCS file: /cvsroot/firebug/firebug/web/gps_tests.htm,v retrieving revision 1.5 retrieving revision 1.6 diff -C2 -d -r1.5 -r1.6 *** gps_tests.htm 15 Jul 2004 00:32:16 -0000 1.5 --- gps_tests.htm 15 Jul 2004 16:11:38 -0000 1.6 *************** *** 13,16 **** --- 13,84 ---- <body> + <h1> + GPS Receiver Accuracy + </h1> + + <p> + The accuracy of the LeadTek GPS receiver as advertised as + ± 5 meters. An investigation to assess this claim was + conducted in El Cerrito, California on April 11, 2004. + As can be seen by the figures below, the receiver ranges from + being very accurate to very inaccurate. + </p> + + <img src="./images/latitude.png" alt="latitude" /> + <img src="./images/longitude.png" alt="longitude" /> + + <p> + The preceding figures were produced using all of the + data emitted from the GPS receiver. Statistics + indicate that the mean and variance of the position + is correlated with the number of satellites used to + obtain the position fix. As the following table shows, + 5 satellites is the realistically minimum number + necessary to produce a fix within 5-10 meters of the + actual location. + </p> + + <img src="./images/orbits.png" alt="Position orbits" /> + <img src="./images/numsats.png" alt="Number of satellites" /> + + + <h1> + GPS Receiver Acquisition Time + </h1> + + <p> + All GPS units require a certain amount of time to acquire 4 + satellites, the minimum number needed for fixing a position + (3 for space, 1 for time). Most GPS receivers implement tracking + in a reduced power mode that enables fixes to be computed + very rapidly when switched to a fully alert state. For the + LeadTek 9546, test was performed to investigate the acquisition + times necessary for a sequence of cold starts. + </p> + + <p> + The tests were performed April 11, 2004 in El Cerrito + California. A simple test code exercising only the + GPS sensor was loaded onto Crossbow Mica2 mote. The + mote was run for approximately 18 hours, indoors, with + the GPS antenna located outside to enable satellite + acquisition. The antenna had clear view of more than + half the eastern hemisphere of the sky. + </p> + + <p> + As can be seen from the results, acquisition times range + from a few seconds to nearly 10 minutes to acquire 5 + satellites, a practical minimum necessary to achieve the + published accuracy of the device, ± 5 meters. + </p> + + + <img src="./images/acquisition_times.png" alt="Acquisition times for 5 sats" /> + + <img src="./images/acquisition_histogram.png" alt="Acquisition histogram for 5 sats" /> + + + <h1> GPS Receiver Performance Tests *************** *** 144,213 **** - <h1> - GPS Receiver Accuracy - </h1> - - <p> - The accuracy of the LeadTek GPS receiver as advertised as - ± 5 meters. An investigation to assess this claim was - conducted in El Cerrito, California on April 11, 2004. - As can be seen by the figures below, the receiver ranges from - being very accurate to very inaccurate. - </p> - - <img src="./images/latitude.png" alt="latitude" /> - <img src="./images/longitude.png" alt="longitude" /> - - <p> - The preceding figures were produced using all of the - data emitted from the GPS receiver. Statistics - indicate that the mean and variance of the position - is correlated with the number of satellites used to - obtain the position fix. As the following table shows, - 5 satellites is the realistically minimum number - necessary to produce a fix within 5-10 meters of the - actual location. - </p> - - <img src="./images/orbits.png" alt="Position orbits" /> - <img src="./images/numsats.png" alt="Number of satellites" /> - - - <h1> - GPS Receiver Acquisition Time - </h1> - - <p> - All GPS units require a certain amount of time to acquire 4 - satellites, the minimum number needed for fixing a position - (3 for space, 1 for time). Most GPS receivers implement tracking - in a reduced power mode that enables fixes to be computed - very rapidly when switched to a fully alert state. For the - LeadTek 9546, test was performed to investigate the acquisition - times necessary for a sequence of cold starts. - </p> - - <p> - The tests were performed April 11, 2004 in El Cerrito - California. A simple test code exercising only the - GPS sensor was loaded onto Crossbow Mica2 mote. The - mote was run for approximately 18 hours, indoors, with - the GPS antenna located outside to enable satellite - acquisition. The antenna had clear view of more than - half the eastern hemisphere of the sky. - </p> - - <p> - As can be seen from the results, acquisition times range - from a few seconds to nearly 10 minutes to acquire 5 - satellites, a practical minimum necessary to achieve the - published accuracy of the device, ± 5 meters. - </p> - - <img src="./images/acquisition_times.png" alt="Acquisition times for 5 sats" /> - - <img src="./images/acquisition_histogram.png" alt="Acquisition histogram for 5 sats" /> <hr> --- 212,218 ---- + <!-- Last lines, leave in place. --> <hr> |
From: David M. D. <do...@us...> - 2004-07-15 14:43:25
|
Update of /cvsroot/firebug/firebug/web In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv15384 Modified Files: publications.html Added Files: glaser_spie_2004_paper.pdf Log Message: Added Steve's spie paper and abstract to pub list. --- NEW FILE: glaser_spie_2004_paper.pdf --- (This appears to be a binary file; contents omitted.) Index: publications.html =================================================================== RCS file: /cvsroot/firebug/firebug/web/publications.html,v retrieving revision 1.7 retrieving revision 1.8 diff -C2 -d -r1.7 -r1.8 *** publications.html 14 Jul 2004 23:35:28 -0000 1.7 --- publications.html 15 Jul 2004 14:43:15 -0000 1.8 *************** *** 51,55 **** <li> ! D. M. Doolin, S. Glaser and N. Sitar. <a href="interface_poster.pdf" alt="TOS Tech Exchange Poster"> Software Architecture for GPS-enabled Wildfire Sensorboard</a>. --- 51,55 ---- <li> ! D. M. Doolin, S. D. Glaser and N. Sitar. <a href="interface_poster.pdf" alt="TOS Tech Exchange Poster"> Software Architecture for GPS-enabled Wildfire Sensorboard</a>. *************** *** 75,82 **** <li> ! Professor Glaser's ! <a href="sensor_net.pdf">talk</a> on sensor networks. ! <p> ! ABSTRACT: Talk on sensor networks. </p> </li> --- 75,105 ---- <li> ! S. D. Glaser. ! <a href="glaser_spie_2004_paper.pdf">Some real-world applications of wireless sensor nodes</a> ! Proceedings of SPIE Symposium on Smart Structures & Materials/ NDE 2004, San Diego, ! California, March 14-18, 2004 ! <p> ! ABSTRACT: This paper presents two case histories of the use of ! wireless sensor Mote technologies. These are devices that ! incorporate communications, processing, sensors, sensor fusion, ! and power source into a package currently about two cubic inches in ! size - networked autonomous sensor nodes. The first case discussed ! is the November, 2001, instrumentation of a blastinduced ! liquefaction test in Tokachi Port, Japan. The second case discussed ! is the dense-pak<sup>TM</sup> instrumentation of the seismic shaking test of a ! full-scale wood-frame building on the UCB Richmond shake table. The ! utility of dense instumentation is shown, and how it allows location ! of damage globally unseen. A methodology of interpreting structural ! seismic respose by Bayesian updating and extended Kalman filtering is ! presented. It is shown that dense, inexpensive instrumentation is ! needed to identify structural damage and prognosticate future behavior. ! The case studies show that the current families of Motes are very ! useful, but the hardware still has difficulties in terms of reliability ! and consistancy. It is apparent that the TinyOS is a wonderful tool ! for computer science education but is not an industrual quality ! instrumentation system. These are, of course, growing pains of the ! first incarnations of the Berkeley Smart Dust ideal. We expect the ! dream of easy to use, inexpensive, smart, wireless, sensor networks ! to become a reality in the next couple of years. </p> </li> |
From: David M. D. <do...@us...> - 2004-07-15 00:32:25
|
Update of /cvsroot/firebug/firebug/web In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv13768 Modified Files: gps_tests.htm Log Message: Added links to plots for orbits and number of satellites. Index: gps_tests.htm =================================================================== RCS file: /cvsroot/firebug/firebug/web/gps_tests.htm,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -d -r1.4 -r1.5 *** gps_tests.htm 15 Jul 2004 00:19:15 -0000 1.4 --- gps_tests.htm 15 Jul 2004 00:32:16 -0000 1.5 *************** *** 170,173 **** --- 170,177 ---- </p> + <img src="./images/orbits.png" alt="Position orbits" /> + <img src="./images/numsats.png" alt="Number of satellites" /> + + <h1> GPS Receiver Acquisition Time |
From: David M. D. <do...@us...> - 2004-07-15 00:31:06
|
Update of /cvsroot/firebug/firebug/web/images In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv13505 Added Files: numsats.png orbits.png Log Message: Added position orbits and number of satellites. --- NEW FILE: numsats.png --- (This appears to be a binary file; contents omitted.) --- NEW FILE: orbits.png --- (This appears to be a binary file; contents omitted.) |
From: David M. D. <do...@us...> - 2004-07-15 00:19:28
|
Update of /cvsroot/firebug/firebug/web In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv11272 Modified Files: gps_tests.htm Log Message: Added more discussion to GPS results. Index: gps_tests.htm =================================================================== RCS file: /cvsroot/firebug/firebug/web/gps_tests.htm,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -d -r1.3 -r1.4 *** gps_tests.htm 16 Sep 2003 20:48:45 -0000 1.3 --- gps_tests.htm 15 Jul 2004 00:19:15 -0000 1.4 *************** *** 5,13 **** <head> <link type="text/css" rel="stylesheet" href="firebug.css"> ! <link rel="SHORTCUT ICON" href="./images/favicon.ico"> ! <title> ! GPS Receiver Performance Tests ! </title> </head> --- 5,13 ---- <head> <link type="text/css" rel="stylesheet" href="firebug.css"> ! <link rel="SHORTCUT ICON" href="./images/favicon.ico"> ! <title> ! GPS Receiver Performance Tests ! </title> </head> *************** *** 75,153 **** 51 and 52 seconds. Moreover, the following observations were made: ! <ul> ! <li> ! Cold-start acquisition time seems to be unrelated to the # of ! satellites in line of sight. ! </li> ! <li> ! Geographical data more accurate with four or more satellites. ! </li> ! <li> ! As observed at 'Main Stacks' and 'Under Trees', GPS occasionally ! fails even if an adequate number of satellites is know to be in ! line of sight. ! </li> ! <li> ! Small tree canopies do not block GPS signals. ! </li> ! <li> ! Acquisition times might be reduced by setting the receiver's ! sampling rate rather than power cycling it from the host (mote). ! To test this, though, it will be necessary to send commands to the ! receiver. ! </li> ! </ul> ! ! <h2> ! Location Accuracy ! </h2> ! <p> ! When the number of satellites is greater than three, the GPS ! estimatation was reliably within ten meters of the true location. ! In this regard, the Leadtek performed similar to other receivers ! of the same class. ! </p> ! <h2> ! Movement Tracking ! </h2> ! <center> ! <img src="./images/gps_equip.jpg" alt="Taking GPS measurements"> ! </center> ! <p> ! Lastly, a brief experiment was done to determine how well the ! receiver could track movement beyond the ten meter error. In ! particular, the GeoMapper software was used to see whether the ! GPS could follow a walk around Memorial Glade without lag. ! (Note: no pauses were taken during walks.) ! </p> ! <center> ! <img src="./images/mem_glade1.jpg" alt="Picture of Memorial Glade"> ! </center> ! <p> ! For a leisurely four minute walk, no lag was apparent. For a ! more brisk walk, a lag of about 2-3 seconds was seen. The GPS ! refresh rate was set at 1 Hz (note: blue markers in figure ! correspond to spots where a new GPS fix was gotten during the ! walk). ! </p> ! <center> ! <img src="./images/mem_glade2.jpg" alt="Motion Tracking about Memorial Glade"> ! </center> ! <hr> ! <p> ! Last Updated: $Date$ ! by $Author$. ! </p> --- 75,215 ---- 51 and 52 seconds. Moreover, the following observations were made: ! <ul> ! <li> ! Cold-start acquisition time seems to be unrelated to the # of ! satellites in line of sight. ! </li> ! <li> ! Geographical data more accurate with four or more satellites. ! </li> ! <li> ! As observed at 'Main Stacks' and 'Under Trees', GPS occasionally ! fails even if an adequate number of satellites is know to be in ! line of sight. ! </li> ! <li> ! Small tree canopies do not block GPS signals. ! </li> ! <li> ! Acquisition times might be reduced by setting the receiver's ! sampling rate rather than power cycling it from the host (mote). ! To test this, though, it will be necessary to send commands to the ! receiver. ! </li> ! </ul> ! ! <h2> ! Location Accuracy ! </h2> ! <p> ! When the number of satellites is greater than three, the GPS ! estimatation was reliably within ten meters of the true location. ! In this regard, the Leadtek performed similar to other receivers ! of the same class. ! </p> ! <h2> ! Movement Tracking ! </h2> ! <center> ! <img src="./images/gps_equip.jpg" alt="Taking GPS measurements"> ! </center> ! <p> ! Lastly, a brief experiment was done to determine how well the ! receiver could track movement beyond the ten meter error. In ! particular, the GeoMapper software was used to see whether the ! GPS could follow a walk around Memorial Glade without lag. ! (Note: no pauses were taken during walks.) ! </p> ! <center> ! <img src="./images/mem_glade1.jpg" alt="Picture of Memorial Glade"> ! </center> ! <p> ! For a leisurely four minute walk, no lag was apparent. For a ! more brisk walk, a lag of about 2-3 seconds was seen. The GPS ! refresh rate was set at 1 Hz (note: blue markers in figure ! correspond to spots where a new GPS fix was gotten during the ! walk). ! </p> ! <center> ! <img src="./images/mem_glade2.jpg" alt="Motion Tracking about Memorial Glade"> ! </center> ! <h1> ! GPS Receiver Accuracy ! </h1> ! <p> ! The accuracy of the LeadTek GPS receiver as advertised as ! ± 5 meters. An investigation to assess this claim was ! conducted in El Cerrito, California on April 11, 2004. ! As can be seen by the figures below, the receiver ranges from ! being very accurate to very inaccurate. ! </p> ! ! <img src="./images/latitude.png" alt="latitude" /> ! <img src="./images/longitude.png" alt="longitude" /> ! ! <p> ! The preceding figures were produced using all of the ! data emitted from the GPS receiver. Statistics ! indicate that the mean and variance of the position ! is correlated with the number of satellites used to ! obtain the position fix. As the following table shows, ! 5 satellites is the realistically minimum number ! necessary to produce a fix within 5-10 meters of the ! actual location. ! </p> ! ! <h1> ! GPS Receiver Acquisition Time ! </h1> ! ! <p> ! All GPS units require a certain amount of time to acquire 4 ! satellites, the minimum number needed for fixing a position ! (3 for space, 1 for time). Most GPS receivers implement tracking ! in a reduced power mode that enables fixes to be computed ! very rapidly when switched to a fully alert state. For the ! LeadTek 9546, test was performed to investigate the acquisition ! times necessary for a sequence of cold starts. ! </p> ! ! <p> ! The tests were performed April 11, 2004 in El Cerrito ! California. A simple test code exercising only the ! GPS sensor was loaded onto Crossbow Mica2 mote. The ! mote was run for approximately 18 hours, indoors, with ! the GPS antenna located outside to enable satellite ! acquisition. The antenna had clear view of more than ! half the eastern hemisphere of the sky. ! </p> ! ! <p> ! As can be seen from the results, acquisition times range ! from a few seconds to nearly 10 minutes to acquire 5 ! satellites, a practical minimum necessary to achieve the ! published accuracy of the device, ± 5 meters. ! </p> ! ! ! <img src="./images/acquisition_times.png" alt="Acquisition times for 5 sats" /> ! ! <img src="./images/acquisition_histogram.png" alt="Acquisition histogram for 5 sats" /> ! ! <hr> ! ! <p> ! Last Updated: $Date$ ! by $Author$. ! </p> |
From: David M. D. <do...@us...> - 2004-07-15 00:01:32
|
Update of /cvsroot/firebug/firebug/web/images In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv8041 Added Files: latitude.png longitude.png Log Message: Added lat and long accuracy figures. --- NEW FILE: latitude.png --- (This appears to be a binary file; contents omitted.) --- NEW FILE: longitude.png --- (This appears to be a binary file; contents omitted.) |
From: David M. D. <do...@us...> - 2004-07-14 23:57:17
|
Update of /cvsroot/firebug/firebug/web/images In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv7292 Added Files: acquisition_histogram.png acquisition_times.png Log Message: Plots for GPS 5 satellite acquisition times. --- NEW FILE: acquisition_times.png --- (This appears to be a binary file; contents omitted.) --- NEW FILE: acquisition_histogram.png --- (This appears to be a binary file; contents omitted.) |
From: Kevin <kar...@us...> - 2004-07-14 23:35:37
|
Update of /cvsroot/firebug/firebug/web In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3496 Modified Files: menu.html publications.html Log Message: Removed Network Architecture and Burning links from menu.html Index: menu.html =================================================================== RCS file: /cvsroot/firebug/firebug/web/menu.html,v retrieving revision 1.11 retrieving revision 1.12 diff -C2 -d -r1.11 -r1.12 *** menu.html 20 Nov 2003 22:32:17 -0000 1.11 --- menu.html 14 Jul 2004 23:35:28 -0000 1.12 *************** *** 40,51 **** <td class="Nav"> <div class="NavText"> - <a href="./sensorarch.html" target="main">Network architecture</a> - </div> - </td> - </tr> - - <tr class="NavRow"> - <td class="Nav"> - <div class="NavText"> <a href="./firetraining.html" target="main">Fire training</a> </div> --- 40,43 ---- *************** *** 56,67 **** <td class="Nav"> <div class="NavText"> - <a href="./burn.html" target="main">Burning</a> - </div> - </td> - </tr> - - <tr class="NavRow"> - <td class="Nav"> - <div class="NavText"> <a href="./publications.html" target="main">Publications</a> </div> --- 48,51 ---- Index: publications.html =================================================================== RCS file: /cvsroot/firebug/firebug/web/publications.html,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -d -r1.6 -r1.7 *** publications.html 14 Jul 2004 23:26:53 -0000 1.6 --- publications.html 14 Jul 2004 23:35:28 -0000 1.7 *************** *** 85,87 **** </body> ! </html> --- 85,87 ---- </body> ! </html> \ No newline at end of file |
From: Kevin <kar...@us...> - 2004-07-14 23:17:37
|
Update of /cvsroot/firebug/firebug/web In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv32171 Modified Files: introduction.html publications.html Log Message: Removed Professor Glaser's talk from the Introduction page to the Publications page Index: introduction.html =================================================================== RCS file: /cvsroot/firebug/firebug/web/introduction.html,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -d -r1.3 -r1.4 *** introduction.html 30 Jan 2004 18:39:16 -0000 1.3 --- introduction.html 14 Jul 2004 23:17:28 -0000 1.4 *************** *** 18,26 **** <h1>Introduction</h1> - <p> - <b>New!</b>Professor Glaser's - <a href="sensor_net.pdf">talk</a> on sensor networks. - </p> - <p> The FireBug system is composed of a network of GPS-enabled, --- 18,21 ---- Index: publications.html =================================================================== RCS file: /cvsroot/firebug/firebug/web/publications.html,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -d -r1.4 -r1.5 *** publications.html 9 Jul 2003 17:57:44 -0000 1.4 --- publications.html 14 Jul 2004 23:17:28 -0000 1.5 *************** *** 49,52 **** --- 49,59 ---- </li> + <li> + Professor Glaser's + <a href="sensor_net.pdf">talk</a> on sensor networks. + <p> + ABSTRACT: Talk on sensor networks. + </p> + </li> </ul> |
From: David M. D. <do...@us...> - 2004-07-14 22:46:57
|
Update of /cvsroot/firebug/firebug/web In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv27092 Modified Files: db_select.php db_table_select.php Log Message: Removed session variables from table selector. Index: db_select.php =================================================================== RCS file: /cvsroot/firebug/firebug/web/db_select.php,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -d -r1.6 -r1.7 *** db_select.php 4 Aug 2003 16:17:29 -0000 1.6 --- db_select.php 14 Jul 2004 22:46:48 -0000 1.7 *************** *** 25,28 **** --- 25,29 ---- $dbname = $HTTP_POST_VARS["db1"]; + mysql_connect("localhost","root","") or die("Error: ".mysql_error()." in mysql_connect."); $dblink=mysql_select_db("$dbname") or die("Error: ".mysql_error()." in mysql_select_db."); Index: db_table_select.php =================================================================== RCS file: /cvsroot/firebug/firebug/web/db_table_select.php,v retrieving revision 1.9 retrieving revision 1.10 diff -C2 -d -r1.9 -r1.10 *** db_table_select.php 14 Jul 2004 22:40:38 -0000 1.9 --- db_table_select.php 14 Jul 2004 22:46:48 -0000 1.10 *************** *** 1,6 **** <?php ! session_start(); ! session_register("dbname"); ! session_register("tblname"); ?> --- 1,7 ---- + <?php ! //session_start(); ! //session_register("dbname"); ! //session_register("tblname"); ?> *************** *** 42,45 **** --- 43,47 ---- $tblname = $HTTP_SESSION_VARS["tblname"]; + print("<h1>Mote activity: Database $dbname, table $tblname</h1>"); ?> |
From: Kevin <kar...@us...> - 2004-07-14 22:40:50
|
Update of /cvsroot/firebug/firebug/web In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv26024 Modified Files: db_table_select.php Log Message: Removed phpinfo() from db_table_select.php Index: db_table_select.php =================================================================== RCS file: /cvsroot/firebug/firebug/web/db_table_select.php,v retrieving revision 1.8 retrieving revision 1.9 diff -C2 -d -r1.8 -r1.9 *** db_table_select.php 7 Jul 2004 19:24:55 -0000 1.8 --- db_table_select.php 14 Jul 2004 22:40:38 -0000 1.9 *************** *** 33,38 **** <?php - phpinfo(); - //if (!isset($HTTP_SESSION_VARS["tblname"])) { if ($HTTP_POST_VARS["tbl1"]!=Null){ --- 33,36 ---- |
From: David M. D. <do...@us...> - 2004-07-14 22:07:44
|
Update of /cvsroot/firebug/firebug/web In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv19192 Modified Files: admin.html Log Message: Changed schema for collecting weather data. Index: admin.html =================================================================== RCS file: /cvsroot/firebug/firebug/web/admin.html,v retrieving revision 1.14 retrieving revision 1.15 diff -C2 -d -r1.14 -r1.15 *** admin.html 14 Jul 2004 21:42:25 -0000 1.14 --- admin.html 14 Jul 2004 22:07:35 -0000 1.15 *************** *** 122,127 **** <pre> USE DATABASE firebug;<br> </pre> Then create the tables: ! <pre> CREATE TABLE current (mote_id INTEGER,<br> time TIMESTAMP,<br> temp FLOAT,<br> rel_hum FLOAT,<br> baro_pres FLOAT,<br> cnt INTEGER);<br> </pre> ! <pre> CREATE TABLE cumulative (mote_id INTEGER,<br> time TIMESTAMP,<br> temp FLOAT,<br> rel_hum FLOAT,<br> baro_pres FLOAT,<br> cnt INTEGER);<br> </pre> Load the example.txt file using: --- 122,144 ---- <pre> USE DATABASE firebug;<br> </pre> Then create the tables: ! <pre> ! CREATE TABLE current (time TIMESTAMP, ! mote_id INTEGER, ! rel_hum FLOAT, ! sens_temp FLOAT, ! inter_temp FLOAT, ! pres FLOAT); ! </pre> ! ! <pre> ! CREATE TABLE cumulative (time TIMESTAMP, ! mote_id INTEGER, ! rel_hum FLOAT, ! sens_temp FLOAT, ! inter_temp FLOAT, ! pres FLOAT); ! </pre> ! ! Load the example.txt file using: |
From: David M. D. <do...@us...> - 2004-07-14 21:42:36
|
Update of /cvsroot/firebug/firebug/web In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv13566 Modified Files: admin.html Log Message: INfile data for mysql must be tab delimited. Index: admin.html =================================================================== RCS file: /cvsroot/firebug/firebug/web/admin.html,v retrieving revision 1.13 retrieving revision 1.14 diff -C2 -d -r1.13 -r1.14 *** admin.html 16 Feb 2004 02:03:06 -0000 1.13 --- admin.html 14 Jul 2004 21:42:25 -0000 1.14 *************** *** 127,131 **** Load the example.txt file using: <pre> LOAD DATA INFILE 'example.txt' INTO TABLE example;<br> </pre> ! The example.txt file must be located in the <code>$mysqlroot/data/firebug</code> directory for <code>LOAD DATA</code> command. The example data should now be displayed on its own <a href="./example.php">web page</a>. --- 127,132 ---- Load the example.txt file using: <pre> LOAD DATA INFILE 'example.txt' INTO TABLE example;<br> </pre> ! The example.txt file consists of tab-delimited data and ! must be located in the <code>$mysqlroot/data/firebug</code> directory for <code>LOAD DATA</code> command. The example data should now be displayed on its own <a href="./example.php">web page</a>. |
From: David M. D. <do...@us...> - 2004-07-13 12:57:03
|
Update of /cvsroot/firebug/firebug/doc/chassis In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31979 Modified Files: .cvsignore Makefile Log Message: Added bibtex ref files. Index: .cvsignore =================================================================== RCS file: /cvsroot/firebug/firebug/doc/chassis/.cvsignore,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 *** .cvsignore 2 Jul 2004 20:41:21 -0000 1.1 --- .cvsignore 13 Jul 2004 12:56:55 -0000 1.2 *************** *** 1 **** --- 1,2 ---- *.pdf *.dvi *.aux *.log + *.bbl *.blg Index: Makefile =================================================================== RCS file: /cvsroot/firebug/firebug/doc/chassis/Makefile,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -d -r1.3 -r1.4 *** Makefile 13 Jul 2004 12:54:43 -0000 1.3 --- Makefile 13 Jul 2004 12:56:55 -0000 1.4 *************** *** 13,15 **** clean: ! rm -rf *.dvi *.aux *.log *.bbl *.pdf *.ps *.blg \ No newline at end of file --- 13,16 ---- clean: ! rm -rf *.dvi *.aux *.log *.bbl *.pdf *.ps *.blg *~ ! |