Home AMX User Forum AMX General Discussion

RTI and AMX integration?

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

Comments

  • jazzwyldjazzwyld Posts: 199
    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.
  • Jimweir192Jimweir192 Posts: 502
    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.
  • iainshawiainshaw Posts: 133
    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.
  • tobygagliotobygaglio Posts: 5
    any chance you guys would be will to share code with me. I am very green to this.

    Thanks Toby
  • Jimweir192Jimweir192 Posts: 502
    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.
  • iainshawiainshaw Posts: 133
    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.
  • jjamesjjames Posts: 2,908
    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.
  • 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
  • thanks guys, this should get me started.

    Toby
  • a_riot42a_riot42 Posts: 1,624
    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
  • iainshawiainshaw Posts: 133
    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_riot42a_riot42 Posts: 1,624
    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
  • iainshawiainshaw Posts: 133
    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_riot42a_riot42 Posts: 1,624
    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
  • iainshawiainshaw Posts: 133
    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_riot42a_riot42 Posts: 1,624
    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
  • iainshawiainshaw Posts: 133
    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
Sign In or Register to comment.