Troubleshooting
      Back to home
      1. Help Center
      2. Wavelet Devices
      3. Troubleshooting

      Communication Problems

      How to troubleshoot various problems that you might have with device communication.

      Problem:

      Sample data is being collected, but there is no communication with FAI Pro or with FAI Local server.

       

      Background:

      Communication can use MQTT or HTTP protocols. HTTP is the default and this protocol can transmit all stream types (data, technical, virtual, external, and event). MQTT can only transmit data streams.

      All devices transmit HTTP. Devices with firmware version 2.388 and newer can transmit both HTTP and MQTT, if configured to do so. Otherwise, they can be configured to work with only HTTP.  The  Wavelet 4R™ device with FW version 2.388 and newer supports MQTT. 

      If the device is configured to work with both technologies, the device transmits commands, logs, health statuses, and so forth with HTTP, but sensor data is transmitted with MQTT. Consequently,  HTTP and MQTT transmissions alternate -  one HTTP transmission (or more) and one MQTT transmission, then again HTTP, MQTT, HTTP, MQTT, and so on. Both HTTP and MQTT protocols are used on each scheduled transmission. 

       

      The following decision tree gives you a bird's eye view of how to troubleshoot particular problems. 

      Recommended actions:

      Communication problems may occur if there are disruptions with the external antenna, low battery, misconfigured streams, or inability to reach the cellular network provider.

      1. Confirm that an external antenna is connected. An external antenna is required.

       Ayyeka considers a device to be improperly installed if it does not use an external antenna.

        • If the device and antenna are in problematic areas, for example in hilly regions or in manholes, get a photo of both the device and antenna.
        2.    In the UI, check the following tabs for the device:

        • Configuration tab - what is the retry frequency to reconnect to the cellular network? 
          • If the device fails to connect to a cellular network (both HTTP and MQTT), the device will retry to connect according to the value of the parameter GSM>HOME_INTERVAL_RETRY_ARRAY>home_interval_retry_minutes. This parameter will affect connection retries in the Normal, Event, and Emergency transmission intervals. In the meantime, the device will continue to collect and store data. The transmission frequency is automatically reduced to conserve power until communications can be successfully re-established, at which point the device returns to its normal transmission frequency.
        • In Advanced Device Configuration area, check GSM >  HOME_INTERVAL_RETRY_ARRAY.  Each number, 0-5, represents the number of connection retries: 
          • 0 - 1st delay after connection failure. Has not yet retried to connect.
          • 1 - The 1st connection retry.  The 2nd (consecutive) connection failure delay.
          • 2 - The 2nd connection retry. The 3rd (consecutive) connection failure delay. 
          • 3 - The 3rd connection retry. The 4th (consecutive) connection failure delay.
          • 4 - The 4th connection retry. The 5th (consecutive) connection failure delay.
          • 5 - The 5th connection retry. The 6th (consecutive) connection failure delay.

      For each connection retry, check the value of home_interval_retry_minutes. 

        • Commands tab - what commands were sent to the device just before the problem started? Click the command to see what specific command was sent before the problem occurred. The following are commands that might cause issues:
          • The Server Address is incorrect. In Advanced Device Configuration area, check HTTP > Server Address
          • The external antenna is not selected. In Advanced Device Configuration area, check GSM > Antenna Selection
          • SIM and APN are not configured correctly. In Advanced Device Configuration area, check GSM > gsm_apn*, GSM > gsm_sim*,  and GSM > lkgc_gsm*
        • Log tab - any communication errors listed in the Message column? Look for strings such as BATTERY_LOW, FAILED, SIM. Look for which network carrier is used.
          • CREG +0,1 = Connected to a network, with a designated SIM card (VERIZON) Not Roaming
          • CREG 0,2 = Looking for a network
          • CREG 0,3 = SIM not activated
          • CREG 0,4 =
          • CREG 0,5 = Connected to a network, Roaming
        • Device Reports tab - Check the Device Reporting Profile. 
        • Health tab - Check for number of boot counts and errors.
       3.   In the UI, check the following technical streams for the device:

       

      What happens to the data when communication is lost?

      You cannot retrieve data samples manually via the USB port until communication is restored.

      If communication was down for less than three days, data samples will be transmitted as soon as the communication is restored.

      If communication is down for a longer period, the data samples will be transmitted as soon as the communication is restored, but the samples have the date 1970-01-01.