Detecting a Reboot Has Occurred

There are several ways to know if a reader has rebooted.  The first way is to visit the Reader Web UI and check whether the "Uptime" value shows the expected duration (i.e., if the reader ran without interruption since the last time the user started its inventory). If the "Uptime" is significantly shorter than expected, this could be a sign that reader operation was interrupted by an unexpected reboot.

The second way is to ssh into the reader and execute RShell command “show logging events err 1000” and search for log entry “MC4: MC starting” which indicates the reader is starting up:

               Event14='Mar  3 05:19:45 (none) MC4: MC starting'

 

Use RShell to determine reboot reason

Once you know the reader has rebooted, you can determine the last boot reason by executing RShell command “show system platform”:

 

Status='0,Success'

BootEnvVersion='2'

HLAVersion='386-003-000'

HardwareVersion='275-006-005'

IntHardwareVersion='275-006-005'

ModelName='R700'

SerialNumber='370-20-27-1681'

IntSerialNumber='370-20-27-1681'

MACAddress='00:16:25:13:4A:A9'

FeaturesValid='1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32'

BIOSVersion='1.6.4.240'

PTN='001.002'

UptimeSeconds='66129'

BootStatus='0'

BootReason='Cold'

PowerFailTime='4294967295'

ActivePowerSource=‘jack'

 

Here is a list of known reboot reasons:

• Processor / Reboot 

• Cold

• External Watchdog

• External Watchdog Fallback

 

Troubleshooting Steps

The following section goes into more details for each of these reasons.

Processor / Reboot

Someone or something requested the reader to reboot.

 

How it can happen

• Click the “Reboot” link on the Web UI of the reader
• Executes “reboot” via ssh or osshell

 

How to resolve

• Determine what person or operation is instructing the reader to reboot and ensure that only authorized reboot commands are issued to the reader.

Cold

The reader never went through the restart scripts that would log additional information before rebooting.

 

How it can happen

• Power Related Challenges:

• PoE switch is failing to deliver 15.4W to the reader
• Brick power is intermittent
• The power cables are bad
• The power (current/voltage) draw on the USB interface is too high
• Both PoE and Brick power are used at the same time in order to revert to Brick power

• Temperature

• The ambient temperature around the reader passes the threshold (+50C) above which is allowed.

 

How to resolve

• Power Related Challenges:

• Check the Power Supply
• Use Brick power supplied by an Impinj Power Adapter
• Supply 15.4W on the POE switch
• Provide 24VDC @ 2.1A of clean power
• Make sure the power draw on the usb interface is below the stated reader maximums.

• Temperature

  • Search for “<Impinj:Temperature>” to see what degrees C the reader is at.
  • The reader consumes a maximum of 15 Watts when it is transmitting with the maximum transmit power of +32.5 dBm.
  • This can be reduced to about 6 Watts by putting the reader into Low Duty Cycle if the use case bodes well for this feature.
• Check the temperature setting via ssh with RShell command “show rfid llrp config”
• Reduce the reader transmit power
• Use Low Duty Cycle
• Use Fans, Metal, and other cooling strategies
• Lower the Transmit Power

External Watchdog / External Watchdog Fallback

A firmware code assertion/exception has occurred. In the case of an External Watchdog Fallback, an assertion/exception has occurred multiple times in a short period of time causing the secondary firmware and cap images to become the primary images on the reader.

 

How it can happen

• Hardware failures
• Firmware changes
• CPU, Memory, and/or I/O resource intensive processes (Custom Applications and/or OS related) running on the reader

How to resolve

• Upgrade to the latest firmware version
• Downgrade to a known good firmware version
• Fix the custom application to be less resource intensive
• Please contact support@impinj.com for additional troubleshooting techniques