diff --git a/_pages/software.md b/_pages/software.md
index fb2c781..c75ec96 100644
--- a/_pages/software.md
+++ b/_pages/software.md
@@ -39,6 +39,16 @@ $$\theta_{z,n+1} = \theta_{z,n}+(\omega_{z,raw}-\omega_{z,bias})\Delta t$$
 This function along with the ability to ``reset_integrators()`` is key in measuring our turns to a high degree of precision, necessary for many events in our state diagram.
 
 #### **Beacon Processing**
+Low level control over the IR beacon detection circuit is handled by the IR_Beacon class: this class initializes the analog input pin and digital reset pin, and provides an ``update()`` function that when called periodically takes a new sensor reading from the analog input pin and briefly pulls the reset pin high in order to reset the peak detection circuit. The last detected value of the IR beacon is mapped to a value between 0 and 1023 and is stored in the class for use by other subroutines. 
+
+In our robot the primary role of the IR beacon detector is to determine initial orientation. To do this, the robot sweeps the swivel servo through a 180-degree arc and identifies the IR signature that best matches the servo. The original intention was to design the filtering circuit such that only signals from the beacon would pass through to the Arduino: if this was the case, then the robot would only need to find the direction of maximum signal. However during testing we found two additional sources of noise: 
+
+- Spurious peaks, likely due to electronic noise generated by the servos, high-frequency glints or reflections of sunlight that passed through the filtering, or noise caused by the peak detection reset process. 
+- Consistent high-signal regions due to strong sunlight or interference from other IR sources in the room. 
+
+The maximum-only method occasionally failed due to these sources of noise. Attempts to redesign the circuit failed to completely suppress the noise, so we devised a convolution-based method for isolating the beacon signal based on geometric characteristics: this routine is implemented in ``find_beacon_relative()``. We found empirically that when sweeping through 1-degree angle increments from the starting zone the beacon generated a roughly Gaussian-shaped peak covering about 10 degrees. As the sensor sweeps through the angles, the beacon detection subroutine retains the last 15 samples, and multiplies them element-wise with a convolution kernel consisting of an approximate Gaussian covering the middle 10 samples, and heavily negative weights outside of these samples. The sum of these multiplied samples corresponds to a measure of how well the middle of the 15-sample range matches the expected signal shape. Both the single-sample spurious peaks and many-sample noise could be effectively suppressed using this method. 
+
+However, we found that when the board was moved to the other side of the building, we did not see the expected signal shape, and new sources of noise appeared that interfered with this method. For the competition, we simplified this routine to use a simple top-hat convolution kernel that only filtered out spurious peaks. 
 
 #### **Line Sensor Processing**
 The line sensor processing was relatively straight forward in our software. We used hysterisis in order to remove chattering around a single threshold, and the min and max thresholds were turned experimentially such that we could detect line crossings. The software also kept running counters of the number of transitions between ``on_line`` and ``off_line`` states which was useful for debugging. The reliability of our sensor meant that this simple software implentation was very reliable, and it did not cause many issues during the project.