Toadtog and Koss KD260

[The Robman]

The Koss_DVP2163.txt file uses NEC1 protocol with a device code of 1. I am surprised that this file worked for you as it uses a completely different protocol to the other two files that you tested. Are you 100% sure that you tested it properly.

Sorry, sorry, I don't know what happened there. When I use this upgrade, the power button (mapped to L4) does turn the player on and off. But the other functions (direction keys, select, play, pause etc.) don't work.

Then I suspect that the L4 button is not using this upgrade, but is instead pointint to some other upgrade that you have loaded, or maybe even the built in 0651 code.

[Capn Trips]

Obviously while I was away, Rob has given you a LOT of help.

Just to summarize,
(1) you SHOULD use the device upgrade you have (that uses the 0045 protocol, since that maps the bbuttons the way you want them, BUT you should NOT add the 0045 protocol upgrade since that is redundant;
(2) I would assume that the problem you are seeing is related to the issue Rob touched on:

I do wonder however, if the toggle bit in the signal is working correctly when you use Toadtog with this protocol. (John would be able to speak to that).

It really DOES sound like the signal sent by the ToadTog-generated "power" signal is out-of-synch with the required Recs80(45) toggle state (not to be confused with the TT toggle state, which seems to be tracking correctly).

It may indeed be that the toggle bit used by the Recs80(45) protocol is somehow "subverted" by the calls to the function by ToadTog and then it gets out of synch with itself.

I have no personal experience with using ToadTog with a protocol that has an embedded toggle bit. In fact, I find it a bit odd that IF the problem is the peaceful coexistence of these two toggle states that it has not previously been manifested and investigated in this forum, but since only a FEW protocols use this toggle bit system, perhaps it's simply a matter of chance that nobody has heretofore stumbled upon it.

[johnsfine]

I think that toggle bit problem has been discussed before, but I don't recall the details (solution, work around, etc.).

The remote keeps a single global bit for codes with internal toggle bits. It toggles that bit on every command, even for protocols that don't have an internal toggle bit (even for special protocols such as the one that invokes a ToadTog) .

So it is very easy for that bit in the remote to be out of sync with the corresponding bit in the actual device, and rather tricky to define macros that are immune to the resulting problems.

[The Robman]

If the internal toggle bit is indeed being incremented for each step in the extender's macros, I would expect that simply moving the toadtog either up one place or down one place in the macro would solve the problem.

[Bebel]

Okay, let's break this down.

Let' s leave aside for a moment the question of the state of the TT bit because the LED behaviour on the remote indicates that it's tracking the state correctly.

There's no reason I can think of that would explain why the ToadTog state toggle (my L3) won't work when L4 (power) does. Whatever the state of the toggle bit, it should send L4 to the player. And the LED indicates that it's doing so -- or at least sending something. And yet, toggling ToadTog 1 does nothing, whether it's set to $11 $28 $28 (Toggle, L4/L4) or $12 $55 $28 $55 $28 (Toggle, X_DVD;L4/X_DVD;L4). (There seems to be an unaccounted for but rare exception to this rule, as I discovered in my tests.)

Obviously, this behaviour makes no sense. But I think it must hold the key to the more general problem, since clearly the player is not responding when it's sent L4 repeatedly via the ToadTog in toggle mode, whereas it responds unfailingly if it's sent L4 manually.

The central questions are therefore the following:

(1) What is the difference between a manual L4 and a ToadTog L4 [$11 $28 $28]? Is there any difference at all in the signal emitted by the remote? As noobish as I am, it seems clear that there should be no difference at all.

(2) If not, then, is there any situation in which the player would refuse a signal (apart from a macro being executed too quickly, which doesn't seem to apply here -- we're only talking about one key)? For example, could the player be "expecting" the RECS80 toggle bit to be in a specific state (i.e., could it refuse L4 with T=0 but accept L4 with T=1)? This sounds unlikely. (And I admit that if this were so, it would be unclear why the manual L4 works unfailingly.)

Neither of the explanations suggested in these two sets of questions is satisfactory. Therefore, there must be a third consideration.

Could it be the extender? Would it be worthwhile reinstalling the extender from scratch?

More specifically, could it be ToadTog itself? I realize that this is very unlikely as no one else seems to be having this problem. Nevertheless, is there another version of ToadTog I could try?

Logically, these seem to be the only options available, unless there's something I'm not getting.

Thanks so much for all your ongoing help. I really appreciate it.

Edited to get rid of a dumb and unintended smiley.

[Bebel]

Okay, now I'm out of sync. A whole load of replies streamed in while I was composing my last post. I'm just going to assimilate the information and come back to you in a minute.

Thanks!

[johnsfine]

I suggest being careful for the rest of this thread to distinguish whether you are talking about the ToadTog toggle bit or the RECS80 toggle bit. The two are very seperate items.

[The Robman]

For example, could the player be "expecting" the RECS80 toggle bit to be in a specific state (i.e., could it refuse L4 with T=0 but accept L4 with T=1)? This sounds unlikely. (And I admit that if this were so, it would be unclear why the manual L4 works unfailingly.)

This is exactly what we're saying. This is why people with learning remotes have problems learning signals with toggle bits in them. The usual symptom is that the learned signal works once and once only. You need to press a different button before the button will work again.

Do you have a second JP1 learning remote at your disposal? If so, could you try learning the signal emitted when you press the toadtog button. If you don't have another learning remote, do you have a digital camera? If so, you can use the camera to see if the remote is sending a signal at all. Remember, Toadtog controls whether the remote should send a signal or not, so half the time it won't send a signal at all.

[Bebel]

Okay! Now we're getting somewhere. However, something occurs to me...

If I send power commands to the DVD player through L4, then the remote's global internal toggle, which simulates the RECS80 toggle bit in the original remote, would change state with every successful command. Correct? This is why a manual, repeated L4 (power command) works unfailingly.

But if this is so, it should be just as true when ToadTog successfully sends L4's power command to the device too, i.e, when the TT bit permits it. In other words, a ToadTog L4 (power) should also change the state of the remote's internal global toggle.

So ToadTog shouldn't cause a problem, UNLESS ToadTog DOESN'T change the state of the remote's internal global toggle bit when it processes key presses that refer to RECS80 commands. (EDIT: Or unless ToadTog changes the state of the remote's internal global toggle bit IN SPITE OF whether it sends the commands or not. [I suppose.])

Am I off base here?

[Bebel]

Do you have a second JP1 learning remote at your disposal? If so, could you try learning the signal emitted when you press the toadtog button. If you don't have another learning remote, do you have a digital camera? If so, you can use the camera to see if the remote is sending a signal at all. Remember, Toadtog controls whether the remote should send a signal or not, so half the time it won't send a signal at all.

Unfortunately, I only have one learning remote. I do have a digital camera, however. But doesn't the LED on the 8811 show whether it's sending a signal or not? If the camera will help us solve the problem, just let me know what I need to do.

I'd be happy to follow other suggestions too, if only to help out the community -- since this seems to be a rare but significant issue.

[The Robman]

Unfortunately, I only have one learning remote. I do have a digital camera, however. But doesn't the LED on the 8811 show whether it's sending a signal or not? If the camera will help us solve the problem, just let me know what I need to do.

There are two LEDs on the remote, there is the red "visible light" LED and there's the "infrared" IR-LED. The red LED being illuminated simply means that the program is running, which usually means the remote is sending a signal, but when you're using a utility like Toadtog, you cannot be certain that the remote is sending a signal.

The digital camera will let you see whether the IR-LED is sending anything when you press this button.

[Bebel]

The digital camera will let you see whether the IR-LED is sending anything when you press this button.

Now that's cool. Anyway, ToadTog is sending signals when it should and not when it shouldn't.

[The Robman]

Is this file still the one you are testing with? Maybe one of us can try loading it into a URC-8811 and try capturing the signal using another remote.

[Capn Trips]

Might I suggest one additional experiment?

If I recall and understand these protocols with toggle states, the problem with non-responsiveness only arises upon successive sends of the SAME signal. In this circumstance, you are sending the same signal (Power) in your various TT testing combinations (or no signal at all - if TT says you ought not). So how about trying this:

For each instance in which the DVD Power signal is sent as a result of a call from a ToadTog sequence, insert another command (prefeably a benign one) to the DVD player (like a single increment of Vol+ or a Vol-, or "Stop" or a "Down Arrow") PRIOR to the call to the ToadTog command. This might be enough to get the RECS80(45) toggle "unscrewed" (pardon my French).

[Bebel]

Is this file still the one you are testing with? Maybe one of us can try loading it into a URC-8811 and try capturing the signal using another remote.

I can't remember what stage we were at when I uploaded that one! At any rate, the current IR file is here.