Have you ever started a multi-day battery test, only to realize later that the protocol you used was incorrect? The Battery Cycler Simulator helps you prevent this by allowing you to upload a protocol file and run a quick physics-based simulation to verify its behavior before you start a real-world experiment.

​
How It Works

The process is simple: upload your protocol, configure your cell, and run the simulation.
  1. Upload: Upload your protocol file in the raw format (e.g. XML or JSON). The system automatically detects the format and parses it.
  2. Configure: Set the parameters for the cell you want to simulate.
  3. Simulate: Run the simulation and analyze the results.

​
Step 1: Upload Your Protocol File

You can start by uploading a protocol file from your computer. We currently support files from:
  • Maccor
  • Neware
Support for Arbin, BioLogic, and Novonix files is coming soon. Once you upload a file, the system immediately parses it and displays the translated steps.

​
Required Additional Files

Some protocols reference external files for complex steps, such as custom drive cycle waveforms or reusable subroutines. If your protocol requires such files, the simulator will detect this and prompt you to upload them.

​
Step 2: Review and Configure

After parsing, you can review the protocol and set up the simulation.

​
Protocol Steps

The simulator displays the parsed protocol in three different formats, accessible via tabs:
  • Human-Readable: A simplified, easy-to-read summary of the steps in your protocol.
  • UCP (YAML): The full protocol translated into our Universal Cycler Protocol format. This shows the detailed underlying structure that will be executed.
  • Raw: The raw text content of the file you uploaded.

​
Cell Configuration

To run a meaningful simulation, you need to provide some basic information about the battery cell you want to test. This configures the underlying physics-based model (a Single Particle Model, or SPM).
  • Chemistry: Select the cell chemistry from a list of pre-configured options (e.g., NMC/Graphite, LFP/Graphite). This selects the appropriate PyBaMM parameter set.
  • Cell capacity (Ah): The nominal capacity of your cell. This is used to scale the model’s parameters to match your cell.
  • Initial SOC (%): The State of Charge of the cell at the beginning of the simulation.
  • Temperature (°C): The ambient temperature for the simulation.
Check carefully that the cell configuration matches the cell for which the protocol was designed. If the cell configuration is incorrect, the simulation may not be able to run.

​
Step 3: Run Simulation & Analyze Results

Once everything is configured, click Run Simulation. The simulator will execute the protocol against the configured cell model.

​
Simulation Results

  • Plots: The primary output is a plot of Voltage and Current vs. Time. This allows you to visually inspect the cell’s response and verify that the protocol is behaving as you expect (e.g., hitting the correct voltage cutoffs).
  • Key Metrics: Below the plot, you will find key performance indicators calculated from the simulation, including:
    • Total Time
    • Charge Throughput (Ah)
    • Energy Throughput (Wh)
By simulating your protocols, you can catch errors, validate your experimental design, and gain confidence before committing time and resources to a real test.

​
Differences between Commercial Protocols

Much of the challenge in converting between the different protocols is not the syntax, but the fundamental differences in how the cyclers define the logic to follow the same sequence of steps. In this section, we’ll cover some implementation differences between the Ionworks Universal Cycler Protocol, and the protocols from the cyclers we support.

​
CCCV Steps

Most cyclers define CCCV steps as one step with voltage as a “limit” field:
  • Maccor: Uses a constant current step, with voltage as a “limit”
  • Neware: Specifies both current and voltage as a “limit”
  • Novonix: Specifies both the current and voltage as fields, and use the step type to differentiate between CC (voltage is only a cut-off) and CCCV (go to cut-off voltage then hold until a current cut-off)
In UCP, for maximum modularity, we use a step block with two steps, CC with a voltage cut-off and CV with a current cut-off, with total duration and any other end conditions defined at the step block level.

​
Report/Record/SaveData/Resolution

This is the field that defines how often the cycler will save data to the output time series.
  • Maccor uses the “Report” field and allows time, current, voltage, and temperature
  • Neware uses the “Record” field and allows time, current, and voltage
  • Novonix uses the “StepConditions” field with a “ConditionType” set to “SaveData” and allows time, current, and voltage
  • UCP uses the “Resolution” field, which can be set globally and overridden for each step, and currently only supports time

​
Loops

For loops, there are two fundamental approaches:
  1. Nested Steps: Define the loop as a step block with a nested step, with a repeat parameter specifying the number of times to repeat the loop. This is the more modern approach, similar to how loops are defined in modern programming languages such as Python.
The following protocols use this approach:
  • UCP (using step blocks)
  • Novonix (using the “ChildProtocolStepList” field).
  1. Goto/State machine: Define special steps like “start loop” and “end loop”. This is the more legacy approach, similar to older programming languages such as Fortran.
The following protocols use this approach:
  • Maccor (using a Do step to start the loop, and a Loop step to end the loop)
  • Neware (using a special step type to loop back to a specified previous step a certain number of times)