next topic »

[Reply #15 on:]

I would stick to something that is standardized.
irDA has been around a long time and provides everything you need including two way
data communications but isn't really used that much anymore.
There are also non standard things like this:
http://hackaday.com/2012/02/06/play-hide-and-go-seek-with-infrared-leds/
Unfortunately you may not be able to do that kind of stuff using just the camera in a smart phone as the sensor.
(Older devices actually had irDA built in)

If you are going to use an LED as output I'd avoid using brightness levels to indicate
different data. I'd stick with on/off which is much easier to detect.

I'd do a simple serial protocol. You could even do ASCII.
(some thing like space = led off, mark = led on)
Drop the baud rate way way down and it shouldn't be that difficult.
If you want to crush down the numbers of bits/byte you can even look way back
at the 5 bit baudot codes (from the late 1870's).
There was lots of this low speed bit compaction kind of stuff going on back
in the 70's during and earlier on teletypes and even over early modems.

You might even be able to support a standard like 45.5 baud with baudot codes
or possibly just regular ascii.

Google around for things like 45.5 baud, TDD, baudot, 5 bit telex codes etc.
You will find lots of interesting information that predates much of the entire
computer revolution that started in the 80's.

There is often still support for these kinds of things even in todays operating systems.

--- bill

[Reply #16 on:]

in regards to re-inventing the wheel:

I am positive such devices already exist. I believe I have seen a paper which had two circuits communicating bidirectionally using one led per circuit for communication. (I think it was by Toshiba or Motorola or some company with a Japanese name)

Then I think some MIT people developed micro-controllers which are re-programmable by strobe-like light from the monitor.

I dont have time to google, but I am sure there are more things out there.

*

still is a really cool Idea and a standard protocol would be cool...

[Reply #17 on:]

Re reply #16,nice one having just spaces for a name

______
Rob

[Reply #18 on:]

Mister <no name> is now being investigated by moderators. I suspect some sort of forum bug. Meanwhile if you (<no name>) would like to edit your profile and fix your name up that might help.

[Reply #19 on:]

If you look at the members list there are a few no-names.

______
Rob

[Reply #20 on:]

in regards to re-inventing the wheel:

I am positive such devices already exist. I believe I have seen a paper which had two circuits communicating bidirectionally using one led per circuit for communication. (I think it was by Toshiba or Motorola or some company with a Japanese name)

maybe this one from Mitsubishi:
http://www.merl.com/projects/LEDcomm/
link to paper: http://www.merl.com/papers/docs/TR2003-35.pdf

Then I think some MIT people developed micro-controllers which are re-programmable by strobe-like light from the monitor.

Kind of like the way the Timex datalink watch worked.


--- bill

[Reply #21 on:]

Why not this no-brain encoding of ASCII?

Light is "toggled" on and off. Time between "toggles" is either "short" or "long". "Long" is twice as long as "short".
"Short" codes 0. "Long" codes 1.

[Reply #22 on:]

Thanks again to all for all the input.  The Bi-directional communication via LED stuff is really cool, I'll have to try that out some time.  In any event, where I'm headed next is to lab this out using an arduino as a mock 'phone.'  The idea will be to make the mock device act as much like what I expect a phone camera to act (that is, slice up 25-30 'frames' of time and record light/no-light conditions).  I will use that setup to work out what works/doesn't on the encoding side.  Once (if?) I get a handle on that, I will hand it off to a developer to write the analogue for a smartphone OS.
So far, I've gotten about as far as doing a simple test where I just use a photocell to sense the length of time it senses light, and map that time-length value to an ASCII character.  Of course, I realize this is nothing like how a smart phone camera would acquire data...

-shane

[Reply #23 on:]

feel free to contact me, I would be interested to help implement this on android.

[Reply #24 on:]

From a certified dinosaur--
Look at an ASCII chart.  If one were to develop a six bit code using a default of hex 20 through 5F you've got upper A-Z, all digits and a good assortment of punctuation.  You could transmit hex 00 through 3F, (six bits) and the receiver could default-offset by Hex 20 to land you
at "Digits and Upper Case" section of the true ASCII standard, which might suffice for many operations.

Now burn or redefine the highest code,  3F, as the sentinel for a two character "Shift Offset" command.  The highest character in your default is the underscore, which you would lose.  The second character ShiftOffset sequence is limited to values between 0 and 7 decimal.  Multiplied by 32 decimal, it is the ASCII table offset of all subsequent six bit codes. Your default ShiftOffset was 1.

A ShiftOffset sequence directs the receiver to shift it's ASCII lookup offset until another ShiftOffset sequence is sent.  A ShiftOffset of 3 lands you in lower case a-z and a hatfull of non-English alphabet characters. A ShiftOffset of 6 gets you Greek symbols.  A ShiftOffest of 1 gets you back to the default.

A side effect is that a ShiftOffset of 2 lands you in upper and lower case English without digits, and puts that previously shanghaied underscore where it is plain text (but now the DEL is burned for the ShiftOffset sentinel in this segment). 

The math is simpler than it sounds, you just use each transmitted character as the low order six bits of ASCII code, and the low order two bits of the current ShiftOffset as the high order ASCII bits,  and optionally watch for hex FF as a ShiftOffset change.

So, a simple Arduino sends out a 32 bit code and a simple receiver plugs the two high order bits and you've got ASCII 0-9 and upper case A-Z.  You also get comma, decimal, dollar sign and all of the other special characters which are residual from the punch card days.  Trust me, I was there.  Go find an IBM 026 printing card punch at the Smithsonian, and that is the source of ASCII hex 23 through 3F.  But I digress.)

A more ambitious Arduino sends out a 32 bit code with ShiftOffsets, and a simple receiver prints digits and upper case OK, attempted lower case is printed as upper case (because the ShiftOffset does NOT offset, nice), and the underscore prints as an underscore followed by an extraneous pound sign or something, hardly a deal-killer.

I would suggest that an ambitious Arduino actually transmit an initial ShiftOffset of 1 just to let the sophisticated receiver verify that we are dealing with tricked-out full ASCII.   

And, an ambitious Arduino going to a sophisticated receiver not only talks Greek, Russian and draws simple boxes, but can also issue a carriage return for your TTY33  ASR. 

You do have a Teletype model 33 Automatic Send and Receive sitting around that you've trying to get the carriage return to work on, haven't you?

"We computer geeks love Standards.  That's why we have so many of them".

     

[Reply #25 on:]

fkeel, thanks, I will definitely look you up once I get a bit further on my homework.