@DavidMStraub thanks for sharing that background, your experience at Lilium is pretty much the exact scenario that motivated BDF. And yes, we’re absolutely looking for community contributions, especially from people who’ve dealt with multi-vendor data at scale.
We have a few [open spec questions]( BDF: What's Been Built and What's Next ) right now, EIS data, step indexing, temperature columns, where someone who’s wrestled with dozens of formats from external test houses would be directly useful. The Python package ([batterydf]( batterydf · PyPI )) could also use more eyes, particularly around vendor format coverage. The [open standard thread]( Open standard for cycler output data ) has the full discussion history if you want to see how we got here.
On the protocol side, it’s definitely in BDA’s scope though we prioritized aligning on a common format (a format of last resort at the time). However, we did some early work with [BatteryDataInterface]( GitHub - battery-data-alliance/BatteryDataInterface: Battery data interface specifications · GitHub ) but it’s behind where others are. Ionworks and Empa are both great contributors to open source, and each project looks great. @graham @valentin @DavidMStraub There’s clear demand and a real need for alignment across these efforts. Would be a good topic to discuss here on the forum, pros/cons of the different approaches and where BDA should focus.