h a l f b a k e r yA riddle wrapped in a mystery inside a rich, flaky crust
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
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)
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]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
|
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. |
|
|
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. |
|
|
4. I2C over 2 LED: [SCL, SDA] on 2 reds. |
|
|
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) |
|
|
Isn't this just a revamp of IrDA ? |
|
|
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). |
|
|
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,
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). |
|
|
Great, let's crowd out the visible portion of the
electromagnetic spectrum too. |
|
|
//Visible Light Communication (VLC) |
|
|
I believe it's called semaphore. Now if you could get the device to wave little flags about... |
|
|
Didn't know Aldi sells lamps... |
|
|
Not as a regular line, but they have them every few months in
their "special buys" deals. |
|
| |