In this article:
Design Consideration: Internal vs. External GNSS
Reliable communication over the HyperPulse Non-Terrestrial Network (NTN) requires the modem to possess an up-to-date location and time reference. While the nRF9151’s onboard GNSS is capable of meeting these network requirements, your choice between Internal and External GNSS should be driven by your specific use case.
1. Static Use-Cases (Internal GNSS)
- For stationary devices where high-precision location tracking is not the primary function, the internal GNSS module on the nRF9151 is sufficient.
- By default, the HyperPulse Library triggers a GNSS fix using the internal module upon startup. It latches this location and uses these coordinates for all subsequent NTN communication.
- The system assumes the device remains stationary for its lifespan. If the device experiences transient movement prior to final installation (e.g., during transport), you must perform a power cycle or system reset at the time of deployment. This forces the HyperPulse library to acquire a fresh GNSS fix for the final deployed location.
2. High Mobility High Precision Use-Cases (External GNSS)
- For applications requiring high-precision tracking (e.g., Fleet Monitoring, Logistics), the internal GNSS module may not meet the desired accuracy and low-power requirements. In these scenarios, an external GNSS module is highly recommended.
- To maintain reliable connectivity while moving, the device must have the most up-to-date location data before every NTN session.
Integration: You can inject high-precision location data from an external GNSS module directly into the HyperPulse library. This ensures the modem uses the most accurate coordinates for satellite negotiation.
Implementation: Feed the external GNSS coordinates into the library using the following AT command:
AT#MLOCATION=<latitude>,<longitude>,<elevation>
3. Limited Mobility High Precision Use-Cases (External GNSS)
- For applications with limited mobility (< 20 km radius) requiring high-precision tracking (e.g., On-Farm Tracking, Cattle tracking), the internal GNSS module may not meet the desired accuracy requirements. In these scenarios, an external GNSS module is highly recommended.
- As the mobility is limited and confined to less than 20 km radius, there is NO hard requirement to refresh the location before every NTN session to maintain reliable connectivity.
Integration: You can inject high-precision location data from an external GNSS module directly into the HyperPulse library. This ensures the modem uses the most accurate coordinates for satellite negotiation.
Implementation: Feed the external GNSS coordinates into the library using the following AT command:
AT#MLOCATION=<latitude>,<longitude>,<elevation>
Design Consideration: Energy Optimisation
Acquiring a GNSS fix is a high-energy operation. For battery-powered devices, you must carefully synchronize the frequency of these fixes to balance location accuracy with power consumption.
Static Optimization: Leverage the default HyperPulse configuration. Since the device only requires a single fix upon startup (via the internal nRF9151 GNSS), energy consumption is minimized for the remainder of the device's operation.
Mobility Optimization: Application logic is critical here. To prevent unnecessary battery drain following design choices are recommended:
- Motion-Triggered fixes: Only trigger a GNSS fix when the device detects motion (e.g., via an accelerometer).
- Session Synchronization: For high mobility scenarios, time your GNSS acquisition to occur just prior to an upcoming NTN session, ensuring the location data is fresh without wasting energy on fixes that go unused
Design Consideration: Time keeping
The HP lib provides AT command interface to retrieve the system time as UTC epoch in relatively low accuracy ( <2 second off). The system time is not monotonic.
The Zephry library provides APIs to get higher resolution relative time, e.g. k_uptime_get. By default, the clock is configured to be monotonic using 64 bits to avoid rolling over. The clock is subject to drift as well (<2s per day). The drift is cumulative.
If the application has more strict requirements for system time and clock, separate time-keeping logic may need to be implemented, e.g. with the help of the external GNSS.
Summary
| Use Case | Recommended GNSS Hardware | Connectivity Requirement | Implementation Logic | Energy Optimization Strategy |
| 1. Static(e.g., Fixed infrastructure) | Internal nRF9151 GNSS | GNSS fix on start-up and daily refresh would suffice. | Default HyperPulse Library: Uses internal GNSS fix on boot with a daily location updates Action: Perform system reset at final deployment site to ensure accurate location latching. |
Requires only a single GNSS fix during the device lifespan post final deployment |
| 2. High Mobility(e.g., Logistics, Fleet;) | External GNSS(For high precision and reliable connectivity) | Continuous Refresh: Must update location before every NTN session. | Inject Data: Feed external coordinates into HyperPulse library via AT Command. | 1. Sync GNSS fix to occur just before NTN session. 2. Use accelerometer to trigger fixes only during motion. |
| 3. Limited Mobility(e.g., Agriculture; <20km radius) | External GNSS(For high precision) | Daily GNSS Refresh: Movement <20km does not require a regular refresh for connectivity. | Inject Data: Feed external coordinates into HyperPulse library via AT Command. | Since connectivity is robust for movements within 20km radius, trigger fixes primarily based on application data needs rather than connectivity needs. |