I had been registered under this name 7-8 years ago, but I guess I was culled from the list for disuse...now reregistered.

Anyway, I've had my TSU9600 for a couple of days. I'm generally happy, although I could say something about the cheap, toylike ring around the cursor or the finicky USB connection. But I digress.

I had my XCF file ready to go when the remote arrived, having based it on my TSU1000 CCF file. It's worked generally smoothly, but I'm having an issue with controlling the volume on my Lexicon DC2 preamp/processor.

With the OEM remote, pushing the volume up button raises the volume by 1 db. Holding the button causes a continues increase until the button is released. It worked the same on my TSU1000, using a learned code.

But the same code imported to the TSU9600 causes jumps of 2-3 db with each push, and in a sloppy, inconsistent fashion. I tried the code in the database, but it behaves the same. I also tried varying the duration, but one can only set a minimum, not a maximum, and lengthening it just led to greater jumps in volume.

I tried learning the code into the 9600. I got varying results with each try, but eventually got a code which raised the volume by 1 db. Great, except it turns out that holding the volume button down doesn't produce a ramping up, just the 1 db change.

Any ideas for how I can reproduce the behavior of the OEM remote and the TSU1000 on the 9600?

If it helps, this is the code learned on the TSU1000:
0000 006d 0022 0002 0156 00ab 0015 0040 0015 0016 0015 0040 0015 0015 0015 0016 0015 0015 0015 0016 0015 0040 0015 0015 0015 0040 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0040 0015 0040 0015 0040 0015 0016 0015 0040 0015 0016 0015 0015 0015 0016 0015 0015 0015 0016 0015 0015 0015 0040 0015 0016 0015 0040 0015 0040 0015 0040 0015 06a1 0156 0055 0015 0e4b

What is the 'Duration' setting for this code in the 9600 editor? Is it default? If so, try setting it to a value such as 250ms. It may be that the default duration is too long. Experiment with some different values and please report back.

Lyndel-

Thanks for the advice. I think you're right that the code is being sent for too long. I've tried different duration settings, but correct me if I'm wrong here--the setting is labeled as minimum duration, so I would think that a command could be made longer but not shorter (in terms of being truncated prematurely).

This at least appears to be the behavior. Settings above .25 seconds lead to progressively larger jumps in volume. Settings below .25 (I tried down to .01) still give 2-3 db changes at a time.

I realize this is exactly the same issue as in another thread ([Link: remotecentral.com]). It's interesting that that poster had success with a setting of 0.9--he said ms, but I assume he meant seconds. I tried entering .009 (i.e., 9 ms) but it goes back to .01 and 2-3 db volume changes at a time. A setting of .9 seconds leads to a jump of 15 db at a time.

This isn't a huge deal, and I could probably live with it, but it's odd that the TSU1000 works fine in this regard. Incidentally, I updated the 9600 to the latest firmware.


--Eric

I should add this: the above experiments were using the codes from the database. I tried again with the codes learned on the TSU1000, and the effect was the similar, although those codes more reliably jump 2 db at a time rather than 2 or 3 with the database codes.

I tried again learning the code into the 9600. That produces a very long (20 lines or more in the editor) code which jumps 1 db at a time, but won't keep going with the button held down.

OK, I know it's bad form to answer one's own post...twice...but I stumbled upon a working solution.

As I said, using the codes learned on the TSU1000 seemed to work better than the database codes, in that the volume jumps were 2 db rather than randomly 2 or 3. This was from testing using the "test IR" function in ProntoEdit. So, I decided to upload those codes to the 9600. The durations were set to 0.1 sec.

Surprisingly, even though "test IR" gives 2 db jumps with these codes and these durations, once they're uploaded to the 9600, they work as intended--1 db jumps and continuous change if the buttons are held down.

I guess the moral of the story is don't assume the behavior through ProntoEdit is the same as with the Pronto itself. And, of course, Lyndel was correct in his advice.

You're not alone. I feel the same way about the scroll wheel. The design is not the best to be kind. My biggest gripe with it is that it gets in the way of smooth operation of the directional pad and is easy to move by accident which ends up activating the screen. I also run into the HID driver problem at least once a week. The message you get in PEP when attempting to download to the remote tells you to restart your computer to fix the problem. This doesn't work. Resetting the remote, then redocking said remote if it was reset while in the cradle does fix the problem however.

Hi Eelton,

The code I am using is slightly different and for a DC1 but it works in steps of 1 db:
0000 006D 0022 0002 0156 00AA 0015 0015 0015 0040 0015 0015 0015 0015 0016 0015 0015 0015 0015 0015 0016 0040 0015 0040 0015 0040 0016 0015 0015 0040 0016 0015 0015 0015 0015 0015 0016 0015 0015 0040 0016 0040 0015 0040 0015 0015 0015 0040 0015 0015 0015 0015 0016 0015 0015 0015 0015 0015 0016 0015 0015 0040 0016 0015 0015 0040 0016 0040 0015 0040 0015 066C 0156 0055 0015 0E45
Notice the last off time of the header (066C) which is a bit less than 06a1. I have to admit though that I am using a serial extender, but I've heard that that shouldn't matter.