{ [ ] Projects >>> [Hardware] - [Software] - [Class] - [Other] - [Failed] -|!|!|- [Resources] - [Biography] - [Contact] - [ ] }
Autodatalogger
This is an autodatalogger program: feed it a series of variables, set it loose, and it will quietly log the variables in the background. It uses the Parallax Datalogger USB thumb drive interface, which allows the data to be read easily on any computer as a txt file.
Program Overview
This program will automatically log hub variables as fast as possible to the USB Datalogger from Parallax. It does this in the background, with no oversight once start is called. Logging will continue until a critical failure, loss of power, or the Spin function stop is called.
This project uses the USB Datalogger from Parallax.
Hardware Setup
Datalogger:
Connect the Datalogger to the Propeller as follows:
1. Datalogger pin 2 to Propeller CTS
2. Datalogger pin 4 to Propeller TX
3. Datalogger pin 5 to Propeller RX
4. Datalogger pin 6 to system ground
Each connection has a 2K resistor, although down to 100ohm will probably be fine.
Don't forget to connect the datalogger to a 5v supply.
Propeller:
This object requires 80Mhz or more to operate correctly. It is possible to run
slower, but in that case a new baud rate will need to be choosen
for the fast speed. Should slower operation be required, the
following changes should be made:
1. In the init method, change the divisor in bit_ticksFast to
the slower baud rate.
2. In the PASM set_speed, the first two bytes must be changed to
match the table in the Datalogger firmware specification.
This object requires three pins on the Propeller
Software Setup
Once launched, this program does not require any oversight.
Object configuration:
1. Filename: A single filename can be used with this program.
2. File Close Frequency: The frequency with which a file can be "saved to disk"
is configurable. A low value will close the file frequently,
while a higher value will close the file only once in a great
while. Note that until a file is closed, the data is not "saved"
and could be lost in the event of a failure (brownout, disk
removal, etc.). The tradeoff is that the more frequently a file
is saved to disk, the slower the logging occurs. Additionally,
as a file grows very large, a "save" has a much higher cost than
a smaller file. See the benchmarks section below for more information.
3. Field/Watches: The heart of the program is the ability to watch 32bit,
unsigned numbers. The number of variables to watch is completly
configurable, from zero to about 125. Each variable to watch has
two associated pieces of information: a column label (most
likely the name) and the number of digits to log. The number of
digits to log specifies how many decimal digits (starting from
the right) to store. For example, the number 12345 is five
digits long. If the digits value is too small for the number,
the upper digits will be truncated. If the digits value is too
large, the number will be padded with leading zeros. Note that
signed numbers are not loggable at this time. There isn't a set
limit on the quantity of variables to watch, but the total
number of digits plus the number of variables cannot exceed 244:
digits + fields < 244
Object inconfiguration:
1. The object will always log the current system clock value.
2. The object will always log automatically, and cannot be interupted to log something else.
Benchmarks
All tests run for ten minutes.
A = File close frequency
B = User supplied bytes logged per sample
The sum of the passed digits
Does not include commas
Does not include the system clock field
C = Samples per second at the start
D = Samples per second at the end
E = File Size
Samples per second is calculated as follows:
1. Find the difference between the n and n-1 system clock log for the first 101 logs.
2. Average the difference
3. Divide 80_000_000 by the average
Note that if there is a 32 bit rollover, the negative number in the middle is ignored.
HP 4GB USB Drive (with cheap black plastic wood grain cover)
+----------+------------+------------+------------+------------+
| FCF | Bytes per S| SPS start | SPS end | Size KB |
+----------+------------+------------+------------+------------+
|
1|
200|
39.69|
14.51| 2_809|
+----------+------------+------------+------------+------------+
|
10_000|
200|
41.51|
60.54| 7_634|
+----------+------------+------------+------------+------------+
|
1|
10|
53.05|
34.71| 602|
+----------+------------+------------+------------+------------+
|
10_000|
10|
95.87|
91.23| 1_299|
+----------+------------+------------+------------+------------+
Lexar 512MB Firefly USB Drive (with green cover and blinky blue light)
+----------+------------+------------+------------+------------+
| FCF | Bytes per S| SPS start | SPS end | Size KB |
+----------+------------+------------+------------+------------+
|
1|
200|
22.47|
10.78| 1_750|
+----------+------------+------------+------------+------------+
|
10_000|
200|
27.16|
26.47| 3_656|
+----------+------------+------------+------------+------------+
|
1|
10|
26.34|
16.00| 266|
+----------+------------+------------+------------+------------+
|
10_000|
10|
32.59|
32.83| 453|
+----------+------------+------------+------------+------------+Benchmark Conclusions:
1. The specific USB drive has a significant bearing on SPS
2. Large file close frequencies have a minimal effect on the overall SPS
3. Long term datalogging should not have low file close frequencies
4. High spee of a single variable is possible (~95 hz).
Attachments
(Right click and "Save Link As...")
AutodataloggerV1.zip
(c)2010 Cody Lewis
lewisc@cs.ucr.edu