Volume punch-through without mute punch-through

[CyberSimian]

It's a simple text box that one can type into, no context menu. Just use Ctrl/V to paste.

Done that, and created the artificial learn. It tests successfully.

However, comparing it with the genuine learn, RMIR does not display identically:

- In the genuine learn, the MUTE button in "Functions" displays as "_missing1".
- In the artificial learn, it displays as "Mute toggle" (which is how I had named it originally).

- In the genuine learn, the MUTE button in "Buttons" displays as "Learn: Mute" (in bold).
- In the artificial learn, it displays as "Mute toggle".

- On the "Learned Signals" tab, the "IRP from analysis" and "IRP from decode" are virtually identical. There are slight difference in the frequencies, but that is probably not significant.

Do any of these differences matter, and could they cause problems subsequently?

-- from CyberSimian in the UK

[mathdon]

They do not matter, they are display issues only and will not cause any problems. The artificial learn has all the info it needs to display button and function names, as you have entered it. For the real learn RMIR has to create names. As for the IRP, the learn process cannot time the signal pulses exactly so the frequency and timing values are subject to slight errors which usually are not significant. The artificial learn will be true to the protocol specification.

You can use either, but my preference would be for the artificial learn. I would never now do a real learn except as a test. For a signal to actually use, I would always create an artificial one in this way from the IRP.

[CyberSimian]

They do not matter, they are display issues only and will not cause any problems.

That is a relief! When I first created the artificial learn and saw these differences, I thought that there was something wrong and that the definition would not work. But then I thought that I should probably test it, and it worked fine.

You can use either, but my preference would be for the artificial learn. I would never now do a real learn except as a test. For a signal to actually use, I would always create an artificial one in this way from the IRP.

Yes, I agree with this, and I am pleased to say that I have learned something new about RMIR and how to use it.

Thank you very much for helping me with this. It is much appreciated, and I will now be able to go forward and create the complete definition for the XSight Lite to control all of my devices. And thanks to Rob too for his suggestions and offers of help.

-- from CyberSimian in the UK

[CyberSimian]

This method should work for almost all protocols, so unless your devices use very unusual protocols, all should now be well.

Oh dear! It looks like my Cambridge Audio CXN streamer DAC does use an awkward protocol.

I created an upgrade for the CXN using the "RC-5/5x Combo" protocol; see this file in the Files Section: http://www.hifi-remote.com/forums/dload ... e_id=26691. If I follow your procedure to obtain the GIRR file, the entry for the MUTE button looks like this:

Code: Select all

<ccf T="0">0000 0073 0000 000B 0020 ... </ccf>
<ccf T="1">0000 0073 0000 000C 0020 ... </ccf>

from which I conclude that the protocol uses toggle codes (hence two definitions for each function). Is that what this notation means?

I noticed that on the "Learned Signal Details" panel, the "Signal Data" box has selections for odd and even keypresses. So I selected "Odd" and pasted the value for <ccf T="1"> and clicked "Apply". Then I selected "Even" and pasted the value for <ccf T="0"> and clicked "Apply". But the second paste seems to have overwritten the first paste, so only one value has been stored.

Have I not used the correct procedure for pasting a learned toggle code, or can artificial learned toggle codes not be created in this way? Thank you.

-- from CyberSimian in the UK

[mathdon]

I'm afraid there is no such thing as a learned toggling signal. A real learn is a learn of only one signal. The learn process has no way of knowing that the next signal would be different. Since a real learn cannot know this, the way it is encoded in the remote has no way of specifying a toggle, so artificial learns also cannot do it. That is why there are radio buttons in the new learned dialog for Odd and Even keypresses, to specify which toggle state you want.

[CyberSimian]

The learn process has no way of knowing that the next signal would be different. Since a real learn cannot know this, the way it is encoded in the remote has no way of specifying a toggle, so artificial learns also cannot do it.

I tested the artificial learn for the MUTE button for the Cambridge DAC, but as expected it did not work properly. The first press of the MUTE button muted the sound, but subsequent presses did nothing (so the sound could not be unmuted using the Xsight Lite).

Is there any way that I can get this work properly, or am I out of luck?

-- from CyberSimian in the UK

[mathdon]

Can you post a .rmir file of your setup, so I can see exactly what you are dealing with, please?

[The Robman]

CyberSimian, you need to understand how signals with a toggle bit work. Devices that use a toggle bit do so to help them differentiate between a user pressing the button twice and a button held down. On the OEM remote, every time you press a new button, a toggle bit changes, so if you keep pressing the same button, it will send a different signal each time, first with the toggle ON, then OFF, then ON, etc.

A JP1 upgrade replicates this, but a learned signal cannot. A learned signal can only have the toggle either ON or OFF, so a learned signal with a toggle will only work once. To keep using the learned signal, you will need to press another button in between.

If you can think of a button that would do no harm if it were to be pressed after every MUTE button, we could construct some Pronto hex which sends both together, then the learned MUTE might do what you expect.

[CyberSimian]

Can you post a .rmir file of your setup, so I can see exactly what you are dealing with, please?

I have added the RMIR file to the Diagnosis section:
http://www.hifi-remote.com/forums/dload ... e_id=26692

It contains six devices (amp, cd, dac, htpc, radio, tv). The amp and cd devices are still "works in progress", but the other devices are more or less as I want them.

-- from CyberSimian in the UK

[CyberSimian]

Devices that use a toggle bit do so to help them differentiate between a user pressing the button twice and a button held
down.

Yes, I encountered the toggle-flag problem when I used a Microsoft MCE remote control with a Sony amplifier, and then with my current Teac amplifier. All three of these devices use a toggling protocol, and as a result interfere with each other when a universal remote is used. The characteristic symptom is that the MCE button is ignored if pressed after a single press of an amplifier button. But the second press of the MCE button always works (but this is, nevertheless, very irritating).

A learned signal can only have the toggle either ON or OFF, so a learned signal with a toggle will only work once. To keep using the learned signal, you will need to press another button in between.

Yes, I have just tried that and that works. So the first press of MUTE works, but subsequent presses of MUTE are ignored (if no other button intervenes). However, pressing some other button on the DAC remote then allows the MUTE button to work (i.e. unmute the DAC) when pressed subsequently.

If you can think of a button that would do no harm if it were to be pressed after every MUTE button, we could construct some Pronto hex which sends both together, then the learned MUTE might do what you expect.

I have just been reviewing the set of DAC buttons, and there is one that could be used. There are several codes that control the LCD display (bright, dim, off, and toggle). The DAC powers off the display after a timeout, but redisplays it whenever a button is pressed. So creating a composite of MUTE followed by LCD_BRIGHT would probably cure the toggle-flag problem without generating a visible side effect.

-- from CyberSimian in the UK

Edit: changed "with" to "without".

[The Robman]

I have just been reviewing the set of DAC buttons, and there is one that could be used. There are several codes that control the LCD display (bright, dim, off, and toggle). The DAC powers off the display after a timeout, but redisplays it whenever a button is pressed. So creating a composite of MUTE followed by LCD_BRIGHT would probably cure the toggle-flag problem without generating a visible side effect.

Try replacing the code for the DAC MUTE button with this:

0000 0073 0015 0000 0020 0020 0040 0040 0040 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0040 0020 0020 0040 0040 0020 0CA8 0020 0020 0020 0020 0020 0020 0020 0020 0040 0020 0020 0040 0040 0040 0040 0020 0020 0040 0040 0CC8

I've made this non-repeating because I don't think a MUTE button needs to repeat when held but if you find that it does, I could re-do it.

[CyberSimian]

Try replacing the code for the DAC MUTE button with this

Thank you for the modified data for the DAC mute button. I tested it, but unfortunately it does not change the mute status -- the sound continued unabated.

However, I did notice that if the display was set to dim, pressing the MUTE button caused it to brighten. This is different from the original behaviour, whereby pressing MUTE displays "X" for one second before reverting to the previous display, but the brightness does not change -- if it was dim originally, it remains dim throughout this sequence. So the modified definition is having some effect.

-- from CyberSimian in the UK

[The Robman]

Try this version instead then:

0000 0073 000A 000B 0020 0020 0020 0020 0020 0020 0020 0020 0040 0020 0020 0040 0040 0040 0040 0020 0020 0040 0040 0CC8 0020 0020 0040 0040 0040 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0040 0020 0020 0040 0040 0020 0CA8

[CyberSimian]

Try this version instead then.

Brilliant! Works great!

I usually have the DAC LCD set to bright, which is why I suggested using the LCD_BRIGHT function. But I also tested with the display set to dim, and surprisingly the display remained dim when the MUTE button was pressed. I had expected that it might change to bright, but the DAC must be doing something else after it has processed the MUTE signal. However, this is actually a better outcome (for anyone who wants to use dim on this DAC!).

Many thanks.

-- from CyberSimian in the UK

[mathdon]

Thanks, Rob, for this very interesting work-around. It would never have occurred to me to use the fact that for a toggling protocol the toggle alternates on successive signals, regardless of what signal is being sent. So by sending a another signal after each Mute, the device always expects the Mute to have the same toggle value, which the learned Mute supplies. My thoughts had only been to try to find a way to get successive Mutes to have alternate toggle values and I could see no way of achieving that.