开云体育

Anyone familiar with the commands differences between the QDX6000 and the HDX9000.

Using the HDX TCPIP Module to control the QDX but quite a few of the commands dont really work, not been familiar with the units capabilities i am wondering what commands im leaving out.

All IR emulators work some of the others do as well.

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]

We should do that. Come up with a challenge and see who can solve it in the
least number of symbols. Everybody shares their solution, and we all can
learn little shortcuts and such from each other.

Yeah - I've been digging this! Nice work guys... :)

- Chip

Works a treat!

I've had excellent results with this one. Remembers which serial port you've assigned to it.

This has worked with everything I've plugged it into for several years - and without a driver on Windows XP/7 Pro.



Heath Volmer
Digital Domain Systems
(303) 517-9714

On Apr 21, 2012, at 1:15 PM, jfa_crestron wrote:

Can someone recommend which USB serial adaptor to purchase that will work with the CNXLIR Learner? I have a new HP desktop and can't find a 9 pin serial card that connects with this computer.

[Non-text portions of this message have been removed]

Sooooo....how could I convince you to send it my way ;) I'd be willing to port it over and share the results back

Thank you for participating in this week's "Can It Be Done In SIMPL"
challenge. Stay tuned for next week's challenge.

On Sat, Apr 21, 2012 at 12:12 PM, Kool-Aid Drinker <
crug@...> wrote:

Nice. I ended up using the same number of symbols for a basic version,
but saved a crap-ton on digital signals.

Four SUB$ also looks better in terms of when to send the checksum (if
you're into that whole automatic send thing). Currently, I'm sending
it 1 tick after the string arrives, having no easy way to tell when
processing is done. Adding SAW pulses to the outputs of the SUB$ would
let you determine the last character was processed.


On Sat, 21 Apr 2012 11:04:22 -0700, Eric Walters <sentry07@...>
wrote:

If you want less moving parts, 4 SUB$ in 2 pairs will break your string
into even and odd bytes. One SUB$ with parameters (1,1) goes into a STOA,
the other SUB$ with parameters (2,100) feed the other set of SUB$. So when
you get a string in, it hits one pair of SUB$. They push one byte into

your

logic, and the rest of the string to the other set. They push one byte

into

logic and the rest of the string back to the first two. I had gotten that
far and put in the ATODs, XORs, and DTOAs to do the XOR logic, but the

SUB$

were getting too much priority over the XOR logic and nothing was getting
calculated.

On Sat, Apr 21, 2012 at 6:45 AM, Kool-Aid Drinker <

crug@...

wrote:

Yup. It expects the string to be checksummmed to arrive whole, and
then deals however many bytes are in that serial signal.

Having the string arrive in pieces would require extra logic, but
should be do-able.

Basic idea is: SIO and INIT break the string into analog bytes, TOGGLE
and ABUFs sort them into even and odd, ATOD decomposes the bytes, XORs
do the deed, DFFs keeps the running total, DTOA, ATOS, blah blah blah.

On Sat, 21 Apr 2012 08:03:57 -0000, "Chip" <cfm@...> wrote:

Did that account for messages of varying lengths?

- Chip


--- In Crestron@..., Kool-Aid Drinker <crug@...> wrote:

Only took 51 symbols for a basic version of the checksum that started
the thread.

------------------------------------




Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in the
Database area.
Yahoo!
Groups Links

Can someone recommend which USB serial adaptor to purchase that will work with the CNXLIR Learner? I have a new HP desktop and can't find a 9 pin serial card that connects with this computer.

Nice. I ended up using the same number of symbols for a basic version,
but saved a crap-ton on digital signals.

Four SUB$ also looks better in terms of when to send the checksum (if
you're into that whole automatic send thing). Currently, I'm sending
it 1 tick after the string arrives, having no easy way to tell when
processing is done. Adding SAW pulses to the outputs of the SUB$ would
let you determine the last character was processed.


On Sat, 21 Apr 2012 11:04:22 -0700, Eric Walters <sentry07@...>
wrote:

If you want less moving parts, 4 SUB$ in 2 pairs will break your string
into even and odd bytes. One SUB$ with parameters (1,1) goes into a STOA,
the other SUB$ with parameters (2,100) feed the other set of SUB$. So when
you get a string in, it hits one pair of SUB$. They push one byte into your
logic, and the rest of the string to the other set. They push one byte into
logic and the rest of the string back to the first two. I had gotten that
far and put in the ATODs, XORs, and DTOAs to do the XOR logic, but the SUB$
were getting too much priority over the XOR logic and nothing was getting
calculated.

On Sat, Apr 21, 2012 at 6:45 AM, Kool-Aid Drinker <crug@...

wrote:

Yup. It expects the string to be checksummmed to arrive whole, and
then deals however many bytes are in that serial signal.

Having the string arrive in pieces would require extra logic, but
should be do-able.

Basic idea is: SIO and INIT break the string into analog bytes, TOGGLE
and ABUFs sort them into even and odd, ATOD decomposes the bytes, XORs
do the deed, DFFs keeps the running total, DTOA, ATOS, blah blah blah.

On Sat, 21 Apr 2012 08:03:57 -0000, "Chip" <cfm@...> wrote:

Did that account for messages of varying lengths?

- Chip


--- In Crestron@..., Kool-Aid Drinker <crug@...> wrote:

Only took 51 symbols for a basic version of the checksum that started
the thread.

If you want less moving parts, 4 SUB$ in 2 pairs will break your string
into even and odd bytes. One SUB$ with parameters (1,1) goes into a STOA,
the other SUB$ with parameters (2,100) feed the other set of SUB$. So when
you get a string in, it hits one pair of SUB$. They push one byte into your
logic, and the rest of the string to the other set. They push one byte into
logic and the rest of the string back to the first two. I had gotten that
far and put in the ATODs, XORs, and DTOAs to do the XOR logic, but the SUB$
were getting too much priority over the XOR logic and nothing was getting
calculated.

The module is from here



Thanks

I have a beautiful one for the command fusion app, I suspect it could be
ported over to use dynamic graphics on mobile pro g


_____

From: Crestron@... [mailto:Crestron@...] On Behalf
Of blk62180
Sent: Friday, April 20, 2012 9:12 PM
To: Crestron@...
Subject: [Crestron] Dynamic Presets on the iPad??




All,

Has anyone had any success creating dynamic presets on the iPad that are
similar to the ones on the tpmc-3x? If so, I would appreciate any assistance
in making my own that actually function decently and look good.

Thanks for the help!!

Barrett

Hi group.
I'am trying to integrate this module to MC3 program and geting this error then trying to compile for 3 series:
"Errors in .NET cross compiler"
Any ideas what is wrong?
Compiling for 2 series working fine.

Thanks

Artur

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@...> 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@...] On Behalf
Of ChrisK
Sent: Sunday, April 15, 2012 11:55 PM
To: Crestron@...
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> , 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]

Also did you do a sanity check by opening up the program tree and the hard ware tree and linking them?

I would say make it a remote equal. That way you don't have to worry about it.

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@...] On Behalf
Of ChrisK
Sent: Sunday, April 15, 2012 11:55 PM
To: Crestron@...
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> , 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

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the Crestron
group.

File : /Utilities/Wireless Survey Sheet.xlsx
Uploaded by : ender1_1000000 <tdurrant420@...>
Description : Excel Speadsheet for wireless site survey. Contain color coding for ensuring best results

You can access this file at the URL:


To learn more about file sharing for your group, please visit:

Regards,

ender1_1000000 <tdurrant420@...>