MaxCoderz.org

Warning:
I don't know how much current the link port can safely source, so using it to sink current when driving the IR LED might not be exactly safe. It works fine for me but my 5V source is from a regulated 9V PP3, which delivers a very low maximum current anyway.

It might be a good idea to build a small transistor power amplifier so that you only sink a very small current through the link port.

SonyIR is a library that can be used to send and receive commands using the Sony infrared controller (SIRCS) protocol.

Libraries are rather dull on their own, so I've also thrown together a program (likewise called SonyIR) that can be used to turn your calculator into a programmable remote control.

You can download the latest version or download a video (controlling a Sony TV - 960KB WMV).

Features

• Send and receive data using the SIRCS protocol to control Sony devices via infrared.
• Support for 12-, 15- and 20-bit command words.

Sending

• Minimal hardware required (cheap single IR LED and optional resistor, depending on circuit) thanks to software modulation.
• Easily send single commands or repeated commands spaced at 45mS.

Receiving

• Simple hardware thanks to cheap single-package IR module.
• Routine returns button code, device ID and number of bits (or an error condition).

Usual disclaimers apply; this is a first version so I'd like to hear if you encounter any bugs.

awesome work Ben! this makes me remember to start reading your Development Journal again....

Yet another one of your amazing pet projects Ben ... This one is :O.

Im off to the electronics store to get some parts! .

It was a quick project; the most time consuming thing was the clock cycle counting to get the timing right.

I've very roughly written up the protocol used by SIRCS devices. I'm not aware of any other standardised protocols.

The aim of the routines was to provide a way to transmit and receive SIRCS data; however as a programmable remote control library this limits you to Sony devices (and hence the usefulness of the project).

I will experiment with my other (non-Sony) remote controls and log the results, but I'm assuming that most protocols will follow the same pattern - a longish delay of silence, followed by a series of pulses with silence between them.

What you could probably do would be to wait for a "long" silence, then time the length of the ensuing pulses until you "timed out" (ie, you'd hit a long silence again). You could therefore record remote control signals and play them back. The routines would not understand or decode the data received and the storage space for each command would be very much larger, but if it works it would be a lot more flexible than the current Sony-only solution.

It would be interesting to see if someone could come up with a TI<->TI IR protocol/system. Sami Khawam did all this a long time ago, but his solution requires a lot more hardware.

Great work ben, I love your hardware related projects!

After the Sony protocol was sorted out I had assumed that other remote controls would use a similar or - if anything - simpler protocol. I couldn't have been more wrong!



Crivvens. Well, I decided that the best way to store any IR signal would be to store it as a list of delays - switch on 40kHz generator, wait X time, switch off generator, wait X time, repeat until done.

For example, with that signal above, you'd do this:





Multiply by fourty as the carrier frequency is 40kHz - kHz * mS = number of cycles.

The result is this, which (to my surprise) does actually work!

Video (293KB WMV).

(What you can't see, of course, is the real remote control in my left hand).

I'll have to work out a way to detect a single, complete signal (so it can be recorded) and a compression scheme (~200 bytes per button is not exactly small).

You're such a genious ben, this is incredible .

I wish i had more IR devices lying around :X.

That's pretty funny Reminds me of the IR gate my friend and I made in highschool. We could send over bits from one calculator to another, but we lacked the parts to make it two-way, and the time to make it send/read bytes. We did use pretty much the same scematic as you do, though; attach an IR led amost directly to one connector and one of those neat IR receivers on the other. We added an inverter though between the calculator and the IR led to invert the active low signal of the calculator, and to boost the output signal. It increased our range from about 40cm to 2 meters.

In fact, it was that project that first got me thinking about calculator networking with more than two calculators. It's what spawned the article "Multi-user networking" in this zip file, which later got me working on the CLAP (and Kerm on his gCn I think ):
http://www.ticalc.org/archives/files/fi ... 29418.html


That would be quite trivial, I'd think. If you have the senders and the receivers in place, you just need a bit of software to communicate. We came up with the following idea back then:
Sending out a short pulse, followed by a long pulse = 1
Sending out a long pulse, followed by a short pulse = 0
You could use an "average" pulse as an indicator that you're starting a new data packet, and use that average to compare all following pulses with, or just measure all pulses and compare their lengths in pairs of two. That should allow you to communicate between two calculators; adding a networking layer as the CLAP does would allow communication among more calcs.

Unless you mean a protocol/system to connect two calculators as if they were linked with a cable, so you can use the TI-OS send and receive?

i think the most handy thing is having one that would translate any bytes sent to it from the calculator into the IR protocol, and any received from the IR protocol to bytes for the calculator

That'd requite some external hardware, though, and the more complicated the hardware the less likely anyone would ever use it.

The calculator's link port can source very little current, so directly connecting the IR LED between a data line and ground is indeed very short range (and the LED is stuck 'on').

However, the link port can sink a substantial current (I'm not sure how much is safe, hence the warning at the top of the thread) so if you connect an IR LED between +5V to the data line (+5V being supplied, for example, directly from a terminal in the battery compartment) the LED is normally off and when the data line is pulled low it lights very brightly, giving you a good range.

I know, i'm just saying that is a far more useful device

@elfprince: That entirely depends on what you want to use it for.

@Ben: You mean you connect a data line with some external +5v through the IR led? Is that safe..? My knowledge of electonics is fairly limited, so I wouldn't even have been able to come up with that

It depends on how much current the link port can safely sink.



It's all about potential differences. If you ignore the rest of the circuit and just look at the LED and resistor, normally there's 5V (relative to ground) at each end, giving a potential difference of 0V and a non-lighting LED. When the link port data line goes low you have 5V and 0V (relative to ground) at each end of the circuit, so current flows. This takes advantage of two things - that the link port can sink a lot of current (but not source much) and that it's active low.

My only concern is that if the IR LED and resistor draw a lot of current, then that current is also having to flow through some poor component in the calculator which could potentially burn it out.

I've written an all-new library and program (though borrowed a few of the modules, so it looks and acts the same) that can handle most types of remote control, not just Sony ones.

[url=http://benryves.com/bin/infrared/]
Download[/url]

It can decipher the remote control protocol and save away the timings so that button presses can be recorded as a small stream of bits, rather than a lengthy list of on/off timings.



There are some limitations; the library only allows for a single start bit, requires that the main body of the message only has two different timings (a '0' and a '1' bit - so not like this) and that there is a delay after each transmission longer than the total length of the start bit. Seems to work pretty well in spite of this, though.

Not sure how much interest there is in this project (as far as ironing out any further problems goes) and I don't really have much time to dedicate to it. Source is, as ever, available.

Awesome work ben, i absolutely love the dialog box system (and that isnt even the impressive part of this project! ).

I will be testing this out with my remoteless tv ... it will be so cool to be able to control it with my calc (with any luck ).