Home› AMX User Forum› NetLinx Studio

iPort Module and R4 Remotes

jgglennjgglenn Posts: 3
in NetLinx Studio
We are currently using this netlinx module downloaded from the iPort website with the R4 remotes. We have found the module to be quite slow with the R4s due to the zigbee standard. I was just wondering if anyone had found a way in the UI module to slow the rate at which data such as artist and track names etc are sent to the panel as only the first 7 or so appear. Usually when this happens the iPort module then disconnects and becomes unuseable.

Any thoughts on the subject would be very welcome.

Joe

Comments

  • ericmedleyericmedley Posts: 4,177
    jgglenn wrote:
    We are currently using this netlinx module downloaded from the iPort website with the R4 remotes. We have found the module to be quite slow with the R4s due to the zigbee standard. I was just wondering if anyone had found a way in the UI module to slow the rate at which data such as artist and track names etc are sent to the panel as only the first 7 or so appear. Usually when this happens the iPort module then disconnects and becomes unuseable.

    Any thoughts on the subject would be very welcome.

    Joe

    wow, I've not heard too many requests to slow down the data coming out of a media server. :)

    I suppose you could always intercept the data being sent from the module to the display devices and build your own buffer, and then slow down the output of data to the R4s.

    I have had some success with running Lutron Homeworks processors at higher speeds (115Kbaud) by doing a similar thing.
  • AMXJeffAMXJeff Posts: 450
    Slowing Down Commands

    If I understand correctly, I would use a virtual device as a proxy and queue the commands then send them from the queue to the R4.

    So in otherwords, replace the R4 device in your code with a virtual. Then use the data_event of the virtual and add the commands to a queue, and pace the commands to the R4.
  • viningvining Posts: 4,368
    AMX_Jeff wrote:
    So in otherwords, replace the R4 device in your code with a virtual. Then use the data_event of the virtual and add the commands to a queue, and pace the commands to the R4.
    Shouldn't this type of buffering be built into the Gateway or in the processor via special device definition. To route all feedback to the R4s from every device module required to a common virtual device in order to put in a slow down queue is a real pain in the a$$. Wouldn't it have been easier to design and engineer something intelligently instead of having us make up for its flaws and short comings!
  • jgglennjgglenn Posts: 3
    Possible Solution

    Just to update this thread, I was given a module developed by AMX Australia that sits between the R4 and the Master to manage traffic going through the zigby gateway using a virtual device for the R4. In the demo program that I was supplied with, it seemed to work a charm with an R4 and an iPort dock. Just trying to figure out where im going wrong integrating it with the project I am currently working on :-S
  • AMXJeffAMXJeff Posts: 450
    vining wrote:
    AMX_Jeff wrote:

    Shouldn't this type of buffering be built into the Gateway or in the processor via special device definition. To route all feedback to the R4s from every device module required to a common virtual device in order to put in a slow down queue is a real pain in the a$$. Wouldn't it have been easier to design and engineer something intelligently instead of having us make up for its flaws and short comings!

    That's why we programmers have a job, picking up slack from those hardware designers...
Sign In or Register to comment.