Just a minor thing. As a few of us have found that the pioneer stearing wheel remotes do in fact emit codes that the empeg picks up would it be possible to unnoficially add them to the empeg software? This way we wouldn't have to use a custom kernel to translate the codes. It seems like this would be really simple to do and I am sure one of us with the pioneer remotes could post the codes here to minimize the time required by the empeg guys (I would do it, but I have the older remote and I am not sure if the codes are all the same).

-Mike

I agree, it would be very nice to have that functionality.

And btw, your codes did work with the newer version of the remote.

But regardless, with the intercept program and IR_trans, it's obviously possible for the empeg to do this, it just needs to be coded. It would be nice if there was a way to do it without hijacking the serial port with a terminal program, and linux knowledge, but it's still workable now.

My memory is really fuzzy on the subject. But when this sort of thing was first brought up (using IRtrans to capture steering wheel remote codes), didn't Hugo or Mike chime in and say that, if it worked, they'd look into the possibility of adding them officially?

It could be just wishful thinking.

___________
Tony Fabris

I allready tried this, modifying intercept.c, but it only resulted in a terrible lag resulting from the fact that the intercept process can't get enough cpu-priority to run constantly...

Frank van Gestel

It's possible I'm reading this wrong, but I was speaking from the standpoint of having the empeg read the codes and either have it display them for reprogramming on the display, or giving you the option to reprogram the unit itself.

I was NOT thinking of fixing the frequency issue. Personally I feel that falls under 'broken' hardware, even if that isn't an accurate description.

My thoughts fall under a program that would , when enabled, allow the user to point a new remote at the empeg, press a button, and then map a function (either from the display or by pressing the old remote button) to that button.

This I feel could be done on the existing software (or 1.1.1... whatever) without major coding problems. It would have the benefit of allowing the empeg to work with any remote it could see, without having to be a developer (or hacking about in the kernel). Easy enough that the average user (not that there are many here, I assume) could handle it without handholding.

Just seems to be a win/win solution for EMPEG, after all the current 1.1 issues are taken care of.

It also would make it easier to find existing remotes that work with the EMPEG, as you could have immediate notification just by pointing the thing and shooting. It's possible now, using your wonderful intercept program, just impractical in a commercial environment (not that it stopped me from hauling my laptop and empeg into a couple of car audio shops).

Damn. Am I making any sense here?

It's possible I'm reading this wrong, but I was speaking from the standpoint of having the empeg read the codes and either have it display them for reprogramming on the display, or giving you the option to reprogram the unit itself.

I see what you mean, but I doubt the empeg/rio people will implement this kind of feature; They would be overwhelmed by bug-reports from people trying to get their remotes to work, a functionality they cannot support. I'm afraid everything involving non-empeg hardware is third-party material. Another option would be the software-plugin for the empeg software, which was supposed to be one of the future features of the empeg software announced some time ago.


I was NOT thinking of fixing the frequency issue. Personally I feel that falls under 'broken' hardware, even if that isn't an accurate description.

The empeg can read all ir-frequencies ( I suppose ). the ir-device can be set up in raw mode, where it returns all raw ir-data. Every remote I tried gave some kind of output. They filter out specific codes for the kenwood/rio remote ( and apparently also pioneer ) and they are returned through /dev/ir with the right repeat-rate, etc...

Frank van Gestel

I see what you mean, but I doubt the empeg/rio people will implement this kind of feature; They would be overwhelmed by bug-reports from people trying to get their remotes to work, a functionality they cannot support. I'm afraid everything involving non-empeg hardware is third-party material. Another option would be the software-plugin for the empeg software, which was supposed to be one of the future features of the empeg software announced some time ago.



yeah, I can see that too... perhaps I am just hoping for a software plugin type functionality you refer to. I think actually that might work better anyways. We could then have a web page with a remote section of known working remotes and the codes required to program them. But then again, we can do that now. The install process just needs to be cleaned up so non-programmers/non-linux people can select a remote, send a file, and everything work. Hmmmm....

I'm curious to the ratio of people running the developer image/consumer image. Considering how much can be modified with it, surely Empeg isn't going to support, or at least not at the same level, the developer image. At the same time, if a plugin scheme does come to fruition, is it going to be devel image only, or would there be a emplode function to download code modules to the consumer images?



The empeg can read all ir-frequencies ( I suppose ). the ir-device can be set up in raw mode, where it returns all raw ir-data. Every remote I tried gave some kind of output. They filter out specific codes for the kenwood/rio remote ( and apparently also pioneer ) and they are returned through /dev/ir with the right repeat-rate, etc...



I'm assuming (big mistake probably) that your intercept program does NOT put the unit into raw mode then, as I also tried a number of (household) remotes which returned nothing.