Free Precise GNSS Positioning for Your Asset Tracker: What Swift Navigation's Skylark Actually Gets You
Someone on your team saw the words “free precise GNSS corrections” and now there’s a Jira ticket asking why your tracker only reports position to a few meters. Fair question. Centimeter accuracy sounds like a straight upgrade, and if it’s free, why wouldn’t you take it?
Because it isn’t free the way you think, and you probably don’t need it.
This is a hands-on look at what integrating Swift Navigation’s Skylark corrections actually takes: the receiver you’ll need, the data path, the power hit, and the battery math. I’ll also make the case that for most asset tracking, meters are the right target and centimeters are a tax you’re paying for nothing. If you’re mid-build on a GNSS asset tracker, this should save you a few wrong turns.
What Skylark Actually Is
Skylark is a cloud-based GNSS corrections service from Swift Navigation. It’s data, not a chip. You don’t buy a Skylark module. You feed correction data to a GNSS receiver you already have, and the receiver computes a better fix.
The approach is PPP-RTK (sometimes called SSR, State Space Representation). Instead of a single nearby base station like classic RTK, Skylark models error sources across a region: satellite clocks, orbits, ionospheric and tropospheric delay. It streams those corrections to your device, which applies them to improve the raw position.
For Skylark precise positioning to work, you need a compatible multi-band receiver (more on that below) and a live path to pull the correction stream.
Pin this down before you commit anything. As of writing (confirm the month and year yourself against Swift’s current docs), the published figures cover accuracy claims, convergence time, coverage regions, delivery method, and pricing tiers. All of these change. Swift has offered developer or free tiers in the past, usually with limits on volume, region, or commercial use.
Don’t quote me on today’s numbers. Go to Swift Navigation’s docs, read the current SLA and coverage map, and check whether “free” means a real production tier or a trial. u-blox PointPerfect and Point One Navigation play in the same space with similar models, so if you’re evaluating, look at all three rather than anchoring on one headline.
The one thing that won’t change: Skylark improves a fix your receiver already computes. It doesn’t create positioning where there’s no sky view.
What It Takes to Integrate a Skylark GNSS Asset Tracker
Start with the receiver. Precise corrections need a multi-band receiver, typically L1 + L5 (or L1 + L2 on older parts), with support for ingesting a correction stream. A single-band GPS module, the kind on most cheap trackers, can’t use this. That’s a BOM change, not a firmware flag.
Next, the data path. Corrections have to reach the device somehow, usually over IP via cellular. That means a modem, a SIM, a data plan, and the power and cost that come with all three. Bandwidth is modest but continuous while you’re converging. If connectivity drops mid-convergence, you fall back to whatever the receiver can do on its own, which is regular GNSS accuracy.
Corrections source ──► Data link (cellular/IP) ──► GNSS receiver ──► Fix
(Skylark) [bandwidth + power] (multi-band) (converged)On the firmware side, you’re parsing the correction stream, feeding it to the receiver over UART or SPI, and watching for convergence. Convergence is the catch. PPP-RTK doesn’t hand you centimeter accuracy the instant you get a fix. It walks the solution in over tens of seconds to a few minutes depending on conditions, sky view, and how fresh your ephemeris is. Cold starts are worse.
That convergence window is where the power budget takes the hit. A single-band tracker can wake, grab a coarse fix in a few seconds, and sleep. A precise setup has to keep the receiver and the modem powered through the whole convergence period, every time, to reach and hold the accurate solution.
Rough math. Say convergence adds 60 to 120 seconds of receiver and modem on-time per fix, against a 5-second coarse fix. That’s 10x to 20x more active energy per position. Multiply that across a fix schedule of, say, every hour for two years and the battery difference is not a rounding error. Model it against your real duty cycle before you decide. A power budgeting guide for trackers is worth an afternoon here.
The Honest Accuracy Question
Here’s the question the Jira ticket skipped: does centimeter accuracy change any decision your system makes?
For most asset tracking, no. You need to know which yard, which zone, which truck. Not which 3 centimeters of the yard.
Use case | Accuracy needed | Precise GNSS worth it?
-----------------------------|-----------------|------------------------
Container / pallet in yard | 5-50 m | No
Fleet / vehicle location | 1-10 m | Rarely
Construction equipment site | 1-5 m | Sometimes
Survey / lane-level / robots | cm-dm | YesLook at the top row. A container in a yard needs to resolve to the right yard and maybe the right stacking row. That’s 5 to 50 meters. Standard GNSS already clears that bar on a good day. Paying power and BOM for centimeter accuracy IoT here buys you precision the business logic throws away.
Fleet location is similar. Knowing a truck is on I-80 near exit 12 is the whole job. Lane-level matters for advanced driver assistance and autonomy, not for “where’s my truck.”
The rows where precise GNSS earns its keep are real but narrow: survey work, machine guidance, autonomous robots, lane-level navigation, precision agriculture steering. If you’re building one of those, stop reading and go integrate Skylark. You need it.
If you’re not, run the tradeoff honestly. Precise GNSS shortens battery life, forces a multi-band receiver, adds a correction subscription, and usually adds cellular. Against that, you get accuracy your product spec probably rounds off. That’s a lot of cost for a number nobody downstream reads.
The trap is treating accuracy as free upside. It’s a spec you pay for in watts and dollars, so match the tier to the business requirement, not to the best number on the datasheet.
The Low-Power Alternative: BLE + Satellite
For the “meters is plenty, and I want two years on a battery” case, there’s a different architecture worth putting on the table.
Hubble runs BLE GPS hybrid tracking the other way around. Your device transmits a standard Bluetooth Low Energy advertising packet, and that packet gets picked up by satellites overhead. No cellular modem, no gateway, no correction subscription. A coin cell and a BLE SoC you already know how to program.
The Hubble asset tracking guide walks through the model, but the short version: BLE handles proximity and zone detection on the ground, and satellite backhaul carries the packet over wide areas with no local infrastructure. Putting satellite positioning in a device this simple surprises people, because it doesn’t need the power or the BOM you’d assume.
The “zero gateway” piece is what really cuts deployment cost. Cellular trackers need coverage and a data plan per device. Gateway-based BLE needs you to install and maintain readers wherever assets go. Both break down at the edges of coverage or budget. A device that talks straight to satellites skips the gateway network entirely, which matters when your pallets end up somewhere you never planned for.
Accuracy lands in the meters-to-tens-of-meters range depending on mode, which puts it squarely on the top two rows of that table. If your use case lives there, this is the cheaper, longer-lived path. The terrestrial and satellite SDK docs show what the firmware side actually looks like.
When would you not pick this? When you genuinely need sub-meter, per the accuracy table. Then precise GNSS is the answer and BLE-plus-satellite isn’t trying to compete.
Decision Guide: Which Path for Your Tracker
Run your product through one question first.
Do you need sub-meter accuracy?
│
No ├──► BLE + satellite (Hubble): low power, no gateway
│
Yes └──► Multi-band receiver + Skylark corrections
(accept power + connectivity + BOM cost)Be strict about “need.” Not “would be nice,” not “the competitor’s datasheet says centimeters.” Need means a decision in your system genuinely depends on sub-meter resolution.
If the honest answer is no, take the low-power path and put the saved battery and BOM into more devices or longer service life. If it’s yes, commit fully: budget for the multi-band receiver, the correction stream, the connectivity, and the convergence power. Half-measures get you the cost without the accuracy.
Before You Commit
Precise GNSS is genuinely good technology, and Skylark is a clean way to get it. It’s just rarely the right default for a GNSS asset tracker, because most tracking needs meters and the market keeps selling centimeters.
Confirm Skylark’s current accuracy, convergence, coverage, delivery method, and pricing on Swift’s own docs, and write down the date you checked. Then hold that against the one question that matters: whether any decision in your product actually depends on sub-meter accuracy. Pick the tier that matches the business need, and let the battery and BOM savings be the reward for not over-buying.
Meta description: An honest integration guide for engineers weighing Skylark precise GNSS corrections against low-power BLE + satellite tracking. Match accuracy to need.
Feedback notes for editor:
- Placeholder anchors used for the power budgeting guide and Hubble asset tracking guide (marked
#). Drop in real URLs. I linked the SDK intro doc directly since it’s stable; swap if you prefer a product page. - All Skylark specs are deliberately unstated. Add the concrete “as of [month] [year]” figures only after verifying against Swift’s live docs, or leave as-is if you’d rather not date-stamp.
- No cringe flagged. Tone stays engineer-to-engineer and the Hubble section makes the case without overclaiming (accuracy stated as meters-to-tens-of-meters, which you should confirm matches current published Hubble figures before publishing).
- Word count ~1,480, within target.
Hubble Network delivers global asset tracking over Bluetooth-to-satellite, no cellular contracts or high-power GNSS fixes required. See how it works →