3 – Using the DL
30 DL™ User Manual Rev 3
Table 5: Auto-Generated File Name Convention
####$$$%.PDC Comments
#### last 4 digits of the DL’s serial number
$$$ UTC day of the year (001 – 366)
% Session ID assigned in sequence (0 .. 9, A .. Z) based on the
presence of files previously logged on a particular day.
For example, a DL might have a serial number such as CGN95450087. A date such as January 25 has an UTC day-of-
year representation of 025. The 15
th
schedule of the day would have an entry index of E. Thus, this file would have a
name such as 0087025E.PDC.
Should a conflict occur between an auto-generated file name or a file name specified in a scheduled entry, the DL will
resolve the conflict by creating a file name whose first character is a tilde (“~”), followed by a 7-digit random number,
and a .PDC extension (e.g. ~9368412.PDC).
DATA STORAGE REQUIREMENTS
Based on default settings (using RGED logs for observations, and PRTKB logs for positions), Table 6 displays the
amount of data storage required for a single data record for scenarios of 6, 9, or 12 satellites in view.
Table 6: Storage Requirements per Data Record
L1-only L1 & L2
Single-point
Observations
(Bytes)
Single-point or Differential
Observations & Positions
(Bytes)
Single-point
Observations
(Bytes)
Single-point or Differential
Observations & Positions
(Bytes)
6 SV
144 268 264 388
9 SV
204 328 384 508
12 SV
264 388 504 628
The number in a specific cell in this table represents the memory consumption (in bytes) per recorded GPS point, for a
given number of visible satellites and a given recording mode. The following relationship, based on Table 6, yields an
estimate of the data storage requirements for a data-recording session:
• Minimum file size (in bytes)
≈
(bytes per record) x (records per hour) x (number of hours)
This is an approximation - the actual file size will be a few kilobytes larger, due to file headers and other information
(e.g. satellite ephemeris and almanac data). Also, feature tagging increases the file size by an amount that depends on the
number of features tagged, and the number of attributes for each feature.
Example from Table 6:
You wish to record single-point observations, once every 2 seconds, for 8 hours, with 9 satellites visible, during L1/L2
operation. The file size will be no less than (384 bytes/record) x (1800 records/hour) x (8 hours) = 5,529,600 bytes =
5529.6 kBytes
≈ 5.3 MBytes. At this rate, a 20 MByte PC Card could hold approximately 30 hours of data.
Based on the values in Table 6, one can calculate how much data is generated in one hour if the RGED and PRTKB logs
are collected every two seconds. This is the typical data-logging rate for real-time kinematic (RTK) survey applications.
The cells of Table 7 reflect the memory consumption, in kilobytes per hour, for scenarios of 6, 9, or 12 satellites in view.