🌑️  Monitor legacy analog systems with TinyML, Edge Impulse, and Blues Wireless. Learn more in our webinar on May 26th!

Search
Documentation Results
End of results
Community Results
End of results
Support
Blues.io
Notehub.io
Shop
Sign In
Search
Documentation Results
End of results
Community Results
End of results
Support
Blues.io
Notehub.io
Shop
Γ—
HomeGuides & Tutorials
Welcome
Collecting Sensor Data
Routing Data to Cloud
Fleet Admin Guide
Notecard Guides
Guide Listing
Asset Tracking
Attention Pin Guide
Connecting to a Wi-Fi Access Point
Debugging with the FTDI Debug Cable
Encrypting Data With the Notecard
Minimizing LatencyMechanism of ActionConfiguring Notehub InteractionsFlushing Queued Notes
Serial-Over-I2C Protocol
Understanding Environment Variables
Understanding Notecard Penalty Boxes
Updating ESP32 Host Firmware
Using External SIM Cards
Using JSONata to Transform JSON
Routing References
Twilio Route
MQTT Route
Azure Function Route
ThingWorx Route
Rate this page Β 
  • β˜…
    β˜…
  • β˜…
    β˜…
  • β˜…
    β˜…
  • β˜…
    β˜…
  • β˜…
    β˜…

Minimizing Latency

Latency is defined as, "The time interval between initiating a query, transmission, or process, and receiving or detecting the results."

The goal of this guide is to discuss options for minimizing the latency experienced between Notehub.io and a given Notecard. Minimizing latency typically comes at a trade-off in power draw (and potentially data usage - depending on your use case). However, when configured correctly, the Notecard will be opened to a whole new realm of possibilities.

Mechanism of Action

When modeling the flow of information between a Notecard and Notehub.io, you must first take into consideration the following maxim...

All synchronization operations are initiated from the device in a "push/pull" manner; the service is passive.

When you begin to think of a transaction in this manner, the capabilities and limitations of operations will become obvious. As a result, you will gain an intuitive understanding of what steps must occur in order to achieve your desired outcome.

A visual representation of Notecard to Notehub connection(s).

Above, the Notecard is operating in continuous mode with sync set to true. This configuration initiates two separate, simultaneous connections; one dedicated to Note delivery and the other dedicated to notifications.

Database Connection

As previously stated, any time the Notecard and Notehub communicate, that communication must be initiated by the Notecard. Therefore, in order for the Notecard to be gather new information from Notehub.io, the Notecard would need to issue requests to Notehub.io. The frequency of this polling request interval is specified by using the inbound parameter.

Ideally, you wish for the synchronization to occur as close as possible to the moment any data changes. In order to minimize latency by using the inbound parameter alone, the interval must be specified to be as small as possible. However, doing so would ultimately result in great inefficiencies for both data usage and power draw.

Fortunately, this limitation can be overcome by the introduction of a secondary communication channel, one dedicated exclusively to notifications.

Notification Connection

Proving Notehub.io with a mechanism to alert the Notecard of new Notes, while still initiating the transaction from the Notecard itself, has a more elegant and simple solution than you may have guessed...

When sync is set to true, the Notecard establishes a secondary connection, one dedicated to the notification of new Notes. This connection utilizes HTTP long polling to request the set of changes, and the server will only respond once changes become available. Now, when the Notecard becomes aware of any new Notes, it can immediately synchronize the Note queues on the primary connection.

Configuring Notehub Interactions

hub.set Request

req: "hub.set",
mode: "continuous",
sync: true,
inbound: <Number: polling interval in minutes>

mode: "continuous" Parameter

Once mode is set to continuous, a continuous connection is established between the Notecard and Notehub.io. Maintaining a continuous connection requires significantly more power than polling at a periodic interval, but the Notecard will have much faster response times as a result. A continuous connection prevents the Notecard from being required to power on, connect to a cellular tower (or a Wi-Fi access point for the Wi-Fi Notecard), and open a connection to Notehub.io with each transaction. All told, this can minimize the amount of data required for each transaction, as well as the time required to send messages in either direction.

sync: true Parameter

When sync is set to true, a secondary connection is established with the express purpose of allowing Notehub.io to signal that new data has arrived for the Notecard to process.

When Notes are received on Notehub.io, Notehub will send a list of the filenames that were modified to the Notecard. Then, the Notecard will issue a request for changes over the primary connection, and pull the new Notes from Notehub.io to the Notecard. Once they have arrived on the Notecard, then they can be operated on by your program.

If your application can benefit from knowing as soon as information becomes available on Notehub.io, then utilizing sync:true is the most efficient way to expedite Note arrival. Depending on your desired polling interval, operating in this manner can even result in power and data savings.

inbound: <Number: polling interval in minutes> Parameter

Inbound polling will force a synchronization at the specified interval, regardless of whether or not data is known to be queued on Notehub.io.

Theoretically, inbound would have no value when sync:true is enabled. However, in practice, inbound is a necessary evil, and must be used as a backstop to safeguard against connection failures or any other gaps in the secondary, notification connection. Scheduling an inbound interval provides a brute force guarantee to ensure queued data will be never be older than the specified interval.

Each inbound event will necessarily require a connection with Notehub.io, so it can perform a polling request. This transaction will consume both energy and data at the specified polling interval (i.e. for each transaction), so any interval should be selected with care and tailored to the needs of the application.

Flushing Queued Notes

Due to the fact the Notecard is the originator of all transactions between the Notecard and Notehub.io, it stands to reason the outbound operations should be considered separately from the inbound operations. Therefore, minimizing the latency on an outbound transaction is much more simple, because the Notecard controls the connection.

note.add Request

req: "note.add",
...,
sync: true

sync: true Parameter

When sync is set to true, the Notecard will immediately send the queued changes to Notehub.io. Otherwise, when not specified, or set to false, the Notecard will wait for the outbound interval to send the request.

note

Unlike inbound transactions, there is no need to specify an outbound interval as a fail-safe. This is due to the fact the transaction does not rely on a network or external signal to indicate whether or not it should attempt to synchronize queued Notes.

Additional Resources

  • hub.set
  • note.add
Can we improve this page? Send us feedbackRate this page
  • β˜…
    β˜…
  • β˜…
    β˜…
  • β˜…
    β˜…
  • β˜…
    β˜…
  • β˜…
    β˜…
Β© 2022 Blues Inc.Terms & ConditionsPrivacy
blues.ioTwitterLinkedInGitHubHackster.io
Disconnected
Disconnected
Having trouble connecting?

Try changing your Micro USB cable as some cables do not support transferring data. If that does not solve your problem, contact us at support@blues.com and we will get you set up with another tool to communicate with the Notecard.

Connect a NotecardClick 'Connect' and select a USB-connected Notecard to start issuing requests from the browser.