UEI Learning format change

Post by **mathdon** » Tue Oct 10, 2017 10:41 am

The Robman wrote:Also, when I was looking at the functions list in the rf_good.rmir file that vbs posted, I tried to widen the hex column so that I could see all 3 bytes but it wouldn't let me.

I can't reproduce this. I've just tried, and had no difficulty seeing all 4 hex bytes of his AV-Receiver upgrade. Here's a screenshot. I have narrowed the width of the window to see if that prevented all four bytes showing, but it didn't. So I don't know why you couldn't do it on your PC.

Edit: You do know that you have to widen the column header? You can't drag the column dividers on other table entries, only on the column header.

Post by **The Robman** » Tue Oct 10, 2017 11:43 am

I've done some testing, and everything looks fine Graham, I think it's time to release this puppy out into the wild!

Regarding the column width, I re-tested with the new version and get the same results. Yes, I am trying ti widen using the heading row, but no dice. It occurs to me that it could be because of the Java version, so I have taken some screen shots to show all my local versions.

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

Post by **mathdon** » Tue Oct 10, 2017 3:52 pm

I don't understand the column width issue. I still use Java 7 and I see you have Java 8, but it seems strange if Java 8 doesn't work as well as Java 7. I think it needs someone else with Java 8 to test this to see if that could be the cause of the issue.

Post by **vickyg2003** » Tue Oct 10, 2017 4:38 pm

I'm running 32-bit Java 1.8.144 on a Windows 7 64bit Operating system and I've had issues with the Onkyo Nec1-F16 Official upgrade not showing all the hex bytes too. It starts out showing 1 and a half bytes, and you can widen it to show 3 bytes and .. but there seems to be a cap on the maximum width.

Edit
I was on Windows Classic Look and feel. I clicked through all the other look and feels and when I found none of them helped, I went back to Windows Classic, and all 4 bytes were showing, although the font decreased in size. I then increased the font, and they were still all showing. I navigated away from the functions tab, and when I came back I couldn't get it to widen past 2.5 bytes. Played with look and feel some more, and can't get all 4 to pop back again unless I go to Look and Feel Numbers then back to Windows Classic or Windows......

Post by **The Robman** » Tue Oct 10, 2017 4:59 pm

Vicky, download this zip file and look at rf_good.rmir, go to the Devices tab and open up the Tuner/3266 code, then try to look at the hex code column on the Functions tab. This upgrade uses 4 bytes of hex for each button, but the most I can see is 2.5 bytes. For example, the power button's hex code is "81 7E AB 54" but all I can see is "81 7E A...".

Like Vicky, I'm also using Windows 7, whereas I think Graham is on 8 or 10.

I just tried adjusting the width on all the other tabs where you can do so, and it seems like they're all limited, the only one where I had complete freedom to make it as wide or as narrow as I liked was on the Layout tab.

I just tried switching between Look and Feels, of the 4 byte hex code, both of the Windows options give me 2.5 bytes, Metal gives me 3 bytes, Nimbus gives me 4 and CDE gives me 3.

Post by **vickyg2003** » Tue Oct 10, 2017 5:03 pm

I was editing my post when you posted. It seems to be related to Look and Feel. I can get it to go wider if I go to Look and Feel Numbers, then switch to Look and Feel Windows or Windows Classic. It does feel like there is a max width setting here.

Post by **The Robman** » Tue Oct 10, 2017 5:09 pm

I saw that and edited mine too to include Look and Feel.

Post by **mathdon** » Wed Oct 11, 2017 6:54 am

It seems to be only the hex column that is causing concern, so for the next build I've changed the "preferred width", as Java calls it, to show 4 hex bytes. Greg set it to 2 bytes when screen resolutions were smaller. It means there is white space when there is in fact only 1 or 2 hex bytes, but I don't think this should be an issue. Anyway, on my PC at least, I can shrink it from 4 to 2 if needed.

I've also put a display of the region and language for the XSight Touch/Color and Nevo remotes on the Raw Data panel.

Post by **vickyg2003** » Wed Oct 11, 2017 7:50 am

Looking over these last few posts, I see that what I was seeing as Numbers is actually Nimbus, lol.

mathdon wrote: It seems to be only the hex column that is causing concern, so for the next build I've changed the "preferred width", as Java calls it, to show 4 hex bytes. Greg set it to 2 bytes when screen resolutions were smaller. It means there is white space when there is in fact only 1 or 2 hex bytes, but I don't think this should be an issue. Anyway, on my PC at least, I can shrink it from 4 to 2 if needed.

Extra white space, is not going to be an issue, seeing the data is critical. I'm looking forward to the build.

I've also put a display of the region and language for the XSight Touch/Color and Nevo remotes on the Raw Data panel.

THANK YOU!!!!!! That will help me to do no harm!

Post by **The Robman** » Wed Oct 11, 2017 8:38 am

mathdon wrote:It seems to be only the hex column that is causing concern, so for the next build I've changed the "preferred width", as Java calls it, to show 4 hex bytes. Greg set it to 2 bytes when screen resolutions were smaller. It means there is white space when there is in fact only 1 or 2 hex bytes, but I don't think this should be an issue. Anyway, on my PC at least, I can shrink it from 4 to 2 if needed.

In my testing I found that I could shrink all of the columns to almost nothing, so starting off wide is not a problem. I think I will create a fake upgrade that uses 5 bytes just to see if the new 4-byte option can be widened if needed.

Here's the fake upgrade that uses 5 variable bytes, for testing:
https://www.hifi-remote.com/forums/dload ... e_id=14743

Post by **mathdon** » Wed Oct 11, 2017 10:56 am

Rob, on my PC that opens with all 5 bytes showing, and I can widen it so that it would show 6 and possibly 7 bytes. But that doesn't mean it will do so on yours, as we have seen. I wasn't intending another development build before a general release, but things are moving so fast that I have posted development build 8 of RMIR v2.05. See how it works for you.

Post by **vickyg2003** » Wed Oct 11, 2017 11:28 am

I tested the version. All 5 bytes showed up. It looks like it could show up to 6 bytes maybe 6 and 1/2 bytes before it is too small.

I also see that I did screw up Cloud's file when I created a German Language but N. America Region. Sheesh so much to know!

Post by **The Robman** » Wed Oct 11, 2017 1:59 pm

I tested it too, it can properly display upgrades with up to 7 variable bytes, with an 8-byte upgrade it just displays 6 and dots.

While I'd rather be able to make the column as wide as I need, this should be plenty good enough for any upgrades that we're likely to work with. I don't recall ever seeing one with more than 4 variable bytes before.

Post by **The Robman** » Thu Mar 15, 2018 3:54 pm

Hi Graham,
I recently decoded the learned signals for an Ocilion T220 IPTV stb which uses a bi-phase signal where RMIR couldn't properly decode all of the buttons. To decode this, I entered 330 in the Round To box and selected EVEN. Most buttons do decode properly, but some show the raw +660 and -660 times.

The thread for the STB is here:
https://www.hifi-remote.com/forums/viewt ... p?t=101179

The following zip file contains a bunch of text files which show how I manually manipulated the data to get to the binary. It also includes the original RMIR file which contains the learns. Any idea why I couldn't get all of the learns to decode?
https://www.hifi-remote.com/forums/dload ... e_id=25133

Note: some of the repeats are missing a few bursts at the beginning, but I think all but one of the buttons had all the bursts for at least the first string.

chuliu · Post by **chuliu** » Sat Mar 17, 2018 6:23 am

mathdon wrote:Rob, I have just uploaded build 4 to the usual RMIR Development folder. There are numerous changes from build 3, too many to mention in detail but they include: the cases with missing lead-in are now handled correctly; the semicolons following a lead-in should now be correct; there is a Save button that saves the summary as a .csv file; the Parity and Round To settings are now independent for the Raw and Analyzed displays. I think it is this last point that led you to say that Raw should really be Raw. A rounding setting in Analyzed was being applied also to Raw if you switched between these two displays.

Anyway, please try it. I think it addresses everything you raised except the Parity box. "Default" for uni-polar signals is the same as "Even", whether in the Raw display (where everything is uni-polar) or the Analyzed display (where signals that RMIR cannot interpret as bi-polar remain shown as uni-polar). "Default" for bi-polar signals is whichever parity RMIR found was needed to allow a bi-polar interpretation. That might vary between signals in the Analyzed display, especially if the learns cover more than one device. Changing the parity setting will rarely have any effect on bi-polar signals as very few such signals allow both an even and an odd parity analysis.

As the final example in my previous post shows, if you select Even in IR for a bi-polar signal that is really Odd, you get invalid burst pairs in which both values are + or both are -. In RMIR it leaves the signal unchanged, so it displays Odd when you select Even if there is no valid Even analysis. In some sense both behaviours are misleading, it is perhaps a personal preference which one would rather see.

Hi, just wanted to ask, are all the features for helping decoding phase encoding signal included in rmir 206?

I can't seem to find save as csv function for example.

Thanks.