Notices

Quick test to prove that - try with TVBGone (program for N900), and be sure that You're reasonably close, aiming as You should etc. I have yet to see any TV, that doesn't "die" due to TVBGone

BTW, as mentioned program is quite old, also doesn't use LIRC, and probably could use some new disable/standby codes - Copernicus, what do You think about updating that one too? It seems, that it's code is quite simple, and for someone already experienced in developing Ir application, updating code database *should* be trivial, as it seems.

/Estel

Fascinating! I've just pulled down the tvbgone code (which is a nice little python script), and yeah, it doesn't use LIRC. Very nice. Their set of codes is very simple, and consists of entries like this:

In these entries, the first value is the carrier frequency, the second value is a string of indexes, and the third value is an array of microsecond timing pairs. Constructing a shut-off command is then just a matter of building up an array of timings by going through the string, and for each index, selecting the appropriate timing pair.

There are protocols for which this mechanism would be inconvenient (not everybody uses simple pulse/space timings to encode individual bits of data), but you could probably hack it to work with most devices.

There's one big problem with maintaining this code, though: I have no clue which TVs are supported and which are not. I can probably pick out a few -- some protocols have odd timing values that are easy to recognize -- but for most of them, it'd take some effort to determine exactly what device they are for. Which makes it awfully hard to know what needs to be added!

I'm probably not going to get involved with that code (I'm having a hard enough time making enough time for my own projects ), but it looks easy enough for just about anybody to play with if you'd like to mess around with IR.

Thanks for taking a look at this, Copernicus, and for code analysis One last question, if You don't mind:

Theoretically, what do you think about best solution to avoid this problem? Re-write of code/method from TVBGone!, to clearly indicate supported protocols/TV's? Of course, i mean situation, when someone would be interested in keeping it up to date, expanding list once a few months or so.

I know it's a little off-topic here, so sorry for that - I'm quite interested in it, as using "single button killall TV's" was a sanity-saver for me in many waiting longues, and to be honest, I find that I use it even more often that direct IR control. At the same time, without maintaining, this useful python piece of code/widget is going to be obsolete soon.

/Estel

There is an interesting comment at the top of the python code:

So, apparently, there's a TV-B-Gone Kit somewhere...

But yeah, I would write it differently myself -- at the very least, I'd embed as much info as I could about the actual device being controlled by each entry. Even if only as comments. Of course, I'd also write the whole mechanism a little differently; I'm sure whoever came up with this "set of timing pairs" system was working off of the very popular "NEC" protocol, but there's no point to constraining the system to using pairs of timings for every device (especially since some devices don't use pairs of timings at all!). (You can tell that the guys writing the code were a little frustrated when they discovered that they could only pass an odd number of timings in to the device driver, and mentioned that fact in a comment; but of course, the problem is not in the device driver, but in the fact that they are constrained to using even numbers of timings in their system. In this case, it is the device driver that is correct, and their encoding scheme that is wrong...)

Anyway, yeah, the situation here appears to be that the tvbgone code is built off of a "kit" that was created elsewhere. Finding the creator of the kit might provide an easier way of upgrading the code than attempting to reverse-engineer each of the entries.

Is there anyway to help to create a keyset using the remote control on the n900's ir receiver?

Unfortunately, the N900 only has an ir transmitter; it can't receive ir commands, so it can't "learn" keysets the way that a "learning" remote control can.

http://www.ladyada.net/make/tvbgone/

*Might* include good stuff in the download section of that site

edit: Just digging the web to see if I can find something...
http://forums.adafruit.com/viewtopic...b3e316df475e01

But if someone send me a file via Ir to me n900. How is it possible to receive it without a Ir receiver?

Simply, it isn't You're talking about Bluetooth, probably. N900 IR is "only" emitter, it can't receive anything.

/Estel

Ok, i just see that there is no option to send a pic via ir on my n900. I thought that it was.

I think that my N95 has an Ir receiver. Can i use it instead of my n900 to help you with the development of keysets?