Card ATTN mode - Sleep + Watchdog

Hi,

In thinking of ways to bulletproof a device located in a physically remote location I have the following questions.

I am wondering if it’s possible to use ATTN sleep and watchdog modes at the same time with the constraint the watchdog seconds is greater than sleep time seconds or that the watchdog time is only valid when sleep is not active or something.

Second question, is it possible to issue the “sleep” command as an inbound request (from notehub) to the notecard ? i.e. briefly trigger the EN pin of the host in order to restart it.

Kind thanks,
Serge

3 Likes

HI @ssozonoff,

I don’t believe card.attn modes sleep and watchdog can be combined because they both use the JSON “seconds” value, so even if the Notecard firmware can enable both simultaneously (which I’m not sure - I’d have to experiment) they would have the same duration - which would create a race condition.

Regarding your second question - the host can be woken by the Notecard following an inbound sync if a .qi(s) file changes that is monitored by card.attn:

{ “req”: “card.attn”, “mode”: “arm,files”, “files”: [“hostwake.qi”] }

This assumes that the Notecard is configured to continuous or periodic mode (I assume the latter in your case as I assume you are sleeping the host to conserve power).

I’m not clear why you want to combine attn.sleep with attn.watchdog

  • do you need to sleep the host for power conservation ?
  • are you relying on the Notecard to store context for the host (in the sleep payload) (A .dbx file is a better alternative for storing critical host non-volatile context).
  • Is the intent to use the watchdog to guard against the host not waking correctly ?

.dbx files:

Note that if my replies are off base it may be because of insufficient understand of the problem that you are attempting to solve - if you could supply us with a little more information it would help us to offer better support.

Thanks
Sean

Hi,

OK thanks for clarifying this.

My line of questioning pertains too my low power consumption and reliability requirements.

I originally had notecard configured for minimum mode and let the my code on the host trigger the sync request every x minutes, un my case 10min. I have since opted for a hybrid approach using periodic with a long duration like 2 hours and manually sync’s driven by the host.
The idea being that if the host for whatever reason becomes unresponsive the notecard would still check in every now and then. This enables me to validate that the system is still under power, the notecard is still alive and the issue most likely lies with the host.

Now the host EN pin is connected to ATTN on the notecard so that when the host has issued its sync command it will use the attn sleep mode to put itself to sleep for 9 minutes. i.e. it gets fully powered down and restarts after 9 minutes.

So to my last question (poorly explained) about toggling attn pin as in inbound request. If something happens to the host and it “gets stuck” the notecard should still check into the notehub based on the fact it’s in periodic mode. I would like to be able to queue a message to the notecard to in essence tell it to reboot host. i.e. toggle the attn pin next time is checks in during it periodic sync.

Looking at you reply to this I guess the next question is. Can I sleep and files mode for card.attn at the same time ?

Thanks,
Serge

Hi @ssozonoff

I have not tested concurrent attn with files and sleep - I will test card.attn concurrency later today and report back.

Thanks
Sean

Hi @ssozonoff
Just got around to testing concurrent attention monitoring. I did not find a problem, though I did not test exhaustively. However I don’t believe that card.attn watchdog can be used concurrently with other card.attn settings, because it operates differently.

The card.attn watchdog setting leaves ATTN high and periodically pulses ATTN low for 5 seconds - designed as a reset for a host CPU or its power supply.

All other card.attn settings immediately set ATTN low and then set ATTN high when any of the monitored conditions is met.

Here are my test results for concurrency of other card.attn settings:


> // After card restart
> {"req":"card.attn"}
> {"set":true}
> // Confirm nothing being monitored
> {"req":"card.attn","verify":true}
> {"set":true}
> 
> // Arm multiple attn settings
> {"req":"card.attn","mode":"arm,files,connected,location,motion,wireless","files":["data.qi"]}
> {}
> // Confirm armed
> {"req":"card.attn"}
> {}
  // Verify what is being monitored
> {"req":"card.attn","verify":true}
> {"files":["data.qi","modified","motion","location","connected","wireless"]}
> 
> // Sync the notecard: wireless is tripped first, followed by connected
> {"req":"card.attn"}
> {"files":["wireless"],"set":true}
> {"req":"card.attn"}
> {"files":["connected","wireless"],"set":true}
> 
> // Shake the notecard
> {"req":"card.attn"}
> {"files":["motion","connected","wireless"],"set":true}
> 
> {"req":"card.location.mode","mode":"continuous"}
> {"mode":"continuous"}
> // Wait for GPS fix
> {"req":"card.location"}
> {"status":"GPS updated (70 sec, 56/56 dB SNR, 9/9 sats) {gps-active} {gps-signal} {gps-sats} {gps}","mode":"continuous","lat":42.2,"lon":-71.2,"time":1642862735}
> {"req":"card.attn"}
> {"files":["motion","location","connected","wireless"],"set":true}
> 
> // re-set attn and add a .qi note:
> {"req":"card.attn","mode":"arm,files,connected,location,motion,wireless","files":["data.qi"]}
> {}
> {"req":"card.attn"}
> {}
> sync
> {"req":"card.attn"}
> {"files":["data.qi","modified","connected","wireless"],"set":true}
> 
> // rearm and verify that the notecard is monitoring the same attn inputs
> {"req":"card.attn","mode":"rearm"}
> {}
> {"req":"card.attn"}
> {}
> {"req":"card.attn","verify":true}
> {"files":["data.qi","modified","motion","location","connected","wireless"]}

Thanks for these tests, very informative!!
My use case is with sleep and files.

Kind regards,
Serge

@ssozonoff
a cautionary note that the payload in card.attn,mode:sleep is volatile - and is lost if the Notecard reboots or loses power. If your host is storing critical non-volatile information a .dbx file would be a better option since these are non-volatile (like notes):

This could be combined with card.attn,mode:files,seconds: to wake the host if an inbound sync modifies a file, or after an elapsed period of time.

Regarding your original question of combining card.attn sleep and watchdog modes the two modes are fundementally incompatible for the following reason:

card.attn, for all modes except watchdog, sets the attn pin low when it is armed and then raises the attn pin when any of the monitored conditions is met. It is assumed that the attn pin is connected to a host GPIO, which will wake the host from low power mode via an interrupt.

card.attn,mode:watchdog assumes the attn pin is either connected to a control line on the power supply of the host processor (maybe the RST of the processor, but the attn pin is push-pull so this will not work on many processor). In this mode the Notecard leaves the attn pin high unless the watchdog expires, at which time the watchdog countdown is reloaded, and the attn pin in pulsed low for 5 seconds - to cause the host CPU to restart.
Thanks
Sean

Thanks and the host is stateless so no issues here.

As mentioned my main intention is to be able to put the host to sleep for a duration X using the attn pin connected to the EN pin of the host regulator and this works fine.

This could be combined with card.attn,mode:files,seconds:

I assume thats card.attn,mode:files,sleep:seconds, I will give it a try.

Thanks,
Serge