# Open standard for cycler output data **URL:** \ **Category:** BDF & Standards\ **Created:** [February 28, 2024, 3:52pm UTC](https://bda.discourse.group/t/open-standard-for-cycler-output-data/28 "2024-02-28T15:52:46Z")\ **Posts on this page:** 9\ **Page:** 3
**Author:** ![graham](https://avatars.discourse-cdn.com/v4/letter/g/4af34b/32.png) [@graham](https://bda.discourse.group/u/graham)\ **Post date:** [September 19, 2025, 9:12am UTC](https://bda.discourse.group/t/open-standard-for-cycler-output-data/28/41 "2025-09-19T09:12:44Z")
@DrSimonClark some cyclers record time as an integer number of milliseconds internally, Newares also do this. My opinion is that seconds feel more natural, and I don’t think the precision loss storing as a float matters. It would be nice if there was a way to separate label and pint-compatible unit in the column names. e.g. if units were put in square brackets or separated with a different character like double underscore, then tools that read bdf can handle any units with pint. I don’t know if that makes the ontology part impossible. ---
**Author:** ![smedegaard](https://yyz1.discourse-cdn.com/flex029/user_avatar/bda.discourse.group/smedegaard/32/8_2.png) [@smedegaard](https://bda.discourse.group/u/smedegaard)\ **Post date:** [September 19, 2025, 9:40am UTC](https://bda.discourse.group/t/open-standard-for-cycler-output-data/28/42 "2025-09-19T09:40:41Z")
If you store the value and unit of any measurement it is compatible with any and all devices and it is trivial to convert ---
**Author:** ![DrSimonClark](https://yyz1.discourse-cdn.com/flex029/user_avatar/bda.discourse.group/drsimonclark/32/12_2.png) [@DrSimonClark](https://bda.discourse.group/u/DrSimonClark)\ **Post date:** [October 10, 2025, 7:16am UTC](https://bda.discourse.group/t/open-standard-for-cycler-output-data/28/43 "2025-10-10T07:16:47Z")
Hi @graham , yes thanks for your comment! Some cyclers store time as a millisecond integer to avoid accumulation of errors due to [floating-point precision issues](https://learn.microsoft.com/en-us/cpp/build/why-floating-point-numbers-may-lose-precision?view=msvc-170). I think this is more important during the measurement itself, when errors can accumulate over a long time. But for serializing to a global interoperable format, it’s best to stick to community-standard units and the precision of converting integer to decimals should be ok. Handling of units is also an important consideration. That’s why we’ve built in lots of support to parse and convert units. These will be included in a [python package](https://bda.discourse.group/t/python-package-for-simple-bdf-operations/48) that we’ve been working on. Check out the [units notebook here](https://github.com/battery-data-alliance/battery-data-format/blob/feat-python-packagee/examples/units.ipynb). As you mention, we build on top of pint to easily handle unit conversions in python. On the simplest level, you can just strip the unit from the preferred label or the machine name and use that in pint directly. We also have units encoded in the [application ontology](https://github.com/battery-data-alliance/battery-data-format-ontology/blob/main/battery-data-format.ttl) and the [table schema](https://battery-data-alliance.github.io/battery-data-format-ontology/schema/schema.json) for semantic operations. So hopefully this will provided robust redundancy to handle units. What do you think? ---
**Author:** ![graham](https://avatars.discourse-cdn.com/v4/letter/g/4af34b/32.png) [@graham](https://bda.discourse.group/u/graham)\ **Post date:** [October 10, 2025, 8:59am UTC](https://bda.discourse.group/t/open-standard-for-cycler-output-data/28/44 "2025-10-10T08:59:27Z")
Hi Simon, a bdf python package would be great, the validator would be particularly useful for other devs (me) trying to ingrate bdf in our pipelines. I wouldn’t immediately know how to strip units, as there is no reserved character for separating labels and units in names, e.g. charging\_capacity\_milliampere\_hour - where does the label end and unit start? But if a bdf package can do all this for me I am happy. [pint-pandas](https://github.com/hgrecco/pint-pandas) may be of interest for you if you haven’t seen it yet. ---
**Author:** ![gabe](https://yyz1.discourse-cdn.com/flex029/user_avatar/bda.discourse.group/gabe/32/5_2.png) [@gabe](https://bda.discourse.group/u/gabe)\ **Post date:** [December 22, 2025, 7:11pm UTC](https://bda.discourse.group/t/open-standard-for-cycler-output-data/28/45 "2025-12-22T19:11:19Z")
Adding here for this thread’s visibility. [LF Energy Battery Data Alliance Announces the Battery Data Format (BDF): A New Open Standard for Battery Data Interoperability](https://bda.discourse.group/t/lf-energy-battery-data-alliance-announces-the-battery-data-format-bdf-a-new-open-standard-for-battery-data-interoperability/51) ---
**Author:** ![xuganade](https://yyz1.discourse-cdn.com/flex029/user_avatar/bda.discourse.group/xuganade/32/72_2.png) [@xuganade](https://bda.discourse.group/u/xuganade)\ **Post date:** [October 26, 2026, 8:10pm UTC](https://bda.discourse.group/t/open-standard-for-cycler-output-data/28/46 "2026-10-26T20:10:04Z")
One schema decision worth making early is how to represent time and test events. A timestamp should say whether it is absolute or relative to the test, and step transitions should be explicit rather than inferred from current, voltage, or a vendor’s step index. That would make mixed-rate data and comparisons across cyclers much easier to interpret, even when implementations store the records differently. ---
**Author:** ![sepitutu](https://yyz1.discourse-cdn.com/flex029/user_avatar/bda.discourse.group/sepitutu/32/75_2.png) [@sepitutu](https://bda.discourse.group/u/sepitutu)\ **Post date:** [October 27, 2026, 3:00pm UTC](https://bda.discourse.group/t/open-standard-for-cycler-output-data/28/47 "2026-10-27T15:00:21Z")
A useful baseline would be to define units and sign conventions explicitly, rather than relying on cycler defaults. For each measurement, the schema could distinguish the instrument’s recorded value from any normalized or derived value, and preserve both the timestamp and elapsed time. Those details matter when comparing datasets from different vendors or reconstructing a test sequence. ---
**Author:** ![sizuredu](https://yyz1.discourse-cdn.com/flex029/user_avatar/bda.discourse.group/sizuredu/32/77_2.png) [@sizuredu](https://bda.discourse.group/u/sizuredu)\ **Post date:** [October 29, 2026, 11:11am UTC](https://bda.discourse.group/t/open-standard-for-cycler-output-data/28/48 "2026-10-29T11:11:30Z")
The schema should distinguish raw observations from values calculated later, with provenance for each derived field. For every measurement, define the quantity, unit, timestamp basis, and whether the value is instantaneous or integrated; otherwise two files can look compatible while reporting different meanings for “capacity” or “time.” A small set of validation examples would make those rules testable across implementations. ---
**Author:** ![gifupuma](https://yyz1.discourse-cdn.com/flex029/user_avatar/bda.discourse.group/gifupuma/32/65_2.png) [@gifupuma](https://bda.discourse.group/u/gifupuma)\ **Post date:** [October 29, 2026, 3:58pm UTC](https://bda.discourse.group/t/open-standard-for-cycler-output-data/28/49 "2026-10-29T15:58:12Z")
A minimum record should define not just the measured value, but its unit, timestamp basis, and measurement channel. In particular, elapsed time versus wall-clock time and whether timestamps mark sample acquisition or step transitions can change downstream analysis. Making those semantics explicit would help preserve compatibility without prescribing a file format or cycler implementation. [Previous page](https://bda.discourse.group/t/open-standard-for-cycler-output-data/28.md?page=2)