RTI and AMX integration?

tobygaglio · May 2009

Hello all,

Please let me start by saying, I am new to AMX. I have been thru designer / installer and programmer 1 and for our first project we hired an independant programmer. I am now working on my first system (our showroom, so I have time to screw things up and learn from them). I feel confident that I can make everything work using an inwall touchpanel for our showroom theater and whole house audio (setup in zones for the offices with MET6N and a 500i for the boss).

What I'm looking to do also and this is were I really need the help is intergrating an RTI T2c with an RP6 into the system to allow handheld control of the theater. If someone would be willing to give me a tutorial on how this is done that would be great.

Thanks in advance.

Toby

jazzwyld · May 2009

One Way to do it

The way we did it, is by using the XP8, I used the Remote in RF mode. In conjuction with the MIO-IRRX. I programmed the remote to pulse AMX IR Channels. Then use the XP8 to control which IR port it goes out. Then programed in the AMX using button_events.

Jimweir192 · May 2009

Another way is to use a CM232 interface and write your own control protocol - I use 'RTIButton:xxx' with xxx being a numeric value, so each button on the RTI issues a unique serial string that I can pass in my AMX code and treat it almost like a TP.

The other option is to use the AXlink AXB-RF but this restricts you to 255 channels.

iainshaw · May 2009

Agree the CM232 and RP6 combination is preferable. The RTI RF receiver has better range, and it gets you away from the 255 buttons limit - which becomes a REAL pain if you have to use two AMX RF receivers to increase overall range coverage. Our home-brewed 232 comms protocol carries info about what device, what room and what command and the string is broken down on the AMX master. Works well.

tobygaglio · May 2009

any chance you guys would be will to share code with me. I am very green to this.

Thanks Toby

Jimweir192 · June 2009

Toby, this is an ideal lesson for serial comms - ie you can specify the complexity of the serial string from the RP6 and then you can learn all about parsing these strings in AMX.

ie as a start send a simple number - say 678, then in your data_event string handler you can capture this string and try to work with it. i.e

data_event[dvRTI_CM232]
{
      Online:
           {
                     //port config here
           }
      String:
           {
                    send_string 0, "'String from RTI= ',data.text"
           }
}

Then watch in diagnostics.

There are tons of posts on here about parsing, but also look up LEFT_STRING, REMOVE_STRING & MID_STRING for starters in Netlinx help. Also look at data.text and CREATE_BUFFER. Once you understand how the string is received by AMX, you can then manipulate this and have it work for you.

Have a try and if you get stuck come back and post your code.

iainshaw · June 2009

RTI Serial

couple of fragments from our setup

this is what we use in the online event

send_command dvRTI, "'SET BAUD 9600,N,8,1'" - we've always used this when combining RTI RP6s and AMX Masters and it's fine

this is the beginnings of what we use to get the data out to do something sensible with it

WHILE (FIND_STRING(RTI_BUFFER,"13",1)) // Parsing data against the pattern below and looking for strings ending with a CR (Decimal 13)
// <<RTI,RO:nnn,DV:nnn,CO:nnn>> (string format for the RTI commands)

Agree with Jim, have a play, look at the string manipulation commands and see what you can come up with.

jjames · June 2009

Our format of strings are as follows:
a:b<CR>
Where a is the room number or remote number; b is the code number (i.e. 1 - play, 2 - stop, 3 - pause, etc.) and it's ended with a carriage return so it's easier to parse.

I keep all the code numbers the same as the panel's code numbers so it's easy to integrate and it also makes it portable since my channel codes are the same from job to job.

John Gonzales · June 2009

I don't use the RTI, I use the URC remotes with an MSC-400. Same concept though... Button press on the URC remote gets processed inside the URC MSC-400, and it sends a serial string to the AMX Master for parsing. I format my strings out of the MSC-400 as "RxCHy;" where x is the Remote or Room #, y is the Channel #, and ; is the termination character. When I parse out the remote numbers and channel numbers, I know which remote/room issued the command, and depending on the number of devices being controlled I just group the channel numbers.

For instance CH would go from 1-1000. If I have 10 devices being controlled then channels 1-100 would be device 1, 101-200 would be device 2, 201-300 would be device 3, etc... If we have 20 devices then the channel groups would be smaller, 1-50 is device 1, 51-100 is device 2, etc...

In code it would look like this (after you parse out the R and the CH):

DEFINE_CONSTANT
INTEGER kChannelGroupSize = 50 //Number of channels we're using per device


DEFINE_FUNCTION fnInitiateCommand(INTEGER nRemID, INTEGER nCH)
{
  nDeviceID	=	((nCH-1)/kChannelGroupSize)+1
  nCH		=	((nCH-1)&#37;kChannelGroupSize)+1
  
  PULSE[dvDeviceArray[nDeviceID],nCH]
  //Or PULSE[dvDeviceArray[nDeviceID],nChannelArray[nDeviceID][nCH]] if the channel #s don't line up with the IR File
}

Or if you need more than just a 'PULSE' you can use this instead:

IF(nRemID == 1)
  {
	 IF(nDeviceID == 1)
	 {
		SWITCH(nCH)
		{
		  CASE 1:
		  {
			 //do stuff here
		  }
		  CASE 2:
		  {
			 //do stuff here
		  }
		  CASE 3:
		  {
			 //do stuff here
		  }
		  .
		  .
		  .
		}
	 }
  }

This code gives me a lot of flexibility in what I can do.

--John

tobygaglio · June 2009

thanks guys, this should get me started.

Toby

a_riot42 · June 2009

jjames wrote: »

Where a is the room number or remote number; b is the code number (i.e. 1 - play, 2 - stop, 3 - pause, etc.) and it's ended with a carriage return so it's easier to parse.

You shouldn't need a remote number, the device ID tells you which device the string is from no?
Paul

iainshaw · June 2009

a_riot42 wrote: »

You shouldn't need a remote number, the device ID tells you which device the string is from no?
Paul

In one of our typical setups we might have 3-4 RTI remotes each of which might be controlling one or more satellite boxes, one or more tuners, one or more Kaleidescape players, lights etc. And they might be doing that in any one of 10-20 rooms.

All the master sees is the communication from the RTI RP6 on one serial port. So dvRTI = 5001:2:1

Information about device, room and command has to be in the string coming from the RTI

a_riot42 · June 2009

iainshaw wrote: »

All the master sees is the communication from the RTI RP6 on one serial port. So dvRTI = 5001:2:1

Information about device, room and command has to be in the string coming from the RTI

Ah, I thought you were using one RP6 per remote.
Paul

iainshaw · June 2009

No, we'd probably use multiple RF receivers to ensure decent coverage across large projects but they'll all go back to a single RP6

a_riot42 · June 2009

iainshaw wrote: »

No, we'd probably use multiple RF receivers to ensure decent coverage across large projects but they'll all go back to a single RP6

Would that mean that you couldn't have a wandering remote with which you can control more than one zone?
Paul

iainshaw · June 2009

No, the remotes are normally programmed to control multiple rooms so we use a room -> device -> commands hierarchy for the pages. If you're interested there's a standalone windows executable preview on our website

http://www.brilliantliving.co.uk/option,com_docman/task,cat_view/gid,90/Itemid,70/

a_riot42 · June 2009

iainshaw wrote: »

No, the remotes are normally programmed to control multiple rooms so we use a room -> device -> commands hierarchy for the pages. If you're interested there's a standalone windows executable preview on our website

http://www.brilliantliving.co.uk/option,com_docman/task,cat_view/gid,90/Itemid,70/

I ran the program but couldn't find a way to switch rooms. I always liked RTI remotes though, and wish the company I work for now would sell them. The only fly in the ointment I found with them when using RF was that if one remote was holding down a button like volume up, and then someone else was also holding a button down, when the first person released the button, it wouldn't release until the second remote released their button.
Paul

iainshaw · June 2009

a_riot42 wrote: »

I ran the program but couldn't find a way to switch rooms. I always liked RTI remotes though, and wish the company I work for now would sell them. The only fly in the ointment I found with them when using RF was that if one remote was holding down a button like volume up, and then someone else was also holding a button down, when the first person released the button, it wouldn't release until the second remote released their button.
Paul

we've never seen that limitation in live projects, think we've got 8 going in our largest AMX/RTI implementation - guess it's there though, just don't see it in day to day usage

Ref the windows executable. One of them is just a bog standard cinema demo, the other is a whole house implementation. In this instance the home button should take you back up the hieracrchy

RTI and AMX integration?

Comments