RMIR download from jp1/usb remote problem

Post by **ElizabethD** » Sat Apr 09, 2011 12:30 pm

Download worked.
Thanks 3fg

I need to examine why the downloaded data saved in RMIR as .IR is different than the same remote downloaded by parallel cable in IR.
It could be something as small as different sequences of devices. I have to be out of the house for couple hours but will check more later. And if the differences are real I'll post the files.

Post by **ElizabethD** » Sat Apr 09, 2011 6:10 pm

Does the sequence of keymoves and protocols matter when the remote checksum is calculated in RMIR and IR?

Post by **ElizabethD** » Sat Apr 09, 2011 9:51 pm

In the RMIR error log is a line about detecting first 10 bytes. Checksum, signature and the other bytes match the remote. Visual inspection tells me the download was ok.

It could be that RMIR rearranging and moving things around caused the checksum to change. I'll try downloading parallel way tomorrow rather than comparing to what IR does.

3FG · Post by **3FG** » Sun Apr 10, 2011 12:03 am

Liz,
I think that RMIR always reads the first 10 bytes from the remote, tries to extract the signature, and if multiple matching RDFs are found, asks the user which remote is being downloaded from. It does this before the main download of data.

That's true for any kind of interface. It does not indicate an error, IMO.

Post by **ElizabethD** » Sun Apr 10, 2011 11:10 am

Testing interface: JP1 USB
Interface matched. Trying to open remote.
Opened
Interface opened successfully
Base address = $0
Read first 10 bytes: 6D 92 43 50 54 30 43 50 78 31
Searching for RDF
Final signature sought = CPT0CPx1
Remote identified as: URC-8910(Old) Extender 1
Number of bytes read = $800
Ending normal download

Testing interface: JP1 Parallel
Interface matched. Trying to open remote.
Opened
Interface opened successfully
Base address = $0
Read first 10 bytes: 6D 92 43 50 54 30 43 50 78 31
Searching for RDF
Final signature sought = CPT0CPx1
Remote identified as: URC-8910(Old) Extender 1
Number of bytes read = $800
Ending normal download

Checksum read in, 6D 92 above, matches what IR sees, but does not match what RawData in RMIR shows. Must be due to rearranging of keymoves and protocols, both of which did occur, what else could it be.

Start of RMIR file
0000=2F D0 43 50 54 30 43 50 78 31 07 EA 17 EC 60 00

Start of IR file
0000: 6D 92 43 50 54 30 43 50 78 31 07 EA 17 EC 60 00

Bottom line, 3fg, the remote is detected and download does work. I think the checksum thing is an RMIR feature but that can be answered by Graham and Greg.

Post by **mathdon** » Sun Apr 10, 2011 11:56 am

Liz, could you post both the RMIR and IR files, please? Rearranging should not alter the checksum, but RMIR interprets the data and re-creates the binary data from its interpretation, which IR does not do. This can cause changes that are innocuous but which do affect the checksum. I would be interested to check if this is what has happened.

Post by **ElizabethD** » Sun Apr 10, 2011 12:39 pm

Hello Graham,
Thanks for stopping by

I named the files indicating which program downloaded or saved a file, I hope it'll make sense. I included .err files which are enormous.
https://www.hifi-remote.com/forums/dload ... le_id=9594

Could we get some indicator that the download is happening? It was slower than I normally see, and I almost killed the run in ProcessExplorer thinking I was crashed.

Post by **ElizabethD** » Sun Apr 10, 2011 2:21 pm

Not sure if to post it here or start a new thread.
RMIR, running as admin,
CAN open .IR files saved by RMIR or IR
CAN open two .rmir files from 2008
CANNOT open .rmir file from yesterday (in the zip file, link above)
So I posted error log, in case it's somehow related to what we're discussing
https://www.hifi-remote.com/forums/dload ... le_id=9595

Post by **mathdon** » Tue Apr 12, 2011 5:42 am

ElizabethD wrote:Checksum read in, 6D 92 above, matches what IR sees, but does not match what RawData in RMIR shows. Must be due to rearranging of keymoves and protocols, both of which did occur, what else could it be.

Start of RMIR file
0000=2F D0 43 50 54 30 43 50 78 31 07 EA 17 EC 60 00

Start of IR file
0000: 6D 92 43 50 54 30 43 50 78 31 07 EA 17 EC 60 00

mathdon wrote:Rearranging should not alter the checksum

My absence from the forums seems to have addled my brain! When I wrote that, I forgot that rearranging upgrades will alter the pointer tables and so may change a checksum that includes these tables.

That is what is happening in your case, Liz. The only rearrangement that affects the checksum is that two protocol upgrades have exchanged their positions, resulting in one table entry changing. The address at 03D7 is 02D6 in the IR download (which has a first checksum byte 6D) and is 0294 in the RMIR download (which has a first checksum byte 2F). The checksum is an XOR of all the bytes in its range, so the effect of this address change is to XOR the checksum byte with D6 and with 94. So the 6D of IR changes to

6D ^ D6 ^ 94 = 2F

which is indeed the checksum byte from RMIR. The second checksum byte is just the complement of the first.

I take your point that a download indicator is needed. I'll look into this if and when I get back to development, unless Greg has done it by then.

I can't open your .rmir files either, but I haven't yet looked into that.

Post by **mathdon** » Tue Apr 12, 2011 11:07 am

ElizabethD wrote:CANNOT open .rmir file from yesterday (in the zip file, link above)

The remote contained a device upgrade MISC/1107 for which the protocol had PID = 01F8, but there was no protocol (upgrade or otherwise) with this PID. This is an error situation for the remote, but it should not cause RMIR to crash. I've found and fixed the bug and will post an RMIR v2.02 Alpha shortly with the correction.

I've also fixed another bug that I've found - fixed data was not being used on a download to resolve ambiguity when there is more than one remote with the appropriate signature. I thought I had sorted this for v2.01 but it didn't work properly.

I'll look into putting a download indicator before I upload 2.02 Alpha.

Post by **ElizabethD** » Tue Apr 12, 2011 3:28 pm

Graham,
Thanks, I thought also that when things move, the pointers would change. Ergo - checksum change.
Yes I see the missing protocol. Belongs to an unused device.
I clearly got rid of many keymoves which used custom names here, and didn't clean up. IR doesn't care. This remote is a sandbox, and I don't even look closely at what's there

Post by **mathdon** » Sun Apr 17, 2011 4:24 pm

I have now posted RMIR v2.02 Alpha, as promised above. See this post for more details.

Post by **ElizabethD** » Thu Apr 21, 2011 11:26 am

Wonderful. I'll check it out.

Post by **ElizabethD** » Thu Apr 21, 2011 1:03 pm

Works fine, thank you Graham and Greg.
I can download, I can open a saved .rmir file, I saw the red Downloading and Uploading messages. I can upload .rmir file (something I've never tried before), read it back, and they match.

Question on protocols. There aren't any on the Protocols sheet, but I suppose it's one of those RMIR features. Anyway, on the Devices sheet, protocols have subscripts. I gather that it's nothing when built in, * when added, and - when missing. Is that correct?

Post by **mathdon** » Thu Apr 21, 2011 5:36 pm

ElizabethD wrote:Question on protocols. There aren't any on the Protocols sheet, but I suppose it's one of those RMIR features. Anyway, on the Devices sheet, protocols have subscripts. I gather that it's nothing when built in, * when added, and - when missing. Is that correct?

The Protocols sheet only shows protocol upgrades that are not being used by a device upgrade. Your interpretation of the suffixes on the protocol IDs is correct.