1 files changed, 16 insertions, 8 deletions
diff --git a/ma/safety_reset.tex b/ma/safety_reset.tex
index 0fa3cb9..c83e8be 100644
--- a/ma/safety_reset.tex
+++ b/ma/safety_reset.tex
@@ -579,10 +579,10 @@ P}{\Delta f}$, called \emph{Overall Network Power Frequency Characteristic} by E
 \SI{25}{\giga\watt\per\hertz}.
 
 We can derive general design parameter for any system utilizing grid frequency as a communications channel from the
-policies of ENTSO-E\cite{entsoe02,entsoe03}. % FIXME introduce ENTSO-E on first use
-Probably any such system should stay below a modulation amplitude of \SI{100}{\milli\hertz} which is the threshold
-defined in the ENTSO-E incidents classification scale for a Scale 0-1 (from "Anomaly" to "Noteworthy Incident" scale)
-frequency degradation incident\cite{entsoe03} in the continental europe synchronous area.
+policies of ENTSO-E\cite{entsoe02,entsoe03}.  Probably any such system should stay below a modulation amplitude of
+\SI{100}{\milli\hertz} which is the threshold defined in the ENTSO-E incidents classification scale for a Scale 0-1
+(from "Anomaly" to "Noteworthy Incident" scale) frequency degradation incident\cite{entsoe03} in the continental europe
+synchronous area.
 
 \subsubsection{Control systems coupled to grid frequency}
 
@@ -677,10 +677,17 @@ spectrum of any grid frequency modulation system should not exhibit any notable
 of spectral energy in certain frequency ranges.
 
 \subsubsection{Overall system parameters}
+
+% FIXME
+
 \subsubsection{An outline of practical implementation}
+% FIXME
 
 \section{From grid frequency to a reliable communications channel}
+% FIXME
+
 \subsection{Channel properties}
+% FIXME
 
 
 \subsection{Modulation and its parameters}
@@ -905,6 +912,8 @@ realistically be up to $\mathcal O\left(10^3\right)$, which is easily enough for
 \chapter{Practical implementation}
 \section{Cryptographic validation}
 
+ %FIXME
+
 \section{Data collection for channel validation}
 
 To design a solid system we needed to parametrize mains frequency variations under normal conditions. To set modulation
@@ -1141,8 +1150,6 @@ acknowledgement packet to the sensor. When the sensor receives the acknowledgeme
 from the transmission packet ringbuffer. When the host detects an incorrect checksum it simply stays quiet and waits for
 the sensor to resume with retransmission when the next ADC buffer has been received.
 
-% FIXME make actual error rate measurements
-
 The serial interface logic presents most of the complexity of the sensor firmware. This complexity is necessary since
 we need reliable, error-checked transmission to the host. Though rare, bit errors on a serial interface do happen and
 data corruption is unacceptable. The packet-layer queueing on the sensor is necessary since the host is not a realtime
@@ -1150,7 +1157,8 @@ system and unpredictable latency spikes of several hundred milliseconds are poss
 
 The host in our recording setup is a Raspberry Pi 3 model B running a Python script. The Python script handles serial
 communication and logs data and errors into an SQLite database file. SQLite has been chosen for its simple yet flexible
-interface and its good tolerance of system resets due to unexpected power loss.
+interface and its good tolerance of system resets due to unexpected power loss. Overall our setup performed adequately
+with IO contention on the raspberry PI/linux side causing only 16 skipped sample packets over a 68-hour recording span.
 
 \subsection{Frequency sensor measurement results}
 
@@ -1208,7 +1216,7 @@ Captured raw waveform data is processed in the Jupyter Lab environment\cite{kluy
 extracted as described in sec. \ref{frequency_estimation} using the \textcite{gasior01} technique. Appendix
 \ref{grid_freq_estimation_notebook} contains the Jupyter notebook we used for frequency measurement.
 
-% FIXME comparison against reference measurements?
+% TODO comparison against reference measurements?
 
 \section{Channel simulation and parameter validation}