The Nodes

Figure 8: Schematic diagram of the receiver hardware.

The receiver prototype consists of a small electronic circuit connected to the parallel port of a laptop computer running Linux. Figure 8 shows a schematic diagram of the receiver hardware. A photo diode converts the intensity of the incident light into a proportional voltage. The light that is incident to the photo diode mainly consists of three components:

• direct current (DC) components resulting from slowly changing daylight
• low frequency components resulting from artificial lighting powered with 50Hz alternating current (AC)
• higher frequency components resulting from laser light flashes at about 200Hz-300Hz ( $1/t_\mathrm{mirror}$)

Since we are only interested in the higher frequency laser flashes, we run the output signal of the photo diode through a high pass filter (HPF) which removes DC and low frequency components. Due to this, the detector is insensitive to daylight and artificial light.

The output of the HPF is then amplified using an operational amplifier, whose output is in turn fed into a Schmitt Trigger. The latter implements a hysteresis, i.e., when the input voltage level exceeds a certain value $\mathrm{V}_1$ it lowers the output voltage to a minimum. When the input voltage falls below a certain value $\mathrm{V}_2$, the Schmitt Trigger raises the output voltage to a maximum. The output of the Schmitt Trigger is connected to the parallel port, so that each laser flash on the photo diode causes a parallel port interrupt to be triggered.

The receiver software consists of two main components, a Linux device driver which handles the parallel port interrupt, and an application level program which performs the actual location computation and lighthouse calibration. The device driver mainly consists of the parallel port interrupt handler, which is implemented using the parapin [37] parallel port programming library. Moreover, it implements a Linux special device /proc/location, which provides a simple interface to user level applications. By writing simple ASCII commands to this device, a user level program can instruct the device driver to do some action. By reading the /proc/location device, a user level program can obtain the current status and measured angle $\alpha$ according to Equation 1 of all detected lighthouses.

Figure 9: Input voltage at the parallel port as beams pass by the photo detector.

In order to measure $\alpha$, the driver has to evaluate the interrupts it sees. To understand how this is done, consider Figure 9, which shows the input voltage at the parallel port over time. As the first rotating laser beam passes by the photo detector, the parallel port sees a sequence of sharp pulses resulting from the fast rotating mirror. The pulses stop if the lighthouse platform has turned enough so that the photo detector isn't hit any longer by the rotating beam. After some time, the second rotating beam passes by the photo detector and again generates a sequence of fast pulses.

Recall that each pulse generates an interrupt, which results in the device driver interrupt handler being invoked. The handler then uses the system clock (which has $\mu$s resolution under Linux) to determine the point in time when the interrupt occurred.

The time interval between two successive fast pulses equals the time $t_\mathrm{mirror}$ for one rotation of the mirror. Since each lighthouse has a different $t_\mathrm{mirror}$, this value can be used to distinguish different lighthouses. Please note that the pulse sequences can contain ``holes'' where the laser beam missed the photo detector due to vibrations. The driver removes all peaks separated by holes from the beginning and the end of the sequence of pulses. The time median of the resulting shorter sequence of pulses without holes is assumed as the detection time of the beam (indicated by the braces in Figure 9).

Recall from Section 4.2, that we implemented a ``virtual'' wide beam by two rotating laser beams that form the outline of this wide beam. Therefore, the time passed between the medians of two successive packs is either $t_\mathrm{beam}$ or $t_\mathrm{turn} - t_\mathrm{beam}$. If the actual value is small (e.g., $<$ 1sec) then it is assumed to be $t_\mathrm{turn}$. If the lighthouse has just been initialized the driver also measures $t_\mathrm{turn} - t_\mathrm{beam}$ in order to obtain $t_\mathrm{turn}$. Since the latter does not change, this has to be done only once. Later on, the driver can output a new $\alpha$ with each round of the lighthouse.

In order to distinguish successive pulses from ``holes'', and holes from ``beam switches'', the driver knows tight lower and upper bounds for the possible values of $t_\mathrm{mirror}$ and $t_\mathrm{turn}$. In Section 4.3.1 we mentioned the possibility that beams from different lighthouses may hit the photo receiver at the same time. If this happens the resulting time between successive pulse will fall below the lower bound for $t_\mathrm{mirror}$, such that the driver can detect this situation instead of producing faulty results.

We also ported the receiver hardware and software to an ATMEL AT128L 8-bit embedded micro controller [38]. This setup more closely resembles the limited capabilities of a Smart Dust node and allows us to study the potential effects of a Smart Dust node on the location system.