Unreliable cloud messaging on hologram dash.

I am having issues with my dash unreliably connecting to the network, and sending messages to the cloud router.

I am even having issues with the basic code in my setup that notifes the boot event.

void setup() {
  Serial.begin();
  delay(5000);
  Serial.println("powerup");
  
  Dash.pulseLED(50, 100);
  //Will connect to the Hologram Cloud automatically
  while (!HologramCloud.sendMessage("Boot Up", "Boot")){
    int status = HologramCloud.getConnectionStatus();
    Serial.print("Failed:");
    Serial.println(status);
  }
}

I get the following output

powerup
Failed:5
—Repeats 57 times
Failed:4
–Repeats 63 Times
Failed:0

This raises a few questions, why am I getting CLOUD_ERR_SIGNAL and CLOUD_ERR_UNREGISTERED faults, and then finally CLOUD_DISCONNECTED on the last iteration before the message sends.

Do you have any tips on how to troubleshoot this as I have an identical unit that has been deployed for a few months with the same software, that works most of the time but had a period of about a week where this issue occurred.

In addition it appears that on the first run after programming there will be no issues, but if power is removed and reconnected (battery or USB) the above issue occurs.

@Hugoagogo

What you are seeing is the modem start up process. When you apply power to the Dash, your program will start and the modem will also start its boot process. The error states you see are the normal progression of the modem after power on.

After the modem has booted up and is running, it starts looking for a cell signal. Until one is found, it is in the CLOUD_ERR_SIGNAL state. Once a tower is found and there is a valid signal, the modem attempts to register on the network. Until it is registered, it is in the CLOUD_ERR_UNREGISTERED state. Once registered on the network, it is in the CLOUD_DISCONNECTED state. From CLOUD_DISCONNECTED (registered but no IP yet) or CLOUD_CONNECTED (registered and IP address assigned) a sendMessage will normally succeed.

The easiest way to block while waiting for the modem to be ready is:

while(!HologramCloud.connect()) {
  Dash.sleep();
}

Once connected, you can send your message. You could also trigger off the registered event if you want to do some work while waiting for registration https://hologram.io/docs/reference/dash/api/#hologramcloud-attachhandlernotify-callback-

An earlier version of the firmware would block for an extended period trying to connect. This method didn’t work well with applications that didn’t want to block, so the duration was shortened. And there is no guarantee the registration would occur even in the extended period due to signal/antenna issues. This is probably the difference you are seeing.

The reason you see a quick connect if the board has been powered is that the modem is already registered on the network. Resetting/reprogramming the processor doesn’t reset the modem, so it would stay registered.

1 Like

I presume this is the same after powering off them modem, and entering deep sleep?

Dash.deepSleep() and Dash.shutdown() don’t affect the modem. That allows you to stay on the network and save some power on the user processor. HologramCloud.powerDown() will shut off the modem, requiring it to reboot and reconnect to the cell network.

1 Like

Hi Erik,

In the case of the U-201 board, I’m not seeing the error codes you mentioned here (other than error codes 2 and 5) during power-up and this doesn’t changed after 2-5 minutes so I unplugged the board from the computer. I did this 10 times, and the only time it did connect to the Hologram Cloud is when I upload the firmware to the board… (where I think the connection is made by the system firmware while I’m coding, compiling and eventually uploaded the code).

Below is the arduino sketch I used for the test as well as the two log files showing success/failed connections… Note that the failed connections are 9 out of 10 tries… and this is stopping me from releasing the prototype to my client.

Here are some questions I have regading the HologramCloud API:

  1. Signal strength of 4 to 13 (-105 to -87 dBm) are within the WEAK signal range and is not good to get a GPRS connection.
    I wonder why I got the 2nd log consistently connected to the server.
  2. I tried to use a bigger antenna (pcb type) but the signal strength can't get higher than 13.  
    
  3. I'm getting failed connection status for more than 5 minutes... and I don't know what API to execute to recover from **status 2** (CLOUD_ERR_UNAVAILABLE (2) – Could not communicate with the modem)  and **status 5** (CLOUD_ERR_SIGNAL (5) – No tower was found).
    
  4. Since connect command is non-blocking, and since there's no connection status that says 'busy connecting' how can I safely call the connect command repeatedly?  Will the second call force the first call to be aborted or just ignored by API state machine?
    
  5. Does **sendMessage** command handle re-connection to cloud in case the line is dropped by the telco or by some other process?
    

I hope you can validate if this happens at your end.

Hi Eric,

I took video of the tests I made of the above arduino sketch on U270 and U201.
You’ll notice that U270 was able to connect to the network and send the data, while U201 was not able to connect to the network.
But… taking out the SIM from U270 and inserting in U201 (while SIM has not timed-out the network connection yet) will have the U201 board transmitting data to the server just like how the U270 did earlier.

1: U270 test: U270 API TEST - YouTube
2: U201 test: U201 API TEST - YouTube

Let me know if this happens at your end.

Hi Arnold, I’m going to start a new thread for you to pass over your ICCIDs.

Hi Eric and Derrick,

Regarding SIM:
I’m using only 1 SIM for both tests.
I started with SIM in U201, transferred SIM to U270 then back to U201.

The purpose of the test is to make sure that both user and system firmware, as well as SIM are the same for both boards. This is to validate/show the difference in the bootup behavior between the two boards.

I would like to suggest that instead of MODEM throwing Error code while busy setting up connection, why not throw setup status on each stage instead. This way, it’s more discrete if modem encounters error or still busy setting up connection.