Help trying to fix a ZTE remote that flips the toggle...

[Noirfire]

I have a USA ZTE remote what the problem is with this remote I have it set to ‘toggle’ and the X value is 39. With the other X value that is fired out by the RCU is for one key is 167. If I change the X value for the remote in ‘Remote Master’ to 167 then only that one key (On Demend). If it’s set back to 39 then they all work apart from that one key has anyone seen this before?


More infomation on this issue; The ZERO button sends the same signal the whole time the button is pressed and it alternates the toggle with each press. The ON-DEMAND button sends the signal 3 times, then has a longer pause, then flips the toggle and sends it one more time. It will also alternate the toggle with each press. The ZERO button acts normally, the OD button does not.

[eferz]

I have a USA ZTE remote what the problem is with this remote I have it set to ‘toggle’ and the X value is 39. With the other X value that is fired out by the RCU is for one key is 167. If I change the X value for the remote in ‘Remote Master’ to 167 then only that one key (On Demend). If it’s set back to 39 then they all work apart from that one key has anyone seen this before?


More infomation on this issue; The ZERO button sends the same signal the whole time the button is pressed and it alternates the toggle with each press. The ON-DEMAND button sends the signal 3 times, then has a longer pause, then flips the toggle and sends it one more time. It will also alternate the toggle with each press. The ZERO button acts normally, the OD button does not.

It is difficult to give you appropriate advice without understanding the big picture. Unfortunately, you didn't give enough information. So, I had to find a ZTE set-top box to match and figure out what you're referring. Found a match to ZTE ZXV100 B700 and recorded the IR signals with the JP1 tools to create the respective files.

• ICT file: https://www.hifi-remote.com/forums/dload ... e_id=10427
• RMDU file: https://www.hifi-remote.com/forums/dload ... e_id=10428
• BIN files: https://www.hifi-remote.com/forums/dload ... e_id=10429

BIN file Instructions.

• Mac: http://support.slingbox.com/get/KB-1000223.html
• PC: http://support.slingbox.com/get/KB-1000218.html

Customization instructions:

• http://slingbox.wikia.com/wiki/How_to_c ... te_upgrade

Okay, so I am not positive if this is the exact issue with your box. But, the one I recorded seems to use Nokia32 protocol. And there's three options for the High X-bit; toggle, constant, or release. From looking at pattern of these learns, it uses a "toggle" since the bit rotates between each key press. Because you're getting a difference between 167 and 39, that means your toggle bit 128. To get a better understanding of how it works, I'll juxtapose these values for you in binary and decimal form below.

10100111b = 167d
00100111b = 039d
======== = ====
10000000b = 128d

So, as you see above the bit that represents 128 is being toggled on and off between key presses. Therefore the value for "X" should be 128 and the High X-bit value should be toggle.

[The Robman]

I moved this one out of the Slingbox forum into the General forum as it's really a protocol question rather than a Slingbox question.

I was helping Noirfire offline with this before he posted. All the buttons use the Nokia32 protocol and all of them act normally except the ON-DEMAND button. The other buttons send the same signal while the button is held and the toggle alternates with each button press.

The ON-DEMAND button (which uses the same OBC as the ZERO button) acts differently. It sends the normal signal 3 times, then it pauses briefly then it sends the signal one more time with the toggle flipped. The toggle also flips between each press.

I don't believe any of our versions of the Nokia32 executor handle this situation.

[eferz]

I was helping Noirfire offline with this before he posted. All the buttons use the Nokia32 protocol and all of them act normally except the ON-DEMAND button. The other buttons send the same signal while the button is held and the toggle alternates with each button press.

The ON-DEMAND button (which uses the same OBC as the ZERO button) acts differently. It sends the normal signal 3 times, then it pauses briefly then it sends the signal one more time with the toggle flipped. The toggle also flips between each press.

I don't believe any of our versions of the Nokia32 executor handle this situation.

Very interesting. What is the exact model of this particular ZTE set-top box anyways?

[Noirfire]

The full Remote details are as follows;
ZTE USA
Remote control - Titan
IPTV STB
Band Name - Cincinntai Bell
Model - ZXV10 B703V3B700V3 or Fioptics

I'll try the Files you provided above and see if they give me any joy with this issuse

[The Robman]

Here are the learns. The two numbered files are the general learns, the other two are experiment files where I asked him to re-learn the ZERO and ON-DEMAND buttons several times, using long and short button holds, so I could verify the signal structure.

https://www.hifi-remote.com/forums/dload ... e_id=10434

[eferz]

The ON-DEMAND button (which uses the same OBC as the ZERO button) acts differently. It sends the normal signal 3 times, then it pauses briefly then it sends the signal one more time with the toggle flipped. The toggle also flips between each press.

That sounds like the On-Demand command is using High X-bit as Release instead of Toggle or maybe a hybrid of the two.

Here are the learns. The two numbered files are the general learns, the other two are experiment files where I asked him to re-learn the ZERO and ON-DEMAND buttons several times, using long and short button holds, so I could verify the signal structure.

https://www.hifi-remote.com/forums/dload ... e_id=10434

Is it possible that the UEI learns have misinterpreted the decodes? I found a few relative profiles and in two cases the "OnDemand" signal was present, they both decoded to be functional with Nokia32, "X=128", "High X-bit=Toggle" and OBC 220. This also matches the ZTE ZXV100 IR profile posted earlier. Not that I would treat the LHD as gospel, but it would be awfully suspect for a backwater company, like ZTE, to go out of their way to fuss with the protocol for just one button.

The details are as follows;

• Remote control - Titan
• IPTV STB - ZTE USA Model - ZXV10 B703V3B700V3

So, is it my understanding that you are NOT using this with a Slingbox at all? Or, is this the remote that came with the set-top box? Anyways, I decided to merge the IR profiles; ZTE ZXV10 B700, B703, and B703V3 with the JP1 tools to create the respective files.

• ICT file: https://www.hifi-remote.com/forums/dload ... e_id=10435
• RMDU file: https://www.hifi-remote.com/forums/dload ... e_id=10438
• BIN files: https://www.hifi-remote.com/forums/dload ... e_id=10439

BIN file Instructions.

• Mac: http://support.slingbox.com/get/KB-1000223.html
• PC: http://support.slingbox.com/get/KB-1000218.html

Customization instructions:

• http://slingbox.wikia.com/wiki/How_to_c ... te_upgrade

[The Robman]

He is using it with a Slingbox

[The Robman]

Here are the learns. The two numbered files are the general learns, the other two are experiment files where I asked him to re-learn the ZERO and ON-DEMAND buttons several times, using long and short button holds, so I could verify the signal structure.

https://www.hifi-remote.com/forums/dload ... e_id=10434

Is it possible that the UEI learns have misinterpreted the decodes? I found a few relative profiles and in two cases the "OnDemand" signal was present, they both decoded to be functional with Nokia32, "X=128", "High X-bit=Toggle" and OBC 220. This also matches the ZTE ZXV100 IR profile posted earlier. Not that I would treat the LHD as gospel, but it would be awfully suspect for a backwater company, like ZTE, to go out of their way to fuss with the protocol for just one button.

I agree that it sounds weird, but take a look at the learns in the files above and see what you think. The ZERO button learns just like all the other buttons, with the same signal repeating all the time, whereas the ON-DEMAND button shows 3 similar signals, followed by a longer OFF time and then one more repeat signal with the toggle flipped.

The current executors don't allow for one button to be programmed differently to all the others, right?

[eferz]

I agree that it sounds weird, but take a look at the learns in the files above and see what you think. The ZERO button learns just like all the other buttons, with the same signal repeating all the time, whereas the ON-DEMAND button shows 3 similar signals, followed by a longer OFF time and then one more repeat signal with the toggle flipped.

The current executors don't allow for one button to be programmed differently to all the others, right?

Have you ever watched the movie Ratatouille? The main protagonist, Remy, in the beginning of the movie described how he's able to experience the smells and taste; the animators drew it in wonderful array of shapes and colors. However, there was a part in the movie where he was trying to teach his brother, Emil, how to taste of food the way he does. Emil starts to see it but doesn't quite observe it the same way and ended up lost in the explanation.

This how you and I differ. You see, in this scenario I'm Emil and you're Remy. While it is a pretty cool coincidence that our names start with the same letter of our analogous counterparts, like Emil, I just don't have the skill to see the same thing you do in signal interpretation, protocol knowledge, or executor creation.

I didn't even know there were more than the signals which appeared in RMIR Learned Signals tab. But, being resourceful I did figure out it was possible to copy and paste the data in the durations box into IR Scope's Import... Timing List with 35874Hz. Then I started to notice a pattern. And if I broke that pattern up, and imported them separately into IR Scope, I was able to see there were multiple signals. This is from Learn Signal #2 from Zero_key.ir file

Durations:
+416 -278 +166 -280 +166 -612 +166 -280 +166 -446 +166 -612 +166 -612 +166 -280 +166 -280 +166 -612 +166 -612 +166 -446 +166 -780 +166 -280 +166 -280 +166 -280 +166 -280 +166 -90532 +416 -278 +166 -280 +166 -612 +166 -280 +166 -446 +166 -612 +166 -612 +166 -280 +166 -280 +166 -612 +166 -612 +166 -446 +166 -780 +166 -280 +166 -280 +166 -280 +166 -280 +166 -90532

1. Nokia 32, Device 33.160, OBC 0, X=167
2. Noika 32, Device 33.160, OBC 0, X=167

From Learn #12 from the OnDemand_key.ir, I saw there was actually five separate signals in the one learn.

Durations:
+416 -278 +166 -280 +166 -612 +166 -280 +166 -446 +166 -612 +166 -612 +166 -280 +166 -280 +166 -612 +166 -612 +166 -446 +166 -780 +166 -280 +166 -280 +166 -280 +166 -280 +166 -90536 +416 -278 +166 -280 +166 -612 +166 -280 +166 -446 +166 -612 +166 -612 +166 -280 +166 -280 +166 -612 +166 -612 +166 -446 +166 -780 +166 -280 +166 -280 +166 -280 +166 -280 +166 -90536 +416 -278 +166 -280 +166 -612 +166 -280 +166 -446 +166 -612 +166 -612 +166 -280 +166 -280 +166 -612 +166 -612 +166 -446 +166 -780 +166 -280 +166 -280 +166 -280 +166 -280 +166 -130904 +416 -278 +166 -280 +166 -612 +166 -280 +166 -446 +166 -612 +166 -612 +166 -280 +166 -280 +166 -280 +166 -612 +166 -446 +166 -780 +166 -280 +166 -280 +166 -280 +166 -280 +166 -90536 +416 -278 +166 -280 +166 -612 +166 -280 +166 -446 +166 -612 +166 -612 +166 -280 +166 -280 +166 -280 +166 -612 +166 -446 +166 -130904

1. Nokia 32, Device 33.160, OBC 0, X=167
2. Nokia 32, Device 33.160, OBC 0, X=167
3. Nokia 32, Device 33.160, OBC 0, X=167
4. Noika 32, Device 33.160, OBC 0, X=39
5. <unknown>

So, I am curious if that little piece of <unknown> signal is actually triggering the OnDemand menu. Would it be possible to edit or add just that part into RMIR as a learned signal to see if it does bring up the the OnDemand menu by itself?

[3FG]

earl,
Signal 5 is identical to signal 4, except it has been truncated about 2/3 of the way through. We often see partial IR signals in the last part of a learn, so I doubt that signal 5 means anything.

I suppose this signal could be sent as a macro, if Slingbox does those.

[eferz]

Signal 5 is identical to signal 4, except it has been truncated about 2/3 of the way through. We often see partial IR signals in the last part of a learn, so I doubt that signal 5 means anything.

The odd thing is if you check the aforementioned file it is consistently the same truncated signal on every one of the learns. If it wasn't intended to be a part of the command and was abruptly cutoff then wouldn't it be different in at least one of the other twelve learns?

I suppose this signal could be sent as a macro, if Slingbox does those.

I don't believe it does. Heck, I can't even get it to use any of the commands from the "Shift" column in the Buttons tab of RM.

[3FG]

Just talking through my hat here, but all of the signals short, medium, and long have the same number of burst pairs. Maybe this is a length limitation in the learning remote?

[eferz]

Just talking through my hat here, but all of the signals short, medium, and long have the same number of burst pairs. Maybe this is a length limitation in the learning remote?

Sounds reasonable to me.

So, as you see above the bit that represents 128 is being toggled on and off between key presses. Therefore the value for "X" should be 128 and the High X-bit value should be toggle.

Okay, I have to apologize for my insolence. As apparently, I've remembered this part incorrectly. According to Vicky in this thread (https://www.hifi-remote.com/forums/viewt ... 9119#p99119), the X should be the lower number of the two not the difference. It is supposed to be 39 not 128 as I've suggested. So, I'm going to have to go back and fix the bin and RMDU files for both ZTE upgrades. However, from playing around with options for X and Hi-bit value, I noticed that it didn't make a difference whether or not it was set to either 39 or 167. While the High X-bit option is set to "Toggle", IR Scope demonstrated the appropriate values alternated whether either number was used.

Now, here's the interesting thing, IR Scope did not register a difference between the Constant and Release. It always showed me copies with the same X value which was in the protocol of the device upgrade. I would have had at least expected it to give me two separate learns when using Release; multiple copies with a specific X value while it was being held down then a single learn with difference when released. However, this was never the case and neither Constant nor Release showed any difference.

[Noirfire]

Thanks guys for the help I think I need to do some more reading on the how the code base for the remote signaling works. I never would have worked this out by myself I'm feeling slightly in over my head, but I will read and try and catch up...