Home AMX User Forum AMX Control Products

R4 complaints

2

Comments

  • glr-ftiglr-fti Posts: 286
    Ok, I finally received my cradles so I could charge the batteries. That was nice. Now I've spent some time with the gateway and the R4. It sure would be nice to have some sort of document, besides both reference guides, that walks you through all of the steps necessary to get this up and running. The Quick start was on the right track but lacking in essential detail.

    I have had to disable security on my Netlinx master because I am not given an opportunity within the gateway configuration to add the user and password. The fields are greyed out. Anyone get around this?
  • jjamesjjames Posts: 2,908
    What's the status on this thing falling offline when it goes to sleep? I was wondering why whenever it'd time out things were weird when I tried to hit stuff when it woke up. Once it took over 5 seconds to finally get online - how many button presses do you think a client would have hit during that time?

    And does it not have a "smart transfer" option? I made changes to 6 buttons, and it was only removing their addresses codes. And it decides to transfer the entire file - not to mention the USB transfer seems rather slow.
  • i have a question concerning R2: i get a Hold_event, but BUTTON.INPUT.CHANNEL is 0 always. is this because BUTTON_EVENT is done on channel 0? in the push-hanlder BUTTON.INPUT.CHANNEL works perfectly
  • ericmedleyericmedley Posts: 4,177
    i have a question concerning R2: i get a Hold_event, but BUTTON.INPUT.CHANNEL is 0 always. is this because BUTTON_EVENT is done on channel 0? in the push-hanlder BUTTON.INPUT.CHANNEL works perfectly

    Can you show us the hunk of code? Thanx..
    ejm
  • DHawthorneDHawthorne Posts: 4,584
    i have a question concerning R2: i get a Hold_event, but BUTTON.INPUT.CHANNEL is 0 always. is this because BUTTON_EVENT is done on channel 0? in the push-hanlder BUTTON.INPUT.CHANNEL works perfectly

    Easy enough to test: change your button channel 0 to an array that spans all the buttons on the remote. Then see if it works.
  • viningvining Posts: 4,368
    I get the same no HOLD response. I made a simple button that should toggle on/off every second in the below code for the purpose of testing the ZigBee wireless range. The idea was to hold a button, walk about and watch the feed back button turn on/off.

    I figured why not try the [dvArray,0] as I never have before and sure enough no hold when holding a button but down below if you look at the diagnostic print out I get a HOLD 0 every [HOLD,repeat] time when nothing is held. The system apparently always sees 0 as being a hold_event.

    So I guess if you need to HOLDS in a button_event you can't use [dvArray,0].

    BUTTON_EVENT [dvR4_Array,0]//nR4BtnArray  *******************************button event
    
         {
         PUSH:
    	  {
    	  LOCAL_VAR INTEGER nBTN
    	  STACK_VAR CHAR cDevice[11] ;
    	   
    	  nBTN = BUTTON.INPUT.CHANNEL//GET_LAST(nR4BtnArray)
    	  cDevice = fnDEV_TO_STRING(BUTTON.INPUT.DEVICE) ;
    	  If (nR4_DeBug)
    	       {
    	       SEND_STRING 0,"'R4 ',cDevice,'-CHANNEL ',itoa(nBTN),' Line-<',ITOA(__LINE__),'>',CRLF" ;
    	       }
    	  SELECT
    	       {
    	       ACTIVE (nBTN > 0 && nBTN < 50):
    		    {
    		    SWITCH(nBTN)
    
    

     HOLD [20,repeat]:
    	  {
    	  STACK_VAR INTEGER nBTN
    	  STACK_VAR CHAR cDevice[11] ;
    	   
    	  nBTN = BUTTON.INPUT.CHANNEL//GET_LAST(nR4BtnArray)
    	  If (nR4_DeBug)
    	       {
    	       SEND_STRING 0,"'R4 ',cDevice,'-CHANNEL ',itoa(nBTN),
    						  ' Line-<',ITOA(__LINE__),'>',CRLF" ;
    	       }
    	  SELECT
    	       {
    	       ACTIVE (nBTN > 0 && nBTN < 50):
    		    {
    		    SWITCH(nBTN)
    			 {
    			 CASE 22: 	//
    			      {
    			      ON [dvR4_Array,10] ;
    			      wait 10 
    				   OFF[dvR4_Array,10] ;
    			      break ;
    			      }
    

    diagnostics:
    Line 31 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:23:30
    Line 32 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:23:32
    Line 33 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:23:34
    Line 34 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:23:36
    Line 35 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:23:38
    Line 36 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:23:40
    Line 37 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:23:42
    Line 38 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:23:44
    Line 39 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:23:46
    Line 40 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:23:48
    Line 41 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:23:50
    Line 42 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:23:52
    Line 43 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:23:54
    Line 44 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:23:56
    Line 45 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:23:58
    Line 46 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:24:00
    Line 47 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:24:02
    Line 48 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:24:04
    Line 49 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:24:06
    Line 50 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:24:08
    Line 51 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:24:10
    Line 52 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:24:12
    Line 53 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:24:14
    Line 54 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:24:16
    Line 55 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:24:18
    Line 56 :: R4 -CHANNEL 0 Line-<145>$0D$0A - 09:24:20
  • Objects in a HOLD
    i have a question concerning R2: i get a Hold_event, but BUTTON.INPUT.CHANNEL is 0 always. is this because BUTTON_EVENT is done on channel 0? in the push-hanlder BUTTON.INPUT.CHANNEL works perfectly

    Never use button event objects in a HOLD. Those objects are really only available in the PUSH or RELEASE. Use a global variable to make an assignment and then reference the varialbe in the HOLD.

    Think of a HOLD as much as you would a WAIT. And never use a HOLD with a panel array in a button event, only a single panel.
    DEFINE_VARIABLE
    Volatile cDevRef[11]
    Volatile nChanRef
    
    BUTTON_EVENT[dvPNL,0]
    {
      PUSH:
      {
        cDevRef = fnDEV_TO_STRING(Button.Input.Device)
        nChanRef = Button.Input.Channel
      }
      HOLD[20,Repeat]:
      {
        If (nR4_DeBug)
        {
           SEND_STRING 0,"'R4 ',cDevRef,'-CHANNEL ',itoa(nChanRef),
             ' Line-<',ITOA(__LINE__)"
        }
      }
    }
    
  • viningvining Posts: 4,368
    B_Clements wrote:
    Never use button event objects in a HOLD.
    Hmmm! How many times have I done that?

    You could almost argue the need for a seperate cDevRef or nChanRef var
    for every panel in the dvArray so that the potential of another panel changing the value before the hold executes is eliminated. Rare but possible!
  • mpullinmpullin Posts: 949
    B_Clements wrote:
    Never use button event objects in a HOLD.
    Does this refer to the R4 or all Netlinx Programming? :(
  • Play it safe.
    vining wrote:
    Hmmm! How many times have I done that?

    You could almost argue the need for a seperate cDevRef or nChanRef var
    for every panel in the dvArray so that the potential of another panel changing the value before the hold executes is eliminated. Rare but possible!
    mpullin wrote:
    Does this refer to the R4 or all Netlinx Programming? :(

    I have chosen to use a HOLD only if my button event references a single panel because of the rare but potential conflict of two panels needing to use button objects. Again, button objects are only valid during the PUSH or RELEASE. Any other time the objects are subject to being either nul or subject to change by other events.

    It is very important to make sure the variables in a HOLD are not unintentionally altered when the code in the HOLD executes. A HOLD is more a stealth WAIT or stealth TIMELINE than a button event.
  • viningvining Posts: 4,368
    B_Clement wrote:
    I have chosen to use a HOLD only if my button event references a single panel
    BUTTON_EVENT[dvPNL,0]
    
    I missed that part!

    Now it's even worse, requiring a seperate button_event for each TP if HOLDS are to be used to avoid the remote possibility of another panel changing a value prior to the HOLD executing. Before I thought we were just going to reference a single panel in the HOLD (which isn't really possible). Yuk! The alternative is to take your chance and hope some one on a different TP doesn't use the same device during the period that the HOLD is in a wait to execute. Again, yuk!

    And you can't even use local variables. Which brings up another questions, why can't we declare local variables just after the opening brace of the button_event prior to the PUSH so they can be used for all handlers under the button_event?
  • Is there a reason, that on the R4 the Channels for Cursor up/down/left/right/ok are between 32 and 36 instead of the SNAPI channels 45-48. This does'nt make any sense at all to me and is annoying like hell.
  • mpullinmpullin Posts: 949
    Is there a reason, that on the R4 the Channels for Cursor up/down/left/right/ok are between 32 and 36 instead of the SNAPI channels 45-48. This does'nt make any sense at all to me and is annoying like hell.
    Doesn't make much sense to me either, but you can change this in TPDesign4. Open the R4 file and open up "External Controls" and change the cursor channels to whatever you want; just make sure there's no 45-48 anywhere else on that remote.
  • viningvining Posts: 4,368
    You can change the global channel assignment or just the channel assignment while a particular page is displayed or both which is a very nice.
  • vining wrote:
    You can change the global channel assignment or just the channel assignment while a particular page is displayed or both which is a very nice.


    a hint for those wishing to change the global assignment:
    - make sure the workspace viewer is on (view => workspace)
    - the first entry in the workspace after the name of the workspace is named "external controls"
    - double-click on that entry, change buttons as you like, they will be changed everywhere.
  • New R4 firmware

    In case anyone is interested, new R4/ZigBee firmware has been released.

    Please review the release notes before upgrading.

    http://www.amx.com/techcenter/firmware.asp?Category=Mio%20Remote%20Controls#Mio%20Modero%20R-4%20Firmware
  • joecjoec Posts: 55
    I tried to like the R4's but I found that the lack of important hard buttons renders this remote to be more like a touch panel then a handheld.

    Maybe to switch sources or other contorl functions I dont mind using the touchpanel, but most people use tivo's or other dvr's and without those buttons, the remote is a bad design IMO.

    My workaround was to use the number buttons for left/play/right pause. BUt man for the price of this remote, I dont want workarounds.
  • GSLogicGSLogic Posts: 562
    joec wrote:
    I tried to like the R4's but I found that the lack of important hard buttons renders this remote to be more like a touch panel then a handheld.
    AMX should have realize that play, stop, pause, rec... buttons are a must, anyone buying this remote will have a video DVR connected to their system. When trying to use the circle control for these functions people really get confused when they try to control the DVD - is the circle control for the play/stop/ect or for the menu up/down/ect????

    But I do like the R4 much more than a touchpanel when watching TV.
  • jjamesjjames Posts: 2,908
    For the price of this thing, I was hoping it was going to do tricks for me - you know, jump up and down, do backflips, and even do my laundry. I was dissapointed to hear it only recieves feedback from the processor.

    I used the circle buttons as directional buttons.
  • mpullinmpullin Posts: 949
    I think you pretty much have to put transport controls on the screen. Using the direction pad for anything other than cursor control could get confusing.

    Of all buttons that should be hard buttons, it makes the most sense to leave out the transport buttons since they are most often associated with feedback, so that when they're put on the screen their state can also be used to indicate the current process. Of course this is not relevant for IR devices.
  • jjamesjjames Posts: 2,908
    <-- Insert advertisement for a similar remote that can be used with AMX's RF reciever here -->

    AMX is so close to having such a great remote, they just need to replace the Zigbee junk with Ethernet and add some valuable hard buttons. I just hope they release an R-5 remote that addresses these issues.
  • mpullinmpullin Posts: 949
    jjames wrote:
    <-- Insert advertisement for a similar remote that can be used with AMX's RF reciever here -->

    AMX is so close to having such a great remote, they just need to replace the Zigbee junk with Ethernet and add some valuable hard buttons. I just hope they release an R-5 remote that addresses these issues.
    Let's think about this from an engineering standpoint for a sec. If we were to add transport controls to the R-4, where would they go? Would the remote be longer? Or would we remove buttons currently on the remote?

    Maybe remove the number pad, but how would we enter channels, passwords, etc? Having to type on a keyboard on this screen would be a pain.

    Maybe remove the direction pad, put a trigger on the underside of the remote, and detect direction based on the movement of the remote a la Wii. How much would this add to the cost? Would we need to install one of those little strips in every room?

    I like that other remote too, but it has no feedback and it's slow. The remote is the most accepted paradigm for controlling media, so I am glad to see AMX is improving its remote line. Like many others have said, there is still room for improvement.
  • jjamesjjames Posts: 2,908
    Yup - exactly what I was thinking. I've never compared the two side by side, but have worked with both of them. I know the T2-C is a bit bulkier, but . . . I would prefer one of those over an R-4 any day in my home. The touch on the R-4 just seems awkward compared the T2-C; I dunno what it is, it just "feels" weird hitting the R-4 screen.

    We actually load up the T2C with AMX RF codes. Work great too.
  • DavidRDavidR Posts: 62
    i agree completely with with jjames, ethernet for connectivity and especially downloads is a must. I just installed 3 of these and switching between usb and mesh is not fun in the field.
  • jjamesjjames Posts: 2,908
    DavidR wrote:
    i agree completely with with jjames, ethernet for connectivity and especially downloads is a must. I just installed 3 of these and switching between usb and mesh is not fun in the field.
    Imagine having 90% of your jobs 3 hours away. Not a quick fix.
  • joecjoec Posts: 55
    TrikinCurt wrote:

    That is a nice remote but I like this design:
    http://www.universalremote.com/product_detail.php?model=128
    It has all of the most used buttons as hard buttons and I know its not a touch screen but there is no reason why AMX could not make it with a touch screen.
  • GSLogicGSLogic Posts: 562
    mpullin wrote:
    Let's think about this from an engineering standpoint for a sec. If we were to add transport controls to the R-4, where would they go? Would the remote be longer? Or would we remove buttons currently on the remote?
    There are many remotes on the market that have a better design. I think AMX needs to have a beta group that can give feedback before the product goes to market. I used to test for DigiDesgn (digital audio work stations) and our group made countless changes to the product that Digi would have never thought of... Something about not seeing the trees in the forest or is it the research lab? And most important the group gets to keep the product! :)
  • DarksideDarkside Posts: 345
    GSLogic wrote:
    There are many remotes on the market that have a better design. I think AMX needs to have a beta group that can give feedback before the product goes to market. I used to test for DigiDesgn (digital audio work stations) and our group made countless changes to the product that Digi would have never thought of... Something about not seeing the trees in the forest or is it the research lab? And most important the group gets to keep the product! :)
    We recently commissioned a couple of R2s - which I appreciate are a little off topic, but, I ponder the following...

    Do we really need to have the majority of our buttons labeled. Fixed. Unchangeable?

    Do we really only need 6 sources to choose from and another 3 that can be sort of used as sources?

    Traditionally the software designer determines what the remotes should do (the old TXC xx platform as an example) No limitations, no pre-determined ideas of what we should do with this remote. Blank out the unused buttons etc.

    I feel like these fixed design remotes are sort of telling US what we can do a bit.
  • trobertstroberts Posts: 228
    Steven,
    I could not aggree more with you. The R2 should spit out 45 channel numbers and that is it. It creates more programming headaches to use it in its current form. All buttons engravable would also be awesome.
    I am also confused as to why the website says the AXB-RF is in LTD supply, if this is true, then does that mean the R2s are also in limited supply. I hope not it is a great remote and a great solution to axcess programming. I would also love to see more frequencies become available. The R2 in many ways is such a better remote than the R3, so it should be expanded upon.
Sign In or Register to comment.