## 3 Dynamic AR Marker  
Several options are available to link a physical IoT node to its logical representation in the network, so that end user applications may access this information directly through the AR user interface. Some frameworks use previously analyzed images as markers (also called anchors) to track the position and orientation of areas where augmented content needs to be added [23, 24, 25], while others use QR codes or even geopositioning to locate the points of interest. The less computationally expensive mechanism is geopositioning. It is, however, also the least accurate option and is generally useless for scenarios where the object is centimeters or even meters from the user's smartphone. For short-range applications, such as interactive print, QR codes or image anchors are preferred for their high precision, yet they require greater computing power in user devices. Whatever the case, all of these approaches are static in the sense that the information coded in the anchor (the image, the information decoded from the QR image or the geographical position of a marker) cannot be changed at runtime. Most systems based on these approaches resolve this issue by using anchors only as a referrer to an online resource. In other words, a persistent connection is needed between the user devices and a backend infrastructure. In this work, we propose a new type of optical AR anchor that allows precise definition of the area of interest for media overlays while providing a direct low-bandwidth communications channel for dynamic information. To achieve this, instead of static markers based on images or QR codes, we employ an LEDmatrix that can be easily read by most personal device cameras nowadays. A basic diagram of this dynamic marker is shown in Figure 1.  
Because of its geometric simplicity, a beacon consisting of a square array of eight LEDs was selected for a proof-of-concept implementation. The function of the LEDs in the corners of the array is to define the area to be analyzed, which is used as a reference to determine the position and orientation of the beacon. The LED in the upper left corner always remains on as a reference point to find the other three vertices and, hence, the transmitting LEDs. The remaining LEDs on the vertices (upper right, lower left and lower right) blink at a fixed frequency (\(F_{1}\)), as a clock reference for synchronizing the sampling of the data LEDs. The four remaining LEDs, positioned halfway between the reference LEDs, are used to transmit information (data LEDs). The four transmitting LEDs follow a pattern depending on the value to be transmitted. Each transmitting LED corresponds to a bit, in such a way that information is partitioned in four-bit chunks, equivalent to nibbles. Thus, the values sent range from \(0x0\) to \(0 xF\), expressed in hexadecimal format (\(0b0000\) and \(0b1111\) in binary format). Each of the four LEDs \(X_{i}\) is assigned a weight \(2^{i}\), so that the transmitted nibble \(X\) can be calculated simply as defined in Expression (1), where \(X_{i}\) is zero for a dark LED and one for a lit LED. \[X=\sum_{i=0}^{3}X_{i}2^{i} \tag{1}\]  
Care must be taken when reading the values of each \(X_{i}\) so that the smartphone camera does not sample the status of a changing LED (ON to OFF or OFF to ON), since this could lead to errors in the decoded message. To prevent this from happening, the blinking reference LEDs are used as a clock source, so that data LEDs only change their values when the blinking reference LEDs are OFF. Furthermore, the value of each \(X_{i}\) is only assumed to be valid if the blinking reference LEDs for the frame being processed are all ON. According to this symbol coding scheme, the information transmission data rate for a given frequency \(F_{1}\) is \(F_{1}/2\) bytes per second (half a byte every \(1/F_{1}\) seconds).