file_formats:ekho_.raw
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
file_formats:ekho_.raw [2024/12/06 19:26] – [Header] ibchadmin | file_formats:ekho_.raw [2024/12/06 19:44] (current) – ibchadmin | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== | + | ====== |
- | ===== EKHO RAW files ===== | + | **Version: |
An EKHORAW file is a binary file format for storing recorded IV-information from Ekho. This file is recorded to an SD card on the Teensy, which is attached to the Ekho board. It will later be processed to create an IV surface. | An EKHORAW file is a binary file format for storing recorded IV-information from Ekho. This file is recorded to an SD card on the Teensy, which is attached to the Ekho board. It will later be processed to create an IV surface. | ||
Line 30: | Line 30: | ||
* **RESERVED** (29 octets) — Leaving space here in case we need to add something. | * **RESERVED** (29 octets) — Leaving space here in case we need to add something. | ||
- | ===== ## Samples ===== | + | ===== Samples ===== |
Samples are stored in batches. Each batch has the following format: | Samples are stored in batches. Each batch has the following format: | ||
* **TimeStamp** (4 octets) — the time (in milliseconds) since the recording began. This allows for up to 49 days of continuous recording in one file. For longer recordings, multiple files can be generated. Frankly, if you're going longer than a day or two, you should probably generate multiple files anyway. | * **TimeStamp** (4 octets) — the time (in milliseconds) since the recording began. This allows for up to 49 days of continuous recording in one file. For longer recordings, multiple files can be generated. Frankly, if you're going longer than a day or two, you should probably generate multiple files anyway. | ||
- | * **Samples** (10 octets/ | + | * **Samples** (10 octets/ |
* **PADDING** (1 octet) — a lot of microcontrollers like things to be aligned to even boundaries. So, we add single octet of padding. Should be set to 0x00. | * **PADDING** (1 octet) — a lot of microcontrollers like things to be aligned to even boundaries. So, we add single octet of padding. Should be set to 0x00. | ||
* **ERROR CORRECTION** (1 octet) — this value depends on the error correction value specified in the header. If it is None, then this value should be 0x00. For, the Parity Byte setting, it should be a simple parity byte computed by XOR-ing all of the bytes in the batch. For CHKSUM, it should be the simple 8-bit sum of the bytes in the batch (initial value 0x00). For CRC8, it should be the CRC8 computed over the bytes of the batch (using polynomial 0x07). In all cases, except None, the checksum should be computed over all bytes in the batch (including the timestamp, but excluding the error correction and padding). | * **ERROR CORRECTION** (1 octet) — this value depends on the error correction value specified in the header. If it is None, then this value should be 0x00. For, the Parity Byte setting, it should be a simple parity byte computed by XOR-ing all of the bytes in the batch. For CHKSUM, it should be the simple 8-bit sum of the bytes in the batch (initial value 0x00). For CRC8, it should be the CRC8 computed over the bytes of the batch (using polynomial 0x07). In all cases, except None, the checksum should be computed over all bytes in the batch (including the timestamp, but excluding the error correction and padding). | ||
file_formats/ekho_.raw.1733513207.txt.gz · Last modified: 2024/12/06 19:26 by ibchadmin