I have made a small project that enables an arduino to blink information to another arduino. It is inspired by the Electric Imp where it is possible to blink wifi information onto a device which got not keyboard or input devices.

I send information using only an LED and an LDR, the transfer rate is about 20ms/bit (I send 8 bits to construct a byte on the other side, and then build the characters one by one).

So it takes about 2 seconds to send 'HELLO WORLD!". Let me know if someone can use it for something, I will make it available when it is done.

http://www.youtube.com/watch?v=ElVpYfOQJ_c

UPDATE

https://github.com/moryde/blinkIT

There are different functions which are not yet written, the receiver should have the possibility to time out while waiting on a signal. Please fiddle with the timing, and be aware that the strange Serial.print in the Sender somehow make sure that the timing is good.

Could someone maybe apply a logic analyser to show how the timing actually is?

It should be noted that it is likely almost all of the internet traffic these days after it leaves your house likely is transmitted optically over fiber optic lines during at least one step of the journey. Note, you could presumably get more bandwidth by splitting the bits into separate channels that are sent by light at different frequencies, but it will increase the cost of the transmitters and receivers. A quick google shows that you can get low end ethernet converters for about $50 each. Figure maybe $200 if you have to get ethernet sheilds as well. So it likely isn't cost effective....

Nevertheless, for large transfers, avian carriers are capable of high average throughput when carrying flash memory devices.

Back in the dark ages, we had two data centers maybe 40 miles apart, connected by a state-of-the-art 56KB line. Management wanted to move data over this channel, the usual method had been to drive magnetic tape up the highway in a station wagon. We implemented the desired functionality, but management was disappointed at the slow throughput. We did the math and showed how a station wagon full of mag tape had much higher bandwidth than the comm line. We named the comm program STAWGN.

Back in the dark ages, we had two data centers maybe 40 miles apart, connected by a state-of-the-art 56KB line. Management wanted to move data over this channel, the usual method had been to drive magnetic tape up the highway in a station wagon. We implemented the desired functionality, but management was disappointed at the slow throughput. We did the math and showed how a station wagon full of mag tape had much higher bandwidth than the comm line. We named the comm program STAWGN.

Yep, I remember station wagon full of mag tape being the standard unit for large data transfers. Somewhat after that, somebody decided to up the ante, and was talking about a 747 full of CD-roms.

At one point early in my career before FedEx took off with world wide next day delivery, somebody in Europe wanted a tape of a bug fix for the DG/L compiler I was working on, and the company had just put in X.25 connections to its overseas offices. We did a back of the envelope calculation, that it would be cheaper and faster to pay for a round trip ticket across the pond and hand carry the data, than it would be to upload it. I believe the customer decided they could live with delivery out 2-3 days, and we did a normal package mail.

Speaking of using airplanes, one of my coworkers in a previous job was saying at times she would have to fly to the fab in Japan, and get two carry on suitcases filled of the first tape-out of whatever the new chip was and fly back first class (to get more carry on space) to the home base so the company could begin system bring up ASAP. She could carry nothing in carry on luggage, as all of that space was reserved for chips, and it was extremely important that the new chips never leave her custody, which is why FedEx, etc. wasn't used.

Nice!please post the code and some more detail if you can. I am interested to have a look. Are you using any kind if encoding? Looking at the video, it seems like a long pulse high marks the beginning of transfer. Have you considered the issue of ambient light (daylight), or is it too early at this stage?

Nice!please post the code and some more detail if you can. I am interested to have a look. Are you using any kind if encoding? Looking at the video, it seems like a long pulse high marks the beginning of transfer. Have you considered the issue of ambient light (daylight), or is it too early at this stage?

Anders

It is not using any encoding atm, just reading bit by bit to construct bytes on the other side. The problem with daylight is not really that big of an issue as I see it, it would be very easy to tweak to whatever conditions you want it to work in.

Yes,laser beam is on my mind too. It would be very cool to use as an unusual and alternative wireless transfer technology. I think doing some basic encoding, such as Manchester encoding, on the signal will improve robustness a whole lot. That will probably help when doing longer distance.

Yes,laser beam is on my mind too. It would be very cool to use as an unusual and alternative wireless transfer technology. I think doing some basic encoding, such as Manchester encoding, on the signal will improve robustness a whole lot. That will probably help when doing longer distance.

Are you willing to share the code? I am curious.

Again, nice work!

Anders

Original post is updated with a github rep.

I am currently working on an iOS application that can memic this: http://youtu.be/-R_thigW_-w?t=3m2s