This documentation: © 2005, 2006, 2009 Mark Hämmerling.
Revision: 2009-06-08-A.
This document specifies the streaming format of Log1 Type databases for the VeloAce Open Source Bike Computer System for Palm OS.
Please note that this is not yet a finalized official specification. Please do not rely on the information stated here, as this document is still under development.
| Creator ID | Type |
|---|---|
| 'VAce' | 'Log1' |
Any section of a stream compatible to the Log1 Container Type is prepended with a
Log Session Init (LSI) event. A new stream section is started with each new log session, i.e. when the user
initiates a new log database or appends to an existing log database. All values defined during the previous log session
shall be reset to their default values upon opening a new log session.
Each log session is closed with a Log Session End (LSE) event, indicating that the session was properly
shut down and no software or hardware malfunction did interrupt the recording.
Note: The LSI event code was chosen in such a manner that it does not conflict with known codes from Log0 databases. This helps identifying Log1 Type streams.
Note: Mixing Log0 and Log1 data within the same database is
discouraged and only described here in order to allow developers to make their
analyzing algorithms as robust as possible.
VeloAce will not support recording mixtures of Log DB Types, so it should be
safe to decide about the type of database at the very first event (LSI or not).
The analyzing algorithm shall start interpreting the data as a Log0 stream. Upon detection of an LSI event code, it shall switch to Log1 mode and continue interpreting the succeeding data as a Log1 stream, until the detection of an LSE event, which switches back to the Log0 interpreter for compatibility.
There is no global database header. Each contained log session is initiated and ended through events.
When analyzing a Log1 Type DB, reading of data specified as reserved shall lead to a fatal error, as interpreter errors
are an indication for unsupported features that might lead to misinterpretation of the data.
As an option, the interpreter might just print a non-fatal warning message upon reading reserved events and continue
trying to decode the stream.
The data is recorded as a stream of bytes. It starts at record #0 and is then continued in the next record, wrapped at any byte(!) on each 16384 Byte (16kB) boundary.
The stream consists of concatenated events, each initiated by an Event Header (EH) byte. Each event consists of two (EH only) or three (EH, plus data) parts:
The type and length of the event data is encoded in bits 2..0 of the Event Header byte. Listed are the masked values (bit mask 0x07):
| Value | Data type | Data format |
|---|---|---|
| 0x00 | Integer | No data following, or zero (when treated as integer). |
| 0x01 | Integer | 1 byte of data following. |
| 0x02 | Integer | 2 bytes of data following, encoded in big-endian. |
| 0x03 | Integer | 3 bytes of data following, encoded in big-endian. |
| 0x04 | Integer | 4 bytes of data following, encoded in big-endian. |
| 0x05 | – | (reserved) |
| 0x06 | – | (reserved) |
| 0x07 | String | Zero-terminated string following, 1 byte per character. |
The actual type of the event is encoded in bits 7..3 of the Event Header byte. Listed are the masked values (bit mask 0xf8):