Notices


Reply
Thread Tools
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#561
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
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 
Copernicus's Avatar
Posts: 1,986 | Thanked: 7,698 times | Joined on Dec 2010 @ Dayton, Ohio
#562
Originally Posted by Estel View Post
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.
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:

Code:
      # code EU 0
      [ 35714, "510040000000000031026100400000000000310",
        [(430, 470), (430, 910), (430, 83240), (880, 470), (1330, 1330), (2640, 900), (2640, 910)]],
      # code EU 1
      [ 30303, "011111111143261111115326111111",
        [(470, 2650), (510, 540), (510, 1080), (510, 2630), (510, 20530), (510, 116470), (1000, 1090)]],
      # code EU 2
      [ 33333, "0122111222123112211122212",
        [(430, 2060), (460, 2040), (460, 4560), (460, 34880)]],
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.
 

The Following 2 Users Say Thank You to Copernicus For This Useful Post:
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#563
Thanks for taking a look at this, Copernicus, and for code analysis One last question, if You don't mind:

Originally Posted by Copernicus View Post
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!
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
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 
Copernicus's Avatar
Posts: 1,986 | Thanked: 7,698 times | Joined on Dec 2010 @ Dayton, Ohio
#564
Originally Posted by Estel View Post
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?
There is an interesting comment at the top of the python code:

Code:
# Codes scanned by Limor Fried & Mitch Altman for the "TV-B-Gone Kit" project.
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.
 

The Following 2 Users Say Thank You to Copernicus For This Useful Post:
Posts: 268 | Thanked: 75 times | Joined on Jan 2011
#565
Is there anyway to help to create a keyset using the remote control on the n900's ir receiver?
 
Copernicus's Avatar
Posts: 1,986 | Thanked: 7,698 times | Joined on Dec 2010 @ Dayton, Ohio
#566
Originally Posted by Brian_7 View Post
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.
 

The Following User Says Thank You to Copernicus For This Useful Post:
Posts: 1,163 | Thanked: 1,873 times | Joined on Feb 2011 @ The Netherlands
#567
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
 

The Following User Says Thank You to mr_pingu For This Useful Post:
Posts: 268 | Thanked: 75 times | Joined on Jan 2011
#568
Originally Posted by Copernicus View Post
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.
But if someone send me a file via Ir to me n900. How is it possible to receive it without a Ir receiver?
 
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#569
Simply, it isn't You're talking about Bluetooth, probably. N900 IR is "only" emitter, it can't receive anything.

/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 
Posts: 268 | Thanked: 75 times | Joined on Jan 2011
#570
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?
 
Reply

Tags
infrared, pasta, remote, remote control

Thread Tools

 
Forum Jump


All times are GMT. The time now is 19:17.