We're new to using the NL115 add-on device with a memory card, and I'm having some difficulty understanding how best to use the card. I thought the cardout() instruction would be sufficient to store data tables on the card, but it seems that any changes to the program, e.g. by changing an entry in the constants table, invalidates the files already defined on the card, and the tables are no longer written to it.
We commonly use the constants table for field-adjustable settings, e.g., sensor calibration constants, SR50A height above the ground, but those change the program signature and apparently invalidate the existing files. Similarly, uploading a new program via telemetry appears to cause the files not to be written.
Am I wrong in this interpretation?
A possible solution might be to include the program signature in the table file name on the card, so that any program change would write to a new file. (We specify the table sizes on the card explicitly, so they don't use all of the
card.) But I don't think that's something we can do in CRBasic.
Maybe we're better off using tablefile() to write to files on the card under program control?
Our hope was to rely on data being written to the card so that all data could be retrieved by swapping cards, e.g., during a brief visit by helicopter. As it is, it seems we still need to fire up loggernet and download the data from the logger.
Any pointers on using the card to completely back up data logged on the logger, even after program changes? Thanks!
Ken,
Just for clarity, the files are still "valid", you can eject the card and retrieve your data.
What you are experiencing is a property of CardOut(). It is a protection mechanism designed to keep people from accidentally losing / overwriting data stored on the card or corrupting an existing file. There is this distinction over TableFile() because CardOut() makes the card "extension" of the logger memory instead of simply being a storage device.
I think you are on the right path. TableFile() is a much better fit for what you are trying to do.
Give the following a spin. I think it's what you are looking for.
TableFile ("CRD:" & Status.SerialNumber & "_Test_",64,-1,0,24,Hr,OutStat,LastFileName)
Experiment with different format options and intervals. Option 64 and 8 are the most popular, but they do behave differently.
64 will pre-allocate a file large enough to handle an interval's amount of data (in this example 24 hours). Data will be written to the card when about 1K of data is buffered up. When the interval is up, the file will be closed and the next file will be pre-allocated. If the remove card button is pressed, the 1K buffer will be flushed to file and the file will be closed; I.e this happens really quick. When the card is reinserted, a new file will be created.
8 (and all other formats) will wait until the interval is up, create a new file, write an interval's worth of data to file, and then close the file. When the remove card button is pressed a new file will be created, all the data since the last write event will be written to file, and then the file is closed. The time required to complete a card removal will be dependent on how much data needs to be written to file. If flushing times are too long, but option 64 isn't a good fit for you, you can add 100 to the format option (e.g. 108) to tell the logger not to flush any unwritten data when the removal button is pressed.
Much of what I've described here applied to OS25 in the CR800, CR1000, CR3000.
Thanks for the explanation. TableFile() does seem to do what we need.