High Voltage Shareware/high1.zip/high1/DIR15/BM105.ZIP/FORMAT.TXT

Text File | 1993-12-08 | 13KB | 365 lines

CASE- TAB-T MARG+1,77

Bike Manager (TM)
Copyright (C) 1991, 1992 Joern Yngve Dahl-Stamnes
All rights reserved.

e-mail: [e-mail]

Database file format, version 1.05.
-----------------------------------

NOTE: The modification done in version 1.05 adds new fields to the database
file. The program can read databases created by version 1.04 without
problems. But version 1.04 of the program cannot read a database created by
version 1.05.

The database is an ASCII file which can be typed out to the screen, printed
out on a printer or you can edit it in any editor. However, before you begin
edit a database file, you should know about the format of the file.

The header is the first part of the file. It consist of setup data, record
counts etc. A typical header:

09-02-92 11:39.26 rev=12
3 - 3 : 0 0 0 0 1 f9f
3 5 6 10 2
3 5 6 10 0 0 0
1 1 1 2 0 0

The first line contain the date/time for last saving and the revision count
(increased by one for each save operation). This line will be printed out in
the window when retrieving the file. The next line have 10 fields which are
setup data:

    1: Date format number (0 - 9).
    2: Date separation sign (single character).
    3: Time format number (0 - 3).
    4: Time separation sign (single character).

    Measurement types (0 = metric, 1 = nonmetric):
    5: distance
    6: height
    7: length
    8: speed
    9: temperature

    10: Option flags (32 bit value in hex format)

Line three contain, in order, the number of bikes, trails, training types,
training entries and calendar messages written in the database. Line four
contain the values used when new bikes, trails, training types or training
entries are created. This line should not be modified. The last line in the
header is flags that tells if rating, personal information and heart rate
monitor (HRM) information is present in the database. When these flags are
set to 1, these informations are present. 0 mean that they are not present.
The 4th number in line 5 tells the number of calendar messages in the
database (stored at the end of the database file).

The three 0's in line 4 and the two 0's 5 shall always be 0. These are just
spare values for futhure use.

If there is an error in on of the header lines, the error message "read
error, level=N", the number N gives the number of the line where the error
was found. If you get this error message while retrieving a database, check
the header line where the error occured.

In the following sections all information that are related to a bike, a
trail etc. are enclosed in {} parenteses. If one of these are missing, the
record cannot be read. In worst case the database cannot be read by the
program. The general format of each field are as follow:

    single_character_code=data, ...
or
    single_character_code=data <End Of Line>
or
    single_character_code=data}

All fields will begin with a letter (case sensitive) followed by a equival
sign (=) and then the data. For integer and float values, there might be
leading spaces, which will be ignored. A comma or a }-parentese will follow
the data exept for the data at the end of a line when there is more data on
the next line (the } parentese terminate the current record). All strings
must be quoted by double quotes (") (note 1).

Each field are described belowe. The [?] tell the type of data, where ? can
be as follow:

    b: Boolean flags (0 or 1).
    i: Integer values.
    f: Float values.
    s: Quoted strings (note 1).
    x: Hex bitmask values (no leading 0x).



The next section of the database file is the personal information fields.
This section is only present if it has been defined. Flag 2 in line 5 in
the header must be 1 if this section is present. Example:

#
# personal data
#
{n="Grey LeHound", a="Earth, The Solar System"
p="[phone]", y=1968, s=1, h=182.0}

    n: [s] Your personal name.
    a: [s] Your home address.
    p: [s] Your phone number.
    y: [i] Year of birth.
    s: [b] Your sex, 1 = male, 0 = female.
    h: [f] Your height.



If flag 3 in line 5 in the header is 1, then the next section is the heart
rate monitor data:

#
# HRM data
#
{n="Polar Accurex",  s="12345", f=f, l=3}

    n: [s] The montor brand name.
    s: [s] Serial number.
    f: [x] Bitmask flags.
    l: [i] Number of laptimes if the monitor got a stopwatch.



The bike section:

#
# Bike data
#
{I=1, n="C'dale R1000", b="Cannondale", m="R1000", s="123456789"
S=54.00, y=(1992,1992), X=1
d={Description text}
C={b="Cateye", m="Micro cc-6000"
o=17, s="123456", z=( 208,207.70)}, G=(0)}
{I=2, n="C'dale V2000", b="Cannondale", m="Delta V 2000", s="123456789"
S=48.00, y=(1992,1992), X=0
d={Mountain bike}
C={b="Cateye", m="vectra cc-7000"
s="12345", z=( 204,204.00)}, G=(0)}
{I=3, n="Trek", b="Trek", m="750", s="123456789"
S=19.00, y=(1990,1992), X=0
d={Description text¡
Up to 20 lines of 60 characters each}
C={}, G=(0)}

    I: [i] Unique identifier for the bike. No bikes must have the same ID.
    n: [s] The bike name that will appare in the menues.
    b: [s] Brand name.
    m: [s] Model name.
    s: [s] Serial number.
    S: [f] Frame size.
    d: [s] Description text (note 1).
    y: [i] Production year, purchase year (enclosed in () parenteses).
    C: Optionaly (C={} if not used), contain bike computer data:
        b: [s] Brand name.
        m: [s] Model name.
        o: [x] Option mask.
        s: [s] Serial number.
        z: [f] (Setting, actual setting).
    G: Gearing data, (0) if none, othervise:
        field 1: [i] No. of chainwheels.
        field 2: [i] No. of cogs.
        field 3: [f] The wheel size.
        field 4-N: [i] no. of teeths on freewheel followed by the cogs.
    A: [x] Attribute mask.
    X: [x] Preference mask.

If a bike doesn't got any computer, the argument to the C field should be
'{}' (see example above).



The trail data follows the bike data section:

#
# Trail data
#
{I=5, n="Around the corner!", m="none", A=210.1, a=(100,20), l= 100.00, s=5,
X=0, M=0, d={no comments}}
{I=3, n="Paris - Bouraix", m="France", A=10540.0, a=(9999,9), l=1234.00, s=9,
X=1, M=0, d={Description text for this trail.¡
Can consist of up to 20 lines each 60 characters long.}}
{I=1, n="Paris - Brest - Paris", m="France", A=850.3, a=(400,100), l=1260.00,
s=9, X=3, M=1, d={Trail description...}}
{I=4, n="To work and back home again", m="none", A=210.0, a=(120,30), l=15.60,
s=1, X=0, M=0, d={To work and back}}
{I=2, n="Trondheim - Oslo", m="Norway", A=2100.0, a=(1033,10), l= 540.00, s=9,
X=0, M=0, d={The Great Trail of Strength.}}

    I: [i] Unique identifier, no trails must have the same ID.
    n: [s] Trail name which you find in the menues.
    m: [i] Map reference.
    A: [f] Total Accumulated Altitude given in meters (note 2).
    a: [f] (max altitude, min altitude) given in meters (note 2).
    l: [f] Trail length, given in km (note 2).
    s: [i] Skill rate (0 - 9).
    d: [s] Description (note 1).
    X: [x] Preference mask.
    M: [b] Multiple stage trail.



Then comes the training data section:

#
# Training data
#
{I=6, n="Commuting", v=(  0.00,  0.00,  0.00), z=(0,0)
h=(  0.0,  0.0), X=0
d={description text}}
{I=4, n="Group training", v=( 50.00, 60.00, 50.00), z=(175,155)
h=(150, 5.0), X=0}
{I=3, n="Offroad training", v=( 30.00, 60.00, 60.00), z=(180,150)
h=(155, 10.0), X=0}
{I=2, n="Road training", v=( 50.00, 60.00, 30.00), z=(180,150)
h=(155, 7.5), X=1}
{I=5, n="Team Time Trial", v=( 90.00, 30.00, 90.00), z=(185,155)
h=(175, 10.0), X=7}
{I=1, n="Time Trial", v=( 90.00, 20.00, 90.00), z=(185,150)
h=(178, 5.0), X=0
d={Training type description text¡
Can have up to 20 lines with 60 characters each.}}

    I: [i] Unique identifier, no training type must have the same ID.
    d: [s] Description text (note 1).
    h: [f] (Average heart rate, deviation in %).
    n: [s] Training type name.
    v: [f] (Speed value, Endurance value, Power value).
    z: [i] HRM Target zone (Max,Min).
    X: [x] Preference mask.



The next section is the rating section. The flag 1 on line 5 in the header
must be 1 if this section is present:

#
# Rating data
#
{l=1, h=6
d={very light¡
light¡
normal¡
a little bit hard¡
hard¡
very hard}}

    l: [i] Low rating value.
    h: [i] High rating value.
    d: [s] Rating description (note 1).



Now comes the biggest section which contain all the training data entries:

#
# Log data
#
{I=001, D=(1992,1,12), R=(3,6,4,2), t=  4215, o=(   0.0,   0.0), l=  15.60
T=( 14.0, 12.0), r=(60,21,149), z=(145,175)
d={Notes about the workout etc.¡
Up to 20 lines with maximum 60 characters each.}}
#
{I=002, D=(1992,1,16), R=(3,6,4,2), t=  4512, o=(   0.0,   0.0), l=  15.60
T=(  9.0,  7.0)
d={just another trip to work!}}

    I: [i] Unique identifier, no training data entries must have the same ID.
    A: [f] Total accumulated altitude in meter (note 2).
    D: [i] Training date (year,month,day).
    R: [i] References (bike ID, training type ID, trail ID, Rating value).
    t: [f] Training time.
    o: [f] ODO value (before,after) given in km (ntoe 2).
    l: [f] Training distance (trip distance) given in km (note 2).
    h: [f] Optionaly, HRM data: (time over TZ, in TZ, under TZ).
    r: [i] Optionaly, HRM data: Recovery data (recover time,recover factor
           and average heart rate).
    z: [i] Optionaly, HRM data: Target zone (low,high).
    c: [f] Optionaly, Correction factor.
    X: [x] Mask value (not used, for futhure expansion 8-).
    T: [f] Temperature, (max,min) given in celcius (note 2).
    d: [s] Description, freetext (note 1).

The correction factor is used to correct for the wheel setting on your
bike computer. The values in the 'o' and the 'l' fields are multiplied
with this value when the data are processed (note that the data for
these fields in the database file are what you punched in). The z field
(HRM target zone values) are fields which are copied into the data entry
when it is created. The source is the training type that the user
select. Field I must be present before the training data entry is legal.
The X field are not in use in the current version of Bike Manager.



The second last section is the goal records:

#
# Goal data
#
{T=1, n="test-1", r=(1), l= 2000.0, D=(1992,1,1,1992,6,1)}
{T=1, n="test-2", r=(1), l=10000.0, D=(1992,1,1,1992,12,31)}

    T: [i] Type of goal, the number correspond to the menu you get when you
       define a goal (range 1 - 4).
    n: [s] The goal name.
    r: [i] Bike or training IDs. Note the parenteses.
       (ie: "r=(1)" or "r=(1,4,5)").
    l: [f] Length field given in km (note 2).
    D: [i] Date range (from year, -month, -day, to year, -month, -day).
       Only valid for goal type 1, 2 and 4.
    P: [i] Date range (from year, -week, to year, -week).
       Only valid for goal type 3.
    c: [i] Count, valid only for goal type 2.

Note that some of the fields are only valid for some goal types. Mixing
fields that are used by different goal types will cause unpredictable
results.



If there is any calendar messages in the database, they are located at the
end of the file. The number of these messages are stored as the 4th value in
line 5 in the header. A typical section of calendar messages in a database
file may look like this:

#
# Calendar messages data
#
{D=(1993,3,22), X=0, d="Time to get the racer out on the road... "}
{D=(1993,6,19), X=0, d="The Great Trial of Strength              "}

    D: [i] Message date (year,month,day).
    X: [x] Message options (not currently used).
    d: [s] The message.



note 1:
-------
Since the description text for trails and training data entries can consist
of more than one line, the format of the description may look like this:

d={this is line 1¡
this is line 2¡
this is line 3, the last one}

Note that these lines are not quoted, and the each line (exept for the
last line) is terminated by ASCII character 173. Any quote will be
treated as a part of the text.

note 2:
-------

All values for length, distance, height and temperature are internaly stored
as metric values regardless of what the user prefer. If the user select
non-metric values, the metric values are converted to non-metric when they
are printed out.

---- end-of-file