Hi I am working with a Polycom viewstation and this nice tsu3000. And I am having the hardest time learning the codes for the numberpad. I have a document from the manufacturer showing me what the codes are supposed to be but the Learned Strings are much longer and in most cases dont seem to contain the manufacturers string at all.

Example of Learned IR Code for the Number 1 on the Keypad:
0000 006B 0000 0012 0065 0065 0016 0022 0016 0022 0022 002E 0022 002E 0016 0022 0022 002E 0016 0022 0022 002E 0022 002E 0022 002E 0016 0022 0016 0022 0016 0022 0022 002E 0022 002E 0016 0022 0016 091B

Documented Code for the same key:
RM_ONE 0x0E

Another Example is Number 2
Learned:
0000 006B 0000 0012 0065 0065 0016 0022 0016 0022 0022 002E 0022 002E 0016 0022 0022 002E 0016 0022 0022 002E 0022 002E 0022 002E 0016 0022 0016 0022 0022 002E 0016 0022 0022 002E 0016 0022 0016 091B

Documented:
RM_TWO 0x0D

Can anyone shed some light on this for me? Thanks in advance for any help.

[Link: remotecentral.com]

I figured this was the most appropriate Forum for my problem.... didnt know how to move the thread

This might be the most appropriate forum and I don't know how to move a thread either. I suspect you're running into some TSU3000 issue rather than some Polycom issue, so the other forum is more appropriate, but I'm not at all sure of that and didn't post above to question your change of forum.

I just wanted to save any expert who might look at it here the time of going down the same path as I went down there.

If you want to expand on your last post there, I might even think of something else useful to try. The phases "other than the simple discrete code", "try to dial" and "it freezes" in that post all leave me guessing. None of them give me any kind of picture of what you actually tried and what results you observed.

well i think that the tsu3000 is learning some bad codes and I am having continuous problems with them. i was hoping to take the Discrete codes from polycom and convert them into something that the tsu3000 can push out thats compatible with the polycom. And sorry that Im so sketchy some times but believe it or not my brain thinks in quips and phrases also... :)

If you email me what you have from the manufacturer, I and the learned numerals 0 through 9, I can probably decode it.

If you consider 0016 0022 to be the One, and 0022 002E to be the Zero then you get:

1100101000 1110 01
1100101000 1101 01

where the 4 bits in the middle are 0xE and 0xD respectively, but it is always reckless to decode two commands and conclude a pattern.

-Jon

Postscript: I got interrupted while answering and didn't see John's answer before responding

I didn't initially see the fit for 0xE and 0xD that Jon saw.

Jon, comparing those to the samples at Premise, I think the command is six bits, not 4, so those examples are.

11001010 001110 01
11001010 001101 01

I think the last bit is parity, but I'm confused by the bit before the last. Either I'm hand decoding carelessly or it doesn't match. If it doesn't match, it's probably a toggle bit. If it's a toggle bit, then that probably explains the problem.

ZaneH, if that's a toggle bit and you learn any one function of the original remote twice in row to two different buttons on the TSU3000, the resulting data will confirm that it's a toggle bit. Be careful not to do any extra presses on the original remote of the same or different buttons between the press for the first learn and the press for the second.

This is a quasi-automated decoding of the numerals 0 through 9 of the Premise system commands in the layout John suggested. I suspect then manufacturer's hex values are really the binary complement as shown below. Curiously, the next to the last bits were reversed in the learned commands above. So it could be a toggle bit (but I would have expected it to vary), but perhaps a control bit of some sort. If so, the last bit is consistent with a parity bit of the previous 15 bits.


0xF 11001010 001111 11
0xE 11001010 001110 10
0xD 11001010 001101 10
0xC 11001010 001100 11
0xB 11001010 001011 10
0xA 11001010 001010 11
0x9 11001010 001001 11
0x8 11001010 001000 10
0x7 11001010 000111 10
0x6 11001010 000110 11

-Jon

I think I remember a long time ago some questions on polycom. And I think they do have a parity bit

Anthony, I'm fairly sure what you're calling a "parity" bit is what Jon and I are calling a "toggle" bit. In fact I think the Polycom has both a toggle bit and a parity bit (actually a toggle bit and probably two parity bits) but only the toggle bit is significant for the problem in using learned signals.

I did a search and found only one thread that indicates Polycom has a toggle bit
[Link: remotecentral.com]
and it only describes the symptom of the toggle bit, no one seems to have explained the symptom in that thread nor mentioned toggle (or parity) bits. However that symptom description does increase my confidence in the guess that this signal does have a toggle bit.

Jon, If those signals at Premise were learned signals then I certainly would expect the toggle bit to vary as you said. I'm leaping to a lot of conclusions here on scant evidence and one of those conclusions is that those signals at Premise were derived from a program based on a protocol description, rather than directly learned from a Polycom remote. I'd also guess that the last bit of each group of eight is even parity for that group rather than the 16'th bit being even parity for all 16 bits. Without seeing a different device code we couldn't really know that and it wouldn't matter for generating the signal.

Well if the polycom documentation says that the code is 0x0F would that be the same as the 0xF That jarmstrong has above? And although I understand Hex to a certain degree What exactly is the 0x part and how are you so sure that it is 11001010? And my last question is the toggle bit/parity bit a checksum? Simply the addition of all the 1's in the binary string?

0x means the following digits are in hex (base 16) rather than decimal.

0x0F is the same number as 0xF. Documentation would represent that as 0x0F rather than 0xF to highlight the fact that there are more than 4 bits in the binary form of the command number (I'm guessing there are 6 bits in this protocol).

Jon decoded the 16 bits of each of those signals from the samples at Premise. The first eight bits were 11001010 in each case. Those might represent a device number to distinguish commands meant for this device from commands meant for some other device using the same protocol, but since we don't know of any other device using the same protocol, that theory is hard to check. We don't really need to know what the first eight bits are for, just that they're there.

The parity bit is just a form of checksum, so if some random glitch messes up one bit of the signal the receiver will know to ignore the bad command rather than thinking it is some other command.

The toggle bit is more serious. If I'm right, there are two forms of each command and the receiver is designed to never believe the same form of the same command twice in a row. That's a big problem for using learned signals. There are a few possible work arounds, but first you should confirm (as I described above) that the orriginal remote really does alternate between two versions of each command.

Hi John. Sorry some of it was through e-mail if you want I can forward them to you, but not much there except that the guy said he added a code. He must have seen me discuss before videoconferencing /or saw it in my profile and asked me to help, but since I have only dealt with Pronto and Tandberg equipment (that I consider much better by the way) I could not be much help. He ended up using a unused code to fix the problem.

Yes, I use parity and toggle interchangeably. But I think I prefer parity, since toggle code and toggle bit sound too much the same and are totally different concepts and might (actually have in the past) lead to confusion.

Zane emailed me the document from Polycom last night that had 64 commands (including 31 that were labeled "IDLE_MSG" that apparently means an unused command.) Here are the ones that apparently do something:

RM_VOL_DOWN 0x03
RM_VOL_UP 0x04
RM_MUTE 0x05
RM_NINE 0x06
RM_EIGHT 0x07
RM_SEVEN 0x08
RM_SIX 0x09
RM_FIVE 0x0A
RM_FOUR 0x0B
RM_THREE 0x0C
RM_TWO 0x0D
RM_ONE 0x0E
RM_ZERO 0x0F
RM_AUTO 0x26
RM_PUT_DOWN 0x27
RM_PICKED_UP_LOW_BATTERY 0x28
RM_PICKED_UP 0x29
RM_SNAPSHOT 0x2A
RM_INFO 0x2B
RM_MENU 0x2C
RM_SLIDES 0x2D
RM_REMOTE 0x2E
RM_LOCAL 0x30
RM_ZOOM_DOWN 0x31
RM_ZOOM_UP 0x32
RM_POUND 0x33
RM_STAR 0x34
RM_RIGHT 0x35
RM_LEFT 0x36
RM_SELECT 0x38
RM_DOWN 0x39
RM_UP 0x3A
RM_CALLHU 0x3C


Yesterday, John suspected that those hex values were for a 6-bit data field and since 111111 binary is 0x3F or decimal 63 and that is undoubtedly correct. Lets focus on the values for Numerals 1 and 2 (rearranged as John has suggested):

From Premise Systems website:

0xE 110010 10 001110 10
0xD 110010 10 001101 10

My Original decode of Zane's learned commands posted above:

0xE 110010 10 001110 01
0xD 110010 10 001101 01

The numeral commands that Zane emailed me:

0xE 110010 10 001110 01
0xD 110010 10 001101 10

I agree with John (and this would make a compelling argument) that the next to the last (starting from left to right) bit is a toggle bit and the last bit is a parity bit.

Further, the link that John posted above describes the classic symptoms of learning an IR command with a toggle bit --that the system doesn't recognize the second or greater SUCCESIVE command of the SAME key.

For example, if you LEARN numerals 1,2,3,4, and 5 and try to dial 555-1234 all it sees is 5-1234.

The only flaw in this theory is that the learned numerals (0 through 9)that Zane emailed me were the following:

0xF 110010 10 001111 11
0xE 110010 10 001110 01
0xD 110010 10 001101 10
0xC 110010 10 001100 11
0xB 110010 10 001011 10
0xA 110010 10 001010 11
0x9 110010 10 001001 11
0x9 110010 10 001001 11
0x7 110010 10 000111 10
0x6 110010 10 000110 11

With the exception of numeral 1 (0xE) all had a "toggle bit" of 1, where if you learned those commands in succession we would EXPECT them to alternate. In this case numerals 0,1, and 2 seem consistent with that expectation, but not 3 and up.

Especially troubling is that the numeral 8 command was the numeral 9 command that was apparently learned twice.

Zane, it is important that you learn the same command several times and post your Pronto hex. Is it possible that it only toggles with a repetition of the same key within a few mS.??

-Jon

This message was edited by jarmstrong on 09/30/03 11:40.

I learned the number 1 on the Keypad 4 times. The toggle bit seems like the explanation since the codes alternate.

---

1st learn
0000 006B 0000 0012 0065 0065 0016 0022 0016 0022 0022 002E 0022 002E 0016 0022 0022 002E 0016 0022 0022 002E 0022 002E 0022 002E 0016 0022 0016 0022 0016 0022 0022 002E 0022 002E 0016 0022 0016 091B

---

2nd learn
0000 006B 0000 0012 0065 0065 0016 0022 0016 0022 0022 002E 0022 002E 0016 0022 0022 002E 0016 0022 0022 002E 0022 002E 0022 002E 0016 0022 0016 0022 0016 0022 0022 002E 0016 0022 0022 002E 0016 091B

---

3rd learn
0000 006B 0000 0012 0065 0065 0016 0022 0016 0022 0022 002E 0022 002E 0016 0022 0022 002E 0016 0022 0022 002E 0022 002E 0022 002E 0016 0022 0016 0022 0016 0022 0022 002E 0022 002E 0016 0022 0016 091B

---

4th learn
0000 006B 0000 0012 0065 0065 0016 0022 0016 0022 0022 002E 0022 002E 0016 0022 0022 002E 0016 0022 0022 002E 0022 002E 0022 002E 0016 0022 0016 0022 0016 0022 0022 002E 0016 0022 0022 002E 0016 091B

so I guess the next question is has anyone been able to circumvent the toggle bit?

I just happen to have 2 factory remotes and as I alternate between remotes only the original works.

This message was edited by ZaneH on 09/30/03 12:15.