Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
Bunned. James Bunned.

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.

user:
pass:
register,


                                               

Please log in.
Before you can vote, you need to register. Please log in or create an account.

Dead Simple LED Communication

There are probbly faster and more complex options, but dead simple and reliable is the goal here.
  (+1)
(+1)
  [vote for,
against]

Ideally for most devices, you want a small alphanumeric LCD to display quick information. However for some companies, they are too much of a cheapskate to even include one.

Concept: "Dead Simple" Visible LED for low speed but realiable communcation, to a smartphone via it's camera?

(Why not bluetooth or NFC? Because cost too much)

How is this LED hooked up to the microcontroller? There is three methods I think should be considered.

1. UART hooked to an single colour LED: Cheap but would require a UART port (Not easy to bitbang serial), and requires accurate timing.

2. SPI communication over RGB LED: Bit more expensive than first option and more PCB area to route (due to two extra LEDs). [Red, Green, Blue] = [SCLK, MOSI, SS] = [Clock,Data,Sync]

3. Custom protocol over 2 LED: Bit banging required, but is clocked via "pulses". E.g. PulsedRed=0, PulsedGreen=1, RedGreen(Yellow)=Sync , (The clock is implicit via pulses).

4. I2C over 2 LED: [SCL, SDA] on 2 reds. (Idea from lurch)

5. RGB LED: Red=Sync, Green=Bit1, Blue=Bit2

I would prefer (3), as it has the benifit of (2)'s clocked transmission, simplying the reciver's program. While (3) is not as "dead simple" as (2), it has the advantage of only needing 2 LEDs, Green and Red. And finally, its easier to record 1's and 0's from (3) manually via eyeball if needed, since 1 is green, and red is 0 (At low speed, e.g. error code).

Both would still be relatively easy to reverse engineer (sorta futureproofed?).

Forward Error Correction is definately recommended, but can be optional.

This will be very interesting if smartglasses become popular enough. Imagine walking though a server room, and seeing a real time serial feeds when staring at a mounted server.

-------------

TERMINOLOGY: (SPI:~Serial Peripheral Interface) (Clock:~ Indicates next bit of data) (Sync:~ Indicates that a character has transferred) (Data:~ current bit to transfer)

mofosyne, Jun 06 2014

Data transfer from computer monitor http://hackaday.com...a-computer-monitor/
[mofosyne, Jun 06 2014]

Can transfer over RGB LED to an RGB photodetector... as for smartphones... https://globaljourn...tooth-RGB-Color.pdf
[mofosyne, Jun 06 2014]

Has a javascript demo of data transfer using Clock and Data only http://www.swharden...ta-transfer-part-2/
[mofosyne, Jun 06 2014]

ATtiny NFC tag http://hackaday.com...1/14/a-diy-nfc-tag/
[Spacecoyote, Jun 06 2014]

SVG diagram of (3) the 2 RG LED based transmitter concept http://imgh.us/Dead...LED_Transmitter.svg
[mofosyne, Jun 06 2014]

(?) SVG diagram of (3) the 2 RG LED based Receiver http://imgh.us/Dead...al_LED_Receiver.svg
Untested of course. Its more for conceptualizing [mofosyne, Jun 06 2014]

IrDA http://en.wikipedia...ed_Data_Association
Been around a while. [8th of 7, Jun 06 2014]

ChipTAN flickercode http://www.agses.ne...cker-code-generator
Alternatively, you could just use this approach of using 5 photodiode, where there is 1 clock and 4bits of data [mofosyne, Jan 03 2015]

Smartphone semaphore Smartphone_20semaphore
Much more obvious form of visible light communication [mofosyne, Jan 03 2015]

Timex Datalink http://en.wikipedia...wiki/Timex_Datalink
Transfer by CRT flash [8th of 7, Jan 03 2015]

[link]






       Really? I'm interested if that is possible, never heard of directly driving NFC without an NFC dedicated chip.   

       Though, cost wise, this method is still cheaper, and nearly all phones have a camera. Not the same can be said for NFC.
mofosyne, Jun 06 2014
  

       NFC is basically RFID with optional two-way communication. It was designed to be cheap and simple enough for disposable devices (e.g. smart tags.) Really for a one-off device the cost would be basically the same either way, once you get into volume it would depend on your suppliers and design efficiency. Not saying this is a bad idea, it's just not the way the industry is going, most new phones have NFC and that's what they use for this kind of thing.   

       edit: My initial post about NFC above seems to have disappeared. The point was that all you need for NFC (aside from your microcontroller, of course) is an antenna etched into your board and a few passives.
Spacecoyote, Jun 06 2014
  

       4. I2C over 2 LED: [SCL, SDA] on 2 reds.
lurch, Jun 06 2014
  

       Lurch - I2C is relatively complex to bit bang on the transmitter side. Not sure how easy it is to create the receiver side for I2C. The purpose of I2C is to act as a peripheral bus to multiple addressable devices. This is more intended for point to point connection between device to smartphone. NFC is closer to that goal than I2C-to-LED (and is bidirectional as well)
mofosyne, Jun 06 2014
  

       Isn't this just a revamp of IrDA ?   

       <link>
8th of 7, Jun 06 2014
  

       This half baked idea is not a protocol stack. It only defines the hardware. I am intending this to be a low speed communication to a smartphone's camera, with minimal complexity. So want to avoid "timing" requirements, and go for synchronous.   

       I am aiming for this to be at least as fast as 8bit spoken words to a typical smartphone's camera. Not sure about typical refresh rate of a smartphone camera thought. Will need to test. Might end up being a stale half baked idea if typical camera is slower than spoken voice (until cameras get better). In which case, I'll try pulsing 2 bits at a time synchronously (e.g. Red=clock), or 3 bits asynchronously ( :/ pretty much 3 bit UART).
mofosyne, Jun 07 2014
  

       The capture rate's probably going to be around 60 fps max. With overhead, you might get 3 or 4 characters a second that way.
8th of 7, Jun 07 2014
  

       — 8th of 7, Thanks for the information. Its a bit disappointing I guess.   

       (60fps/2)/8bits=3.75 ~= 3 char for 1 bit TX   

       Which means anything that is relatively 'practical' for smartphone camera to be used, must be RGB based 3 bit UART transmission (Giving 9 char per sec transmission, which is not that bad, but is no longer "dead simple").   

       At the very least, this idea could partially live on as a "semi detailed error code reporting" system, for short error messages. But aside from that, it's a burnt loaf as far as 'dead simple' is concerned. Still will interesting to give both the 2LED(Syncronous) and 3LED(Async) idea a shot myself. So thanks for the heads up.   

       On a side note. There is a thing called Visible Light Communication (VLC) coming soon in a few years for light fixtures, which theoretically can compete with wifi. However I don't think it will replace wifi. Most likely it would just provide opportunistic speed boost, especially in wifi congested areas (VLC is infrastructure costly, needs custom LEDs fixtures).
mofosyne, Jun 07 2014
  

       Great, let's crowd out the visible portion of the electromagnetic spectrum too.
Spacecoyote, Jun 08 2014
  

       //Visible Light Communication (VLC)   

       I believe it's called semaphore. Now if you could get the device to wave little flags about...
not_morrison_rm, Jun 08 2014
  

       … or an Aldis lamp …
8th of 7, Jun 08 2014
  

       Didn't know Aldi sells lamps...
not_morrison_rm, Jun 08 2014
  

       Not as a regular line, but they have them every few months in their "special buys" deals.
8th of 7, Jan 03 2015
  
      
[annotate]
  


 

back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle