Ok. My method was very simple. But for start:
The photodiod is very fragile to light from a standard bulb - It makes the sygnal very bad. The best way I thing is first to observe the signal in a recording program (like Audacity). You can there see if the covering is good, and if the led blinks in the right place. Next thing is to try to narow the blink lenght so that you can easyly see the blinks in the program.
The photodiode works like a differential, with a delay - so a blink don't look like:
___/-------\___
but like
----/-- ------\----
in zoom it goes like:
___|\____ and a similar downward.
So when the blink starts there is a shift upword, then it goes slowly to 0 then when the blink ends there is a move downward and slowly back to 0.
Moral is: When the blinks are near themselfs you can't read it directly - you have to [d/dt] it. Then you'll have a nice 0 0 0 0 -1 0 0 0 0 1 0 0 0 0 -1 0 ...
Ok, now why I said it? becose now you can write yourself a program. You install ESD (linux? cygwin?) and then run: esdrec -m | ./yourprogram. It make life easy: esdrec -m sends a raw stream of integer values 44100/s. You revice it, and analyse it. First program is d/dt and watch what is the hight value, and what is the low value. Next is to count the integers between them. Next is to make the delays in to bits and write them to stdout.
I used the simple method to code strings (I copied the code in some thread) You can use a better one. Thing is - If you'll start the program without running os or something - it blinks perfectly. If you want you can make a checksum :-) I used base64 so that the binary data will be readable so I can see on the screen if there transfering properly. When you stick the photodiode it sometimes slips away - and the signal is lost - you can see it on the screen then :-)
I attache a very badly writen program to analyse the data from esdrec -m (-m is for mono :-) ). It do what I wrote - You can set the delays in the header - and ... you'll see what is for what :-)
