Well, I found a steering wheel remote that can be made to work with the empeg. It is the Pioneer CXB3488. The empeg sees the codes that it emits and using fvgestel's ir_trans stuff it works great with the empeg. Here are the key mappings that I used in the empeg_ircodes file.



0x0000AD0A:0x0000B914

0x0000AD0B:0x0000B915

0x0000AD43:0x0000B90B

0x0000AD42:0x0000B90A

0x0000AD12:0x0000B95E

0x0000AD1A:0x0000B91F




This enables the sound up and down buttons, the forward and backward buttons, and the info change (forget what button that is on the empeg remote) and DNPP buttons as Band and SRC on the Pioneer. There are several other buttons on this remote, but I have not decided what I want them to do yet.



Here are a couple of pics of the remote









The only problem that I have so far is that the key repeat rate is a little fast. Frank V, would it be possible to slow down the key repeat rate with your ir stuff? I will have this at the empeg meet next weekend if anyone wants to play with it.



-Mike

Forgot to mention that this only changes the ir codes that the empeg sees for the Pioneer remote so the regular empeg remotes still works as normal.

-Mike

Holy crap, i want one! I hope i'm not asking something that's been answered before...but would the CDRS77 model work as well? Or have you only found this one to work..

I ask 'cause after a quick web search i found only this site with the CXB3488 model, but the other one seems very available. I'm gonna order that puppy this week. Thanks!!!!


|| loren.cox || 080000446 ||

That site looks rather shady... I think the 77 is the update model, hence it may be hard or impossible to find any of these older ones around. I'd like to know if anyone can confirm or deny the CDRS77 working, I think I remember Frank, the guy who wrote the IR thing, saying it didn't generate the right frequency or the right codes or something.

I would SO love a steering wheel remote but I'm not going to order until I find one that works.

-Tony
MkII #554

Sorry I don't know about the 77 model because I don't have one. The empeg only listens on a certain frequency range so the remote needs to send in that range. I would expect that all of the Pioneers would use the same range, but I don't really know. The remote that I have came with a pioneer head unit that I bought about one year ago so it seems like they ought to still be somewhat available. BTW, the ir_tran kernel up on Frank's site is for v1.01 and I am not sure if it is for a mark1 or mark2 so I compiled my own 1.02 image. You can grap a copy for mark1(untested) or mark2 from me if you need it.



-Mike

I'm using the Kenwood KCA-600 steering remote. This is a pretty recent one, and works fine for basic control.

One of the few remaining Mk1 owners... #00015

I think I remember Frank, the guy who wrote the IR thing, saying it didn't generate the right frequency or the right codes or something.

Based on some probability-calculations, I did indeed think that changes were low. I tried about 50 different IR-devices with a 100-in-one remote, and only 3 of them were showing IR-codes through /dev/ir. I know the 1.02 also accepts the new rio-remote, which uses another code-set; maybe there were also some other sets implemented?

Frank van Gestel

Frank V, would it be possible to slow down the key repeat rate with your ir stuff?

I guess it would be possible, dunno how it will impact performance/responsiveness of the empeg. I am rather busy lately, but I will experiment some; don't expect anything before april though...

Frank van Gestel

No problem. Just curious if you had any thoughts. I tried playing with IR_RPTDELAY_DEFAULT and IR_RPTINT_DEFAULT in empeg_ir.c but they did not seem to have any effect. The problem is that this pioneer remote tends to send the code two or three times unless you are really quick about releasing the button. I was hoping that these two constants had something to do with catching and dropping repeats, but my C isn't good enough to really figure out what is going on (I will have to look through the code again and see if I can figure out what is actually happening). If anyone has any suggestions please let me know.

Thanks, -Mike

The CDRS77 does indeed work.... Althought I think it has the same problem you are encountering. The repeat coming off of the remote appears to be about 1.4-1.5 time that of the kenwood. As a result, unless you are REALLY light on the keys, it's pretty easy to get a couple of hits registered, instead of one.

Felt like I was playing piano with a pair of mittens on. Sure you are going to get the key you wanted, but chances are, you'll also hit a few you didn't.

It would probably be fine if you could ignore every other IR input.

I didn't buy it, based on this. But I have to say, the salepeople were damn impressed by the unit sitting on the desk scrolling through 1000+ songs.

It works, true, but it's far from ideal. It's got a limited selection range, and mounting (for me at least) is very much un-satisfactory.

I'm trying to find someone with the Blaupunkt thummers in stock. If I can find a local dealer, I'll bring the EMPEG in with my laptop and find out if it can work with the remote or not.

So wait, synergy, you've confirmed that the CDRS77 DOES emit codes that the Empeg can "hear," and should therefore work with Frank's IR mapping patch? If that's the case then I'm gonna snatch one of those puppies up as soon as possible. Saw it for $35 at one of the online stores, can't beat that.

-Tony
MkII #554

Yes, In fact, it works with the codes that were posted earlier by mcomb. I loaded my empeg up with the IR-trans kernel and codes posted. Then went searching for pioneer dealers in the area.

The remote does "work", but I really sugggest that you try it before you buy it, as it's increased freq. really doesn't make controlling easy. I knew within a few minutes of playing with it that it would end up pissing me off, so I didn't buy it.

But to answer your question. Yes, it does emit freq. that the EMPEG can see and respond to. And yes, it DOES work with the IR-trans kernel. But after having played with it, I can't see it as a good replacement, due to the fact that you end up jumping 1-3 (random) steps with every button press. That might be able to be coded out, but it doesn't appear like that will happen soon.

Hm. I think I could code a fix, though I haven't set up a toolchain yet. I think it'd be relatively simple to discard every Nth remote press to compensate for the fast repeat... This would be a great excuse for me to get into Empeg kernel programming. I'm gonna order the remote and see if it bothers me enough, if it does, I'll commence hacking.

-Tony
MkII #554

Well I received my Pioneer CD-SR77 steering wheel remote. Repeat is a bit fast but it's tolerable until I can hack my kernel up a bit to ignore some of the repeats. Seems to be working well. The codes are probably the same as for the model mcomb has, but I'll attach a pic I made so I can remember the hex codes for the buttons.

Once I get a toolchain set up I'll work in a way to slow down repeat rate and share it with everybody. I do recommend this remote, very handy.

The only thing that would make it more useful is for the player software to have arcade game "enter your initials" style entry for some of the alphanumeric fields (like FF/REW or Vol up/down buttons cycle through each letter, track forward/backward buttons move the cursor left/right, etc.) Then you could actually do searches for artists/albums with the Direct/OK button menu. But it might be a little crazy typing them in one character at a time... Hmm...


-Tony
MkII #554

THANK YOU GUYS SO MUCH, THIS MAKES ME VERY HAPPY!!!!

even an idiot like me can get it working, tha tis great.

It is a little fast, but i have faith you guys will slow it down, at least we know lag won't be a problem!!

one thing, i notice there are some buttons left unused, i jsut used the codes posted on teh front page. I don't really understand the codes, can anyone explain how exactly to figure out which button goes to which feature, i am sorta lost on this.

THANKS GUYS!

I attached a JPG that shows the hex codes that are sent by the CD-SR77.
Here it is.

That image tells you the hex codes SENT. To figure out what you want to map them to, use the following, which I stole from some code on the Empeg developer site. These codes correspond to the codes sent by the Kenwood credit card remote.

0               0x0000B900

1               0x0000B901

2               0x0000B902

3               0x0000B903

4               0x0000B904

5               0x0000B905

6               0x0000B906

7               0x0000B907

8               0x0000B908

9               0x0000B909

Track (-)       0x0000B90A

Track (+)       0x0000B90B

AM              0x0000B90C

FM              0x0000B90D

Prog (play)     0x0000B90E

Direct/OK       0x0000B90F

Vol Up          0x0000B914

Vol Dn          0x0000B915

Asterisk        0x0000B91B

Tuner           0x0000B91C

Tape            0x0000B91D

CD              0x0000B91E

CD/MD/CH        0x0000B91F

DNPP            0x0000B95E

So, like, if you wanted to map the "Func" button on the CD-SR77 to cycle Info modes like the CD/MD/CH button on the Kenwood remote, you add the following line to your mapping file:

0x0000AD19:0x0000B91F

Hope this helps.

-Tony
MkII #554

Well tonight I went from not having Linux on my system at all to compiling my first kernel in about 4 hours. Not too shabby. Had to get a good .config file from this BBS and figure out a few things about the toolchain, but now it's a breeze.

My first attempt at slowing down the repeat rate was to to the same changes to the #defines just to see if the repeat settings worked, and they don't seem to. I even tried increasing the timings buffer in empeg_ir.h (which probably doesn't even have anything to do with the repeat count) just for fun.

I guess the next strategy would be to put something in the ir_read() function to discard every Nth code received. Until I become more familiar with the code and the various custom typedefs and structures, I probably won't be getting anywhere. The thing I'm concerned with is the code and ocmments make it look like there's already "filter repeat" logic in there, and a "discard" strategy might cause timing issues with whatever repeat logic is in there.

Well, time to get VMWare running so I can do this crap from Windoze. I'll do some more hacking in the next few days and report my results. Looking at this code has given me a new respect for the Empeg programmers, though I *am* a little confused as to why the #defines don't do what they say they do!

-Tony
MkII #554

though I *am* a little confused as to why the #defines don't do what they say they do!

Well, if true, it wouldn't be the first time that's happened in a piece of code. But I think there's probably something else going on that's got nothing to do with the defines. It's probably related to the pioneer remote sending out the IR signals in a completely different fashion than the empeg remote.

I know that sort of thing can be tricky, but I don't know enough about IR to offer specific suggestions.

___________
Tony Fabris

I guess the next strategy would be to put something in the ir_read() function to discard every Nth code received.

My idea was to use add_timer in the case a code is received that should be translated. When the second code arrives, the timer is checked for expiration. This would allow a second parameter in the config file to set the delay time. So a config file would look like :

# original code:new code:delay time in ms

0x0000AD0A:0x0000B914:100

0x0000AD0B:0x0000B915:100

0x0000AD43:0x0000B90B:100

0x0000AD42:0x0000B90A:100

0x0000AD12:0x0000B95E:100

0x0000AD1A:0x0000B91F:500

this way you could add multiple timers and different delays for different codes... Dunno how many timers are allowed though.

Frank van Gestel

Help!

Seeing the recent posts on installing the IR kernel for the Pioneer streeing wheel remote, I see that it may be fairly involved to carry out the procedure. I am majorly Linux-challenged, is there anyone one willing to do the hack from start to finish and put it all into one post with a step-by-step instruction? I would really love to use my remote but I'm not ready to risk screwing with my new player just yet due to my ineptness with Linux coding....Thanks - John

Technoweenie
12 GB Blue / Red MK2

I haven't got the 1.02 source at the moment, maybe someone else has compiled the ir-trans hack in a 1.02 kernel? Anyway, I'm still planning on doing the delays for the remote when I have time. There were some general instructions for installing the kernel and init-script posted somewhere in this thread

Frank van Gestel

I've compiled a 1.02 kernel with the IR patch, but my Linux machine isn't running right now, so I can't FTP it over. I will post it tonight unless someone beats me to it.


-Tony
MkII #554

I've posted two IR Kernels on http://wedding.d0gz.net/empeg/

One has the voladj hack on it, the other doesn't. Both include the IR trans. Both are MK2 only.

Note: I didn't compile either of these, just found them browsing about the BBS. If anyone is needing, I can host files like this without a problem.

Thanks guys, this gives me more confidence to give it a go, Maybe there will be a chance for the techies at Empeg putting the IR kernel codes for the Pioneer remote into a later software version due to it's popularity as an alternative to the Kenwood/Rio? (maybe/hopefully)



Technoweenie
12 GB Blue / Red MK2

I've got a kernel which should slow down the repeat rate to 500ms. Only the custom codes get delayed, so your kenwood-remote should still work properly. I haven't got a pioneer remote, so could anyone verify this? the kernel is a standard 1.02 image with only my ir-patch.
zip-file irtrans1.0.2.zip can be found at http://empeg.dyndns.org/empeg/ir_trans_kernel

Frank van Gestel

Frank,

You've done it again! And darn it, you beat me to it!

It's working well. Just flashed and it performs as advertised, delays the custom codes and avoids the annoying fast repeats. My automobile thanks you, because the concentration I was using on clicking exactly once on the remote is concentration I can now devote to driving!

So... Can I get an updated patch so I can apply it to my own source tree? I have the settings and 1disk patches on there and would love this as well. Thanks again.

-Tony
MkII #554

Is the delay sufficient or should I raise/lower it?
I'm thinking of hard-coding the pioneer-codes and delays in the kernel-image, so no further modifications other than applying a new kernel would be necessary. I guess this would please a lot of people. Custom codes and delays would still be available through catting the config file to /dev/ir though.
Is everybody happy with the ir-codes that mike posted in the original post and should I make this set the default?
BTW, I'm also getting one of these steering wheel remotes; the kenwood-remote is fine, but not very usefull in the car due to my inability to drive and find the right buttons without looking at it...
I'll try to get the new kernel-image and patch ready for download this evening

Frank van Gestel

The delay seems okay, maybe a little shorter would be nice, but I'd have to tweak around with it to find the "sweet spot." I'm using a totally different code layout than mcomb listed, but I don't have a problem catting a custom file (or even hard coding my own in the kernel.)

The next "whiz bang" feature might be to allow one of the buttons to be a "modifier" button, like maybe the "ATT" button would allow the next keypress to be interpreted as a different command. So you'd get an extra 10 or so functions out of it. That might be something I try to work on, unless you make it there first!

And to think, some people just want to listen to music on these things. :)

-Tony

-Tony
MkII #554

Thanks Guys, this is great! I appreciate all of the effort to make this work for us non-Linux guys...One thing about the "ATT" button though, on my Pioneer head unit, the att (attenuation) button is very useful for an instant lowering of the volume ie while in a drive-through or customs booth (like Detroit/Windsor tunnel). I would suggest that it be left as is for that reason in case you didn't know what it was for.....

Technoweenie
12 GB Blue / Red MK2