-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathresults.tex
38 lines (30 loc) · 2.8 KB
/
results.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
\chapter{Experimental results}
Production delays made full-scale testing of the battery infeasible. However, the main features of the BMS have been tested separately and encouraging data has been collected.
\section{Balancing}
\begin{figure}[h]
\centering
\input{pictures/fenice_imbalance.tex}
\caption{Unbalanced Fenice segment}
\label{fig:fenice_imbalance}
\end{figure}
To test the balancing algorithm a battery pack segment was connected to a cellboard. Every segment cell was charged individually to different voltages to create an imbalanced situation. \autoref{fig:fenice_imbalance} shows the initial state of the segment with a total imbalance of $V_{17} - V_{7} = 3.976V - 3.808V = 0.168V$. For this test, the balancing settings are set to have a maximum imbalance of $100mV$. With these settings all cells with a voltage above $V_{7} + 100mV = 3.908V$ need to be discharged, in this case cells 1, 3, 4, 5, 9, 10, 11, 12, 13, 14, 15, 16 and 17 are all above the threshold voltage.
The test setup only involved a single cellboard, disconnected from the mainboard. The balancing algorithm and state machine ran on the cellboard only relying on its internal voltage measurements as input. A serial console was connected to a computer for monitoring and data gathering.
After starting the state machine the algorithm correctly computed the cells to balance and proceeded to the discharge state. The serial console showed the cells that were being discharged and after the predefined 30 seconds of discharge, the state machine went into the cooldown state. After 10 seconds a new set of cells was computed and balancing began again.
\begin{figure}[h]
\centering
\input{pictures/fenice_balanced.tex}
\caption{Fenice segment after balancing}
\label{fig:fenice_balanced}
\end{figure}
\section{Error management}
Unit testing was used to validate the priority queue part of the system. The timer scheduling part has been tested using a logic analyzer to verify the scheduling and timing accuracy.
In \autoref{fig:error_test} test results can be seen. The test scenario is analog to the one presented in \autoref{fig:error_scheduling} in which two errors happen within the same timeframe. The two small drops of the \textit{Timer} channel signal when the timer switches from following $E_0$ to $E_1$ and vice versa.
When the timer triggers the \texttt{Fatal} signal can be seen going high.
The timing shown in was very consistent across multiple tests albeit being higher than expected. Given the high repeatability of the unwanted extra time, all timeout values have been shortened to remain within the rulebook specification.
\begin{figure}[h]
\centering
\includegraphics[width=\textwidth]{error_test}
\caption{Error timing test. $E_1$ is reset before triggering, and the timer switches back to $E_0$.}
\label{fig:error_test}
\end{figure}
\newpage