Cool! Thanks
From: Crestron@... [mailto:Crestron@...] On Behalf Of Neil Dorin
Sent: Saturday, April 21, 2012 11:26 AM
To: Crestron@...
Subject: Re: [Crestron] Re: CP3 Question
A CP2E as an eslave to an MC3 will behave normally. It's only the MC3's internal IR stack that is limited to a single UART
-Neil Dorin
On 2012-04-21, at 9:38 AM, "Jonny" <ComeAlive@... <mailto:ComeAlive%40thegablers.com> > wrote:
I have be thinking about this all week, as I am designing a large system.
So here is the thought, would a CP2E as an Ethernet slave fix this issue? I
haven't been able to get a real answer as to whether the IR output issue is
related to the physical IR section of the MC3 or if it is more in the core
operations of the MC3 and would affect any slave equipment that is defined
in the program running on the MC3.
From: Crestron@... <mailto:Crestron%40yahoogroups.com> [mailto:Crestron@... <mailto:Crestron%40yahoogroups.com> ] On Behalf
Of ChrisK
Sent: Sunday, April 15, 2012 11:55 PM
To: Crestron@... <mailto:Crestron%40yahoogroups.com>
Subject: [Crestron] Re: CP3 Question
It is disappointing, even understanding the original purpose.
As an aside to your example, I always set a 'turn-on' volume for every zone
(AVR, Pad8, sonnex, etc.) to eliminate the blow your head off issue.
A queue system could be created (Apparently Chap has one) that could be
stepped thru on the release of the previous IR/digital signal so even in
this scenario:
P+H Vol+, Press TV On, Press SRC select
The release of the Vol+ could trigger the ON, Release of the on could
trigger the SRC
You would have find a way to capture each digital in order and its pulse
length.
The real issue would be with P+H Volumes, especially if there were more than
one device being controlled by IR.
First, user experience would be erratic if one person was ramping and
another started it wouldn't start for the second right away.
Then, any delay in start of the Vol Ramp coupled with a puse length capture
for later release would likely be VERY BAD!!!
This is at its root a hardware issue, so unless/until Crestron comes out
with an MC3v2 I think it would be best to limit all commands to pulses with
a queue system.
This would suck for the customer to have to pulse Vol+/- to change the vol,
but much better than a runaway volume!!
BTW, why are ALL runaway volumes, Volume UP??? and never Volume DOWN???
The good news is that most devices that control volume can be controlled
via, serial, IP, etc.
.02223 cents
Chris K............;)
--- In Crestron@... <mailto:Crestron%40yahoogroups.com> <mailto:Crestron%40yahoogroups.com> , Jay
Basen <jay.m.basen@...> wrote:
Engineering may have designed the MC3 for a one-room/hospitality
installation but once sales and marketing got hold of the MC3 it became the
most powerful processor that Crestron had ever built. It was faster and had
more memory than a Rack2. It was capable of running one program for all your
A/V needs and you could even run a second program written in D3 to control
your lighting system. It is unfortunate that the limitation in IR hardware
is the only thing I have seen that separates the promise from reality.
I'm not sure that there is any way to truly program around the problem and
I'd be very thankful if someone could show me that I'm wrong. The issue as I
see it is that we can all carefully program our systems so IR commands
during system start up or shutdown are separated by enough time so they
don't collide. However, if, for example:
1) the teenage son was watching an action film the night before with the
volume cranked up
2) Mom turns on the system to watch the morning news
3) As soon as the sound starts she firmly plants her finger on the volume
down button and holds it there
4) The stream of volume down IR commands are now going to hammer any other
commands required to properly start up the system
Now the system is in a state without all the gear properly turned on and
potentially equipment not set to the proper inputs.
Of course you could block all other IR commands during the start up
sequence but that isn't a good solution either.
I'd love to know if there is a way to code around this scenario such that
the system would really be bulletproof. You could implement a queue, as was
suggested, but since we don't get feedback as to how long it takes for any
IR command to be completed by the hardware, the only way I see to implement
this is to empty the queue with a timer that allows the maximum amount of
time an IR command might need before sending the next one to the hardware. I
believe this would have problems with the scenario where someone is holding
down their finger on a volume button. The IR signals being sent out would
lag behind what was being queued and you would have significant over-run
where the volume moved beyond where the user wanted.
I know Crestron is aware of the problem. I'm hoping they can implement a
more intelligent queuing mechanism than we have the tools for. However, as I
said, I'd love for someone to tell me that there really is a bulletproof
solution we can implement ourselves.
Jay
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
