[Announce] Pierogi - a universal infrared remote control app - Page 24 - maemo.org

Active Topics

Firefox with Leste (5)
to Maemo 7 / Leste by teroyk - 4 days, 11 hrs ago
Handbook (2)
to Maemo 7 / Leste by teroyk - 5 days, 10 hrs ago
more...

Page 24 of 140

Thread Tools

	Copernicus	2012-02-18 , 00:36
	Posts: 1,986 \| Thanked: 7,698 times \| Joined on Dec 2010 @ Dayton, Ohio	#231

Originally Posted by sixwheeledbeast

Eventually as the Compatible Devices List gets bigger maybe the search can be adapted to search for a device.

Actually, my original design included two different collections to choose from -- you could either choose a keyset or a device. But the device list I came up with was so pitifully small, I just gave up on it. I am indeed hoping that the Compatible Devices List grows rapidly! (And in fact I'm adding the compatible devices into Pierogi bit by bit, even though I don't yet have an interface to access them yet...)

are there any guidelines for testing keysets?

The biggest problem for Pierogi right now is that all of the keyset information I've got, every last bit of it, was derived from folks "reverse-engineering" their remote controls by pointing them at an IR receiver hooked up to a PC and pressing each button one by one. That's how the LIRC folks do it, how the Pronto folks do it, and how the JP1 guys do it. So I'm sure there are times when people wrote down the wrong timing value, or missed a button, or swapped two different buttons, or made an error naming the button, etc. (Let alone the errors I make importing the config files.) The data is not going to be perfect. What I would most like to know is this -- when people find a keyset that works with their device, do all the buttons work? Are there missing buttons? Are there buttons swapped around?

This is time consuming work, and I don't really expect people to just sit in front of their device and hit every single button in Pierogi.

But I'd love to hear about it if and when a keyset does not perform as expected...

Quote & Reply |

The Following 4 Users Say Thank You to Copernicus For This Useful Post:
don_falcone, fw190, peterleinchen, sixwheeledbeast

	Copernicus	2012-02-18 , 01:04
	Posts: 1,986 \| Thanked: 7,698 times \| Joined on Dec 2010 @ Dayton, Ohio	#232

Originally Posted by tecs

Is the point of the project to implement all of LIRC's database or just to add keysets when requested?

I would love to incorporate the full LIRC database, and perhaps, in the fullness of time, I will accomplish that goal. Until then, though, some folks may not want to wait for their favorite device to get supported.

Why don't you make a way to enable the community to contribute with keyset data/import from LIRC instead of channeling everyone's wishes through you?

Good question! In fact, a couple months back, I started the project planning to use the same scheme QtIrreco does -- reading individual LIRC config files provided by the user. Even as I started creating my own internal database of keysets, I still intended to keep the ability to import LIRC config files.

But there are problems with using the LIRC system. LIRC was created for the purpose of allowing a PC to read data from any random remote control pointed at it. Receiving IR is its bread and butter, transmitting IR back out again is just a side-project. The LIRC config files are very poorly designed, if what you want is to create a universal remote control, not a universal IR receiver -- they don't provide much (if any) information about the original target device of the remote, they have no coordinated method for naming individual commands (most LIRC users don't even care what their remote buttons are labelled as, since they end up remapping them for their own purposes anyway), and they mostly just describe the raw IR pulse sequence, which is inefficient as many protocols use redundancy and checksums to improve reliability. So, as time has passed, Pierogi's internal system for managing keyset data has moved further and further away from the LIRC format; so much so that I no longer have an easy way for people to just import LIRC files.

There's no reason I couldn't come up with an alternative standard. Indeed, the file formats that the JP1 folks are using are much closer to what Pierogi would need (which only makes sense, as they are more interested in the transmission side of the equation than in the reception side). But yeah, this is all going to take more time to implement.

I think it would be cool to show information which remotes/devices are supported for each keyset inside Pierogi.

Absolutely! (And in fact, if you take a look at the Pierogi keyset code, you'll see that I've actually started to put device data into each keyset, where I have it. I just haven't set up an interface to access it yet...) My problem has always been that I just don't have enough data. The Wiki page with the Compatible Devices List should hopefully make this more useful...

Also... could you get this one in http://lirc.sourceforge.net/remotes/sony/RM-887

Sony is quite nice in that they set up one protocol for all their TVs from way way back when, and they've stuck to it (for the most part) all the way up to today. So almost all Sony TVs should be supported directly from the Sony TV Keyset 1. I've checked, and the RM-887 keys fall into that keyset as well. If it doesn't work for you, please let me know!

Quote & Reply |

The Following 4 Users Say Thank You to Copernicus For This Useful Post:
bocephus, fw190, nkirk, sixwheeledbeast

tecs	2012-02-18 , 01:57
Posts: 34 \| Thanked: 29 times \| Joined on Oct 2011 @ Plovdiv, Bulgaria	#233

Originally Posted by Copernicus

Good question! In fact, a couple months back, I started the project planning to use the same scheme QtIrreco does -- reading individual LIRC config files provided by the user. Even as I started creating my own internal database of keysets, I still intended to keep the ability to import LIRC config files.
....
My problem has always been that I just don't have enough data. The Wiki page with the Compatible Devices List should hopefully make this more useful...

I have no knowledge of Pierogi's inner workings but I think of each keyset being something in the form of a config file (similar to LIRC) with a human readable format in a keysets directory would be a super easy way for each user to import/write/test keysets, after that it is a matter of uploading that config to the public/proposing it to be included in the next release.

Originally Posted by Copernicus

So almost all Sony TVs should be supported directly from the Sony TV Keyset 1. I've checked, and the RM-887 keys fall into that keyset as well. If it doesn't work for you, please let me know!

Unfortunately it does not. Neither it does with any of the other Sony TV keysets. I will give it another try tomorrow just to be sure.

Thanks for the great work

Quote & Reply |

	Copernicus	2012-02-18 , 02:20
	Posts: 1,986 \| Thanked: 7,698 times \| Joined on Dec 2010 @ Dayton, Ohio	#234

Originally Posted by tecs

I have no knowledge of Pierogi's inner workings

Oh, well, let me give you a little intro!

Don't worry, it isn't too painful. Here's a bit of the current sony.cpp file:

Code:

// The "Sony TV Keyset 1" constructor!

SonyTV1::SonyTV1(
  QObject *guiObject,
  unsigned int index)
  : PIRKeysetMetaData(
      "TV Keyset 1",
      Sony_Make,
      index)
{
  addControlledDevice(Sony_Make, "KV-M1420D", TV_Device);
  addControlledDevice(Sony_Make, "KV-20FV10", TV_Device);
  addControlledDevice(Sony_Make, "KV-2184MT", TV_Device);
  // and so forth....

  threadableProtocol = new SIRCProtocol(guiObject, index);

  addSIRC12Key("1", One_Key, 0x01, 0x0);
  addSIRC12Key("2", Two_Key, 0x01, 0x1);
  addSIRC12Key("3", Three_Key, 0x01, 0x2);
  addSIRC12Key("4", Four_Key, 0x01, 0x3);
  addSIRC12Key("5", Five_Key, 0x01, 0x4);
  addSIRC12Key("6", Six_Key, 0x01, 0x5);
  addSIRC12Key("7", Seven_Key, 0x01, 0x6);
  addSIRC12Key("8", Eight_Key, 0x01, 0x7);
  addSIRC12Key("9", Nine_Key, 0x01, 0x8);
  addSIRC12Key("0", Zero_Key, 0x01, 0x9);
  addSIRC12Key("enter", Enter_Key, 0x01, 0x0B);
  // And so forth...

So yes, I'm just dropping the data directly into the constructor for each keyset object. Each object has a set of associated devices, a "threadableProtocol" object that is used to actually interact with the IR hardware, and finally a set of key assignments, each containing three pieces of data: the human-readable string (taken from the LIRC file), a mapping to a Pierogi button, and the actual code to be sent out in infrared. In this case, the Sony 12-bit code is composed of two pieces of data, a 5-bit address and a 7-bit command. (There are also 15-bit and 20-bit Sony codes.)

If you wanted to code this up yourself from an LIRC file, there are two problems -- one, LIRC doesn't know anything about Pierogi buttons, so you'd have to do that mapping yourself (not so hard), and two, LIRC doesn't know anything about Sony codes, so you'd have to convert their pulse counts into Sony format yourself (which might be harder for folks to do, if they're not handy with thinking in hexadecimal.) Originally, I was using the LIRC pulse counts directly, but it is just far easier (and more efficient) to calculate the pulses using the manufacturer's protocol instead.

But yeah, I do agree that there needs to be a better way to do this, other than just writing it all down directly in the code.

Unfortunately it does not. Neither it does with any of the other Sony TV keysets. I will give it another try tomorrow just to be sure.

Well, drat. I'm not sure what to say about that... One thing I should ask: does your TV support "pairing"? I haven't added pairing support for Sony yet, so if you don't have the TV set up on the default pairing setting, this keyset won't work...

Quote & Reply |

The Following User Says Thank You to Copernicus For This Useful Post:
nkirk

	Copernicus	2012-02-18 , 03:34
	Posts: 1,986 \| Thanked: 7,698 times \| Joined on Dec 2010 @ Dayton, Ohio	#235

Hey, another keyset update working its way into extras_devel. This time, we have new keysets for Huawei, Onida, Vestel, Virgin Media, and Vizio. Also added a Sharp air conditioner keyset.

On that Pioneer Amp: I've got a file that purports to be the keys associated with the VSXD510, but they come out being the keys already associated with Pioneer Audio Keyset 3. I don't know why that keyset isn't working. It may be that my protocol code is just messed up somewhere. I'll have to keep digging on that one...

Quote & Reply |

The Following 2 Users Say Thank You to Copernicus For This Useful Post:
kent_autistic, king Ralphred

kalilucho	2012-02-18 , 07:36
Posts: 5 \| Thanked: 1 time \| Joined on Sep 2010 @ Sofia	#236

thank you, I am very pleased with the application

Quote & Reply |

The Following User Says Thank You to kalilucho For This Useful Post:
Minhaz

tecs	2012-02-18 , 11:11
Posts: 34 \| Thanked: 29 times \| Joined on Oct 2011 @ Plovdiv, Bulgaria	#237

I think initializing every keyset as an object (that initializes several more in itself) might be the source of the memory hogging. If you place the keysets in separate files and let the app collect the filename list on startup, initializing only one generic keyset object and replacing it's routines and commands each time you choose another one, you are going to get rid of the memory problem and migrate to a config file architecture. Heck, if you load all the files in the memory as a binary data and initialize only one at a time, you are going to save more memory

About pairing, I have no idea what that is... It is an old CRT TV that I doubt is smarter than - receive IR commands, execute them...

Quote & Reply |

	Copernicus	2012-02-18 , 11:44
	Posts: 1,986 \| Thanked: 7,698 times \| Joined on Dec 2010 @ Dayton, Ohio	#238

Originally Posted by tecs

I think initializing every keyset as an object (that initializes several more in itself) might be the source of the memory hogging.

Yes, you are absolutely right!

That is exactly what is causing the memory issues.

If you place the keysets in separate files and let the app collect the filename list on startup, initializing only one generic keyset object and replacing it's routines and commands each time you choose another one, you are going to get rid of the memory problem and migrate to a config file architecture.

Well, I was hoping to avoid putting so many files into the N900's file system. I thought it would be a pain to manage. But, as you say:

Heck, if you load all the files in the memory as a binary data and initialize only one at a time, you are going to save more memory

That is my current plan. I'm going to take all the keyset data out of the constructors and either (a) create a "factory class" that constructs keysets dynamically as required, or (b) set up a database to read in keyset info as needed. I had looked into sqlite when I started all this, but it seemed like overkill for my needs then; but it might make accessing the keyset data easier for users.

In any case, yes, that should ease the memory problems significantly.

About pairing, I have no idea what that is... It is an old CRT TV that I doubt is smarter than - receive IR commands, execute them...

Ah, I wouldn't put anything past Sony. They can create some amazing products. But yeah, I just looked up the RM-887 in Google, and it doesn't appear to support pairing... I'm not sure what is going wrong.