View previous topic :: View next topic |
Author |
Message |
pasha
Joined: 30 Aug 2005 Posts: 26
|
Posted: Tue Aug 30, 2005 8:00 am Post subject: Russound CAV 6.6 "Whole House Audio" |
|
|
Please help with protocol upgrade for Russound remote
Pronto link (untested) rus-dis-cav66uno.zip
1. Device: Russound CAV 6.6
2. Type of device: Whole House Audio
3. JP1 Remote model: URC-8811
4. JP1 user? Yes
5. Still have original remote? Yes
6. Checked the file section? Yes
7. Checked Pronto file section (at R/C)? Yes (untested link posted)
8. Partially working setup code? No
9. Learning remote question? few learned codes attached.
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=2142 |
|
Back to top |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Tue Aug 30, 2005 8:47 am Post subject: |
|
|
I edited your post above so the URL to RemoteCentral doesn't make this whole thread too wide to read easily.
I checked and you are right that your learned signals match the corresponding one in that CCF.
I can't recall if anyone has built a Russound protocol executor for JP1 or found one UEI built.
Russound protocol has a four way bit structure, a nasty check nibble, and a changing lead-in that each make writing a protocol executor trickier than typical.
I could rediscover the things I've forgotten for solving those issues. But at the moment I don't have time. Usually when I say I don't have time to construct a Protocol executor, Rob jumps in and proves it was easier than I thought. Hopefully he will this time.
The best description I have of Russound is in my DecodeIr documentation:
http://john.fine.home.comcast.net/ir/DecodeIr.html#Russound |
|
Back to top |
|
|
Capn Trips Expert
Joined: 03 Oct 2003 Posts: 3990
|
Posted: Tue Aug 30, 2005 9:03 am Post subject: |
|
|
johnsfine wrote: | I can't recall if anyone has built a Russound protocol executor for JP1 or found one UEI built. | Try looking in THIS THREAD wherein Rob created a Russound protocol and device upgrade. _________________ Beginners - Read this thread first
READ BEFORE POSTING or your post will be DELETED!
Remotes: OFA XSight Touch, AR XSight Touch
TVs: LG 65" Smart LED TV; Samsung QN850BF Series - 8K UHD Neo QLED LCD TV
RCVR: Onkyo TX-SR875; Integra DTR 40.3
DVD/VCR: Pioneer DV-400VK (multi-region DVD), Sony BDP-S350 (Blu-ray), Toshiba HD-A3 (HD-DVD), Panasonic AG-W1 (Multi-system VCR);
Laserdisc: Pioneer CLD-D704.
Amazon Firestick
tape deck: Pioneer CT 1380WR (double cassette deck)
(But I still have to get up for my beer) |
|
Back to top |
|
|
pasha
Joined: 30 Aug 2005 Posts: 26
|
Posted: Tue Aug 30, 2005 9:04 am Post subject: |
|
|
I've seen that one... no it's not working for me.... |
|
Back to top |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Tue Aug 30, 2005 9:29 am Post subject: |
|
|
As I noted in that thread the signals there had some similarity to the protocol we previously identified as "Russound" but they weren't the same protocol.
The signals in this thread are exactly the protocol we had previously identified as Russound.
In that thread, Rob attacked the complex structure by breaking the signal into a larger number of smaller "bits" rather than making the executor understand the true bit structure of the protocol. That method tends to require much longer hex commands meaning more work either in setting up a manual upgrade in KM or in defining a protocols.ini entry for RM, plus a much larger resulting device upgrade. But that's usually better than waiting longer for someone to write a more complex executor.
I haven't totalled the details of this one, but I think the real bits would each require two, three or four smaller bits and the 4-bit check nibble would be added to that. So an 8 bit command might take as much as 4*(8+4) = 48 bits of hex command. An upgrade with 6 byte hex commands would be pretty ugly. Probably the distribution of bits makes the true worst cast a lot better, but even 4 or 5 bytes of hex command is quite ugly when 1 should be enough. |
|
Back to top |
|
|
pasha
Joined: 30 Aug 2005 Posts: 26
|
|
Back to top |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Tue Aug 30, 2005 1:47 pm Post subject: |
|
|
That documentation doesn't leave much doubt that internally the Russound remote is the same as a JP1 remote. And it has learning so it almost certainly has an eeprom.
Usually that would mean the Russound protocol would be included in the eeprom as a factory loaded upgrade. If that's the case then we can easily port it over to a form that KM and RM can make upgrades for your 8811.
Edit: I had assumed someone else already did the simple forum search to see if all this had been done before. So I didn't try that search myself until just now. It sure looks like all this work has already been done:
http://www.hifi-remote.com/forums/viewtopic.php?t=4988&highlight=russound |
|
Back to top |
|
|
pasha
Joined: 30 Aug 2005 Posts: 26
|
Posted: Tue Aug 30, 2005 2:32 pm Post subject: |
|
|
Thanks for the link.... However it looks like there is no protocol upgrades in it. |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21210 Location: Chicago, IL |
Posted: Tue Aug 30, 2005 2:51 pm Post subject: |
|
|
johnsfine wrote: | I checked and you are right that your learned signals match the corresponding one in that CCF. |
Except that the learned signals show 40 kHz and the ones in the CCF show 57.6 kHz.
johnsfine wrote: | In that thread, Rob attacked the complex structure by breaking the signal into a larger number of smaller "bits" rather than making the executor understand the true bit structure of the protocol. That method tends to require much longer hex commands meaning more work either in setting up a manual upgrade in KM or in defining a protocols.ini entry for RM, plus a much larger resulting device upgrade. But that's usually better than waiting longer for someone to write a more complex executor. |
I know what you're getting at and I would normally agre with you, except in that case even with the smaller bits, the signal was still just 7 bits total, and the executor was tiny. If I'd tried to write a 4-burst exec for it, I would still have had to use 1 byte per command and the exec would have been much larger.
In this case, however, I totally agree that this is a 4-burst protocol. I haven't looked at the learned signals, but the ones in the CCF decode quite straight forwardly using 4-bursts.
In Pronto hex...
lead-in (1st) = 0155 0044
lead in (rest) = 00AA 0044
lead out = 0022 06B9
0 pair = 0022 0022
1 pair = 0022 0044
2 pair = 0044 0022
3 pair = 0044 0044
There are eight 2-bit pairs where the first 3 pairs appear to be fixed, leaving 5 variable pairs. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
johnsfine Site Admin
Joined: 10 Aug 2003 Posts: 4766 Location: Bedford, MA |
Posted: Tue Aug 30, 2005 3:17 pm Post subject: |
|
|
I can't recall everything I deduced vs. guessed when I added this to DecodeIr. But the documentation I left from that process says there are two bursts of device number, then four bursts of function number then two bursts of check nibble. |
|
Back to top |
|
|
pasha
Joined: 30 Aug 2005 Posts: 26
|
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
|
Back to top |
|
|
pasha
Joined: 30 Aug 2005 Posts: 26
|
Posted: Tue Aug 30, 2005 4:42 pm Post subject: |
|
|
I'm getting message:
The selected protocol "PID 00 62" (0062) is not compatible with selected remote. This upgrade will NOT function correctly. Please choose a different protocol. |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
|
Back to top |
|
|
|