My application is in “minimal” mode – I’m using the ‘card.attn’ pin to notify my app of a “data.qi” file change. The hardware attn pin is connected to an interrupt input port on the MCU for notification – I am also monitoring the pin with a scope so I can observe the pin’s level change.
After “arming” the attn.pin, I’m able to construct a simple JSON command to send to the Notecard by using the Notehub’s “device” web page’s “+Note” dialog.
How is the notecard made aware of the incoming ‘file’ change in minimal mode? Do I need to issue a “hub sync”? and if so, when should that command be sent? (i.e. before or after the attn.pin ARM?
How long should it take to receive the message after it’s been added? I’ve observed times of 45 seconds to 5 minutes? Referring to the previous question, I have issued hub sync during some of the tests but can’t say for sure if the timing was appropriate or even if needed?
I have had success in ‘getting’ the file.qi contents …
1a. How is the notecard made aware of the incoming ‘file’ change in minimal mode?
During a synchronization request. There is no special mechanism for minimal mode.
1b. Do I need to issue a “hub sync”?
Yes.
1c. when should that command be sent?
hub.sync will update all Notefiles and synchronize the Notecard with Notehub. If the ATTN pin is armed (on a Notefile trigger), it will fire if the specified Notefile was updated during the synchronization. The ATTN pin should be armed prior to synchronization, in order for it to fire upon a Notefile change.
When using the Notehub UI or related web API, a Note is enqueued on the service almost instantaneously. The delay is related to the amount of time it requires for the Notecard to connect to the cell tower, phone home to Notehub to check for enqueued Notes, and transfer the payload onto the Notecard. These times are heavily dependent on the reliablity of the cellular connection, and are non-deterministic.
In my experience, if you are already connected to the the tower (which you won’t be) with a solid connection, then the message will arrive in a few seconds.
It is nearly impossible to predict the amount of time required for your Notecard to wake and establish a connection with the cellular tower. As you have experienced, this can take a matter of seconds to minutes.
Hi Zak – thanks for the helpful quick response. Another related question …
Is there a maximum time that a notefile can be updated after a Notefile trigger/hub.sync? For instance, I arm the ATTN pin and issue hub.sync at 8:00 AM this morning? If a notefile change occurs tomorrow at 8 AM, will the trigger occur? or do I need to re-arm and (hub).sync after a set amount of time?
Hi @richf ,
I’d like to better understand your application.
I assume you have a host processor ?
You would like to leave your host processor in a low power state and have the notecard wake it when there is incoming (.qi) notes ?
You require low power consumption ?
Could you let us know if the above is all true, and if not where my assumptions are incorrect. I believe you will either need to use hub.set,mode:periodic , if low power is a requirement, or hub.set,mode:continuous,sync:true if low latency is a requirement.
I think using hub.set.mode:minimum is not optimum if you want the Notecard to wake your host CPU with the attention pin, because in minimum mode the Notecard will only sync to check for new .qi notes on receipt of a hub.sync request - meaning your host CPU has to keep waking and issuing the requests. If you use periodic or continuous mode the Notecard will sync and alert your host processor autonomously.
The ATTN pin is latching, so there is no expiration. It will only trigger based on one or more of the configured events.
@seant is raising a good point though. Based on how you are discussing the usage, it sounds like you may be overlooking a core feature of the Notecard.
The Notecard idles at ~8uA. The benefit is that you can set it to wake and sync on a “periodic” interval; let’s say 24 hours. Then it will wake up and sync automatically, without requiring you to issue an explicit hub.sync command. If any new Notes have arrived, then the ATTN pin will fire. This could be hooked to an interrupt on your MCU, or to the EN pin. Based on your system requirements, this can be one of the easiest ways to achieve low power.
We have a couple guides on the topics of ATTN and low power that may be interesting to you:
Thx for the feedback. My current setup pretty much duplicates your suggestion – the ATTN pin feeds an input port on our host which interrupts upon ATTN firing.
The end ‘user’ would typically tap a button on their phone which sends a command to the cloud, the Notehub, the Notecard and finally our host. The message is extracted after the ATTN pin fires by issuing note.get . He/she would expect a ‘timely’ response to the command – typically no longer than a few minutes. I currently have the ‘wakeup period interval’ set to 2 minutes to achieve a ‘timely’ response. Upon receiving all the incoming ‘notes’ , I re-arm the ATTN pin – thus putting the Notecard back to idle.
Do my assumptions/method sound correct … especially the wakeup period timing and putting the Notecard back to ‘idle’ state?
Actually, if you are time sensitive and not battery sensitive, then I would point you at the Minimizing Latency guide instead. Again this would eliminate the need for you to manually (or unnecessarily) sync with Notehub.
It works by maintaining a continuous connection to both the cellular tower and then again with Notehub. It is quite responsive and should definitely be considered in your design if possible.
In the coming weeks I will be adding a section to the guide as well as documenting a new API, that will further trim the latency down to the bare minimum beyond basic cellular latency.