Transparent methodology

How SupaKewber calculations work

This page defines calculations used in the timer, profiles, leaderboards and first-party research, including the limits of smart-cube measurement.

Timing and stage analysis are calculated from recorded events, not estimated from a finished time. Manual timing records a start and stop. Smart-cube timing can additionally record moves, cube-state milestones and the solved state when the Bluetooth stream remains synchronized.

Solve timing

Start, finish and penalties

MeasureHow it is calculatedLimitation
Manual solveElapsed time between the timer start and stop events, stored in milliseconds.No move stream, automatic CFOP split or TPS is claimed.
Smart-cube solveThe first accepted turn starts execution timing and the detected solved state ends it after scramble validation.Packet loss can desynchronize the physical and virtual cube; affected stage data is unreliable.
+2Two seconds are added when the penalty is applied.Current public research excludes +2 results unless stated otherwise.
DNFThe attempt is marked Did Not Finish.Excluded from personal-best and average calculations below.

Automatic analysis

How Cross, F2L, OLL and PLL are detected

After every accepted smart-cube move, SupaKewber evaluates the cube pattern in order. Cross is recorded when the four cross edges are solved relative to their side centres. F2L is recorded after Cross when the first two layers are solved. OLL is recorded after F2L when every last-layer piece is oriented. PLL ends at the fully solved state.

The stored values are cumulative milestone timestamps. Exclusive durations are:

Cross = cross milestoneF2L = F2L milestone − CrossOLL = OLL milestone − F2LPLL = solved milestone − OLL

A stage percentage is its exclusive duration divided by detected execution time, multiplied by 100. Missing, non-monotonic or overlong stage records are excluded from research.

Statistics

Singles, rolling averages and TPS

  • Current mean: arithmetic mean of valid results in the selected timing mode.
  • Ao5 and larger: each consecutive window drops one fastest and one slowest result, then averages the remainder. The fastest eligible window is the recorded best average.
  • Personal best: the lowest non-DNF time of at least 3.00 seconds in that timing mode.
  • TPS: accepted move count divided by execution seconds; protocol reporting and rotations can affect it.
  • Mode separation: manual and smart-cube histories and personal-best state are kept separate. Public smart-cube leaderboards use smart-cube results.

These are training calculations, not an official WCA competition system.

First-party research

Publication rules for aggregate data

Unless a dataset states otherwise, solve research uses completed 3×3 solves between 3.00 and 120.00 seconds and excludes DNFs, +2 penalties, deleted solves and invalid stage timestamps.

A SupaKewber cell normally publishes only after at least 20 distinct users and 100 eligible observations. Anonymous connection telemetry has no account identifier and requires at least 100 observations. Smaller cells remain suppressed.

Datasets include sample size, date range, definitions, inclusion and exclusion rules, last-updated date and CSV or JSON downloads where appropriate. See the research methodology and data catalogue.

External data

Official WCA data is kept separate

When SupaKewber analyses the WCA public export, the page identifies the WCA as the source and applies separate filters suited to official competition results. WCA results are not relabelled as practice data, and practice solves are not presented as official results.

Questions unsupported by the source are reported as limitations. For example, age is not inferred when the export lacks a valid date-of-birth field.

Interpretation

What the numbers do not prove

SupaKewber users are self-selected, supported hardware is unevenly distributed, and practice conditions differ from official competitions. Results describe eligible records in the stated window; they do not automatically represent every speedcuber.

Bluetooth packet loss, an incorrect initial state, unusual solving methods and rotations can reduce move-aware reliability. Material method changes are dated and documented.