How do I reset the RC-5 toggle bit info in the reciever?

[blader_se]

My custom exec will always send a quick meaningless signal before sending the proper signal, and the toggle will alternate between the two.

I would really like to know what "meaningless signal" you are sending.

My problem is not learning (the URC-8910 worked fine), but blasting with
my USB-UIRT blaster. I recently got a replacement sattellite reciever that
are always expecting the toggle bit to toggle, i.e. if I am to send "12",
and the first "1" have the toggle bit set, the second "2" MUST have it reset.

So If I would include your "meaningless signal" in the IR-definition file
(pronto format) perhaps I can reset the toggle bit info in the reciever.

[blader_se]

Is there any way in the RC-5 protocol to force the reciever to forget the state of the "toggle bit"? I guess it should be a time-out but that is to huge to be notable on my Sat reciever.

My problem is blasting with my USB-UIRT blaster. I recently got a replacement sattellite reciever that are always expecting the toggle bit to toggle, i.e. if I am to send "34", and the first "3" have the toggle bit set, the second "4" MUST have it reset.

So If I could include some "reset-toggle-bit-please-command" before sending the actual channel numbers, I could be certain that channel changing would work.

[underquark]

What happens if you send "3-3-4" instead of "3-4" - does it simply ignore the middle digit? Does it require the same toggling on others keys such as vol+, ch+, menu etc.?

I see that you've read this:
https://www.hifi-remote.com/forums/viewtopic.php?t=5136

I think any signal would be count as "meaningless" if the toggle-bit is wrong but I'm sure the Robman will have picked a signal that doesn't generate a dangerous function.

[blader_se]

What happens if you send "3-3-4" instead of "3-4" - does it simply ignore the middle digit? Does it require the same toggling on others keys such as vol+, ch+, menu etc.?

Well, that depends on the toggle bit. Basically it will ignore any digits that have the toggle bit in the "wrong" state. If the reciever is waiting for
a toggled digit ('), sending "3'-3-4" would result in channel 33 selected, if waiting for a non-toggled-digit, channel 3 would be selected.
And the memory function of the toggle bit seems to be in the range of more than just a few seconds, but I have not yet verified this.

I have not tested other buttons than the digits yet...

[johnsfine]

Is there any way in the RC-5 protocol to force the reciever to forget the state of the "toggle bit"?

Hopefully you can find a do-nothing command that the receiver recognises.

Simply sending that do-nothing command would then get the RC-5 toggle bits in sync. If the bits were not in sync, the do-nothing command wouldn't be accepted and the receiver's toggle state wouldn't change, but the remote's toggle state would change. If the bits were in sync, both would change so they'd stay in sync.

Very few RC5 devices behave the way you described. Maybe you should test more to be sure you understand the behavior.

With the original remote, if you press a key while covering the emitter with your hand, you should then be out of sync with the receiver. Does it then fail to accept the next key you press?

[The Robman]

My custom exec will always send a quick meaningless signal before sending the proper signal, and the toggle will alternate between the two.

I would really like to know what "meaningless signal" you are sending.

The meaningless signal is just an un-used OBC from the same device code as the main part of the signal. You could absoutely edit the pronto hex to do the same thing, however, you wold need to use the raw pronto hex, not the "5000" hex where the pronto has recognized that the signal is RC5.

[blader_se]

With the original remote, if you press a key while covering the emitter with your hand, you should then be out of sync with the receiver. Does it then fail to accept the next key you press?

Exactly, and it does this even when over 2 hours passed since the last time I switched channels! So there's no timeout either.

Anyone else experienced this? It has to be a bug in the reciever, but how do I convince the sat provider that???

[The Robman]

My problem is not learning (the URC-8910 worked fine), but blasting with my USB-UIRT blaster. I recently got a replacement sattellite reciever that are always expecting the toggle bit to toggle, i.e. if I am to send "12", and the first "1" have the toggle bit set, the second "2" MUST have it reset.

Can you tell me more about the USB-UIRT? What is it and how are you using it to control your SAT?

[blader_se]

Can you tell me more about the USB-UIRT? What is it and how are you using it to control your SAT?

The USB-UIRT (http://www.usbuirt.com/) is an IR reciever/blaster that I use in conjunction with the GB-PVR software (http://www.gbpvr.com) to change channels and record programs from my sattellite reciever. The sattellite reciver have Philips, or Nokia printed on the front, and it's some mediahighway box for canal digital in Sweden.

You specify pronto codes in the IR definition file for the USB-UIRT.
I've been told that "learned" pronto codes start with 0000 but original codes start with 5000. Is there a way of getting the 5000 codes from the learned ones? These should supposedly auto-toggle - do you know something about this?

[johnsfine]

We do know how to translate RC5 signals in either direction between the form beginning 5000 and the form beginning 0000.

The form beginning 0000 represents a single state of the toggle bit for a single command. The form beginning 5000 represents the command without specifying the toggle state, so a Pronto that knows how can perform the toggle.

Are you saying that your USB-UIRT is able to understand the 5000 format and toggle correctly when given commands in that format? Most non Pronto devices that understand Pronto Hex understand only the 0000 form.

You can decode the 0000 form using IrTool.exe

If it was RC5, you'll get that fact together with the device and function number.

In 5000 format each signal is
5000 0073 0000 0001 00wx 00yz
where you replace wx with the device number in hex and replace yz with the function number in hex.

So you can easily manually create the 5000 format from the decode of the 0000 format.

[blader_se]

We do know how to translate RC5 signals in either direction between the form beginning 5000 and the form beginning 0000.

Great info. I grabbed a coupple of IrTool and tried to decode it but I get the error "This is an incomplete code. There are too few data pairs."
So either I did not understand how to use the tool, or the codes are not in pronto format...

An example of the code I have of the digit 1 is:

Code: Select all

1a 0000 0072 0000 000B 0020 0021 0020 0021 0041 0040 0041 0040 0041 0021 0020 0021 0020 0021 0020 0021 0020 0021 0020 0040 0020 0CC0
1b 0000 0072 0000 000B 0020 0021 0041 0021 0020 0040 0041 0040 0041 0021 0020 0021 0020 0021 0020 0021 0020 0021 0020 0040 0020 0CC0

where a and b are the two toggle states.

To give you more info, The setup in RemoteMaster is RC-5, Device 10, and the button 1 have EFC 205, Device 10, OBC 1 and Hex f8

And the upgrade code RemoteMaster gives me is

Code: Select all

Upgrade code 0 = 70 d2 (SAT/0210) Philips digital SAT (RM v1.31)
 e8 04 56 fe 20 21 15 55 15
 00 00 e5 cc c0 bd b9 a9 a5 a1 55 c1 b1 5c 40
KeyMoves
 25 f3 70 d2 b5«serv»
End

Update:With the help of MakeHex I reproduced the code, and finaly I got an 5000 code of

Code: Select all

5000 0073 0000 0001 000a 0001

which I now realize I could have calculated strait ahead with your formula, if I had used it correctly

The bad news is that the USB-UIRT don't seem to correctly handle those ;-(