• Author Author: amgalbu
  • Date Created: Date Created
  • Views 1099 views
  • Likes 7 likes
  • Comments 15 comments
Related
Recommended

LEDRoadTestPlus - Post 11

amgalbu

This is the last post of this roadtest

The initial idea was to transmit a unique code using the visible light. This has applications in indoor navigation (in museum, shops, etc)

 

I got a working prototype (I will publish a video in the next days), with several limitations

 

1. the algorithm used is tailored for my smartphone, so I don't expect it to work on another model. In particular, the algorithm is affected by the frame rate and by the exposure time. Also, not all the possible image formats supplied by the smartphone camera are supported. A more robust algorithm in my hopinion should be based on FFT transform

 

2. the application works only with reflected light

 

3. There is no way to "isolate" codes transmitted by LEDS that are installed close to each other

 

So, far from being a commercial application, in these roadtest I got the opportunity to explore this new (at least for me) field of application

 

Attachments:
VLCDecoder2.zip
  • in reply to balearicdynamics

    Hi Enrico

    the problem is not to see the light source, but set an exposure time that is somewhat related to the frequency of the PWM that drives the LED, so that the rolling shutter effect is "captured". That's the difficult point: how to determine the optimal exposure time. Note that the optimal exposure time is related to fps, preview image' resolution, etc

     

    Ambrogio

  • in reply to amgalbu

    Starting up from Android 4.x.x Camera settings are very well controlled by the system with a robust set of APIs. It is possible on the better smartphone models (the ones that includes camera light sensor and non-digital autofocus) setup them for super-bright shooting. This not only avoid the saturation of the sensor but also - IMHO - optimise the data acquisition as the transmitting LEDs become the only well detectable light source respect the background.

     

    Enrico

  • in reply to amgalbu

    Ambrogio, this super-bright LED are sure "too" bright, but I see it as a great advantage. We should consider that a kind of light source like this will not be used 15cm away from the detector. So - just thinking to and example - I imagine a large room, e.g. a underground parking, where the same lighting low cost system will be used to send / receive data and security information (i.e. to unlock the car for automatic ticket payment) also when the car owner is at a reasonable distance from the source (15 meters ?). In cases like this this kind of method may be better than any other alternative.

     

    Enrico

  • in reply to DAB

    Yes DAB, you are right: the brightness of the LEDs is saturating the camera

    However, my idea was to implement VLC in a device that can replace a standard light bulb, so it is not advisable to dim the LED too much

     

    Cheers

    Ambrogio

  • in reply to shabaz

    Hi Shabaz

    Actually the problem is the decoding... I need to devise a way to robustly detect the start of the frame, and, as I said, the current method depends too much on camera settings

     

    Cheers

    Ambrogio