Cheap full function remote - source

[offroad]

Well am shopping for the ultimate cheap full function remote.

Currently have an HP RC6 MCE remote, that included the IR receiver (USB connection), and an IR BLASTER to control my COMCAST cablebox. Works fine. Cost about $25 four years ago.

All works fine for now, though getting the blaster to work was a PITA because of driver issues with WMC not recognizing the blaster was connected (you have to put earphones in the blaster 1/4 inch stereo jacks to force WMC to recognize the blaster is connected - a weird fix but works).

Just ordered a new MCE certified remote that is a learning remote also ($30). No blaster so will need to keep my old hardware USB blaster. That in combination with the INTELLIREMOTE software for $25 should get a very adaptable solution for my HTPC.

Anyone else see something cheap and better? Harmony remote is still in the $100 price range. Yes I know I can use my IPHONE as a remote, but that is very inconvenient to work with, and rather have a dedicated remote.

Summary:

1) learning remote
2) MCE certified or equivalent
3) Blaster included with USB IR reciever
4) USB connection with driver that works with WMC

[tzr916]

I couldn't find any MCE w/usb receiver that were learning capable. So I had to buy two remotes...
Got a Philips 7 in 1 Universal Remote model SRP6207/27. It's very simple learning/programming and is less than $15 on ebay/amazon.
Got this MCE remote because you can move mouse/click with it (and it's $15)-
http://www.amazon.com/gp/product/B00224 ... UTF8&psc=1

[soccerdad]

There are a variety of Harmony remotes on ebay for $40. I have a 688 and it works great for my HTPC, AV system, etc. Two remotes would be a pain.

[soccerdad]

There are a variety of Harmony remotes on ebay for $40. I have a 688 and it works great for my HTPC, AV system, etc. Two remotes would be a pain.

[mdavej]

Can't beat JP1 remotes IMO. Many are $3-$8 and more programmable than harmony, and far more capable than other cheap remotes. You probably already own one and don't even realize it, especially if you have cable tv.

[adam1991]

Can't beat JP1 remotes IMO. Many are $3-$8 and more programmable than harmony, and far more capable than other cheap remotes. You probably already own one and don't even realize it, especially if you have cable tv.

Well, Unix-based command line operating systems are free and can run on $50 hardware. Why do we have more expensive computers again?

[mdavej]

Can't beat JP1 remotes IMO. Many are $3-$8 and more programmable than harmony, and far more capable than other cheap remotes. You probably already own one and don't even realize it, especially if you have cable tv.

Well, Unix-based command line operating systems are free and can run on $50 hardware. Why do we have more expensive computers again?

At least one user HERE seems to like his horrible JP1 remote just fine. The beauty of JP1 remotes is you don't have to use the software if you don't want to. They program exactly like the cheap MCE remotes mentioned so far if you don't use the software and are far more capable. But the kicker is the OP said "cheap", which doesn't exist in the harmony world. $30 is the minimum price of admission, and that particular model (200 or 300) sucks, managing only a couple of devices and only one macro.

[adam1991]

well, if a JP1 remote doesn't have the necessary codes on board, then it's useless. Hence the whole concept of JP1, which is to make such a remote useful--which for most people is like building your own airline reservation system using the built-in tools in Linux.

For 7MC DVR use, the Harmony 200 and 300 do a wonderful job.

[offroad]

For 7MC and everything else under the sun would now highly recommend the RCA RCRP05BR remote that can be bought at Walmart for $15. It is a JP1 remote, plus it is a learning remote, and it has a code (code 1972 on DVR mode) for 7MC (aka WMC or MCE). And it works. The only button not in the 7MC control on this remote, is the green button, which has to be mapped-programmed separately (not a big deal takes 60 seconds to do that).

Can not recommend this remote enough. I already had an HP RC6 remote that had a USB IR sensor and blaster with it, that was working. But now I have a remote that does everything for one tenth the cost of a harmony. And it has AA batteries to give it weight, and last a long time. It can control my HTPC with 7MC and XBMC, and my HDTV (Samsung Plasma), and my ROKU 3, and my DVD (panasonic - no regions playback), and my Apple TV 1 (using OpenELEC).

Next step is an attempt to get a mouse working via the remote. Ordered a mouse remote via USB IR, that has UP-DOWN etc buttons on the IR remote. If I map-program the RCRP08BR to the mouse remote, I have one remote to rule them all!!!!

[mdavej]

well, if a JP1 remote doesn't have the necessary codes on board, then it's useless. Hence the whole concept of JP1, which is to make such a remote useful--which for most people is like building your own airline reservation system using the built-in tools in Linux.

For 7MC DVR use, the Harmony 200 and 300 do a wonderful job.

I understand your point. But I disagree with your premise. The concept of JP1 is not to make a useless remote useful, but to make a very useful remote even more useful and to make it very simple to program. If you don't want to mess with codes or JP1 programming, learning still works fine. The problem I have with cheap harmonys is that they can only do one macro. That really stinks IMO. Even without JP1 tools, the RCA can easily do dozens of macros and control more devices, all for less money.

As far as being useless without on-board codes, this isn't accurate. All you need is a working protocol, which is usually on board, then you can get ANY function programmed into it with codes. If you use JP1 tools, you can load any device and any commands, even ones a harmony finds unlearnable. You can also import pronto hex, which is generally quite difficult on harmony, and expensive on a 200/300 if you warranty has run out.

JP1 software is quite easy to use these days. We've come a long way since the days of using excel spreadsheets and tons of codes. Today, it's mostly drag and drop and picking things from drop down lists, very similar to harmony. Nothing like your Linux analogy.

[CyberSimian]

As far as being useless without on-board codes, this isn't accurate. All you need is a working protocol, which is usually on board, then you can get ANY function programmed into it with codes. If you use JP1 tools, you can load any device and any commands, even ones a harmony finds unlearnable. You can also import pronto hex, which is generally quite difficult on harmony, and expensive on a 200/300 if you warranty has run out.

Can you do device-state tracking with the JP1 remotes? My Toshiba TV has only a power toggle (not separate power on and power off), so without state tracking, macros to control multiple devices are of limited use. Example: I have to use separate buttons to power on/off each device, not one button for each activity.

I know that One-for-All claim support for activities on several of their remotes, but they are not true activities in the Harmony sense, because the default setups do not do state tracking. This sounds as though I am bashing One-for-All (well, perhaps I am for their misleading publicity), but actually I have both an Xsight Lite and an Xsight Colour (neither of which I have yet spent any time programming), and I would really like to know whether I can get device-state tracking by using the enthusiast software instead of the One-for-All software. Thanks!

-- from CyberSimian in the UK

[mdavej]

As far as being useless without on-board codes, this isn't accurate. All you need is a working protocol, which is usually on board, then you can get ANY function programmed into it with codes. If you use JP1 tools, you can load any device and any commands, even ones a harmony finds unlearnable. You can also import pronto hex, which is generally quite difficult on harmony, and expensive on a 200/300 if you warranty has run out.

Can you do device-state tracking with the JP1 remotes? My Toshiba TV has only a power toggle (not separate power on and power off), so without state tracking, macros to control multiple devices are of limited use. Example: I have to use separate buttons to power on/off each device, not one button for each activity.

I know that One-for-All claim support for activities on several of their remotes, but they are not true activities in the Harmony sense, because the default setups do not do state tracking. This sounds as though I am bashing One-for-All (well, perhaps I am for their misleading publicity), but actually I have both an Xsight Lite and an Xsight Colour (neither of which I have yet spent any time programming), and I would really like to know whether I can get device-state tracking by using the enthusiast software instead of the One-for-All software. Thanks!

-- from CyberSimian in the UK

So far in this thread we've been talking mainly about using JP1 remotes WITHOUT JP1 software. Without JP1 software, they can't do state tracking. But WITH JP1 software they can certainly do state tracking plus tons of other things Logitech only dreams about. Specifically, you load our extender, which is a custom OS of sorts. Then you get state tracking for 8 devices via Toadtog bits, device multiplexing (meaning unlimited devices), 5 functions per button (short press, long press, double press, shifted, double shifted), nested macros (which essentially gets you unlimited steps), recursion (macros that call themselves), multi-macros, device specific macros, the list goes on. Those Toadtog bits can also be used for memory and conditional branching.

The Xsight remotes (Colour, Touch and Plus) now work quite well with our JP1 Remote Master software, but still lack state tracking. It's worth checking out.

But keep in mind, one thing you loose going to a cheap JP1 remote (not Xsight) is the LCD. So it's great for basic control and macros, but requires a cheat sheet or a really good memory if you try to put every function for every device you own on it.

I personally use an Xsight Touch on my main system and cheaper JP1 remotes everywhere else. I've used Toadtogs for state tracking very successfully in the past but all my devices have discrete commands at the moment, so Xsight is fine.

The way Toadtog bits work is you can set, clear or test a bit and take some action based on the test. So to turn on a device that only has a power toggle, just check to see if you tracking bit is set. If it is, do nothing, else send a power toggle and set it. To turn off the device, check to see if the bit is clear. If it is, do nothing, else send a power toggle and clear it. This is essentially what harmony is doing for you behind the scenes. If the state tracking ever gets out of sync, a power toggle will set it right. This is equivalent to harmony help.

I realize this supports Adam's point about JP1 complexity. But I still maintain that one who doesn't need this advanced functionality can program a JP1 remote quite simply.

[CyberSimian]

Then you get state tracking for 8 devices via Toadtog bits, device multiplexing (meaning unlimited devices), 5 functions per button (short press, long press, double press, shifted, double shifted), nested macros (which essentially gets you unlimited steps), recursion (macros that call themselves), multi-macros, device specific macros, the list goes on. Those Toadtog bits can also be used for memory and conditional branching.

Wow! (Thinks: I must read up about this JP1 software.)

But here is the 64,000 dollar question: does the JP1 software handle toggle codes correctly (e.g. the RC6 codes used by Media Center)? Now you may think that the answer to this question is obviously "yes", but not so fast. I am convinced that there is a bug in Windows' handling of toggle codes. This is not noticeable unless there is a complementary bug in the remote-control's generation of toggle codes. Sadly, my Universal Remote Control MX-850 suffers from this bug, as do the One-for-All remotes that I have. I described this problem in gory detail in this thread:

http://www.thegreenbutton.tv/forums/vie ... ?f=7&t=385

In summary, when a remote generates toggle codes, it needs to keep a status bit to indicate whether the next transmission should have the toggle bit set to '0' or '1'. But it needs to do this for each device separately. The behaviour exhibited by the MX-850 and the One-for-All remotes shows that they keep only a single toggle bit that applies to all devices, and this (combined with Windows' incorrect processing of the signals received) leads to incorrect behaviour perceived by the user (i.e. you sometimes have to press a button twice in order for it to operate once).

Does the JP1 software keep separate toggle bits for each device? Thanks.

-- from CyberSimian in the UK

[mdavej]

Yes, the toggle bit in RC6 is per device. But this is irrelevant for MCE because the toggle bit is a don't care. We did have a case with some device where the toggle bit was used just for discrete power codes. But I came up with a solution for that by managing the toggle bit in the RC6-32 protocol rather than strictly MCE. There is a thread with the details in the JP1 forum. Bottom line is JP1 can handle the toggle bit however you want. You have complete control over that. You can even make your own protocol. There are no limits.

I suspect your issue isn't really related to the toggle bit. What commands aren't working, and what model IR dongle do you have?

[CyberSimian]

I suspect your issue isn't really related to the toggle bit. What commands aren't working, and what model IR dongle do you have?

I am no expert in these matters, but I rummaged around on my hard disk and found this draft of a post that I wrote for the old Green Button, but which I never posted; it dates from February 2011. It explains my thinking as to the cause of the problem that I have with multiple devices and toggle codes:

Remote Control Debounce Processing in Windows Media Center

I am trying to get my universal remote control to work reliably with Windows Media Center. I am using a Dell XPS 420 HTPC to watch and record TV, with a separate remote-control hi-fi amplifier for the TV sound. The Dell was supplied with an infra-red receiver and a Dell-branded Media-Center remote control (similar to this, but without the extra POWER button for the TV):

http://www.origenae.co.kr/en/accessory_rc197.htm

I have tried two different remote-control amplifiers (a Sony TA-S2 from a "Scala 2" hi-fi system, and a Teac A-H500 from a "Reference 500" hi-fi system), but the results are the same. I have also tried two different universal remote controls (a Universal Remote Control MX-850, and a One-for-All [Radio Shack in the USA] URC-7950), but again the results are the same.

I am pretty sure that Media Center and the two amplifiers all use toggle codes (that is, when a button is pressed and released several times in succession, the code for that button alternates between two different values). I have come to the conclusion that the problem lies in the algorithm that Media Center uses for its debounce processing. The remote controls are set up with "punch through" for the VOLUME-UP, VOLUME-DOWN, and MUTE buttons (that is, when the remote control is set to operate the Media Center, those three buttons instead operate the remote-control amplifier). With "EnableDebounce" enabled in the registry, this test demonstrates the problem:

(1) Start Media Center and watch live TV.
(2) Press and release the GUIDE button (the EPG appears on the screen).
(3) Press and release the VOLUME-UP button (the volume increases slightly).
(4) Press and release the GUIDE button (nothing happens).
(5) Press and release the VOLUME-UP button (the volume increases slightly).
(6) Press and release the GUIDE button (nothing happens).
(7) Press and release the GUIDE button again (the EPG disappears from the screen).

Steps (4) and (6) are wrong: the button press is being ignored by Media Center. What is happening (I believe) is that Media Center is discarding the button press resulting from steps (4) and (6) as part of its debounce processing. The significant characteristic of this sequence is that the same Media Center button is pressed before and after a button intended for a different device (e.g. steps (2), (3), and (4)). But note also that the equivalent sequence for the remote-control amplifier (steps (3), (4), and (5)) does not result in step (5) being ignored by the amplifier. This indicates that the remote-control amplifier is performing correct debounce processing, whereas Media Center is not.

I would surmise that the debounce algorithm currently implemented by Media Center is something like this:

Code: Select all

(1)    previous_button = 0;
(2)  get_next_button:          /* target label for "goto" */
(3)    wait for IR signal;
(4)    read new_button from IR receiver;
(5)    if new_button == previous_button  /* same as before? */
(6)      goto get_next_button;  /* ignore this button press */
(7)    if new_button is not for Media Center /* for some other device? */
(8)      goto get_next_button;  /* ignore this button press */
(9)    previous_button = new_button;  /* remember what button was pressed */
(10)   perform the function defined for new_button;
(11)   goto get_next_button;

Below is the algorithm that should be implemented by Media Center; note that line (9) is now in a different position:

Code: Select all

(1)    previous_button = 0;
(2)  get_next_button:          /* target label for "goto" */
(3)    wait for IR signal;
(4)    read new_button from IR receiver;
(5)    if new_button == previous_button  /* same as before? */
(6)      goto get_next_button;  /* ignore this button press */
(9)    previous_button = new_button;  /* remember what button was pressed */
(7)    if new_button is not for Media Center  /* for some other device? */
(8)      goto get_next_button;  /* ignore this button press */
(10)   perform the function defined for new_button;
(11)   goto get_next_button;

I am aware of the "EnableDebounce" registry setting, and I have tried setting that to 0 to disable debounce processing. But that replaces one problem with another, because now button presses start acting twice (that is, I press a button once, but the effect is as if I had pressed it twice). This does not happen on every button press, but it happens enough to be irritating and make the operation of the remote control unreliable. This is precisely the "button bounce" that debounce processing is intended to eliminate!

Finally, I am also of the opinion that the two remote controls that I have tried do not implement toggle codes correctly (although it is possible that their behaviour conforms to the standard that defines toggle-code behaviour for RC6 remote controls). The MX-850 and URC-7950 behave as though they have a single "toggle flag" that applies to all devices, whereas they ought to have a separate toggle flag for each device. This is confirmed by the fact that using the device-specific remote controls to control Media Center and the amplifier avoids the problems (each device does then have its own toggle flag).

If the remote controls implemented toggle flags correctly, the error in Media Center's debounce processing would not matter -- the correct outcome would still be obtained. And if Media Center implemented debounce processing correctly, the error in the remote controls' toggle processing would not matter -- the correct outcome would still be obtained. It is the combination of both errors that results in the unreliable behaviour of the remote controls.

-- from CyberSimian in the UK

[mdavej]

I did some more research and discovered I was mistaken about the toggle bit. Turns out, there's more than one toggle bit, and only one is ignored in MCE. Here are our JP1 protocol notes about the MCE protocol to clarify:

MCE is a form of RC6-6-32
The correspondence between fields of MCE and fields of RC6-M-32 is:
. The RC6 M value is 6 because the protocol is RC6-6-32
. The RC6 Toggle bit is always zero in MCE
. The RC6 Device is the OEM1 field of MCE, which always has the value 128
. The RC6 Subdevice is the MCE Device plus 256 times the OEM2 plus 128 times the MCE toggle bit
for example in Microsoft MCE, device is 4 and OEM2 is 15, so the RC6-6-32 device is 128 and subdevice is 4+256*15+(either 128 or 0) = either 3844 or 3972

The MCE toggle bit actively toggles when this protocol is used, so you do not need the Windows registry change that disables debounce (to work with learned signals in which the toggle bit isn't active). The RC6 toggle bit is a different bit than the MCE toggle bit. The RC6 toggle bit is always zero in MCE signals.

Although I use multiple remotes with WMC, I've never experienced this problem because I don't use the MCE protocol at all. I use Ortek, which doesn't have a toggle bit. That may be the easiest solution for you as well. Just get an Ortek/Adesso/Hama remote and use the dongle instead of your MCE one.

[crawfish]

FWIW, the only time I've run into problems like the ones described for the toggle bit has been when using non-Microsoft IR receivers, like the one in the Pinnacle kit I bought a long time ago and finally tried recently on my gaming system. The Microsoft-branded receiver OTOH has worked fine with my Sony RM-VL610 and also my RCA RCRP05B, the JP1 remote I use to teach discrete codes to the Sony. I ended up ordering a second Microsoft receiver used off eBay.

[offroad]

not sure why my discussion got hijacked to talk about programming JP1 and working some key bounce toggle issue. Am I blind, because the RCA RCRP05B does not seem to show this problem on my remote. Believe it must be what CRAWFISH mentioned, that you need a microsoft branded IR reciever, or an HP IR reciver (mine) to get this all working.

CRAWFISH - can you reference a purchase source for this IR reciever? and does it have a blaster with it also? how mcuh do they cost?

[mdavej]

The problem won't occur if you only use one remote, only when you use 2 remotes, if I understand correctly.

[CyberSimian]

The problem won't occur if you only use one remote, only when you use 2 remotes, if I understand correctly.

No; the problem occurs when you use one remote control to operate two devices. For example, a setup in which all buttons on the remote control operate Media Center except for the VOLUME and MUTE buttons, which operate a remote-control amplifier.

-- from CyberSimian in the UK