Making Wireless IoT Project Easy, Smart, Secure.
GET A FREE SAMPLERecently we helped a device customer track down an inconsistent TTFF problem. Below is how the debugging went and what we concluded, shared for fellow engineers.
The symptom was straightforward: on the customer’s assembly line, 10 SKG123Q sample units were tested one by one, with every first-fix time under 5 s — the report looked perfect. After shipment, end users reported that about one device in five needed more than 40 seconds after power-on before it output a position. The customer’s first reaction was a batch-consistency problem with the GNSS modules: same lot, so why are some fast and some slow?
Once we got involved, we ruled out the modules first: re-testing the same batch on bare boards in a standard setup showed a consistent TTFF distribution with no outliers. The problem lay in the integration and in the test criteria, and the root cause comes down to one sentence: cold start, warm start, and hot start are three different physical processes, and the production line and the field each hands the device different “prerequisites.”
GNSS positioning depends on four pieces of information: ephemeris, almanac, time, and position. The start mode is mainly determined by whether the ephemeris and almanac are valid: valid ephemeris means hot start; ephemeris invalid but almanac valid means warm start; both invalid means cold start. Typical first-fix times are roughly as follows:
| Start mode | Ephemeris | Almanac | Time | Position | Typical TTFF |
| Cold start | No | No | No / inaccurate | Unknown | 20–40 s |
| Warm start | No | Yes | Yes | Yes | 10–20 s |
| Hot start | Yes | Yes | Yes | Yes | 1–5 s |
Two points are frequently underestimated in practice:
An ephemeris keeps its best accuracy for about 2 hours (firmware policy varies by vendor, typically 2–4 hours). Once a device stays in deep sleep past that window, hot-start performance degrades and the device may fall back to a warm start; if both the main supply and the backup battery are cut off, the ephemeris, almanac, time, and position are all lost, and the device falls back to a cold start at power-up.
Time and position are not optional aids — they are preconditions for the search. Only with an approximate position and the satellite orbit data can the receiver compute the currently visible satellites and predict each satellite’s Doppler shift, compressing the two-dimensional code-phase/frequency search space to a manageable size. Drop either one and the receiver can only search the full frequency range across the whole sky — elapsed time jumps to a new level rather than growing linearly.
So a production report stating “TTFF ≤ 5 s” without the start mode is, strictly speaking, neither reproducible nor comparable. That was exactly the trigger here: during the customer’s production test the test tool was still connected, time and position were correct, and the device started in hot-start mode; in the end users’ hands those prerequisites were missing or stale, and behavior was naturally completely different. This was not a module consistency issue — the test criteria simply didn’t separate results by start mode.
Combining this case with what we see in after-sales support, elevated TTFF in real products falls into the following categories, ranked by frequency:
1. Expired ephemeris (most frequent)
Devices can sit two to three weeks between the production line and the end user, unpowered part of that time — by then the ephemeris is long expired. Even more common: once a deep sleep outlasts the ephemeris validity window, the firmware still assumes hot-start conditions and never downgrades, so the UI sits on “locating…” for ages. This one needs no hardware defect — the passage of time alone triggers it — and it accounts for the largest share of our cases.
2. The position injected during production is too far from the actual deployment site
The coordinate written at the production station is the factory’s location, but the device ships thousands of kilometers away. The receiver computes the visible satellites from the wrong position, so the satellites and frequencies it searches first don’t match the current sky; it wastes one round of searching, then falls back to a full-sky scan. A position that exists but is wrong costs more than no position at all — with no position the receiver goes straight to a full-sky strategy and never heads down the wrong path. This deserves particular attention for products shipped across regions or borders.
3. Accumulated RTC time error
While unpowered, the RTC keeps the time. The ±20–50 ppm error of an ordinary 32.768 kHz crystal works out to about 2–4 seconds per day; after a month sitting idle, the accumulated error can reach minutes, and the crystal deviates further at low temperature. Once the time error exceeds the range Doppler prediction can cover, the prediction is useless and the receiver falls back to a wide search anyway. This is the classic “we injected time at the factory — why is it slow again?” case.
4. Poor signal at the time of positioning
Production testing happens on an open-sky bench. Once the enclosure is closed, the antenna installed, and the unit mounted on a vehicle, the overall C/N0 baseline can drop by 5–10 dB-Hz; add tree shade or a parking-garage entrance and the signal sits near the capture threshold, looping capture → fail → retry, stretching TTFF. The module itself isn’t “bad” here — the product’s RF environment ate into the specification — and the production-test environment never shows it.
5. A-GNSS assistance data unavailable (assisted products)
The factory has network access; field networks vary widely, some on private lines. If the assistance download times out, the receiver falls back to a cold start — and at the time, that fallback path had no timeout protection, so the UI kept waiting indefinitely. Production and field networks differ, so this class of problem is virtually guaranteed to occur.
One more note: power-cut anomalies like VBAT dropping to zero during a battery swap and taking the RTC with it — we checked those during debugging too. They are hardware defects, and routine production operations (battery-swap and power-cut tests) catch them almost every time; they are not typical field problems and are therefore not in the ranking above. Firmware that forces a cold start at power-up is the same story — one production-test run exposes it.
In fairness, this class of problem is common in integration work, and design teams can’t be blamed for it — most module datasheets give a single TTFF figure without stating test preconditions. That’s why we added a dedicated section on TTFF test criteria to our documentation and FAE support process: a specification only has engineering meaning when it ships together with its conditions.
Item 7 is the decisive test. If injecting time and position drops TTFF from 40 s to 5 s, the antenna and RF chain are ruled out immediately and the problem must be missing start-state information; then work through items 1–5 in order. Here, that experiment pinpointed the root cause in three minutes — you don’t guess at problems like this; you need a test sequence that isolates one variable at a time.
Copyrights© Shenzhen Skylab Co.,LTD All Rights Reserved.
