Home› AMX User Forum› AMXForums Archive Threads› AMX Hardware

RX & TX Leds of NI3101 SIG always lit, wont work sometimes if not rebooted.

ajish.rajuajish.raju Posts: 185
in AMX Hardware
My NI3101 SIG series controller has the latest master and device firmware but the RX and TX leds are always lit up. The client says that the system hangs every 2 weeks and requires a reboot, then it works fine again. Any suggestions?


Comments

  • Jorde_VJorde_V Posts: 393
    ajish.raju wrote: »
    My NI3101 SIG series controller has the latest master and device firmware but the RX and TX leds are always lit up. The client says that the system hangs every 2 weeks and requires a reboot, then it works fine again. Any suggestions?

    That's the problem that has been fixed in the new firmware. So if you put the new device + master firmware on it you shouldn't be seeing that problem anymore.
  • ajish.rajuajish.raju Posts: 185
    Thanks for the response. As you can see from my screenshot, i have updated to the latest firmwares available for this controller.
  • Jorde_VJorde_V Posts: 393
    ajish.raju wrote: »
    Thanks for the response. As you can see from my screenshot, i have updated to the latest firmwares available for this controller.

    Serves me right for not reading more than the title.

    Are you using any (duet) modules?
    Do you get anything in the log? (errors)
    Do you get anything from telnet? (errors)
    Does diagnostics return anything useful?
    Did this happen before the firmware upgrade as well?
    When it's in that state does it still send out codes? Or is it trying to?
  • DHawthorneDHawthorne Posts: 4,584
    The more I see issues like this, the more I am convinced it is a sign of the controller beginning to fail. If it were older, I'd blame it on the capacitor issue. But I have seen this exact thing several times, and eventually the bad controller starts regularly locking up the master.
  • HARMAN_shane-a-rooHARMAN_shane-a-roo Posts: 39
    The latest version(s) of NI device firmware keep LED's on for a minimum of .5 seconds, regardless of the time duration require for an individual transmit or receive. This was done to have a better visual indication that something occurred for ports running higher baud rates. Previous to this, LED's might blink so fast that you couldn't see them.

    But with this new behavior you may see systems where the LED's stay on solid if the port communication interval is less than .5 seconds.

    LED's staying on solid is not an indication of a failure but rather continuous communication.

    Further analysis of system state would be needed to diagnose any "lockup" condition
  • PhreaKPhreaK Posts: 966
    shane-a-roo wrote: »
    The latest version(s) of NI device firmware keep LED's on for a minimum of .5 seconds, regardless of the time duration require for an individual transmit or receive.

    Cool, was this included in any of the release notes? I don't remember seeing it.
  • HARMAN_shane-a-rooHARMAN_shane-a-roo Posts: 39
    I don't see it noted anywhere. It must have slipped through the cracks since it wasn't an actual "bug" fix
  • DHawthorneDHawthorne Posts: 4,584
    It's good to know the light behavior has changed, but that doesn't address the fact that the controller in question was locking up. It's not simply a visual issue. I suppose the real question is whether the lights and the lockups are related ... and I can say for certain, I have had cases where RX and TX lights have frozen to a solid on state and the master subsequently locked up. When the lights are solid, is there actual communication going on? That would tell you.
  • ajish.rajuajish.raju Posts: 185
    Thanks so much for the responses. On analysing the source code, i found that there was polling happening every .3 seconds which was the cause of the lockups and the led states being on constantly. After increasing the poll time interval, the led states are normal. It was not a hardware issue but a coding issue.
  • ericmedleyericmedley Posts: 4,177
    ajish.raju wrote: »
    Thanks so much for the responses. On analysing the source code, i found that there was polling happening every .3 seconds which was the cause of the lockups and the led states being on constantly. After increasing the poll time interval, the led states are normal. It was not a hardware issue but a coding issue.

    Boy oh boy! An RS232 poll every .3 seconds seems rather odd. Most devices I know don't like to get hit that much. I typically poll in the seconds range (2-5) but certainly never below 2.
  • jjamesjjames Posts: 2,908
    ericmedley wrote: »
    Boy oh boy! An RS232 poll every .3 seconds seems rather odd. Most devices I know don't like to get hit that much. I typically poll in the seconds range (2-5) but certainly never below 2.

    I was sending chapter, play status and time status queries all within one second every second to Oppo blu-ray players before they updated firmware to send that information out without being solicited. It handled it quite well actually - I was surprised.

    Generally whenever I receive a response I set the ready flag and send the next queued string usually without any consideration for timing. If I experience any issues, that's when I add a time buffer.
Sign In or Register to comment.