Can't make manual shift buttons to work in Atlas.

[ElizabethD]

Two Atlas Time Warner 1056B1 black remotes. Both have the same problem. Or I do
One uses extender v211, the other uses v303.

I press and hold Setup (or another button designated for shifting) and press Shift-0 for instance then let go of both.
NOTHING happens. (It's supposed to switch inputs)
Use the the VideoSource button to toggle through the 10 shift-numbers I have - works great.

Put Shift-0 or shift-anyOtherNumber in a macro - it works great.
Am I pressing it wrong?

[The Robman]

Why are you pressing and holding SETUP?

[ElizabethD]

Aha!
Why hold shift? Simple: I don't remember how it's done. Last time I had to use shifts was in unextended 8910 years ago.
This time I needed to confirm a function in a file from long ago. It didn't work the amplifier and didn't work in IRscope.
So I tried without holding shift. Tap it, then tap a number. Receiver responds correctly. Problem solved.
Thank you, Rob.

IRscope doesn't like it, I get gaps and goofy numbers, but that's ok for now.

[The Robman]

In un-extended remotes, you have to tap SHIFT twice for shifted number buttons, in extended remotes you can just tap it once.

Why are you trying to use IRScope to decode a button that's being sent by a JP1 remote? Surely you can just look at the upgrade that you used to program it?

If that's not it, maybe explain what you're really trying to do and I can help with that.

[ElizabethD]

I no longer need to use IRscope since stuff is working once you taught me how to shift.
Why was I trying IRscope? Because I'm not familiar with that remote (maybe Atlas changed things I thought), with that extender (where some button numbers changed). So looking for a point of failure I wanted IRscope to tell me that the remote sends correct value which I finally saw when I captured a corrected macro (added tiny pause) with shift-0.

For some reason Shift numbers get messed up in IRscope. Maybe has to do with a complicated Yamaha protocol.

[The Robman]

If IRScope is struggling to capture the shifted number buttons, it's whatever code you have assigned to the buttons that's causing the problem, or it's user error in the capture process.

[ElizabethD]

If IRScope is struggling to capture the shifted number buttons, it's whatever code you have assigned to the buttons that's causing the problem, or it's user error in the capture process.

Rob, I think I press it correctly though it's rough to do since I don't have 3 hands to press capture, shift, number since the silly remote rolls about.
When I do shift numbers to the receiver, all functions are correct.

In fact Raw data in .rmir matches upgrade codes in .rmdu for all device inputs.
I just made a test macro with those ten shift numbers. All but shift-0 don't decode - all say Gap... So me thinks it's a IRscope puzzle.
I put in Diagnosis a IRscope Summary file and .rmdu in case you're under covid house arrest and have nothing to do:
http://www.hifi-remote.com/forums/dload ... e_id=26031
It's based on a file you made long ago for this jungle of yamaha protocol which to me is clear as mud. But it works, so I don't care and don't have the skills to understand it.

[The Robman]

I blame weak batteries in the remote.

I just added an Excel file to your zip, in it I take all of your decodes and round them up to multiples of 550, then pair them up to make '1' or '0', then convert the binary into decimal and they all match the input selects that you programmed to the shifted number buttons.

But...

There were a lot of ON times that were just +50 instead of +550, so I had to replace a bunch of them (they're colored red in the spreadsheet). I think that is a symptom of weak batteries.

Now that you see what I have to do to decode output from IRScope, you can see why I much prefer doing it in RMIR, which can now handle ICT files too, thanks to Graham and Barf.

[ElizabethD]

The Excel sheet is amazing. Thank you. Maybe I'll learn something from it.
Batteries: Great hint worth trying so I put new ones in.
But IRscope still doesn't like my shift-numbers and issues Gaps just like before.
I played with Macro delay in Settings - no effect.
I'll no longer blame Atlas because I unarchived 8910 extender1 files built under KM and IR and later in the RMxx stuff.
IRscope issues Gaps just like in Atlas. But works my receiver just fine.
In case you want to see .ict files from 8910, just ask. I don't know how to do the complicated magic you do.

[The Robman]

Yes, anytime you want me to look at the data in an ICT file, I would much rather see the original ICT file over a cut & paste of the timing data. In the old days, I would convert it into an IR file so that I could open it in IR.exe, but Graham recently added functionality to RMIR which lets you open an ICT file there, which in turn lets me use the cool analysis tools in RMIR to convert the data to binary.

In a case like this, I would advise eliminating variables. You are under the impression that the fact that the functions are assigned to shifted buttons in contributing to the problem, but I doubt that that is true. I suspect that if you were to assign them to un-shifted buttons you would get the same result.

Once you've done that exercise and found that you get the same results, the next question is, is the problem with the signals or with IRScope? To test that, I would recommend learning the signals from one remote to another and then verifying how they get displayed in RMIR.

Also, just FYI, Graham recently changed RMIR to use one of Barf's programs to decode the signals, so if you do do the remote to remote learning exercise, when you check how they get displayed in RMIR, go to the Options > Set IR Decoder and switch it between DecodeIR and the other program to see if they display differently based on which decoder is used. In this case, I expect they will decode the same.

[ElizabethD]

I uploaded OEM remote recorded on IRscope - Summary and .ict files in case they're helpful.
http://www.hifi-remote.com/forums/dload ... e_id=26032
Interesting that the decoding is still the same, wrong, but most keys are interspersed with some short bursts.

i'm now reading sifting through your suggestions. Will likely follow up tomorrow. Have to figure out the best sequence.

I don't know if Atlas is a learner. Even if it is, deactivating the extender will require me to rebuild everything from scratch.
Maybe one of 8910s could learn for me. But I think they're all extended as well.

[The Robman]

I would recommend using the 8910 as it is indeed a learner, and loading and unloading the extender is as simple as loading an .ir or .rmir file.

There are WAY too many variations of Atlas remote for me to know which model you're talking about, but even if it's a JP1.x version, most extenders have a mechanism to deactivate them, and then re-activating would be as simple as re-loading your .rmir file and pressing the activation button. But regardless, I do know how it works with the 8910 so that's what I would use if I were you.

[The Robman]

Liz, when I open your ict files using IRScope, I get decodes for all of them. Do you have DecodeIR.dll in your IRScope folder?

[ElizabethD]

Rob,
Thanks for posting the screenshot with clear version numbers. All my problems due to wrong tools.
It turns out that IRscope I got from my XP (2.01 beta3) just won't fly any more but it was the only thing I had.
About a year ago I tried using 2.01a. It never worked when I migrated jp1 stuff to Windows7. Turns out DecodeIR in it was the the wrong version.
I fixed it today. 2.01a works just fine. Problems solved

Did you notice that in windows explorer DecodeIR properties doesn't show version number? I wish it did because it's very inconvenient as is.

[mathdon]

Did you notice that in windows explorer DecodeIR properties doesn't show version number? I wish it did because it's very inconvenient as is.

IRScope, however, shows both its version and the DecodeIR version on its title bar (as well as the versions of ExchangeIR and MakeHex that it is using).