I was working an a completely different project, an infrared light barrier for outside and I needed some way to filter out the IR light of the LED from the sunlight. A common way to do this is modulation. Instead of just having a LED constantly on, you flash it really fast, e.g. with 33 kHz. The receiver filters out all other frequencies and gives a steady signal. We had a TSOP31233 (datasheet) lying around. This one connects the output pin over a transistor to ground when a 33 kHz signal is applied. The modulation worked fantastically, but the receiver is that sensitive that you cannot simply block the light with a simply object, you have to completely cover the receiver with a black box. That isn't really surprising, since those receivers where made for IR control systems and have to work under every condition. So I took the TV remote and looked what I can get out of it. Strangely enough it works with the same frequency, and it also uses a really simple protocol.

Schematic:

As you can see, there are no other electronic components needed!

I hooked up the sensor to my trusty 83+ and made a simple program that plots the state of the sensor over time. I figured out that the protocol starts with a rather long HIGH pulse, then a short LOW. The bits are coded in the length of the HIGH pulses (long pulse = 1, short one = 0), the LOW pulses are all the same time; the LSB arrives first, then a sequence of up to 15 bits. On this Sony remote, newer functions have more bits (such as enable surround sound or the Bravia sync system) where as functions that have been there forever (numbers, volume, power) have only 8 bits. I figured I only need the lower 8 bits so the following code ignores the upper bits. The program is written in pure Axe:
Lbl READ
While 1
EndIf port    //wait for the start bit to end
For(r1,0,7)
  If EAT()  //return if Stop bit reached or abort
    Goto END
  End
  GET()->{L1+r1}   //buffer the input
End
Lbl END
0->r2     //result
For(r1,0,7)
  r2*2->r2   //shift left
  {7-r1+L1}+r2->r2   //reverse and "or" together
End
r2
Return

Lbl EAT   //"eats" the Low state
For(r3,0,100)
  For(20):End  //some delay
End!If port  //wait until HIGH again
r3>100  // time out exceeded = Stop bit
Return

Lbl GET   //measures the length of a HIGH pulse and returns the result as a bit
For(r3,0,100)
  For(25):End
EndIf port   //wait until LOW again
r3 > 8    //8 seemed to be the threshold that worked best
Return
You can now write programs which use this function. For example move a sprite around the screen:
[3C7EFFFFFFFF7E3C]->Pic1
FnOff  //disable the nasty OS interrupts
44->X
28->Y
While 1
  !If port   //check for a keypress
    READ()->K
    K-244??Y--   //up
    K-245??Y++   //down
    K-180??X--   //left
    K-179??X++   //right
    Pt-On(X,Y,Pic1)
    DispGraphClrDraw
  End
EndIf getKey(15)
LnReg   //turn interrupts back on
Return

--- Subroutines from above ---

The video is probably the thing you are interested in the most:



Currently it works at around 10 key presses per second and I haven't got much hope that this will increase, since the speed is defined by the remote control, so I guess real time games are quite hard to accomplish.



Going further

What I have shown you is only a proof of concept. You can include remote control to any Axe or Asm program.

What you then could do is place the routine into a link port hook (IIRC there is one to transmit programs "silently") which enables when a key code is incoming. The code is then translated to "real" TI 83+ keycodes via a LUT and then given to the OS as a regular keypress - making it possible to enter your calculations with a freakin' TV remote....

The question one might ask is "What's the point of this?".
I'll ask instead:
Where will this lead?

WOAH DOOD  How do I build this???

That's cool

If you add an emitter to it you can make an universal remote control. A small circuit can do the modulation for the calc.

That's a nice idea - you could then program each key by recording the sequence with the receiver.
I don't really want to use another circuit to do modulation - when you use e.g. an ATtiny (which I love by the way!) everything is possible and often much simpler. But the beauty of this project is, that it doesn't use any other hardware than the receiver, which is only one little IC with three leads.

When you let the micro controller do all the work for you you don't even need to program the calc anymore, since the OS has already a key emulation function built in!

MGOS, 33 KHz isn't that fast for a 6 MHz processor. You can do port writes at least 1 MHz, assuming you have what you need to transmit.

MGOS, 33 KHz isn't that fast for a 6 MHz processor. You can do port writes at least 1 MHz, assuming you have what you need to transmit.

Yeah, I misestimated... 33 kHz should work, but 1 MHz isn't doable for the z80: OUT(C),r takes 12 T states, meaning at 6 MHz you can achieve at maximum 500 kHz by putting dozens of OUT instructions after each other - and you need to divide that by two to make up a whole period (high -> low -> high). Having a loop and a nice ending condition and a duty cycle of 10% (which is better than 50% for these applications) you probably come close to the limits even in straight asm.

The IC demodulates the data, so it´s not 33kHz anymore. It´s just the carrier that is 33kHz.

For the receiver yes, but were talking about a sending LED here!

What is this dark magic?

When I read the title, I expected you to have made a remote out of a calc by creating some sort of plug attachment. But this is cool too.