research in visible light communication systems with openvlc1 3

Research in Visible Light Communication Systems with OpenVLC1.3

Ander Galisteo , Diego Juara , D. Giustiniano

Dec 17, 2018

Influential Citations

2019 IEEE 5th World Forum on Internet of Things (WF-IoT)

Key Takeaway : The latest OpenVLC1.3 platform improves throughput, distance, and software robustness while maintaining low-cost front-end for Visible Light Communication Systems research.

In this paper, we present the design and implementation of our latest OpenVLC1.3 platform to perform research in Visible Light Communication Systems. We retain the advantages of the previous versions such as TCP/IP layers support, software programmability and low-cost front-end. We re-design the transceiver to support higher modulation rates and sensitivity. This allows us to reach a throughput of 400 kb/s (a factor of 4 with respect to the previous version) and increase the distance by a factor of 3.5. We further improve the software robustness of the system and reduce the form factor at similar hardware cost.

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

OpenVLC is an open-source and open-hardware, flexible, and low-cost Visible Light Communication platform.

openvlc/OpenVLC

Folders and files, repository files navigation.

This is the repository for the OpenVLC platform, an open-source, flexible and low-cost Visible Light Communication System platform. The research and development is led by IMDEA Networks Institute, Spain, but anyone is welcome to contribute.

New OpenVLC1.3 version

We are delighted to announce that OpenVLC1.3 is ready for delivery! OpenVLC1.3 can now achieve a throughput of 400 Kb/s at the Transport Layer at a distance of more than 3 meter, powered simply by the BeagleBone Black!

Details on how to get started are introduced below.

Instructions

OpenVLC needs just a few components to work:

• BEAGLEBONE Black (BBB) Board (needs Rev C produced from 2017; you need to connect an external 5V power supply to the BBB): cost $ 45 - $ 60; AM3359 1 GHz, 4 timers, 65 GPIOs
• OpenVLC1.3 RevA cape: the VLC front-end
• OpenVLC1.3 driver: software defined MAC and PHY layer (implemented as Linux driver) and firmware (to control the programmable real time units of the BBB (PRU))

The software solution is implemented as a Linux driver that can communicate directly with the cape and the Linux networking stack. In OpenVLC, the VLC interface is set up as a new communication interface that can take advantage of the vast range of Linux tools.

Design of OpenVLC

The new OpenVLC1.3 takes advantage of the programmable real time units (PRU) included in the BBB. This,and the new receiver design allow us to increase the transmission frequency to 1 MHz and, thus, the communication rate. One cape can work as Transmitter (TX) or Receiver (RX).

Testing the cape

Although OpenVLC 1.3 cape is designed to be connected to the BBB, its functionalities can be tried without one. This step is not essential and requires additional devices such as a waveform generator or an oscilloscope. But it can be useful to test its correct functioning before plugging it to the BBB and to avoid possible damages to the board.

Set the connections shown in image below. Connect a 5 V power supply to the jack port. To emulate a transmission with OpenVLC 1.3 you can produce in the cape pin TX SIGNAL (P8_45 in BBB) a square wave between 0 and 3.3 V at 1 MHz. The LED should light on without any noticeable blinking. Modulated light can be measured with a fast light-sensing device (photodiode) connected to an oscilloscope. To test constant illumination, connect TX SIGNAL to GND and the pin next to it (P8_46) to 3.3 V. The LED should provide similar illumination level than in the previous case.

Set the connections shown in image below. Connect a 5 V power supply to the jack port. Produce a square wave between 0 and 3.3 V at 1 MHz at ADC CS, and a square wave between 0 and 3.3 V at 48 MHz at ADC SCLK. You can read the serial digital output from the ADC in the cape on pin RX SIGNAL.

Experimental Setup

Creating the sd card.

We need to flash the BBB with a Debian image. To do that we need a SD Card with at least 4 GB. Follow these steps:

• Format the SD Card with SD card formatter with overwrite format.
• Download the image from the link: https://files.beagle.cc/file/beagleboard-public-2021/images/bone-debian-8.7-iot-armhf-2017-03-19-4gb.img.xz
• Write the image ”bone-debian-8.7-iot-armhf-2017-03-19-4gb” to the SD Card. If you use Windows, you may use Win32 Disk Imager. For Linux, you may use the command line dd.

Flashing the BBB

Now that we have the SD Card ready with the image, we need to flash the BBB. Follow these steps:

• With the power disconnected, insert the SD Card into the BBB and power it up with the USB cable.
• Connect through SSH to the IP 192.168.7.2.
• In order to run the OS on the SD Card, flash it into the BBB: go to /opt/scripts/tools/eMMC and run sudo ./bbb-eMMC-flasher-eewiki-ext4.sh
• Wait until the script of previous steps reports the following message: “eMMC has been flashed”. Once it finishes, disconnect the usb cable and with the BBB switched off, remove the SD Card.

Setting up the OS

The firsts steps are to prepare the beaglebone. This must be done in the OpenVLC board operating as TX as well as in the OpenVLC board operating as RX. These are the steps:

• Disable the HDMI: The HDMI uses some PRU pins that we need. To disable the HDMI cape edit the uEnv.txt file: sudo nano /boot/uEnv.txt and uncomment the line: dtb=am335x-boneblack-emmc-overlay.dtb
• Reboot the OpenVLC board. The HDMI is disable after rebooting.
• Install the headers: Connect the beaglebone to the Internet, and then update with: sudo apt-get update
• Then the board is ready to install the headers with: sudo apt-get install linux-headers-$(uname -r) The code is in github at https://github.com/openvlc/OpenVLC . In Latest_Version subdirectory you will find the Driver (kernel) and PRU code folders. Just fetch them by using sudo git clone https:// github.com/openvlc/OpenVLC , and copy them into the path ”/home/Debian”.

Connecting the cape

Connecting the cape to the BBB is quite easy. You just need to plug the cape to the correct pins as shown in the image below:

Once it’s plugged, connect the 5 V power supply and that’s all.

ATTENTION: Be careful not to bend the components that stand out when you press or pull the cape.

Setting up the TX/RX

There are two parts in the TX/RX, the kernel driver and the PRU code. Follow these steps:

In order to load the kernel driver, run the following command inside the Driver folder: sudo ./load_test.sh. With this script, you can change the IP taken by the interface. That’s the IP in the VLC network, so TX and RX must have different IPs (for example TX: 192.168.0.1 and RX 192.168.0.2).

Once the module driver is installed, make sure that proper paths and symbolic links have been made for the PRU compiler (clpru) and linker (lnkpru). The following commands can be used to this end:

cd /usr/share/ti/cgt-pru sudo mkdir bin cd bin sudo ln -s /usr/bin/clpru clpru sudo ln -s /usr/bin/lnkpru lnkpru

Then go to the PRU folder, enter TX/RX and run sudo ./deploy.sh . This will boot up the PRUs with the code necessary to transmit and receive VLC data.

Working with the TX/RX

Once you have done the steps above in TX and RX, you can start using VLC as a common network interface.

You could measure the achievable throughput by using the iperf tool. To this end, launch iperf in client mode at the TX ( sudo iperf -c 192.168.0.2 -u -b 400k -l 800 -p 10001 -t 100 ) and in server mode at the RX ( sudo iperf -u -l 800 -s -i3 -B 192.168.0.2 -p 10001 ). Make sure that TX and RX have different IPs and the IP of the RX (iperf server) is 192.168.0.2.

The image below shows the results of an iperf test at 2.5 meters of distance:

If you have doubts and questions about these instructions, please leave your message in our Google group: https://groups.google.com/forum/#!forum/openvlc

What is Visible Light Communication - LiFi?

Visible Light Communication (VLC), sometimes also referred to as “LiFi", uses standard off-the-shelf visible light LEDs to transmit data using the visible light spectrum. VLC is receiving strong attention from the designers of the 5G networks and beyond. VLC can enable new pervasive wireless systems in the context of the Internet of Things.

Our Mission

The lack of an open-source and low-cost reference platform is hindering the progresses of research and industry in VLC systems. A general-purpose platform would add momentum to VLC and would open up new avenues of VLC research and spark the interest of researchers and engineers. We take an initial step toward this and we design OpenVLC, an open-source Visible Light Communication platform for fast prototyping of new system protocols to build a LiFi network. It runs on a cost-effective yet powerful credit-card-sized embedded board.

If you have any questions, you can contact us at [email protected] and post your questions at https://groups.google.com/forum/#!forum/openvlc

If you use openVLC for your research, please cite "A. Galisteo, D. Juara, D. Giustiniano, "Research in Visible Light Communication Systems with OpenVLC1.3", IEEE World Forum on Internet of Things (WF-IoT) 2019."

Driver code of OpenVLC is released under GNU General Public License v3.0 - see the LICENSE_driver.md file for details. PRU code of OpenVLC is released under BSD-2 license - see the LICENSE_pru.md file for details.

Contributors 4

• Batchfile 7.7%
• Makefile 3.5%
• Assembly 3.0%
• Python 0.8%

Research in Visible Light Communication Systems with OpenVLC1.3 † † thanks: The project that gave rise to these results received the support of a fellowship from ”la Caixa” Foundation (ID 100010434). The fellowship code is LCF/BQ/ES16/11570019.

In this paper, we present the design and implementation of our latest OpenVLC1.3 platform to perform research in Visible Light Communication Systems. We retain the advantages of the previous versions such as TCP/IP layers support, software programmability and low-cost front-end. We re-design the transceiver to support higher modulation rates and sensitivity. This allows us to reach a throughput of 400 kb/s (a factor of 4 with respect to the previous version) and increase the distance by a factor of 3.5. We further improve the software robustness of the system and reduce the form factor at similar hardware cost.

I Introduction

Visible Light Communication is gaining significant interest as a medium to connect to the Internet  [ 1 , 2 , 3 ] . In the last few years, a range of applications have been developed with low-end Visible Light Communication (VLC) platforms: human sensing  [ 4 ] , communication with toys  [ 5 ] , mobile interaction  [ 6 ] , indoor localization  [ 7 , 8 ] and passive VLC  [ 9 , 10 ] . Industry interest is also resulting in the establishment of the IEEE 802.11bb task group, where the objective is to amend the Medium Access Control (MAC) and Physical Layer (PHY) of IEEE 802.11 with Light Communications  [ 11 ] .

To solve the lack of an open-source and flexible platform for low-end VLC research, we introduced OpenVLC at the VLCS’14 workshop  [ 12 ] , that allowed for quick and flexible testing of new VLC protocols and applications. More recently, we introduced OpenVLC1.2  [ 13 ] with the attempt of increasing the data rate. However, the board was still working only at relative short range and was largely affected by light interference.

In this paper, we introduce the latest version of our platform, OpenVLC1.3, that increases the data rate and the communication range without adding any hardware cost to the platform. Our contributions are as follows:

We make a design that occupies a smaller physical space, improve the hardware of OpenVLC1.3 and add high-pass and low-pass filters to minimize the effect of noise in the system, including the Direct Current (DC) from other illumination sources and high-frequency components from the circuitry such as the overshooting generated by the amplification stages.

We improve the software stability and make a new design in software to modulate the LED light. This allows us to perform sampling rate over 2 MHz and achieve a UDP throughput of about 400 kb/s. This throughput could fulfill the needs of a range of applications with only off-the-shelf low-end hardware.

We design a new technique for computation- and memory-limited fast frame detection to solve the problem of constrained memory in the microcontroller.

We design and implement a new reception mechanism to avoid the synchronization problems present in previous versions of OpenVLC.

The rest of this paper is organized as follows. Section  II introduces the background on OpenVLC and a high level view of the system architecture. Details on the design of hardware, firmware and driver for the transmitter (TX) and receiver (RX) are presented in Section  III and Section  IV , respectively. The evaluation results are reported in Section  V and the limits of the OpenVLC1.3 in Section  VI . Finally, discussions and conclusion are drawn in Section  VII .

II New System Architecture

The new version of OpenVLC consist of four parts: the BeagleBone Black (BBB) embedded board  [ 14 ] , the OpenVLC cape, the OpenVLC firmware and the OpenVLC driver. The OpenVLC cape is the front-end transceiver that is attached directly to the BBB. The OpenVLC firmware uses real-time processing in the BBB’s Processing Real-time Units (PRUs), that work as microprocessors. The OpenVLC driver is a module in the Linux kernel. Both the firmware and the kernel module implement the VLC MAC and PHY layers and implement primitives such as sampling, symbol detection, coding/decoding and Internet protocol interoperability. Also, OpenVLC1.3 retains the best characteristics of previous versions, being flexible and open-source and communicating with a low-cost front-end.

With respect to its predecessor, the architecture of OpenVLC1.3 has been re-designed in order to increase the network performance. The new hardware (HW), called OpenVLC1.3 cape, is shown in Fig.  1 . The OpenVLC1.3 cape has been modified, reducing its surface by more than 50%. This also allows to use the remaining pins to connect sensors, for instance for Internet of Things applications.

The system architecture of OpenVLC1.3 is shown in Fig.  2 . The hardware runs on external power to allow higher power consumptions and harnesses the new LED and Photodiode (PD), together with ancillary circuits, to transmit and receive visible light signals, respectively. The software is responsible for modulating the LED light in order to transmit and sample the incoming signals to receive, both implemented in the OpenVLC1.3 firmware. The software also implements the MAC layer and part of PHY layer in the OpenVLC1.3 driver.

There are three main differences in the design comparing OpenVLC1.3 to its predecessors:

A new design of the OpenVLC cape (hardware).

A new system architecture (both in software and hardware).

A firmware implemented in the PRUs for data transmission as well as frame and symbol detection (software).

To boost the date rate in OpenVLC1.3, we exploit the PRUs of the BBB. Time-sensitive operations are implemented in the 2 PRUs that control the General Purpose Input-Output (GPIO) to modulate LED light and perform sampling of incoming signals. This separation was also proposed in OpenVLC1.2, but resulted in overall lower performance and required some module in user space. Communication between the driver and the firmware is now performed using a shared memory. A new technique for computation- and memory-limited frame detection also resides in the firmware (the details are presented in Sec.  IV ). The OpenVLC driver implements the MAC protocol and non-time sensitive PHY operations. This maintains the advantages of software-based flexibility and programmability while increasing its performance.

OpenVLC1.3 is already available to the research community 1 1 1 www.openvlc.org . A summary of the improvements of each version can be found in Tab.  I .

II-A Data exchange

The data stream is received in the driver from upper layers. The VLC frame is prepared and then the symbol stream is sent to the shared memory from where it is read by the firmware in the PRU, as seen in Fig.  2 . The PRU then controls the GPIOs to modulate the LED light for data transmission.

At the receiver, light signals are detected by the PD and sampled by the firmware in the PRUs. Once a valid preamble and Start-Frame-Delimiter (SFD) are detected, received data is sent to the shared memory, and then received and processed by the OpenVLC driver. Finally, the received data is sent to the network layer, where it is handled using the TPC/IP Linux kernel.

II-B Firmware

The firmware of OpenVLC runs in the PRUs of the BBB, which operates at 200 MHz, meaning that each instruction takes 5 ns. Each PRU has its own memory and a shared one between the two. The size of each memory of the PRUs is 8KB and the shared memory is 12KB. The reason behind adopting the PRUs in OpenVLC is to increase the data rate and handle a higher sampling frequency of the Analog-to-Digital Converter (ADC). Nevertheless, this effort also requires a tight timing precision in both the modulation and sampling processes. For this reason, assembly is used to program the PRU. In this way, the code of the PRU has been designed to know the exact number of instructions executed and, subsequently, the time required to execute them. In addition, the memory space in the PRU is very limited and this requires careful optimization of all instructions. Finally, there is no enough memory to implement queues, and as such, the communication between the PRU and upper layers must be handled carefully.

II-C Kernel Driver

The main objective of OpenVLC is to have a flexible, low-cost and reconfigurable system for communication using visible light. In order to do so, OpenVLC1.3 has been designed to be as versatile and easy to use as possible. For this reason, we have taken two design decisions:

OpenVLC is mostly code-based and the use of VLC hardware is as small as possible. This makes easy to modify the behavior of the platform just by modifying the software code, such as introducing new MAC protocols.

OpenVLC should be easy to use and adaptable to most use case scenarios. Taking this into account, OpenVLC’s interface has been designed as a Linux kernel module.

The OpenVLC kernel module allows us to create a network interface. This means that any user will see the OpenVLC module as if it is just another network device such as Wi-Fi or Ethernet and any application that we would like to run would be connected through the VLC network interface. As the kernel runs in the processor of the BBB, its processing power is much higher than the one of the PRU microcontroller. For this reason, the most computationally demanding tasks are left in the kernel.

III Transmitter

In this section we present all the different parts that allow OpenVLC to perform a VLC transmission.

III-A Kernel module for transmission

When a user space application transmits data, first the packet is received from the IP layer of the kernel. After unwrapping the frame, the driver prepares the header for the VLC MAC layer. The frame structure is presented in Table  II . Each frame starts with a frame header that contains the following fields: preamble, SFD, frame length, destination address and source address. Each field in the MAC header (starting from the frame length) can be freely modified, for instance to adapt it to the IEEE 802.15.7-2011 standard for VLC  [ 15 ] and upcoming 802.11bb standard for integration with Wi-Fi [ 11 ] .

The preamble consists of 24 alternating HIGH and LOW symbols. After that, the SFD is appended to avoid false positives. The next field denotes the length of frame in bytes, followed by the destination and source addresses.

We use Reed-Solomon code to correct errors in the data field during the transmission. The bits for Reed-Solomon are appended to the frame. We use Reed-Solomon (216,200) error correction code in our default configuration. Subsequently, we use Manchester line encoding, which encodes one bit into two symbols with On-Off-Keying (OOK) modulation (a symbol is either a HIGH or a LOW) and it ensures that the average signal power remains constant. In particular, Manchester line coding converts a 1 bit into a LOW-HIGH symbol pair and a 0 into a HIGH-LOW. This is done to avoid flickering. Both Reed-Solomon code and Manchester encoding are also used in the 802.15.7-2011 standard  [ 15 ] . Finally, the driver places the VLC frame in a shared memory, so that the OpenVLC firmware in the PRU can access it.

III-B Shared memory

In Fig.  3(a) we show how the shared memory is used in OpenVLC. The kernel driver transmit data to the PRU using a shared memory. The first 32-bits (referred as the first ‘register’ in the rest of this paper) of the shared memory are the only space where the PRU can write data. This register is used to exchange status flags between the kernel and the PRU.

The communication works as follows: the PRU constantly reads the value of the first register. If it is zero, it reads it again in a loop, waiting for its value to change. If the kernel receives data from upper layers, it will modulate it and put it the shared memory. When it finishes, it writes in the first memory address the number of registers that the PRU should read. The kernel will not be able to write into the shared memory again until the PRU finishes the transmission. The PRU will then transmit the data and once it finishes, it changes the flag in the first memory register to zero so that the kernel knows that the memory is available again.

III-C Firmware for signal transmission

For the transmission, the PRU is used for the sole purpose of emitting the visible light signal according to the pattern of HIGH and LOW symbols stored in the shared memory. Two PRUs are available in the BBB, and only one PRU is used for transmitting the signal. We implement a counter to track the time between symbols. When it reaches zero, a new symbol is transmitted. In order to transmit each symbol, a HIGH or LOW signal is sent through one of the pins of the BBB. In the current implementation, HIGH corresponds to emitting the visible light signal and LOW to not emitting any signal.

III-D Hardware improvement

The main purpose of the TX circuit is to take the signal given by the BBB and amplify it to turn the LED on/off. As mentioned above, the HW is controlled using the firmware implemented in the BBB’s PRUs. The HW used for the OpenVLC transmitter can be seen in Tab.  III . We have improved the TX circuit compared with previous versions mainly to support a higher transmission rate and a larger communication range.

Increase the transmission rate: we use a PRU at the TX to modulate the LED light at higher speeds. Moreover, we use a MOSFET gate driver transistor to control the current flowing to the LED and support a faster switch.

To expand the communication range: a LED that maximizes the power supported by the transmission circuit, working at 2.8 W with a luminous flux of 400 lm. A lens has been attached on top of the LED to better concentrate the optical power and thus, reach further distance. A heat-sink is attached to better dissipate the heat generated by the high-power LED.

IV Receiver

In this section we explain the design and behavior of the RX.

IV-A Hardware for reception

In the previous versions of OpenVLC, the bottleneck for the throughput was the RX’s sampling rate. In OpenVLC1.3, this is solved partly by introducing a new faster photodiode (PD). This PD does not have its own amplifying circuit. Thus, we add an external amplifier to the RX. The PD’s position in the cape is also adjusted for a better detection of visible light. The most important components are shown in Tab.  III .

The bottleneck of the system for the transmission distance on the reception circuit was the high sensitivity to noise on the receiver circuit. For this reason, a reception chain has been added between the PD and the ADC. In previous versions there was only an amplification stage between the PD and the ADC. In this version, as seen in Fig.  4 , the first amplification stage is a low-noise Trans-Impedance-Amplifier (TIA) that converts the current of the PD into voltage.

Subsequently, a high-pass filter is used in order to remove the low frequency components (specially the DC component from other illumination sources). The cut-off frequency of this filter is 10 KHz. This filter allows us to remove the DC light component and other sources of interference. Although non-visible for the human eye, a light flickering at this frequency would distort the VLC signals. After this, a DC component of 2.5 V is added to the signal so that the signal is centered at half the span of the ADC. Then, the second amplification stage prepares the signal for the dynamic range of the ADC. Finally, before the ADC, a low-pass filter with cut-off frequency of 1.1 MHz removes the higher frequency noise components mainly due to overshooting of the amplifiers.

IV-B Firmware for signal reception

The configuration of the RX is more complex than of the TX. It requires two PRUs. One for handling the HW in a very precise manner and another for processing the received signal.

One of them, PRU 0 , performs signal sampling from the ADC and obtains the Received Signal Strength (RSS) and sends it to the other PRU, PRU 1 , that handles signal detection and the process of converting the raw signal into bits. PRU 0 reads the RSSs from the ADC at a frequency higher than twice the symbol rate.

Then, the raw value from the channel is shared with PRU 1 . PRU 1 interprets the RSSs into symbols for frame detection. PRU 1 continuously checks if a new RSS has been read by PRU 0 . If yes, PRU 1 processes it immediately.

IV-B 1 The bit slip problem

One of the most sensitive stages in a communication system is the correct reception of transmitted symbols. One of the main problems with low-cost systems is that TX and RX get easily desynchronized over time. Their clocks are not exactly the same and the frequencies at which they run are slightly different. This could make the system sample a symbol twice or miss a symbol. This problem is known as “bit slip” [ 16 ] . In the older OpenVLC1.2, the TX and RX frequency were adjusted to the instruction level . This meant that there are exactly the same number of instructions between two symbols transmission and between two symbols reading. However, the clocks in the TX and RX always run at slightly differently frequency, and thus, part of the synchronization problems was still present.

In order to solve this problem, we need to make sure that:

All the symbols are sampled at least twice.

The system should detect if a symbol has been sampled more than twice.

OpenVLC1.3 over-samples the signal to assure that all the symbols are sampled at least twice. The higher the oversampling rate, the more information the system is going to have to detect the symbol correctly. Nevertheless, a high oversampling rate requires a fast processing. In our case, in order to fulfill the requirements mentioned above, the sampling frequency f s ​ a ​ m ​ p ​ l ​ i ​ n ​ g subscript 𝑓 𝑠 𝑎 𝑚 𝑝 𝑙 𝑖 𝑛 𝑔 f_{sampling} should be:

With this configuration, OpenVLC1.3 makes sure that we always receive at least 2 sample per symbol and a maximum of 3. It is not possible to receive 4 samples per symbol, which is necessary to assure the second condition. In the implementation, we modulate at 1 MHz and sample at the receiver at a rate of 2.1 MHz.

The symbol detection in OpenVLC1.2 was just a thresholding algorithm with one sample per symbol with the consequent bit sleep problem. In OpenVLC1.3, we avoid this by using a pseudo-edge detection algorithm. Manchester modulation converts a 1 bit into a LOW-HIGH symbol pair and a 0 into a HIGH-LOW. This means that the maximum number of symbols with the same value is 2. There cannot be more than 2 consecutive HIGHs or LOWs. With two samples per symbol, the system makes sure to read at least each symbol twice, at it can be seen in Fig.  5 .

OpenVLC1.3 can count the number of samples with the same value. If the number of samples is 2 or 3, only 1 symbol has been received. If the number of samples is 4 or 5, 2 symbols have been received. This method can be thought as a very simple and rudimentary edge detection system, as it looks for changes in the signal to see when a new symbol (or pair of symbols with the same value, depending on how long ago was the last change in the signal) has been received.

IV-B 2 Frame detection

The system assumes that a new frame is being detected when the last samples received correspond to the preamble + SFD. The frame detection technique is the one used in OpenVLC1.2 [ 13 ] as it showed to be both low-complexity in processing (required by our application) and very effective. This technique works as follows: First, the RSS values read are compared with their previous values. Because at the beginning of a frame in the preamble (0xAAAAAA) every HIGH is between two LOWs and every LOWs between two HIGHs, every symbol is different from the previous one. If the value of the last 24 bits received is not the same as the preamble, the system continues to collect samples. If it does, continues receiving data.

Once the preamble is detected it continues receiving the rest of the frame. Once received and demodulated, the data is sent to the OpenVLC driver for further processing.

IV-B 3 Communication between PRUs

The signal reception starts with the PRU 0 reading values from the ADC and putting them in a memory shared by both PRUs. This memory is used as a circular memory. When it reaches the end, it continues filling the beginning of the shared memory. In the first register, the address of the latest memory where data has been written is stored as illustrated in Fig.  3(b) . In this way, PRU 1 is able to keep track of the RSS obtained by PRU 0 in real time. Then, the PRU 1 processes the samples taking two symbols at a time, to determine if the encoded Manchester bit is a 1 or a 0. If they contain valid data, it is decoded and shared with the kernel using the same process as for the transmitter.

IV-C Kernel for reception

The frame is received by the kernel after being converted from symbols to bits in the PRU. The Reed-Solomon code is checked with three possible outputs:

The Reed-Solomon reports no errors, so the packet is forwarded.

The Reed-Solomon shows some errors that is able to correct, so corrects them and forwards the packet.

The Reed-Solomon code shows that there are too many errors, so discards the packet.

If the packet is forwarded, the kernel encapsulates the packet so that upper layers can manage it.

Both in the transmission and in the reception of packets, OpenVLC considers that, although more powerful, the kernel cannot run in real time. For this reason, two driver queues are implemented, one for transmission and one for reception. Every incoming packet that arrives to the kernel is queued and transmitted to the PRU or to upper layers as soon as the resources are available. In this way, we minimize the likelihood of losing a frame because the CPU is occupied.

V Evaluation

In this section we evaluate the performance of OpenVLC1.3.

V-A Reception chain

In order to understand the behavior of the reception chain we have measured the raw signal with an oscilloscope. As it can be seen in Fig.  6 , the signal is noisy and small after the first amplifier. Then, the signal is filtered and centered around the center of the ADC’s span. Finally, the signal is amplified and cleaned, to improve the reception.

V-B Throughput vs. payload

V-b 1 setup.

We use two OpenVLC1.3 nodes, one as TX and the other as a RX. Since OpenVLC1.3 provides a new network interface that can be easily accessed by upper layer applications, we use the tool iperf to evaluate the UDP performance of OpenVLC1.3.

V-B 2 Results

The first test performed is to see how the system works depending on its payload. In previous versions of OpenVLC, the payload had a huge impact in the system. If the payload was too short, the overhead due to the physical layer headers was too big, decreasing the throughput. Nevertheless, if the payload was too big, the reception was desynchronized and the frame lost. As we modify the symbol detection technique, now no frames are lost due to the size of the payload. For this reason, the bigger the payload, the better. All the following tests are done with payloads of 800 bytes.

Throughput vs. distance. This test contains the two most important parameters regarding VLC. The first one is the distance at which the VLC communication takes place. The second one is the maximum throughput achievable by the system. OpenVLC has been tested over distance under 3 different scenarios. In the first one, the system has been deployed in a realistic scenario with no artificial lights on (here OpenVLC is seen as the primary illumination source), but with the windows open during the day (“W. open”). In the second one, OpenVLC is tested without any external light interference and the window shutter closed (“W. closed”). In the last one, we open the windows, and we add an artificial fluorescent light source with frequency components that enter in the frequency band of the OpenVLC receiver (“Interference”).

As it can be seen in Fig.  7 , the maximum throughput that OpenVLC achieves is 400 kb/s. Until 3.5 meters, the difference between being in a completely dark environment (“W. closed”) and with external light (“W. open”) is negligible, which did not happen in previous versions. This is due to the filters added in the reception chain. Then, at 3.5 meters the intensity of the external light level becomes similar to transmitted light, making it more difficult for the ADC to differentiate between HIGH and LOW symbols, so the throughput starts to drop. When the windows are closed, the communication is possible at longer range, reaching 6 meters.

In summary, the maximum achievable distance is more than three times better than the previous version and 6 times better than the original one. Also, the throughput is 4 times better than the previous version and more than 22 times better than the first version [ 12 ] [ 13 ] .

VI Limitations of the system

The OpenVLC1.3 platform has several limitations, as any real system. The first one is that the throughput can not be improved without major changes in both software and hardware. Changing the ADC would increase the cost of the board and the processing power required to perform the reception. Also, although technically possible to use OpenVLC as a transceiver, in the current version, the throughput is maximized using one board as transmitter and one as receiver.

In addition, the communication is UDP, as there is no return VLC link in the system. This design decision has been taken after realizing that:

The processing power of the BBB’s PRUs is limited, and having a bidirectional system requires at least twice as processing power as an one-way link.

The current trend in networking is that VLC will operate in hybrid systems, where the downlink is VLC and the uplink is RF. By using the USB interface in the BBB, users may, for instance, use Wi-Fi to send uplink data as well as ACKs for downlink VLC.

VII Conclusion

In this paper, we have presented our latest OpenVLC version and we have evaluated its performance improvements. To the best of our knowledge, OpenVLC1.3 is the first low-cost research platform that achieves a UDP throughput of 400 kb/s using only low-end off-the-shelf hardware. Apart from being used for research and teaching as its predecessors, OpenVLC1.3 can enable real-world applications.

• [1] “pureLiFi,” https://purelifi.com/ , 2018.
• [2] J. Zhang, X. Zhang, and G. Wu, “Dancing with light: Predictive in-frame rate selection,” in Proc. IEEE INFOCOM , 2015, pp. 1–9.
• [3] C. B. Liu, B. Sadeghi, and E. W. Knightly, “Enabling vehicular visible light communication (V2LC) networks,” in Proc. VANET , 2011.
• [4] T. Li, C. An, Z. Tian, A. T. Campbell, and X. Zhou, “Human sensing using visible light communication,” in ACM MobiCom , 2015.
• [5] N. O. Tippenhauer, D. Giustiniano, and S. Mangold, “Toys communicating with leds: Enabling toy cars interaction,” in IEEE CCNC , 2012.
• [6] C. Zhang, J. Tabor, J. Zhang, and X. Zhang, “Extending mobile interaction through near-field visible light sensing,” in Proc. MobiCom .   ACM, 2015, pp. 345–357.
• [7] Y.-S. Kuo, P. Pannuto, K.-J. Hsiao, and P. Dutta, “Luxapose: Indoor positioning with mobile phones and visible light,” in Proc. MobiCom .   ACM, 2014, pp. 447–458.
• [8] C. Zhang and X. Zhang, “Litell: robust indoor localization using unmodified light fixtures,” in Proc. 22nd Annual International Conference on Mobile Computing and Networking .   ACM, 2016, pp. 230–242.
• [9] Q. Wang, M. Zuniga, and D. Giustiniano, “Passive communication with ambient light,” in ACM CoNEXT , 2016.
• [10] X. Xu, Y. Shen, J. Yang, C. Xu, G. Shen, G. Chen, and Y. Ni, “PassiveVLC: Enabling Practical Visible Light Backscatter Communication for Battery-free IoT Applications,” in ACM MobiCom , 2017.
• [11] “802.11bb,” https://standards.ieee.org/develop/project/802.11bb.html , 2018.
• [12] Q. Wang, D. Giustiniano, and D. Puccinelli, “OpenVLC: Software-Defined Visible Light Embedded Networks,” in ACM VLCS , 2014.
• [13] A. Galisteo, D. Juara, Q. Wang, and D. Giustiniano, “Openvlc1.2: Achieving higher throughput in low-end visible light communication networks,” in 2018 14th Annual Conference on Wireless On-demand Network Systems and Services (WONS) , Feb 2018, pp. 117–120.
• [14] “BeagleBone Black,” http://beagleboard.org/Products/BeagleBone+Black , 2018.
• [15] “IEEE 802.15.7-2011 - IEEE Standard for Local and Metropolitan Area Networks–Part 15.7: Short-Range Wireless Optical Communication Using Visible Light,” https://standards.ieee.org/standard/802_15_7-2011.html , 2011.
• [16] O. Jung and C. Ruland, “Analysis of the statistical self-synchronization mode of operation,” ITG FACHBERICHT , pp. 119–126, 2004.

Demonstration Abstract: Research Platform for Visible Light Communication and Sensing Systems

Ieee account.

• Change Username/Password
• Update Address

Purchase Details

• Payment Options
• Order History
• View Purchased Documents

Profile Information

• Communications Preferences
• Profession and Education
• Technical Interests
• US & Canada: +1 800 678 4333
• Worldwide: +1 732 981 0060
• Contact & Support
• About IEEE Xplore
• Accessibility
• Terms of Use
• Nondiscrimination Policy
• Privacy & Opting Out of Cookies

A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity. © Copyright 2024 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.

• español

• book book part conference object doctoral thesis journal article magazine master thesis patent technical documentation technical report
•   IMDEA Networks Principal
• Ver ítem

Research in Visible Light Communication Systems with OpenVLC1.3

Identificadores, estadísticas, difusión.

• Instructions

Publications

• M. Mir, W. Yan, P. Dutta, D. Giustiniano, A. Varshney. "TunnelLiFi: Bringing LiFi to Commodity Internet of Things Devices", ACM Workshop on Mobile Computing Systems and Applications (HotMobile), 2023. [ PDF ]
• D. Frometa, M. Mir, B. Genoves, D. Giustiniano. "Visible Light or Infrared? Modulating LiFi for Dual Operation in the Visible and Infrared Spectra", IEEE Wireless On-demand Network Systems and Services (WONS), 2023. [ PDF ]
• ​B. Genoves, M. Mir, D. Frometa, A. Galisteo, Q. Wang, D. Giustiniano, "Prototyping Visible Light Communication for the Internet of Things Using OpenVLC ", IEEE Communications Magazine, 2023. [ PDF ]
• B. Genoves,  et. al. "Towards sustainable greenhouses using battery-free LiFi-enabled Internet of Things", IEEE Communications Magazine, 2023.
• M. Mir, B. Genoves, A. Varshney, D. Giustiniano, "PassiveLiFi: Rethinking LiFi for Low-Power and Long Range RF Backscatter”, ACM Mobicom 2021. [ PDF ] [ Video1 ] [ Video2_Spanish ] [ Video3_Spanish ]
• C. Lin, Y. Yu, J. Xiong, Y. Zhang, L. Wang, G. Wu, and Z. Luo. "Shrimp: A Robust Underwater Visible Light Communication System", ACM Mobicom 2021.
• M. Cui, Q. Wang, J. Xiong, "RadioInLight: Doubling the Data Rate of VLC Systems", ACM Mobicom 2021.
• J. Talavante, B. Genovés, D. Giustiniano. "Multi-cell Deployment for Experimental Research in Visible Light Communication-based Internet of Things", ACM Workshop on Internet of Lights 2021, co-located with ACM Mobisys 2021.
• K. Ngo, S. Mangione, I. Tinnirello, "Exploiting EDCA for Feedback Channels in Hybrid VLC/WiFi Architectures", MedComNet 2021.
• M. Cui, Y. Feng, Q. Wang, and J. Xiong. "Sniffing visible light communication through walls", ACM Mobicom 2020.
• A. Galisteo, P. Marcocci, M. Zuniga, L. Mucchi, B. G. Guzmán and D. Giustiniano, "Filtering Visible Light Reflections with a Single-Pixel Photodetector", IEEE SECON 2020
• M. Mir, B. Genovés, A. Galisteo, D. Giustiniano, “Non-linearity of LEDs for VLC IoT applications”, Light Up the IoT Workshop Co-located with ACM MobiCom 2020. [ PDF ]
• A. Galisteo, D. Varshney, D. Giustiniano, "Two to Tango: Hybrid Light and Backscatter Networks for Next Billion Devices", ACM Mobisys 2020. [ PDF ]
• J. Beysens, Q. Wang, A. Galisteo, D. Giustiniano and S. Pollin, "A Cell-Free Networking System With Visible Light", IEEE/ACM Transactions on Networking, 2020. [ PDF ]
• M. Haus, A. Yi Ding, J. Ott, "LocalVLC: Augment Smart IoT Services with Practical Visible Light Communication", IEEE WoWMoM 2019.
• A. Galisteo, D. Juara, H. Cordobes, and D. Giustiniano. 2019. "Demo: Video Transmission Using Low-Cost Visible Light Communication", Demo at ACM Mobihoc '19. [ PDF ]
• A. Galisteo, D. Juara, D. Giustiniano, "Research in Visible Light Communication Systems with OpenVLC1.3", IEEE WF-IoT 2019. [ PDF ] [ Video ]
• L. Matheus, L. Pires, A. Vieira, L. Vieira, M. Vieira, J. Nacif. "The internet of light: Impact of colors in LED‐to‐LED visible light communication systems". Internet Technology Letters 2019.
• L. Matheus, A. Vieira, M. Vieira, L. Vieira, "DYRP-VLC: A dynamic routing protocol for Wireless Ad-Hoc Visible Light Communication Networks", Ad Hoc Networks, 2019.
• J. Beysens, A. Galisteo, Q. Wang, D. Juara, D. Giustiniano, S. Pollin, "DenseVLC: A Cell-Free Massive MIMO System with Distributed LEDs", ACM CoNEXT 2018. [ PDF ] [ Video ]
• A. Galisteo, D. Juara, Q. Wang, D. Giustiniano. "OpenVLC1.2: Achieving Higher Throughput in Low-End Visible Light Communication Networks". WONS 2018. [ PDF ]
• Q. Wang, D. Giustiniano, M. Zuniga. "In Light and In Darkness, In Motion and In Stillness: A Reliable and Adaptive Receiver for the Internet of Lights". IEEE Journal on Selected Areas in Communications (JSAC), 2018. [ PDF ]
• H. Wu, Q. Wang, J. Xiong, M. Zuniga. "SmartVLC: When Smart Lighting Meets VLC". ACM CoNEXT 2017. [ PDF ]
• A. Galisteo, Q. Wang, A. Deshpande, M. Zuniga, D. Giustiniano. "Follow that Light: Leveraging LEDs for Relative Two-Dimensional Localization". ACM CoNEXT 2017. [ PDF ]
• Q. Wang, M. Zuniga, D. Giustiniano. "Passive Communication with Ambient Light". ACM CoNEXT 2016. [ PDF ]
• Q. Wang, D. Donno, D. Giustiniano, "Research Platform for Visible Light Communication and Sensing Systems", Demo at ACM IPSN 2016.
• S. Yin and O. Gnawali, "Towards Embedded Visible Light Communication Robust to Dynamic Ambient Light", IEEE GLOBECOM 2016.
• Q. Wang, D. Giustiniano, "Intra-Frame Bidirectional Transmission in Networks of Visible LEDs", IEEE/ACM Transactions on Networking, 2016.
• M. Heydariaan , S. Yin, O. Gnawali, D. Puccinelli , D. Giustiniano, "Embedded Visible Light Communication: Link Measurements and Interpretation", EWSN workshop on New Wireless Communication Paradigms for the Internet of Things, 2016.
• Q. Wang, D. Giustiniano, O. Gnawali, "Low-Cost, Flexible and Open Platform for Visible Light Communication Networks", ACM HotWireless 2015, ACM MobiCom 2015. [ PDF ] ​​
• Q. Wang, S. Yin, O. Gnawali, D. Giustiniano, "Demo: OpenVLC1.0 Platform for Research in Visible Light Communication Networks", Demo at ACM MobiCom 2015.
• D. Giustiniano, Q. Wang, "OpenVLC, an Open-Source Platform for the Internet of Light", IEEE Photonics Society Summer Topical Meeting Series (invited), 2015. [ PDF ]
• Q. Wang, D. Giustiniano, D. Puccinelli, "An Open-Source Research Platform for Embedded Visible Light Networking", IEEE Wireless Communications 2015.
• Q. Wang, D. Giustiniano, " Communication Networks of Visible Light Emitting Diodes with Intra-Frame Bidirectional Transmission ", ACM CoNEXT 2014. 
• Q. Wang, D. Giustiniano, D. Puccinelli, "OpenVLC: Software-Defined Visible Light Embedded Networks", ACM VLCS workshop, ACM Mobicom 2014. 
• Q. Wang, D. Giustiniano, D. Puccinelli, "OpenVLC: Software-Defined Open Architecture for Embedded Visible Light Networks", Demo at ACM VLCS workshop, ACM Mobicom 2014.