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

Post by **The Robman** » Fri Jan 27, 2012 11:19 am

Earl, when you need to take a deep dive into signals like this, I would recommend that you switch over to IR.exe as RMIR doesn't have the deep analysis tools built into it yet.

IR.exe has a tool that let's you round the timing data so it's consistent across all of the learns. This helps you use global edits to convert signals into binary.

Looking at the IRP definitition for Nokia32 on DecodeIR.html I see the burst times are 164,-276 | 164,-445 | 164,-614 | 164,-783. The difference between the 4 OFF times is 169 and if I subtract 169 from the first OFF time I get 107. This tells me that I can use 169 as the "RoundTo" value in IR.exe with 107 as the "Seed" value. This will distort the ON time (from 166 to 107, but that's ok).

Once the rounding data has been entered, I use the Times Summary button to see all the times at once and I cut & paste them to Notepad. For this test I pasted both the ZERO times and the ON-DEMAND times into Notepad.

Once all the rounded learn data is in Notepad, perform the following edits to convert it into binary:

+107 -276 = 00
+107 -445 = 01
+107 -614 = 10
+107 -783 = 11

Next, remove all the "Extra:" breaks and replace them with breaks between the long leadout times (ie, +107 -90522 or +107 -130913) and the leadin pairs (ie, +445 -276). The results should look like this file:

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

Looking at this file, you can clearly (I hope) see that the ZERO learns all show the same signal repeating for as long as the button is held, and the toggle bit alternates with each button press.

Looking at the ON-DEMAND data, you should see that most of them show the signal being repeated 3 times with the 3rd repeat having a longer leadout time. Then the repeats continue with the toggle flipped. Most learns only show 1 more repeat after the toggle flip followed by an incomplete signal. This is due to the limitation in how much data the remote can learn. In all of the partial learns you can see that the toggle is still set the same way as the preceding learn. The exception here is the first learn, which shows 2 repeats, then a toggle flip, then 2 more repeats. I believe for this learn, the user was slow in getting the JP1 remote into learn mode and they missed the first repeat. This does show that the repeats do continue after the toggle flip though. My guess is that if you were to capture the OEM remote using IRScope, you would see 3 repeats, toggle flip, 3 more repeats, toggle flip, 3 more repeats, etc, etc.

Regardless of where the toggle ended up with all those repeats, the next button press will start with the toggle flipped compared to how the previous press started.

eferz · Post by **eferz** » Fri Jan 27, 2012 11:25 pm

Noirfire wrote: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...

Have you at least tried v1.1 of my aforementioned files? I've recently updated them to fix the X value error. I'm still curious whether or not OBC# 220 as listed from the LHD is also able to trigger the OnDemand command.

The Robman wrote:Earl, when you need to take a deep dive into signals like this, I would recommend that you switch over to IR.exe as RMIR doesn't have the deep analysis tools built into it yet.

IR.exe has a tool that let's you round the timing data so it's consistent across all of the learns. This helps you use global edits to convert signals into binary.

Awesome. It took me a little to absorb your tutorial but after a few dozen tries it finally sunk in. There just was a few things that road blocked me, like "Advance > Force Learned Timings" wasn't enabled by default, so I didn't know where the "Round to:" or "Seed" options were. Then it took me a bit to realize the "OFF" times you referred to were -276, -445, -614, and -783 and that's where you got the difference of 169 and you subtracted it from 276 to get 107. Because my math wants to add when subtracting from negative numbers. I then had to go back to figure out why those particular values were substituted. And that's my fault for not understanding IRP as well. But, I was able to finally grasp on how you saw those values.

The funny thing is, I was able to see that the different signals started with the +419 -278 pair and the toggle bit was in the 10th pair without using the binary substitution. I just didn't understand what the numbers represented. Now that I have the secret decoder ring it does make a little more sense.

From your file:
+445 -276 00100001 10100000 10100111 00000000 +107 -90522

00100001b = 33d which is the device.
10100000b = 160d which is the sub-device
10100111b = 128d + 39d = 167d which is the high X value.
00100111b = 39d which is the low X value
10000000b = 128d the left most bit alternates between 1 and 0, so it is the toggle bit even though it is encapsulated in one timing pair
00000000b = 0d would be the OBC code.

And in the original duration timings it would be color coded this way:
+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

So, now that I have that ironed out. Isn't it also possible that OBC# 220 could trigger the OnDemand command without the using the "secret handshake" or "fancy knock on the door" with OBC# 0? I've seen quite a few devices promiscuously respond do different protocols, so isn't it within reason to at least check to see if OBC #220 might do the same thing?

P.s., okay I had a question what "Break:" meant from your file. I figured "Extra:" was an arbitrary notation when IR doesn't fully understand how to break down the signal and it evaluates it as some sort of "run off" but I'm not sure what "Break:" represented from your manipulation.

Post by **The Robman** » Sat Jan 28, 2012 3:50 pm

eferz wrote:P.s., okay I had a question what "Break:" meant from your file. I figured "Extra:" was an arbitrary notation when IR doesn't fully understand how to break down the signal and it evaluates it as some sort of "run off" but I'm not sure what "Break:" represented from your manipulation.

When IR.exe decodes the signals, it uses the terms "Once", "Repeat" and "Extra" as the UEI learning structure supports those three concepts. Usually when I manually manipulate a file the way I just described to you, I just cut & paste one of the "Extra" breaks between the leadout and leadin pairs to make each repetition of the signal start on a new line, but I figured if I did that in the file that I showed you, you would ask how did I make IR.exe do that (which of course, I didn't) so I changed it to the word "Break", which I described above as 'Next, remove all the "Extra:" breaks and replace them with breaks between the long leadout times and the leadin pairs'.

eferz · Post by **eferz** » Sat Jan 28, 2012 4:46 pm

The Robman wrote:When IR.exe decodes the signals, it uses the terms "Once", "Repeat" and "Extra" as the UEI learning structure supports those three concepts. Usually when I manually manipulate a file the way I just described to you, I just cut & paste one of the "Extra" breaks between the leadout and leadin pairs to make each repetition of the signal start on a new line, but I figured if I did that in the file that I showed you, you would ask how did I make IR.exe do that (which of course, I didn't) so I changed it to the word "Break", which I described above as 'Next, remove all the "Extra:" breaks and replace them with breaks between the long leadout times and the leadin pairs'.

Ah, okay. That makes sense. I just wanted to make sure that there wasn't some other meaning to it, like this signal is invalidated and not sent because there is a break in it or something like that.

Noirfire · Post by **Noirfire** » Mon Jan 30, 2012 5:08 am

Have you at least tried v1.1 of my aforementioned files? I've recently updated them to fix the X value error. I'm still curious whether or not OBC# 220 as listed from the LHD is also able to trigger the OnDemand command.

Hi efez,
yeah I've tried that this morning it has the same reaction from the STB as the oringal files, where it looks as if the zero key is being pressed.

So unfortunately the same problem still exists...

eferz · Post by **eferz** » Mon Jan 30, 2012 5:30 am

Noirfire wrote: Hi efez,
yeah I've tried that this morning it has the same reaction from the STB as the oringal files, where it looks as if the zero key is being pressed.

So unfortunately the same problem still exists...

Wait a second. Which original files; yours or mine? My original files shouldn't have worked at all because the X value was all wrong. Are you definitely, sure that OBC #220 is reacting like OBC# 0? OnDemand on my files are bound to "Setup".

Noirfire · Post by **Noirfire** » Mon Jan 30, 2012 5:47 am

Wait a second. Which original files; yours or mine? My original files shouldn't have worked at all because the X value was all wrong. Are you definitely, sure that OBC #220 is reacting like OBC# 0? OnDemand on my files are bound to "Setup".

Sorry just to be clear I was referring to my original files. Yes I'm sure I moved the Ondemand key from setup to F4 so it would align with the custom skin and remain on the Ondemand Key.

Just to be sure I double checked the files and reconfigured it once more, the correct file was there and still the same problem after I reconfigured it.

eferz · Post by **eferz** » Mon Jan 30, 2012 6:03 am

Noirfire wrote:
Wait a second. Which original files; yours or mine? My original files shouldn't have worked at all because the X value was all wrong. Are you definitely, sure that OBC #220 is reacting like OBC# 0? OnDemand on my files are bound to "Setup".
Sorry just to be clear I was referring to my original files. Yes I'm sure I moved the Ondemand key from setup to F4 so it would align with the custom skin and remain on the Ondemand Key.

Just to be sure I double checked the files and reconfigured it once more, the correct file was there and still the same problem after I reconfigured it.

And did you make sure to reset the Slingbox's input before loading a new one? There have been times where the upload doesn't actually occur if the files headers match. Something I'd like for you to try is place the function of OBC# 220 in several places on the same upgrade. This will allow you to verify the new upgrade is taking and also you can verify the same results are happening for each button you've assigned it.

The problem is, if we cannot find an alternate method of using a plain OBC to bring up the OnDemand menu. Then you probably won't be able to have a button to use it. Might have to manually navigate through the menu system of the receiver to bring that function up.

My only other suggestion would be to load up a configuration with all the unused OBCs from 0-255 then test each one of them until (hopefully) you find the one that will bring the OnDemand button.

Noirfire · Post by **Noirfire** » Mon Jan 30, 2012 6:11 am

And did you make sure to reset the Slingbox's input before loading a new one?

When you say reset the input do you mean going through the configuration of the input once again with the new Bin in the SBAV file?

eferz · Post by **eferz** » Mon Jan 30, 2012 6:38 am

Noirfire wrote:
And did you make sure to reset the Slingbox's input before loading a new one?
When you say reset the input do you mean going through the configuration of the input once again with the new Bin in the SBAV file?

See the reset link above? That's what I'm talking about. Make sure to reset it before you upload a new file. And to make sure the new file is taking by placing the same command in several spots. We just want to have a solid confirmation that the new files are taking. I guess the other way to check is to use your JP1 learning remote to capture the commands.

Noirfire · Post by **Noirfire** » Mon Jan 30, 2012 7:02 am

See the reset link above? That's what I'm talking about. Make sure to reset it before you upload a new file. And to make sure the new file is taking by placing the same command in several spots. We just want to have a solid confirmation that the new files are taking. I guess the other way to check is to use your JP1 learning remote to capture the commands.

ooh Ok sure I can reset it using slingplayer 2.0 I don't use that but I have it I'll use it to reset and then reconfigure. Unfortunately I can't test with the capture remote as the STB is in the US and I'm in the UK.[/quote]

Noirfire · Post by **Noirfire** » Mon Jan 30, 2012 8:30 am

Ah hah right that was a bit strange I reset and retried the same file it still didn't work. So I did what you suggested and tried on other key Nub 0-9 they all work the Ondemand menu appeared. Scratching my head at this point I tried the ondemand key agian and Nothing happen at all....

Confused at this point I decided to start again built the RMDU file again and the exported the bin.

Now it works!

I'm not sure why it wasn't working the first few times I tried it but its all working now which is great.

I would just like to thank you all for your help on this issues it's much appreciated!

working file;

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

Thanks Phil

eferz · Post by **eferz** » Mon Jan 30, 2012 8:41 am

Noirfire wrote:Ah hah right that was a bit strange I reset and retried the same file it still didn't work. So I did what you suggested and tried on other key Nub 0-9 they all work the Ondemand menu appeared. Scratching my head at this point I tried the ondemand key agian and Nothing happen at all....

Confused at this point I decided to start again built the RMDU file again and the exported the bin.

Now it works!

I'm not sure why it wasn't working the first few times I tried it but its all working now which is great.

I would just like to thank you all for your help on this issues it's much appreciated!

working file;

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

Thanks Phil

Awesome. I'm glad you got it worked out. Can you please also upload a copy of the working RMDU file too? I want to compare it and find out why mine didn't work when you uploaded it earlier.

Noirfire · Post by **Noirfire** » Mon Jan 30, 2012 8:53 am

Sure I have no idea why it does work they look essential the same to me. It was your file that I was using when I swap the Ondemand to the number keys and they worked fine just not the Ondemand key its self....

Link for the RMDU file Below;

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