|
|
Log in / Subscribe / Register

Developing an inexpensive, visible-light network

By Nathan Willis
October 21, 2015

ELCE

Most of us are accustomed to networks that run over radio links or via electrical signals on a physical wire, but those are not the only options. At Embedded Linux Conference Europe 2015 in Dublin, Ireland, Stefan Schmid presented a new networking technology, developed at Disney Research, that operates in the visible light spectrum and uses commodity hardware. The effort is still considered a research project, but once it matures, it may open the door to a variety of new short-range networking uses that will be well-served by staying out of the increasingly crowded unlicensed radio spectrum bands.

For background, Schmid reminded the audience that there are already other optical network technologies, including fiber optics and the direct laser signaling used between some satellites. There are even IP-based network stacks using visible or infrared light, such as Li-Fi. All have advantages—like requiring no spectrum licensing and the ability for users to see when an attacker attempts to intercept or man-in-the-middle a transmission. Disney's new technique is more modest than the others in what it attempts; it uses a bit rate that is slow by wired or radio-based signaling standards and focuses on point-to-point links. On the up side, it has the advantage of using inexpensive components and it can be deployed anywhere there is a standard light socket.

Disney first became interested in visible-light networking for use in toys, where it can provide advantages over Bluetooth or WiFi for communications. LEDs are inexpensive compared to radio modules, and many manufacturers (as well as retailers) remain concerned about the health effects that radio exposure has on young children.

Called visible-light communication (which Disney abbreviates to VLC; no relation to the media player), the technique encodes information in light pulses that are too rapid for the human eye to detect—indeed, the pulses are shorter than the pulse-width modulation (PWM) cycles typically used to set the perceived brightness level of an LED, so the information can be inserted into the PWM pattern without affecting brightness. So far, two hardware options have been explored in the project. The first uses the same directly attached LED to both send and (with some clever trickery) receive signals. The second uses separate LEDs and photosensors. Initially, the team used Arduino boards to control the LEDs, and accessed the Arduino from a Linux box over USB. Later, it began working with ARM-based single-board computers (SBCs) running Linux instead to simplify deployment.

The single-LED method requires the LED to be connected to an analog I/O pin. For transmitting data, the LED is simply pulsed on or off. But most people do not realize that LEDs can be used to detect light as well, Schmid said. They have the same properties as a photosensing diode, but with lower sensitivity. To read from an LED, he explained, one charges the LED and then measures the subsequent voltage drop-off. If a photon strikes the LED, the discharge rate is accelerated. By polling regularly during the LED's "off" cycle, one can decide if a bit has been received.

Disney's VLC system is based on a physical network layer that can transmit about 1 Kbps, using differential encoding to send each bit in a separate frame. These frames are transmitted during the PWM "off" cycle, during which the LED would normally be inactive. Each VLC frame is split into six intervals:

[A VLC frame]


  1. A sync interval, S1. The sync intervals are used to keep multiple devices in clock synchronization. Both devices are off and measuring light during the sync intervals. If both intervals are equal to the ambient-light measurement, then the devices are in sync. If either interval is too high, then too much light is hitting during one end of the frame, so the two devices have drifted out of synchronization. Re-synchronizing the devices is handled higher up in the network stack, at the MAC layer.
  2. A guard interval, G, during which the LED is off, in order to avoid light leakage between slots.
  3. The first half of the differential bit pair, D1.
  4. A second guard interval.
  5. The second half of the bit pair, D2.
  6. Another guard interval.
  7. The final sync interval, S2.

To send a zero, a transmitter turns on the LED during D1 and turns it off during D2. To send a one, it turns the LED on in D2 and off in D1. This differential encoding allows the receiver to detect the bit regardless of what other ambient light is also present in the room; if D1 is greater than D2, the bit is 0. If the reverse is true, the bit is 1.

The last piece of the puzzle is how to account for the extra illumination produced by the VLC signaling when the LED is supposed to be in its PWM "off" cycle. The solution is to compensate by dimming the LED by the equivalent amount during the subsequent PWM "on" cycle. With the total amount of light produced thus equalized, the LED should appear just as bright, to the unaided eye, as a normal LED.

The Disney team has designed this protocol with a nominal frame size of 500 microseconds. The range is on the order of a few meters, although it depends quite a bit on the equipment used. Both the physical-layer VLC protocol and the MAC layer were implemented entirely in software, though commercial products would presumably require hardware NICs many times cheaper than Arduinos and Linux SBCs. The MAC layer reuses many of the same techniques used in WiFi (such as Request to Send / Clear to Send) for basic features like collision avoidance. Although VLC-enabled toys do not require a full IP stack, the team used the standard Linux networking stack to develop the protocols and to explore other use cases.

[Stefan Schmid]

Schmid played video demonstrations of several toys using the single-LED-and-microcontroller implementation, such as a toy car that receives commands from a light bulb and an LED-equipped magic wand that can activate other toys with VLC signals.

But Disney believes the fundamental idea has applications beyond entertainment, Schmid said. The team's more recent work involved modifying standard socket-sized LED light bulbs to embed a Linux-based control board, so that the light bulbs can communicate directly to one another. Such light bulbs could obviously be used in Internet-of-Things "smart home" systems, Schmid said, but they could have other uses, too. For example, they could permit geolocation indoors where GPS is unusable. Each bulb can transmit an ID that can be mapped to a location in the building, with finer granularity than WiFi-based location.

The light bulb implementation necessitates using separate LEDs and photosensors, for two reasons. First, "white" LED bulbs actually use blue LEDs that excite a phosphorescent coating, and that coating interferes with the ability to measure the LED's discharge voltage. Second, the bulbs are usually coated with a diffusion material that shortens the effective range of the VLC signal significantly. For the bulb project, the team initially implemented VLC as an Ethernet device, but Schmidt said they were now exploring 6LoWPAN and other ideas. He showed a demonstration video of a series of light bulbs relaying a "turn off" message as one might use in a smart-home system.

In response to the first audience question, Schmid said that he did not expect Disney to release its code implementation as open-source software, since it is an internal research project. That elicited quite a bit of grumbling from the attendees in the rather packed room. But Schmid added that Disney is interested in turning the VLC protocol into an ISO or IEEE standard if there is sufficient interest, and pointed audience members to the VLC project site, which includes all of the group's published papers and extensive documentation.

Hearing that no code was available put a distinctly down note on the end of a presentation that, up until that point, had engaged the ELCE crowd. On the other hand, if the scheme—or something like it—becomes an open standard, there may be plenty of Linux and free-software developers eager to work with it.

[The author would like the thank the Linux Foundation for travel assistance to attend Embedded Linux Conference Europe.]

Index entries for this article
ConferenceEmbedded Linux Conference Europe/2015


to post comments

Developing an inexpensive, visible-light network

Posted Oct 22, 2015 5:42 UTC (Thu) by alison (subscriber, #63752) [Link] (1 responses)

The potential for application to automotive headlights is obvious. After all, there's prior art in the form of the traditional 'speedtrap ahead!' headlight flash. It would seems that there's little need to transmit during the dark periods of a PWM signal if code-division were used to impress a bit stream on a steady light. Of course, in the case of a steady light, you'd need a separate detector. I wonder if ultrasound would not also have worked for the envisioned toy application.

Developing an inexpensive, visible-light network

Posted Oct 22, 2015 12:15 UTC (Thu) by n8willis (subscriber, #43041) [Link]

Indeed, Schmid actually mentioned automotive (V2I anyway) in a little list of possible applications near the end. I just didn't go into the list in the article since he didn't spend time on the items.

Nate

Developing an inexpensive, visible-light network

Posted Oct 22, 2015 7:57 UTC (Thu) by jem (subscriber, #24231) [Link] (1 responses)

Wait for the bit rate to improve just a little bit (10x), equip the light bulb with a microphone, and we've got the perfect spying device to smuggle into meeting rooms.

Developing an inexpensive, visible-light network

Posted Oct 27, 2015 11:03 UTC (Tue) by NAR (subscriber, #1313) [Link]

As the communcation is done over visible light, I guess it can't get out of a windowless meeting room with closed doors...

Developing an inexpensive, visible-light network

Posted Oct 22, 2015 10:28 UTC (Thu) by robbe (guest, #16131) [Link]

Also prior art: IrDA, http://ronja.twibright.com/

Developing an inexpensive, visible-light network

Posted Oct 22, 2015 19:10 UTC (Thu) by smoogen (subscriber, #97) [Link]

The binary bit pattern is really useful for error detection. I worked on a project that had a <1 milliwatt microwave signal that was half-duplex signal over a distance of 50 km. The other end point was on top a mountain with daylight cloud action so the frequency was mostly water transparent (eg not 2.4 Ghz though I don't remember what one it was). The <1 milliwatt was chosen because that was what the FCC had told a professor it cared about. In order to get 50 km on such a small signal with a lot of possible error, they used a similar encoding mechanism that they based off of DNA base pairs. [signal on antenae 1 was N and signal on antenae 2 was M then 0 was there, different signal pair it was a 1, otherwise send a fail signal back and it would resend.] This had been set up to send large (ok 256x256 images this was originally built in the sixties) images from a telescope that would be compared to look for supernova. In any case they had looked at doing this with lasers in the 1970s but the sensors were not as good [you could do a room not 50 km]

There wasn't much code as handwired circuit boards that had an RS232 interface. [Tubes! I had to change out tubes every couple of months in the 1993. ] but I was able to set up a slip network using Linux SLS running at 115200 over 50km on a signal smaller than the microwave.

Developing an inexpensive, visible-light network

Posted Nov 3, 2015 4:45 UTC (Tue) by jcm (subscriber, #18262) [Link]

Implementation aside, the fact that this is proven possible is the most interesting point. If this were then standardized, plenty of others could create an implementation. This article was a fascinating read!


Copyright © 2015, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds