Hi, I am new to CRBasic.
I am trying to write a table of atmospheric pressure values collected to a CF card reader attached to the datalogger. It is a 2 GB card and so using the instruction CardOut(0,-1) creates a hopelessly large table. I would like to change the record size to store approximately 1 months data..Taken twice hourly this gives 1440 records..CardOut(0, 1440). Is this the correct instruction?or is it more complicated than that?
Also if I wish to add more data to the table for example other sensor information such as temperature does the 1440 refer to the number of rows, not columns?
Any feedback would be appreciated.
Thank You
ac,
CardOut(0,1440) would write the last 1440 data "rows" to a table on the card.
Hi Sam
Thank you for your reply, it is welcomed. I also have another query. Since the posting, I wrote a small program, with the help of the CRBasic Help menu
Public P_temp
Public Pressure
Units Pressure=mbar
DataTable (Flux, True, -1)
DataInterval (0,2,Min,0)
CardOut (0,2)
Sample (1,pressure,IEEE4)
EndTable
BeginProg
Scan(1,sec,3,0)
'CS100 Barometric Pressure Sensor measurement BP_:
VoltSe(P_temp,1,mV5000,1,1,0,250,0.2,600.0)
If IfTime(1,2,min) Then WriteIO (&B10,&B10)
If (IfTime(0,2,min)) Then
pressure=P_temp
WriteIO (&b10,&b0)
EndIf
CallTable Flux
NextScan
EndProg
I was suprised to find that although I wrote CardOut(0,2) when I looked at the data on the CF card there was more than two rows of data. Do you know why that is?
The short answer to your question is that the number of records parameter in the CardOut() instruction is more of a statement like the following:
"I want the table, under normal circumstances to have a minimum of x records."
The long answer requires some detail about the way that the datalogger allocates storage in card memory. The datalogger uses a somewhat complex format, known as TOB3, to store records in card storage. This format divides the file into segments, called major frames, that store the table data. The purpose of this format is to allow the datalogger to "compress" the data as it is written by only writing the time stamp of records on a frame boundary. The number of records parameter in the CardOut() instruction becomes one of the inputs to the compiler as it determines the number of these major frames to allocate for the table file.
For a datalogger program running under "normal" circumstances (no power down events, no file marks written, and no skipped scans), interval driven data records with a continuous sequence of time stamps can be laid down side by side within these major frames quite efficiently. If, however, some event such as a skipped scan or power down event causes a disruption in the sequence record time stamps, the datalogger compensates by creating a sub-structure, a minor frame, within the major frame that holds the new base time stamp. Naturally, the header and footer of this "minor frame" use up storage that could have otherwise been used to store record data.
What I mean to demonstrate in this rather long winded description is that there is a degree of variability in the number of records that the datalogger is actually able to store. The datalogger compiler, when taking the number of records specified in the CardOut() instruction into account, attempts to apply a "fudge factor" that can be used to compensate for things like skipped scans and still be able to honour the specified number as a minimum number of records. The result of this fudging is that, with no skipped scans and etcetera, the actual capacity of the table file will be somewhat greater than what was specified.
Thank you very much for answer. That makes perfect sense and has also given me a bit more insight into storage. I have now rerun the file with some new boundaries using cardout(0,-1000) to mimic the storage on the datalogger.
Thanks,
AC