366705 URC-7145 Evolve 4 R02
-
The Robman
- Site Owner
- Posts: 21940
- Joined: Fri Aug 01, 2003 9:37 am
- Location: Chicago, IL
- Contact:
Good news.
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
You misunderstand the raw dump, Rob. It does not give a suffix on the checksum. In an RDF this would correspond to the default of /4, but in the raw dump it means that the suffix cannot be determined from the data. If it can be determined then the raw dump will give explicitly either /2 or /4.The Robman wrote:I was wondering about the checksum as the older version of the remote uses the /2 checksum, but the raw dump showed /4 so I dismissed the thought.
Graham
-
The Robman
- Site Owner
- Posts: 21940
- Joined: Fri Aug 01, 2003 9:37 am
- Location: Chicago, IL
- Contact:
The first raw download that was posted had the /4 suffix on the checksum:
https://www.hifi-remote.com/forums/dload ... e_id=26300
I didn't notice that the macro file that was posted lacked a suffix, which I'm guessing is what you are looking at.
https://www.hifi-remote.com/forums/dload ... e_id=26300
I didn't notice that the macro file that was posted lacked a suffix, which I'm guessing is what you are looking at.
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Sorry, Rob, my mistake. Yes, I was looking at the macro file. I was not aware of the earlier one. My checksum-finding code in RMIR overlooks the possibility that the data length is an odd value. This can only happen for JP1.4, which this remote is. That first raw download has a data length of 0x67, which should have given an undetermined suffix. I will fix this in the next build, very soon now.
Graham