Polycom HDX modules

Yesterday I was working on an NI-2100 trying to control a Polycom HDX8004 codec with the Eagle-eye camera. Two weeks ago I workd on the same Polycom system with an NI-4100 and had no issues.

This happens with several different versions of the modules. HDX9004 versions 1.0.0, 1.0.2, 1.0.4, and 1.0.5. (Somehow I lost 1.0.1 and 1.0.3). I also tried the HDX9002 version 1.0.0.

I don't use the UI module, only the base comm .jar file. Everything loads up fine. I push the button to to move the camera left and let go (if I remember correctly it is channel 134). At this point, the camera gets freeky. It had been moving since I did the release, then it stops, and jerks for another few seconds. In diagnostics, I see the camera near move left, the camera near move stop, and then a whole bunch of get and set postition commands take place. Sometimes the get values match the previous set, other times they are different. After trying a few different commands, the I/O between the master and the Polycom just lights up the send and receive lights continuously, and eventually the master will start spewing messages about a queue overflow when it reaches "500". I'm not sure it this is bytes, commands or what.

While the AMX is having stress, the Polycom is also having issues. If you happen to be playing audio through the system, it starts breaking up.

The remote contol moves the camera properly, but when using the remote to attempt to adjust volume, the diagnostics start showing continuous reports of the volume level.

I did find out late in the afternoon that just having the cable connected between the two devices would eventually cause the symptoms. I tried two different AMX programming cables as well as one that we built ourselves in the 2,3,5 crossover configuration.

Baud rate changes also do nothing. If I tried to set both to a higher rate, the problem just happens faster. The only other odd thing is that if I reboot the master, I also have to reboot the Polycom to get them to communicate. Even though both are set to 9600.


The only thing that I have done in the past two weeks was to load the NetLinx SNAPI 1.15 update from 10/07/2009. Also after this update, I've started having other duet modules have issues that have generally be corrected by updating the master to the latest available firmware (3.41.422) and manually adding the snapirouter.jar and devicesdkrt.jar files to my projects to force the download.

Has anyone else seen this kind of behavior?. Anyone else had issues with the SNAPI update?

Comments

  • Joe HebertJoe Hebert Junior Member Posts: 2,154
    The only thing that I have done in the past two weeks was to load the NetLinx SNAPI 1.15 update from 10/07/2009. Also after this update, I've started having other duet modules have issues that have generally be corrected by updating the master to the latest available firmware (3.41.422) and manually adding the snapirouter.jar and devicesdkrt.jar files to my projects to force the download.

    Has anyone else seen this kind of behavior?. Anyone else had issues with the SNAPI update?
    I can confirm that .422 firmware is required for SNAPI >= 14.
  • PhreaKPhreaK Senior Member Posts: 966
    From the AMX tech tips newsletter:
    Downloading and Installing SNAPI (v1.14.222)
    Did you know?
    If you download and install the new SNAPI (v1.14.222) and then compile your code you need to upgrade your NI master to firmware v3.41.422 or the Duet modules in your project will not load.

    SNAPI v1.14.222 contains high performance updates which require NI master firmware to be v3.41.422 or later.

    There is mention of this on the AMX Website however if you are regularly updating your AMX software via the WebUpdate utility you will not see this important message.

    Visit the AMX website for more details.
  • Danny CampbellDanny Campbell Senior Member Posts: 310
    Dumb programmer error.

    I learned a new lesson. NEVER use 43001 as the virtual device number.
  • karageurkarageur Junior Member Posts: 97
    Dumb programmer error.

    I learned a new lesson. NEVER use 43001 as the virtual device number.

    Why is that?
  • Danny CampbellDanny Campbell Senior Member Posts: 310
    karageur wrote: »
    Why is that?

    Because that was the cause of all of my problems.
  • Joe HebertJoe Hebert Junior Member Posts: 2,154
    karageur wrote: »
    Why is that?
    Duet virtual devices use device numbers 41000 - 42000.
  • karageurkarageur Junior Member Posts: 97
    Yeah, sure! I have forgotten )
  • Danny CampbellDanny Campbell Senior Member Posts: 310
    karageur wrote: »
    Yeah, sure! I have forgotten )

    So had I. 43000+ must be used internally, because it sort-of worked.
  • Chip MoodyChip Moody Junior Member Posts: 727
    So I'm looking at the HDX module I just got off of amx.com - just the comm module - and it's documentation.

    I think I've counted about three ways (channels) I can emulate the "answer/dial" button on the remote, but I can't for the life of me find one that lets me emulate the hang up button.

    I can use PASSTHRU obviously, but I'm really surprised this is either missing or eluding my view...

    - Chip
  • AuserAuser Junior Member Posts: 506
    Chip Moody wrote: »
    I can use PASSTHRU obviously, but I'm really surprised this is either missing or eluding my view...

    It obviously missed or eluded my view too, because our code uses:
    'PASSTHRU-button hangup'
    
  • Chip MoodyChip Moody Junior Member Posts: 727
    Exactly the "solution" I was using. :)

    - Chip

    Auser wrote: »
    It obviously missed or eluded my view too, because our code uses:
    'PASSTHRU-button hangup'
    
Sign In or Register to comment.