Modem interrupts?

After waking from deep sleep I wait for the modem to be ready before sending a message and going back to sleep.

I found this first while loop in a post here. Looking through hologram gitHub source it appears that connect() just calls powerUp() (which I’ve already called) and returns true, so it never sleeps and it would appear this while loop isn’t needed at all.

while (!HologramCloud.connect()) {

This next loop seems like what I need after powerUp. Are there any interrupts generated when the cloud connection status changes (i.e. use Dash.sleep() instead of snooze) or should I just poll it? Sleeping until there’s a CLOUD_CONNECTED status seems like it would more energy efficient.

while (HologramCloud.getConnectionStatus()!= CLOUD_CONNECTED) {

p.s. I realize that I should examine/handle other return status types, this is simplified for here

I’ve been using this while loop:

while (!HologramCloud.isConnected()) {

isConnected calls getConnnectionStatus so it’s just syntactic sugar.

The interrupt wakes the Dash from normal sleep but not deepSleep. According to the datasheet,

Most peripherals and interrupts are disabled, only select wake-up interrupts can wake from deepSleep (select I/O pins, alarm) when configured.


I ended up changing it to this after having the device “hang” after about a week. My guess is that cell connectivity was down or something else happened such that it never came back from sleep(). Since the device is operating on a battery I figured I’d rather fail on this connection attempt and power everything down to try later.

  int cnt = 0;
  while (!HologramCloud.isConnected() && cnt++<12) {

I also have the same issue with the Dash occasionally not waking up. Dash 1.2e, firmware 0.10.3. In my case it happens about 2 out of 168 times a week. I am reporting hourly.

I’ve been setting a clock alarm to wake up even if the interrupt fails:

while (!HologramCloud.isConnected()) {
  // In case the interrupt fails, wake up every minute.

I set it as Minutes instead of Seconds to see how often the interrupt failed to fire. Look at the 4 small peaks of about 1 minute:

(The large prolonged peak is probably some source of interference or obstruction.)

Interesting. I have about 11 days of success with the new code. I should see about dumping the messages along with the cnt and see how many holes there are and if there’s any pattern. It sends every 15 minutes.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.