Russound CAV 6.6 "Whole House Audio"

johnsfine · Post by **johnsfine** » Tue Aug 30, 2005 4:24 pm

It is the same executor that is already in RM as DirecTV, pid 01 62.

So it would be better to use it as that.

After the raw import to get the basic assignments of EFC numbers to buttons, I'm not sure what is involved in switching over to DirecTV protocol but preserving those EFC numbers and preserving or restoring the fixed data.

Post by **The Robman** » Tue Aug 30, 2005 4:50 pm

I was able to import the upgrade OK using RM and created this RMDU file for it...
https://www.hifi-remote.com/forums/dload ... le_id=2146

I used the RDF for the Gateway TV, which has the same sig...
https://www.hifi-remote.com/forums/dload ... le_id=2147

johnsfine · Post by **johnsfine** » Tue Aug 30, 2005 4:56 pm

Since this protocol is called DirecTV in RM, should I rename it in DecodeIR (from "Russound" to "DirecTV") so we won't be confused this way next time?

gfb107 · Post by **gfb107** » Tue Aug 30, 2005 4:59 pm

There shouldn't be any issue with EFCs or fixed data when importing a raw upgrade in RM.

pasha · Post by **pasha** » Tue Aug 30, 2005 5:06 pm

WOW!!!
This works!

This is defenetly great help from all of you.

Thanks

-Pasha

Post by **The Robman** » Tue Aug 30, 2005 6:22 pm

I've been meaning to take a look at the $0162 exec for a while as it's such a big piece of code. It's too big to be loaded into the Slingbox, which has a 200 byte limit. So this thread has nugged me into reviewing it.

I've only just started looking, but right off the bat I can se that there's some code up front which handles a couple of different frequencies, which most people won't need, and I'm guessing that some of the rest of the code is there to handle the checksum. If the checksum code were eliminated, each function would need 2 bytes of data, so the question is, which would result in a smaller upgrade (device and protocol together).

johnsfine · Post by **johnsfine** » Tue Aug 30, 2005 6:31 pm

The Robman wrote:I've been meaning to take a look at the $0162 exec for a while as it's such a big piece of code. It's too big to be loaded into the Slingbox, which has a 200 byte limit.

I notice it has a lot of subroutine calls to other parts of itself. Those tend to be very costly in executor size for what they accomplish. Usually it is easy to join all the call point of a given subroutine into a loop so there is only one call point so you don't need it to be a subroutine.

Computing the check nibble shouldn't be very hard, but I haven't looked to see how hard they made it for themselves. I'm sure it can be done in few enough protocol bytes to typically save space vs. an upgrade with two byte hex cmds.

Post by **The Robman** » Tue Aug 30, 2005 7:58 pm

That's what I was thinking too. I recall the size of their original ReplayTV exec vs. yours. If you get a chance, could you take a look at this exec please? I'm sure you can do a nice job of cleaning it up.

johnsfine · Post by **johnsfine** » Wed Aug 31, 2005 6:12 am

How small do you need it?

There are a bunch of bytes of code that can be removed trivially, without changing the basic approach to creating the signal. Probably there is a better basic approach that I could find with a lot more effort. But then I might not find time to finish it.

Post by **The Robman** » Wed Aug 31, 2005 6:34 am

Well, the current exec code is 184 bytes and the maximum upgrade size for the Slingbox is 200 bytes, so that only leaves 16 bytes for everything else. Ideally, I'd like to see the code smaller by 50 bytes or so, but I'll take whatever I can get.

For starters, I figure that I can delete all that code that selects the carrier freq as each user just needs one freq. I haven't dug deep enough into the checksum and 4-burst code to see if I can reduce any of that yet.

johnsfine · Post by **johnsfine** » Wed Aug 31, 2005 6:57 am

The Robman wrote: For starters, I figure that I can delete all that code that selects the carrier freq as each user just needs one freq. I haven't dug deep enough into the checksum and 4-burst code to see if I can reduce any of that yet.

I have some misgivings about stripping out the options (frequency and ???). That would mean our executor wouldn't be fully compatible with upgrades based on UEI's. You're probably right that each user would want the options only one way, so RM could have several protocols.ini entries that hard code each option.

I didn't look up details to see what the option on bit 0 means. Bits 1 and 2 seem to select frequencies.

You can save the 4 bytes of call and return on the check nibble computation because it is only used once. You can save nearly half of the code within that computation by getting rid of the stupid table for looking up 1, 3, 5 and 7.

You can use 5 words instead of 8 for the table of bursts by taking advantage of the overlap, and in doing so you save a couple bytes of code in accessing that. I think a few more bytes can also be simplified out of that section.

The three calls, the return and the other overhead of invoking the routine that processes bit pairs looks excessive for what it does, but it isn't immediately obvious how to do the 2/4/2 sequence in a loop rather than as calls.

johnsfine · Post by **johnsfine** » Wed Aug 31, 2005 7:00 am

The Robman wrote:Well, the current exec code is 184 bytes and the maximum upgrade size for the Slingbox is 200 bytes, so that only leaves 16 bytes for everything else.

I haven't looked at all at how Slingbox upgrades work. Most models move the protocol upgrade and device upgrade into ram independently, so any limit would apply to each of them, rather than to their total. Is that different on the Slingbox? I hope you don't mean the total upgrade area in eeprom is just 200 bytes. That would be really lame.

pasha · Post by **pasha** » Wed Aug 31, 2005 7:03 am

seams like this protocol only works alone...
remote doesn't work with extender....

johnsfine · Post by **johnsfine** » Wed Aug 31, 2005 7:07 am

pasha wrote:seams like this protocol only works alone...
remote doesn't work with extender....

That doesn't sound likely.

You should upload (to diagnosis area) your .ir file with the extender and this upgrade and everything as it was when you tested to find that it doesn't work with extender. Maybe we'll spot some error. Also please clarify "doesn't work". With a specific description of actions and results we may be able to perform a comperable test ourself and/or explain what you're doing wrong.

gfb107 · Post by **gfb107** » Wed Aug 31, 2005 7:50 am

johnsfine wrote:You're probably right that each user would want the options only one way, so RM could have several protocols.ini entries that hard code each option.

RM has support for translating device parameters directly into the protocol code, so it might be possible to do that sort of thing with just one protocols.ini entry.

This is done using the CodeTranslator.<processor> value.