An RF engineer can spot a sudden signal drop on a chart in seconds. Understanding it takes longer. The team still needs to find the corresponding place and time, check the serving cell and logged events, and decide whether the observation is strong enough to support an engineering action. CAKRA is built around that second part of the job.
The CAKRA drive-test workspace gives teams one place to import a supported file, review measurements alongside their route, inspect the evidence behind a finding, and prepare a report. The goal is a shorter path from field data to a reviewable decision, while keeping the limits of the source data visible.
A chart is a starting point, not a conclusion
A low RSRP value might be part of a sustained weak segment, a brief passage behind an obstruction, or a record with incomplete GPS. A serving-cell change might sit beside a logged mobility event, but that proximity alone does not establish why the change happened or whether a handover succeeded. Reading one metric without the surrounding route and event history can turn an observation into a claim the data cannot support.
CAKRA places the time series, map, events, and RF review in the same session. An engineer can narrow the sample range, return to the source observation, and compare what each view says about the same interval. The map is spatial context for the measured path; it does not turn a drive route into a survey of an entire coverage area.
From import to a finding that can be checked
The web workspace parses supported drive-test files in the browser, including G-NetTrack TXT and bounded G-Net ZIP packages with a paired events KML. Headered CSV and TXT files use their column names to identify measurements. During import, CAKRA keeps source references and reports rejected rows, so a clean-looking chart does not hide uncertainty introduced by the file format or parser.
A filtered RF review carries its selection into related views. Logged events are associated with nearby measured samples only within a bounded time window; ambiguous matches are left out rather than attached to the wrong selection. The chart also offers a table of underlying samples for keyboard access and exact evidence inspection. These details matter when a team needs to repeat the review or explain why one candidate was included and another was not.
A report that carries its method with it
The engineering report brings together measurement summaries, valid-sample counts, candidate weak segments, serving-cell behavior, data-quality checks, and source traceability. Route length is calculated only across connected GPS samples that pass time and implied-speed limits; jumps and long unmeasured gaps are counted as breaks instead of being added as travel distance. A reader can see both the result and the rule used to obtain it.
The report calls these results candidates for engineering review. A weak segment is not a proven root cause, and sequential cell transitions are not proof of interference. To move from a candidate to a field decision, an engineer still needs to inspect site configuration, measurement conditions, available signaling, and, when necessary, a repeat drive.
Cici helps navigate the evidence
Inside the web workspace, Cici can answer questions about the selected session, sample window, or opened finding. The assistant receives a bounded aggregate context rather than raw drive-test files, source filenames, or precise route coordinates. If AI assistance is unavailable, CAKRA can still produce a local, scope-aware summary, so the review does not depend on one provider response.
An assistant response is a way into the evidence, not a verified diagnosis. The underlying measurements, sample counts, and source records remain the material to inspect. An account gives access to the drive-test workspace: import a supported log, check parse quality, investigate a suspicious interval, and document remaining uncertainty before discussing a field action. CAKRA does not change a live network or certify coverage on its own.