Memory Stick Datalogger (Item 27937)
chip65
Posts: 3
I recently purchased the Memory Stick Datalogger (Item 27937) and am investigating its potential using the DataloggerDemov1.0.bs2 program running on the OEM version of the BS2 stamp. I hooked up the photocell and capacitor as noted in the program.
I am having difficulty in two areas.
1) The slow sample rate.
2) Deciphering the hex code used in communication with the datalogger.
As for the sample rate, prior experience was that writing to EEPROM I can get around 30 samples per second easily. However, the datalogger is only getting about 4 samples per second by removing the half second pause on line 128. Thinking the thumb drive is a factor, I tried three different thumb drives and got a variance of 0.8 samples/sec. I was hoping for a rate of 20 samples/sec or so. Are there any ideas for increasing the sample rate?
Although I have read the VDAPfirmwareSpec.pdf and the BS manual, I do not fully understand what the hex code in the SEROUT commands mean and how to manipulate it to useful ends. I would like to know how to add column headers to the logged data fields and how to add additional input data from multiple sensors to be logged. To achieve this objective, I first need to understand some of the code in DataloggerDemov1.0.bs2.
Referring to program line 126 & 127, the goal is to log the counter and result. Each is a WORD size. According to page 11 of the VDAP document, to write data, we start with hex instruction $08, $20. Next is the size of the data we want to write. In this sample program, we have $00, $00, $00 or twelve bytes of data. However, we are only writing DEC5 counter, and DEC5 result which are a WORD each. I suppose the comma counts for something too but it appears there is quite a bit (or bits) unaccounted for. Can anyone provide an explanation starting with the program line 126 & 127 SEROUT TX\CTS, Baud, [noparse][[/noparse]$08, $20, $00, $00, $00, $0D, CR, DEC5 counter, ",", DEC5 result, CR, LF CR] ?
How can I manipulate the hex instruction to accommodate several more inputs?
I am having difficulty in two areas.
1) The slow sample rate.
2) Deciphering the hex code used in communication with the datalogger.
As for the sample rate, prior experience was that writing to EEPROM I can get around 30 samples per second easily. However, the datalogger is only getting about 4 samples per second by removing the half second pause on line 128. Thinking the thumb drive is a factor, I tried three different thumb drives and got a variance of 0.8 samples/sec. I was hoping for a rate of 20 samples/sec or so. Are there any ideas for increasing the sample rate?
Although I have read the VDAPfirmwareSpec.pdf and the BS manual, I do not fully understand what the hex code in the SEROUT commands mean and how to manipulate it to useful ends. I would like to know how to add column headers to the logged data fields and how to add additional input data from multiple sensors to be logged. To achieve this objective, I first need to understand some of the code in DataloggerDemov1.0.bs2.
Referring to program line 126 & 127, the goal is to log the counter and result. Each is a WORD size. According to page 11 of the VDAP document, to write data, we start with hex instruction $08, $20. Next is the size of the data we want to write. In this sample program, we have $00, $00, $00 or twelve bytes of data. However, we are only writing DEC5 counter, and DEC5 result which are a WORD each. I suppose the comma counts for something too but it appears there is quite a bit (or bits) unaccounted for. Can anyone provide an explanation starting with the program line 126 & 127 SEROUT TX\CTS, Baud, [noparse][[/noparse]$08, $20, $00, $00, $00, $0D, CR, DEC5 counter, ",", DEC5 result, CR, LF CR] ?
How can I manipulate the hex instruction to accommodate several more inputs?
Comments
The hex command set is just the shorter version of the normal (extended) command set. There is nothing really special about it.
The sample rate is highly dependent on the usb drive, but it also depends on the rate at which you are sending data to the USB drive. At 9600 baud, you can transmit 1200 bytes per second. If you are logging 13 ($0D) bytes per sample (5 numbers and two control chars) with 8 datalogger command chars, that is a maximum rate of 57 samples per second. But, you also have to do other things too (including waiting for the reply/flow control and running the other BS2 code).
SEROUT TX\CTS, Baud, [noparse][[/noparse]$08, $20, $00, $00, $00, $0D, CR, DEC5 counter, ",", DEC5 result, CR, LF, CR]The first two bytes ($08 and $20) indicate to the datalogger to write to the open file (OPW). The next four bytes is the size of the data that is going to be sent. In this case it is $0D, so that is 13 bytes. It is followed by a CR which is a spacer between the size of the data and the data. DEC5 indicates to convert a number to decimal and to send out the lower 5 ASCII bytes worth. A comma counts as a single byte, and there is another DEC5 after that. The CR and LF make a line break in the text file. It is all closed off by a CR which indicates the end of the command.
As for the column headers, you can send pretty much anything to the datalogger. You'll probably want to add in a write command at the beginning of the program that sends this information out. In the case of the sample program, such a header might look like this:
SEROUT TX\CTS, Baud, [noparse][[/noparse]$08, $20, $00, $00, $00, $10, CR, "counter,result", CR, LF, CR]Edit: I made a mistake. As Chris points out in the next post, the command is the WRF command, not the OPW command.
Post Edited (SRLM) : 9/25/2009 11:58:23 PM GMT
The $08 and $20 form the command ‘WRF’ or write data to file. The parameters that follow state how much data is in that one write command (CR terminated). The comes the data itself, which is also $0D terminated. Finally the entire command is terminated with the CR. So, our 32-bit value for the number of bytes of data just happened to be $0D which is 13. So we’re saying we are writing 13 bytes out in this WRF command. 5 bytes come from the DEC5 counter command. Next a comma is written out followed by DEC5 result, CR, LF and the terminating CR for the command. So our 13 bytes consisted of #####,#####CRLF. Remember the last CR terminates that command. I hope this helps. Take care.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
50 72 6F 6A 65 63 74 20 53 69 74 65
·
Can I increase the sampling rate simply by increasing the Baud?· If so, all the documentation on BS2 tops out at 9600 (code 84).· What code should I put in increase the speed?
My main interests are in sensor monitoring and eventually, motor control.
Given the options of purchasing the BS2px, or one of the Propeller·kits can you make a recomendation?
have saved some weeks of data, writing 300 seconds-worth of data to each ascii file, but it ended after 3 days. I note that
there were 512 files produced. Is there some sort of (undocumented?) file system limitation that prevents more than
512 files in a single directory ? (or maybe my batteries just happened to run out at 512 files, but that is unlikely)
en.wikipedia.org/wiki/File_Allocation_Table
Question is, whether I have the space on the BS2 to code in dealing with directories..... am already close to maxed out dealing with the serial comm to the datalogger, talking to a DS1307 real time clock, and an MCP3208 ADC......··· a good challenge for me