## 3 Dynamic AR Marker
Since most modern smartphones and video conferencing cameras are capable of shooting video at 30 frames per second [26] (_i.e._, the sampling frequency is \(F_{s}=30 Hz\)) and taking into account the sampling theorem, the maximum LED blinking frequency that can be correctly detected is \(F_{b}=F_{s}/2=15 Hz\). As shown in Figure 2, at least two  
Figure 1: Dynamic LED marker. samples (images) must be captured each blinking period in order to correctly detect the LED frequency of reference. In order to make the system more robust against spurious external light reflections and to avoid errors, the value of each bit must be observed for three consecutive frames for the system to consider it valid. The working frequency of the data transmission system is thus \(F_{1}=F_{b}/3=5\) Hz. This means that, using this transmission channel, a symbol of four bits can be transmitted five times per second, which results in an overall throughput of \(20\) bits per second or \(2.5\) bytes per second. This was sufficient to validate the proposed application in a real scenario. To enable detection of the emitted LED pattern, we implemented a simple image processing routine using OpenCV libraries [28]. First, the RGB image taken from the smartphone camera is converted to grayscale. The FindContours [29] function then locates the frame contours and stores each one as a vector of points. Once the contours of each LED have been identified, the Moments [30] function is used to return the area described by each of the stored contours. Next, the center of these areas is calculated so that each LED is referenced by a pair of \(x\) and \(y\) coordinates. However, even though LEDs are correctly located with the described method, problems may arise in highly illuminated environments. For example, light reflections or direct sunlight may give rise to false positives. To solve this problem, the detection system was improved by eliminating higher and lower contrast regions within a fixed range. Open contours were eliminated, yielding a procedure that is more robust in high luminosity conditions (Figure 3). Finally, once the LEDs have been detected and positioned, the message is decoded. The following restrictions were imposed to improve decoding reliability:  
* All messages start with the byte \(0x00\). * Message length is predefined and fixed. When the mobile device camera is aimed at the beacon and the application starts capturing frames, these frames are analyzed until a single lit LED is found. This corresponds to the fixed reference LED located in the upper left corner of the beacon. Figure 2: Effects of various sampling rates while sampling a signal [27]. This LED can be detected because (1) the three LEDs located in the other corners of the beacon blink at a fixed frequency and (2) all messages start with a \(0x00\) code, with all emitting LEDs off. Thus, all other LEDs are turned off at given times. This serves as a start-of-frame (SOF) marker. Consequently, the byte \(0x00\) should not be included in the message, and therefore, a byte stuffing algorithm, such as COBS [31], is needed to escape illegal characters in the encoded sequence. When the fixed reference LED is detected, its position is stored in memory. More captures are made until four lit LEDs (the fixed LED and the three blinking reference LEDs) are located. Next, some basic trigonometric operations are performed to verify that the four detected LEDs are arranged in a square, and the positions of the other three corner LEDs are also stored in memory. Once the positions of the beacon corners have been identified, the middle points of the edges of the square are calculated. The locations of the data LEDs are estimated to be at these four points, as shown in Figure 4.  
In subsequent captures, the status of all blinking reference LEDs is checked prior to evaluating the status of the data LEDs. If the blinking reference LEDs are all lit, the values provided by the four data LEDs are stored in a vector as the transmitted symbol.