Introduction
Before diving into the specifics of collecting, saving, and managing your datasets, it’s important to understand how the BDS software handles file creation and storage behind the scenes. While much of this behavior is designed to streamline your workflow, the default settings may not always align with your organizational preferences or testing requirements. Knowing where your data is going—and how the software behaves under different logging conditions—will help ensure that nothing is misplaced, overlooked, or unintentionally overwritten.
This article walks through the initial file save behaviors you will encounter when first launching the software, demonstrates how data is logged under various run conditions, and provides guidance on customizing your file paths and naming conventions as your testing becomes more structured. By understanding these foundational behaviors, you can ensure your data is captured reliably and stored in a way that supports efficient analysis and long-term organization.
A Note on the Default File Save Settings
Before starting the process of logging your datasets to file, it is important to understand where the default settings will be placing your files.
When you open the File Options dialog (by navigating to File->File Options) for the very first time, you will find that none of the checkboxes or text fields have been populated, in particular the "Folder" text field:
When no path has been defined, the BDS software will create a folder on the C: drive named "TRK" where all dataset information will be added and appended to a single file named "Capture CSV1_0.csv".
To keep yourself and your data organized, it is advisable that you change the save folder location to one which has specific relevance to you or your activities. To do so, you must first check the "Enable Auto-Save" box to enable the file selection controls, then click on Browse... to specify a location.
The "TRK" folder will still get created, but when the dataset information is saved it will create a log file that has the date and time included with it:
Additional file save settings will be covered in the remainder of this article.
Logging a Single Fixed Duration Dataset
The default behavior for saving data is to do so within the same log file. To illustrate, let us assume you are working in standard tracking mode with the frequency selection settings configured such that the fundamental is 13.56 MHz with a detection filter of 100 kHz and all the Tracking Settings at their defaults.
Select Mode->Options to expose the Configuration dialog, then navigate to the Free Run tab. Let us assume you define the No. Datasets as 10 with the Display Data Rate set to 500 ms to give you five seconds worth of dataset information (click the Apply and OK buttons to confirm the changes).
After you click on the Run button, you will see that the dataset count reaches 9 (because the index starting at zero).
When you check your folder location for the saved data files, you will notice something interesting - there is no file:
At this point, the BDS software is assuming that there is no need to save the data since you may simply be getting comfortable with your configured settings. Only after you manually save the data (navigating to File->Save) will you see your data file appear in the target location.
Upon opening the file, you will find your ten datasets logged at 500 ms intervals.
If you were to run again and save after, you will find a second series of ten datasets appended after the first.
If you are comfortable with your setup and want to ensure your data gets saved after each run automatically, you can navigate back to File->File Options and check the Enable Auto-Save option, followed by Apply then OK.
Continuous Logging of Data
Now consider the case when you want to sample as fast as possible for a long duration, such that your Display Data Rate is 2 ms and your number of datasets is 150,000, making it such that you collect 5 minutes worth of data:
While the 5 minutes of this example is quite large in comparison to the 5 seconds of our last example, it is difficult to argue that it should be considered a long duration. This 5-minute example does help us illustrate some behavior that you will need to be aware of.
Allowing the sample interval to run to completion, you will notice that the software has created two separate data files instead of one.
Looking at the contents of the first file, you will find that the software breaks the log files up to limit to about 100,000 datasets per write. In this case, the first file will have about 100,000 datasets and the second file will have about 50,000 datasets.
One thing to be aware of is that if you were to click run again for another 5-minute sample interval both these files will get updated with another 100k readings in the first and another 50k readings in the second, effectively doubling the size of each.
To sample approximately 24 hours using the 2 ms display update rate, your dataset count would be 43,200,000, giving you 432 separate data files to work with.
You also have the option of applying continuous sample for an indefinite amount of time. You would do so by checking the "Continuous Scan" option in the Configuration->Free Run tab. Note that in this case your Start button click will eventually need to be followed by a Stop button click in order to finalize your testing.
One advantage to keeping your dataset count small is that it helps limit the amount of PC memory used by the software application to hold the accumulated datasets before they are written then discarded. In the case above, the software will write to file and start filling a new memory buffer every 2 s.
Customizing Your Log File Path and Naming
As your testing gets more involved, you may want some assistance in organizing your file saving. The BDS software allows for defining your data file path by tool, operator, recipe, batch, and run number as shown below:
A test run completion will build the folder structure and populate a dataset file in the path:
Conclusion
This article explains how the BDS software handles dataset logging under both default and customized file save conditions. It begins by detailing the default behavior when no save path is defined, including the creation of the “TRK” folder and automatic naming of log files. It then walks through how data is saved (or not saved) during short, fixed-duration runs, and how the software manages file sizes during long or continuous sampling—such as splitting large logs into multiple files of approximately 100,000 datasets each. Finally, the article covers how to tailor your file path and naming structure using tool, operator, recipe, batch, and run identifiers to better organize your data as testing requirements become more advanced.
Comments
Article is closed for comments.