Couple of Memorystick-questions
Moskog
Posts: 554
Trying to understand the datalogger, I ran into a few things here:
First, when using SEROUT the ["WRF"] is similar to [$07 , $20] right?
Next thing..
The following four bytes (after WRF) in this example ($00,$00,$00,$07):
And finally, why use Carrige Return, LineFeed and then Carrige Return once again at the end of the line?
Explanation will be highly appreciated!
First, when using SEROUT the ["WRF"] is similar to [$07 , $20] right?
Next thing..
The following four bytes (after WRF) in this example ($00,$00,$00,$07):
SEROUT TX\CTS, Baud, ["WRF", $00, $00, $00, $07, CR, variable, CR, LF, CR]As I understand they stands for a size of something that will be written at the end of the datafile, size of what?
And finally, why use Carrige Return, LineFeed and then Carrige Return once again at the end of the line?
Explanation will be highly appreciated!
Comments
The size ($00,$00,$00,$07) is the actual amount of data to be written (or read) to the file. The Datalogger wants to know this before it sees the data.
The first CR/LF is considered to be data for writing to the file. It's included in the size value. When you read the file from the memory stick, that CR/LF will be there and acts as a delimiter for the variable value. The last CR indicates the end of the command to the Datalogger.
Read the Firmware Manual for the Vinculum 1 chip used in the Datalogger. It's downloadable from ftdichip.com. There are other examples of these commands.
OK, I do have the Firmware Manual, it was just a few things that was a little bit hard to understand.
When you talk about the actual amount of data, you mean the number of bytes, right? In the example above the Datalogger will expect seven bytes to be written each time the file is opened, is that correct? Or does the separators also count, like: [var1 , var2 , var3 , var4] ..?
Once again, Thanks for quick reply, Mike.
The CR after the $07 is not included in the data, but all 7 bytes that follow, no more no less, are written to the drive. Those bytes can be any ascii code from $00 to $FF, no special codes, because it is all based on the count. I
Do you want to write a text file with printable characters? If so, the variable has to have modifiers something like this:
The data written to the disk will be the 5 ascii digits of the variable, followed by the end of line CR LF. That makes 7 characters, "12345" CR LF. The final CR would not be written on the disk but would instead be interpreted as a command to the drive (resulting in an extra ">" prompt). If the modifier were DEC4 instead of DEC5, then the 7 characters written to disk would include the final CR too, not "12345" CR LF CR, but "1234" CR LF CR.
You have to be very, very careful to get the count right. Too few, and the datalogger just sits there waiting for the rest that it expects, and what you think are supposed to be the next commands end up as part of the data. Too many, and the extra bytes inadvertently become commands, usually nonsense that throws an error and puts the datalogger out of sync. Again, get the count right.
Note that I set RTS low before doing the serout and then back high after sending all the bytes. The RTS low signals to the datalogger that the Stamp is ready to receive data (even tho it is not really executing a SERIN). The datalogger checks that RTS signsl after it has received about 25 characters from the Stamp, and will lock up if it finds that line at a high (=not ready) level. The datalogger does not actually send anything on the rx line, so the Stamp is not missing anything, but it is a quirk in the datalogger firmware.
So this is why we are making this logger who will detect frequency (Hz) and voltages from several parts of the generator system and do this over a periode of a week or so.
To be able to catch a failure we want the logger to record parameters every half minute or so, making some 2880 records a day. To avoid extremely big files we want the logger to create one file for every day, seven days seven datafiles.
I thought we could name a datafile by using time codes from an RTC, like this:
With DEBUG and today's date that will look like "24-08-11.txt" and would have been a good filename. But the logger seems to not accept the HEX2-formatter.
The same problem occured when trying to include time-codes in the datastring itself, like in this example:
So while the datalogger doesn't seem to accept HEX2 formatters, are ther other ways to solve the problems with dynamic filenames and time codes here?
HEX2 Hrs, ":",HEX2 Mins,",",DEC2 Variable1,",", DEC2 Variable2, CR, LF
So we should see "WRF ", $00, $00,$00, $0D and not "WRF ", $00, $00,$00, $0C
Hex characters are transmitted in ASCII form just as DEC characters are so using HEX in your data strings should not be a problem
Jeff T
Jeff, you are right about that, the example above was written this morning from my work-computer and not part of the actually bs2-file here at home. I didn't see that error before I posted. But, I will check the actually file very carefully to be sure the count is right.
On the filename issue we tried to open a new file with this command:
We used Mins as a debug just to see if a new file was created after the loop had run into the next minute. On the finished program that would be changed to Year. But this way didn't work and I cant understand why.
SEROUT TX\CTS, Baud, ["OPW capture1.txt", CR]
If that command does not create the file, that means either that the command buffer was not purged, or that there is a bad hardware connection. Try it on a different USB stick too. Most will work fine, but occasionally I run across one that has a problem. The HEX modifier is not the problem.
The count was really wrong in my program, I guess the error was due to late hours last night. Thanks Jeff for pointing me into the right direction today, also to Tracy Allen for trying your best to hammer the same thing into my mind yesterday and finally thanks to Mike Green for always open up the blinds in my basicstamp-world.
The filename issue is also solved, shame on me I didn't put a space after OPW in my bs2-file:
But in my example written in my post this morning I did, so the post was probably more confusing then neccessary.
If you want some practical application code which does switch instruction modes and handles initialization very easily, please check out the GPS Data Logger project. I will be expanding greatly on this project in the near future.
Hello Chris, yes we used your GPS project as a resource when making our logger program. Our project is basically a logger for temporary use, just to try to figure out the problems with the power generator mentioned in a post above. But now, when the doors are opened to the data-logging world we see many other situations when such a logger could be used. Your GPS-logger is very interesting, as a project itself, but it is also [always] very interesting to study your programming technics.