|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Sat Apr 09, 2011 1:30 pm Post subject: |
|
|
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. _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
Back to top |
|
|
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Sat Apr 09, 2011 7:10 pm Post subject: |
|
|
Does the sequence of keymoves and protocols matter when the remote checksum is calculated in RMIR and IR? _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
Back to top |
|
|
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Sat Apr 09, 2011 10:51 pm Post subject: |
|
|
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. _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Sun Apr 10, 2011 1:03 am Post subject: |
|
|
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. |
|
Back to top |
|
|
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Sun Apr 10, 2011 12:10 pm Post subject: |
|
|
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. _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Sun Apr 10, 2011 12:56 pm Post subject: |
|
|
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. _________________ Graham |
|
Back to top |
|
|
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Sun Apr 10, 2011 1:39 pm Post subject: |
|
|
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.
http://www.hifi-remote.com/forums/dload.php?action=file&file_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. _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
Back to top |
|
|
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Sun Apr 10, 2011 3:21 pm Post subject: |
|
|
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
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=9595 _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Tue Apr 12, 2011 6:42 am Post subject: |
|
|
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. _________________ Graham |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Tue Apr 12, 2011 12:07 pm Post subject: |
|
|
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. _________________ Graham |
|
Back to top |
|
|
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Tue Apr 12, 2011 4:28 pm Post subject: |
|
|
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 _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Sun Apr 17, 2011 5:24 pm Post subject: |
|
|
I have now posted RMIR v2.02 Alpha, as promised above. See this post for more details. _________________ Graham |
|
Back to top |
|
|
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Thu Apr 21, 2011 12:26 pm Post subject: |
|
|
Wonderful. I'll check it out. _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
Back to top |
|
|
ElizabethD Advanced Member
Joined: 09 Feb 2004 Posts: 2348
|
Posted: Thu Apr 21, 2011 2:03 pm Post subject: |
|
|
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? _________________ Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Thu Apr 21, 2011 6:36 pm Post subject: |
|
|
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. _________________ Graham |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|