Moderator: Moderators
Vicky,vickyg2003 wrote:Give this a try and see if it works any better.
http://www.hifi-remote.com/forums/dload ... le_id=8859
which onesJohn S wrote:Vicky,
Okay, some solid progress to report.
Of the 29 functions in the original ccf file, 19 of them definitely work,
which one is that.1 definitely doesn't work
Okay if we understood this protocol better we might have been able to fill in the OBC's, but we never got to that point with this protocol, AND from my notes on the EMP710, the menu keys didn't have the same pattern as the other keys for that Epson. That is the first 6 and last 6 bytes are not static, they changed.Which brings me to another question. The comment listed with the ccf file posted at Remote Central says that the file is the "complete Epson remote" but I do not believe that to be the case.
So the question is: Is it possible to derive unknown function codes from the information we already have or am I foobarred? And if it is possible, how do I go about it?
If you do get those codes, one by one, rather than saving them into a spreadsheet, you should save them into an IR file. To do this, create a new IR file for a remote with lots of learning memory, like the URC-8820, then use the ADD button to create new learned signals by pasting in the pronto hex.vickyg2003 wrote:You should probably have a look at the EMP820. Its in a PCF file, which is an inconvenient form because you need to find the correct ProntoEditNG and then pull them out, key by key. But if you created a spreadsheet with all the pronto hex someone could look at it.
Rob, the Epson signals the EMp835 and the EMP710 create learns that hang up the remote if you try to send them. Can you use these from the IR file to create the binary anyway?The Robman wrote:If you do get those codes, one by one, rather than saving them into a spreadsheet, you should save them into an IR file. To do this, create a new IR file for a remote with lots of learning memory, like the URC-8820, then use the ADD button to create new learned signals by pasting in the pronto hex.vickyg2003 wrote:You should probably have a look at the EMP820. Its in a PCF file, which is an inconvenient form because you need to find the correct ProntoEditNG and then pull them out, key by key. But if you created a spreadsheet with all the pronto hex someone could look at it.
This is the "s-video" button in Pronto hex:vickyg2003 wrote:Rob, the Epson signals the EMp835 and the EMP710 create learns that hang up the remote if you try to send them. Can you use these from the IR file to create the binary anyway?
Instead of 6-8-6-6 (total 26) I decided to treat it as 4-8-8-8 (total 28). So why add the extra 2 bits? If you look at your code, when you're done sending the 6-8-6-6 stuff, you send the +550 -550 pair one more time as a primer for the leadout time. Well, that pair represents 2 zeroes, so instead of hard coding that send, I just added 2 zeroes to the overall signal.vickyg2003 wrote:However it looks like this is going to send out 32 pairs and our signal is 26 pairs. The 6bit fixed, 8 bit command, 6 bit command, 6 bit fixed
Why couldn't I see that! Yes that makes a lot of sense. I'm just not a math person! I guess this is why they wanted us to have all that math when studying programming. I wish I had paid more attention.The Robman wrote:Instead of 6-8-6-6 (total 26) I decided to treat it as 4-8-8-8 (total 28). So why add the extra 2 bits? If you look at your code, when you're done sending the 6-8-6-6 stuff, you send the +550 -550 pair one more time as a primer for the leadout time. Well, that pair represents 2 zeroes, so instead of hard coding that send, I just added 2 zeroes to the overall signal.
