Russound CAV 6.6 "Whole House Audio"

[johnsfine]

RM has support for translating device parameters directly into the protocol code,

I was thinking about complicating this thread further by asking you to add that feature to RM. I didn't realize you already had. Is there a good example and/or documentation on how to use that?

Anyone have opinions on the details (see below) of using that for modulation frequency (which may be the most common reason to use it)?

For example, this protocol is provided by UEI with three different frequencies (controlled by two bits of fixed data). Do we assume they are correct that those are the only three frequencies anyone would want, and give the user a pull down with three choices? How hard will it be for me to make CodeTranslator translate back from the index of a pull down to the actual two byte value encoding each frequency? (I forget some of the details of RM pull downs).

That pull down would have the advantage of keeping our upgrade files more compatible between the remote (6131) that has UEI's version built-in and all the remotes that don't (let a user share an upgrade for one and another user switch it the the other).

But having the user directly type in any frequency he wants might be simpler.

What about having RM generically know how to override frequency when providing an upgrade protocol (it's the same in almost all cases)? That would make it even harder to correctly switch an upgrade for such protocols between a remote with a frequency selecting varient built-in and one with a smaller varient added. But the advantages may outweigh that complication.

[gfb107]

Is there a good example and/or documentation on how to use that?

The only protocol that currently uses it is the RCA Combo (w/Duration)

They work just like a DeviceTranslator or CmdTranslator, except that the target hex is the protocol code instead of the fixed data or cmd hex.
Of course, because the translation is likely to be different for different processors, there is a different one for each processor.

So, it is possible to use the standard Translator class to perform basic translation, or a custom translator can be written to handle more complex cases.

[The Robman]

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.

I'm not proposing that we discontinue supporting the UEI version (though if we come up with a full-featured version that uses less code, that would be great), I'm just talking about creating some stripped down versions for specific tasks, so that if a user has limited upgrade space (or has a remote that has an upgrade size limit) they have the option of using the stripped down version.

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.

The Slingbox doesn't work like regular remotes, even though there's tons of room in the EEPROM for upgrades, the format they've used limits the total size to 256 bytes anyway, but according to my UEI sources the actual limit for the total upgrade (ie, device and protocol upgrade together) is 200 bytes. I haven't verified this myself, but I did create an upgrade that used the full $0162 protocol and they confirmed that it doesn't load. I don't disagree with your "lame" assessment.

[johnsfine]

I slapped together a simple version of this protocol. I left out both the frequency option and the lead-out option.

I used a simple and direct approach to computing the check nibble and generating the signal. That results in MUCH less code than UEI's method.

Unfortunately, the simple method doesn't let me compensate for the slight timing difference between On and Off durations in the basic signal generation process. So the timing of this version is slightly off from the official. I'm nearly certain the actual device can't detect that slight variation. It could be done a little differently and compensate, I think about 6 bytes longer.

I tested this with CapturIr and it looked right (except for the slight timing difference) on the first try. Someone should test with an actual Russound or DirecTV device.

Anywhere here is the upgrade:

Upgrade protocol 0 = 01 62 (S3C80) DirecTV
40 84 11 8B 09 20 0B B8 02 4E 01 22 01 22 08 04
86 40 C0 28 CB 84 C1 C2 02 C2 06 CB 40 FB F1 90
CC 1C 12 F6 01 4C 38 03 48 04 5C 09 1C 14 90 C3
7B 02 1E 1E F6 01 4C 90 C3 FB 05 1C 16 F6 01 6D
76 C5 03 EB 04 38 C4 48 CC 5A E1 C6 F8 38 4A F6
01 58 C6 12 05 DC F6 01 0A 7B C6 AF
End

Commented source code is available.

[The Robman]

92 bytes, that's not too shabby (I'll take a look at the logic later to see what you're doing). I'm guessing that it uses the same fixed and variable data as the official version, so people can just overlay the official protocol to test it?

[johnsfine]

It ignores the three flag bits in fixed data, but otherwise uses the same.

[The Robman]

Oh yeah, I should point out that the version John posted is the 40 kHz version (which is what pasha needs), here are the other two...

1) 38.3 kHz - for DirecTV D10

Upgrade protocol 0 = 01 62 (S3C80) DirecTV
43 8A 11 8B 09 20 0B B8 02 4E 01 22 01 22 08 04
86 40 C0 28 CB 84 C1 C2 02 C2 06 CB 40 FB F1 90
CC 1C 12 F6 01 4C 38 03 48 04 5C 09 1C 14 90 C3
7B 02 1E 1E F6 01 4C 90 C3 FB 05 1C 16 F6 01 6D
76 C5 03 EB 04 38 C4 48 CC 5A E1 C6 F8 38 4A F6
01 58 C6 12 05 DC F6 01 0A 7B C6 AF
End

2) 56.7 kHz - Russound (the one in the CCF)

Upgrade protocol 0 = 01 62 (S3C80) DirecTV
2C 5D 11 8B 09 20 0B B8 02 4E 01 22 01 22 08 04
86 40 C0 28 CB 84 C1 C2 02 C2 06 CB 40 FB F1 90
CC 1C 12 F6 01 4C 38 03 48 04 5C 09 1C 14 90 C3
7B 02 1E 1E F6 01 4C 90 C3 FB 05 1C 16 F6 01 6D
76 C5 03 EB 04 38 C4 48 CC 5A E1 C6 F8 38 4A F6
01 58 C6 12 05 DC F6 01 0A 7B C6 AF
End

(I didn't check to see what lead-out times each device needs)

[The Robman]

I was thinking today about how best to support the different carrier frequencies, and one way could be to use the first 2 fixed bytes for this data.

[johnsfine]

I'll take a look at the logic later to see what you're doing

The commented source code at
https://www.hifi-remote.com/forums/dload ... le_id=2150
may help you follow it.

[The Robman]

Hey John, how does this command shift the date from RC0 into RC1?

Code: Select all

loop1:	MULT	RC0, 40		;Shift RC0 right two places into RC1

[johnsfine]

how does this command shift the date from RC0 into RC1?

Code: Select all

loop1:	MULT	RC0, 40		;Shift RC0 right two places into RC1

The MULT instruction takes two 8 bit inputs and multiplies them together to make a 16 bit value.

The first 8 bit input must come from an even numbered register. The 16 bit result is stored with its high half in that even numbered register and its low half in the following odd numbered register.

So we start with a value X in RC0 and multiply by two to the six power (0x40), getting a 16 bit result. That result is split into a high half (X*2**6)/2**8 and a low half (X*2**6) mode 2**8.

That is the same as shifting RC0 to the right two positions with the two bits that shifted out of the bottom of RC0 going into the top of RC1.

[The Robman]

I've been giving some thought to what the best way to support this executor might be and I have come up with a proposal.

In my opinion we are dealing with three seperate protocols here, granted they all have the same format, but they have different carrier frequencies. They're only joined together in one exec because UEI chose to implement them that way.

So, I suggest that we have three seperate entries in protocols.ini for them, which all use the same $0162 p-id. If the remote doesn't have $0162 pre-installed, we can offer John's scalled down version of the code (once somebody verifies that it works). It might also be a good idea to have an entry for the official version, just so that we can do experiments with it.

I suggest calling the 38khz version "DirecTV". The other two freqs both seem to be used by Russound, so I suggest "Russound 40khz" and "Russound 57khz" as their names.

Thoughts?

[johnsfine]

I disagree:

1) I want to make the protocol name in DecodeIr agree with the protocol name in RM.

2) I prefer to avoid having DecodeIr base a protocol name choice on frequency, since frequency is the least reliably available aspect of the signal in various IR capture environments. Sometimes there is no good choice other than basing the protocol name on frequency. But this time I think a single name for all these is better.

3) We have two choices of lead-out and three choices of frequency. The UEI executor supports all six combinations. I don't know how many of those six are in the real world. Do you? I REALLY don't want to base protocol name in DecodeIr on lead-out duration.

I guess DecodeIr should display the lead-out time, when available, in the misc section of the decode.

The documentation for this protocol in DecodeIr should tell the user to pay attention to frequency and lead-out. The help text for this protocol in protocols.ini should as well. I know it's more than some users will actually do, but the whole design of DecodeIr assumes the user should do the agregation of unreliable data (such as frequency) across all the learns from a single original result, to produce an answer more reliable than DecodeIr could get from one learn.

In RM, I don't have a strong opinion on:

A) Do we want an open edit field for frequency and lead-out to let the user put in whatever he wants, or do we want pull downs that offer just the choices we think match actual original remotes.

B) If we have an open edit field for frequency, do we want to make that a generic advanced freature of RM available whenever a protocol upgrade will (can) be provided, and/or do we want to specify it as a standard setup field for specific protocols such as this one.

I still haven't reviewed RM's translator capabilities to determing for either a pull down or an open edit field, whether we can compute and store the lead-out value with translators that exist now or whether we need a little new JAVA code.

If we pick an open edit field for frequency, I think it will be useful enough in other protocols that it should be new Java code, just to make things simpler for people writing protocols.ini entries, even if the existing translators could do it.

[The Robman]

I anticipated that you would disagree, but I was curious as to what grounds you would pick. You'll notice that I did suggest that in addition to the three variations that I specified, I also suggested that we also support the official version, so that people can (if needed) pick a combination that isn't already covered.

Given the difficulty that so many people have understanding how to use JP1 to program their remotes, I anticipate us having to give ALOT of support for this protocol if you chose to impliment it the way you suggest.

In my personal opinion, asking people to not only keep an eye on the frequency but also the lead out time is crazy, you're just asking for trouble. Again, in my personal opinion, that's DecodeIR's job.

I do agree that the names used by DecodeIR should match those used in RM, but the names are changeable in both right? Currently, when I learn the DirectTV signals, DecodeIR reports the protocol as Russound, so there's already a mis-match.

So, bottom line, please spell out the downsides to going with my suggestions?

[johnsfine]

In my personal opinion, asking people to not only keep an eye on the frequency but also the lead out time is crazy, you're just asking for trouble. Again, in my personal opinion, that's DecodeIR's job.

I'm sure I'd do a lot differently if I were defining the interface between IR.exe and DecodeIr from scratch with what I know now.

But given the way DecodeIr has developed I don't have any practical way to even move in the direction of having it merge information across multriple learns from the same original remote. We don't even have a way for the user to tell the GUI which learns were from the same original remote.

Frequency and lead-out are learned incorrectly too often to be a decent basis for decisions like this without merging data from multiple learns (remember I'm trying to support more than just UEI remotes as IR capture devices).

Think how confused the user gets when he has a mix of "DirecTv" and "Russound" decodes across the learns of one original remote. He won't know it's because the frequency was learned unreliably.

I do agree that the names used by DecodeIR should match those used in RM, but the names are changeable in both right? Currently, when I learn the DirectTV signals, DecodeIR reports the protocol as Russound, so there's already a mis-match.

I mentioned earlier in this thread, the names don't match and that should be fixed and changing DecodeIr seems the right way to fix it. I'm just waiting for the dust to settle on what to change it to. My point about names needing to agree was only meant to explain the seriousness of unreliable frequency capture, not to indicate I don't want to change DecodeIr.

So, bottom line, please spell out the downsides to going with my suggestions?

I missed how lead-out fits into your plan. That may expand the downsides. But pending that, I think the downside is a big increase in confusion for the environments where frequency capture is unreliable.

Also, there seem to be other Russound protocols not closely related to this one, so naming this protocol "Russound" did as much harm as good.

If the lead-out choice DOESN'T increase the number of real versions, then I'd be OK with giving them three entries and three names such as:
DirecTv 38Khz
DirecTv 40Khz
DirecTv 57Khz

Given all the brands that already use some other brand's protocol, it would add confusion to call some of the Russound protocols "DirecTv". DecodeIr could report the nearest of those three (and even factor in lead-out when available, assuming it factors in non combinatorially). When the user gets a set of those decodes that are all the same Khz there would be no confusion. When he gets a mix of 38Khz decodes and 40Khz decodes, it will be a lot easier (than if the names were also different) to explain to him that in the wrong decodes the EFC numbers are still right. Only the 38Khz or 40Khz is wrong and he just needs to pick the best fit of 38Khz or 40Khz for the whole device based on factors explained in the help files.