Failed IR remote

[stu-e]

I am experiencing some strange behaviour with the IR remote control for my MediaMVP. It is the 'old' style remote.
Just recently the remote has stopped working with Vomp.
However the remote control still works ok when using the MVP with the Hauppauge server software it came with that runs on Windows.
It used to work just fine with Vomp 2.2 and I also used it with a 'homebrew' serial LIRC receiver for remote control of Linux apps, but that stopped working to at the same time.
The LED on the front of the unit flashes to indicate it is receiving something, but there is no response on the TV menu.
If I could hazard a guess it's as if the remote has changed the code it transmits but is still recognisable by the Hauppauge software.
I have replaced the batteries with new ones.
Can anyone suggest what is going on here?
Time to get a replacement remote?

[Chris]

I don't believe there have been any changes to the remote control code in the client for a long time. I think you may be heading towards a new remote - no guarantees though!

[stu-e]

Definitely a hardware problem my end.
The point I am making is that considering the remote still works with the original MedaMVP software, perhaps the IR remote decoding mark-space timing in Vomp is too tight and will not work with remotes with timing that has somehow drifted slightly.

I have not succeeded in finding a replacement remote control so I was wondering how easy would it be to edit and recompile the client software for my self to get my dodgey remote going again?

[MarkC]

Definitely a hardware problem my end.
The point I am making is that considering the remote still works with the original MedaMVP software, perhaps the IR remote decoding mark-space timing in Vomp is too tight and will not work with remotes with timing that has somehow drifted slightly.

I have not succeeded in finding a replacement remote control so I was wondering how easy would it be to edit and recompile the client software for my self to get my dodgey remote going again?

All the VOMP code does is read from /dev/rawir: all the low-level stuff is handled by one of the kernel modules, which are simply extracted from the Hauppauge dongle for inclusion in VOMP. Perhaps your Hauppauge dongle is a different version to the one we're using for the VOMP release dongles. I believe they've been updated several times over the last couple of years.

I'm not sure which Hauppauge dongle the current VOMP dongle takes its modules from; Chris will be able to tell us. If yours is different then it might be worth trying to build a VOMP dongle using the modules from your Hauppauge dongle. I'm sure there's a short cut to doing that without building an entire development tree, but I don't have time right now to look into exactly how you'd do it. Perhaps someone else has

[Edit: having said all this, I'd be surprised if much of the timing were actually handled in the kernel module, rather than in hardware, but I can't think of another explanation]

[Chris]

The modules are taken from version 23104 of the Hauppauge dongle. This hasn't changed for a long time, so I don't know how a remote could stop working with vomp but carry on working with other MVP software...

[Sir George]

Hi folks,

I seem to have a similar problem. Yesterday, the remote (old style) of my MVP (Rev. D3A) still worked, the other day no more... I used the device about two years up to now and never had similar problems. Currently I'm using vomp-dongle-0.2.7-6.1-Yaris, but the problems persists even with vomp-dongle-0.2.7.
I tried a few things, amongst checking the remote with lirc on a homebrew receiver (irrecord recognizes it as  RC5|CONST_LENGTH, can anybody confirm? And yes, it works there flawlessly). I did this since the LED on the MVP still flashes when pressing a key (also with other RC5 remotes, BTW), but no reaction whatsoever.
I tried some investigation on /dev/rawir... should I get something from that character device when pressing a remote key (by cat'ing to stdout?).
And yes, batteries were the first I checked.
BTW, connection to the vdr is fine, I can supply logs if you want.

I'm at my wits end... has anybody any advice, besides throwing away that amazing device?

[Chris]

What happens on the client log when you press a key? If you have a dev environment you could add more print statements in remote.cc to see if vomp is getting anything at all from the remote device. It's astounding that it should just stop working.

I think if the LED flashes on the MVP it means the signal has been recognised as an RC5 code.

[Sir George]

Hi Chris!
Thank you very much for your immediate response. I finally managed setting up a dev environment again, thanks to your perfectly working script.

I put in some logging in remotemvp.cc in methods RemoteMVP::getButtonPress and RemoteMVP::init. The device gets opened nicely (devName=/dev/rawir, device=3), however the only message I get regarding the remote is the worker thread calling getButtonPress with waitType=2 and select(device + 1, &readfds, NULL, NULL, &tv) resulting in NA_NONE.
Again, no reaction to keypresses on the remote, not even a single message in the log.

I also tried several versions: the current cvs (with my debugging), the latest yaris-patch and the stable 0.2.7 release, but no luck. I even tried several other RC5 remotes, in case the MVP's one got crazy...
My last struggle was to try and get the device working with Hauppauges original (crappy) software... no luck. Well, in fact I can't even remember I have ever gotten it working this way. May be because of the bad state of that old W2K installation...

Furthermore, I didn't find any code that toggles the LED on reception of IR signals, so this seems to be hardwired.


Edit:
I attached the lirc-config of my (maybe faulty) remote. However, according to http://lirc.sourceforge.net/remotes/hauppauge/lircd.conf.hauppauge my recorded codes seem to be ok, at least compared to some codes of the "Hauppauge" remote (the first section in the link).
Funny enough, I have that remote here (the black one included with the Nexus-S); however I can't remember if it worked with the mediamvp (at least partly). So I have no real confirmation if the codes of my current "broken" remote are OK.
Another one had the same problem according to that http://www.shspvr.com/smf/index.php?topic=10679.0, and it obviously was the remote.

Another thing I found out is that the hex-values in the lirc-config correspond to the IR-codes of the mvp... so maybe it's a problem of the mvp itself nevertheless.
BTW, the mvp in fact works flawlessly - if controlled over the UDP interface...

[Sir George]

Something very strange is happening here... But from the beginning:
Yesterday I got a "new" MVP... well, unluckily it's a D3... but that's another story.

The first thing I tried was to use the remote from the new MVP (which is the "old" style) with my faulty MVP (see my last posts).
Funny enough, it seemed to work partly (at least channel up/down, ok and the numbers) and only from a very short distance. I thought "hey, so it was the damn remote"... hmm, let's first go on.
The next thing I tried was to record the new unit's remote with irrecord... strange things happened here: it was discovered as RC-6, but detection ended in error when it didn't recognize a toggle bit. (Which is what still happens, BTW) Update: it's still recognized as RC-6, but with unknown encoding (so it records in raw mode)

Now comes the real surprise: out of fun, I tried my old remote. And it worked!? And still does...
Accidently I found out that my old remote that is working now is recognized by completely different codes by lirc (namely the "modern remote bundled with haupauges Nexus DVB-Card").

What the heck happened here? Can anybody save me from insanity? I really don't understand things anymore... 

[stu-e]

This is indeed strange!

When my old style remote went wrong, Lirc irrecord reported completely different remote codes compared to when the remote was originally working.
When the remote magically 'fixed' itself, irrecord reported the original codes again!

Since the remote first failed I bought a new style remote and I have been using that ever since. I only noticed the old remote started working again after I started using it with vdr and lirc.

Stuart

[Sir George]

Hi Stuart,
some parallels here, as my now again working remote also changed codes.
But the most esoteric thing is that the "new" remote obviously stopped working after reviving my old one... somewhat frightening...

[MartenR]

Maybe a jumper or wire  on the remote control pcb has a   loose connection and this one switch the remote codes, but this is only a guess, since I do not know the layout of the remote.

Marten

[Sir George]

Hi Marten,
I opened my old style remote (the one which stopped working after reviving the old one) and photographed back and front of the board. Perhaps you or someone else is interested 

[MartenR]

Unfortunely, there seems to be no jumper for switching the codes ( the only suspects are the resistors, but I think they are for the transistor). So my guess was wrong, but I will lock up the IC, may be then I know more.
Edit: The ic seems to be a special one unfortunetely I did not find a datasheet.
Marten

[Sir George]

Thanks for your efforts, Marten.
I couldn't find that MAGIC chip either... But what about the component X1 on the back? What's that, anyway? A quartz? I have no idea, i have to admit. But it obviously directly connects to the MAGIC, so I thought about an external clock source or something like that. If this changed it's frequency? But that's only some very rough guessing of someone not so firm in electronics...

Edit: xmode2 output of the two remotes attached, maybe that shades some light on the case 

Edit2 (yeah, I have nothing to do ): A photograph of my other remote - the one that works again and obviously changed codes. There are some different parts on the board, but the layout seems the same.