Would like your thoughts on an alternative to lcd displays using led/morse code

link=topic=100359.msg760406#msg760406:
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

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.

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

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

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".

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