inconsistencies.yml

# Known inconsistencies between the phyphox implementations.
#
# One entry per divergence. Each entry renders in two places from this single
# source: an inline warning wherever the affected page writes the marker
#
#     {{inconsistency:<id>}}
#
# and a row in the generated "Known inconsistencies" page. See tools/hooks.py.
#
# Fields
#   id         short slug, used in the marker. Required.
#   title      one line, shown as the admonition heading. Required.
#   area       file-format | remote-interface | editor. Required.
#   status     open      - nobody has decided which behavior is correct yet
#              decided   - canonical behavior chosen, implementations not yet fixed
#              There is no "fixed" status: once every implementation agrees,
#              delete the entry (and its markers and spec references) in the
#              same commit as the fix. Readers learn about corrected behavior
#              from the release changelog; a lingering "recently corrected"
#              note only clutters the documentation.
#   canonical  what the correct behavior is. Required once status is decided.
#   affects    map of implementation -> observed behavior. Use the keys
#              android, ios, editor, arduino, micropython, wiki.
#   since      optional: format version or app version the divergence appeared in
#   issue      optional: URL of the tracking issue
#   verified   optional: when and against which builds the divergence was
#              actually observed on hardware, as opposed to read out of the
#              source. Absence means nobody has checked on a device.
#   summary    reader-facing explanation, one short paragraph. Required.
#
# Keep entries factual and cite where the behavior was observed, so the next
# person can re-check it rather than trusting this file.

- id: meta-sensors
  title: Sensor metadata in /meta
  area: remote-interface
  status: decided
  permanent: true
  canonical: >-
    Android-only, by platform limitation rather than by choice. iOS offers no API
    for per-sensor information such as model or manufacturer, so the values cannot be
    supplied there. The sensors object is therefore simply absent on iOS rather
    than present and empty.
  affects:
    android: >-
      Adds a "sensors" object with one entry per sensor, each carrying name,
      vendor, range, resolution, minDelay, maxDelay, power and version
      (RemoteServer.java, handleMeta()).
    ios: >-
      Serves only the non-sensor metadata; no "sensors" key
      (ExperimentWebServer.swift, "for metadata in Metadata.allNonSensorCases").
  verified: >-
    Confirmed on hardware 2026-08-02: Android 1.2.1-beta2 (build 1020102,
    Pixel 9 Pro, from development) against iOS 1.2.0 (build 17272,
    iPhone15,2, App Store build). The iOS WebServer sources are identical
    on master and development, so the store build behaves as the
    development branch here.
  summary: >-
    Android reports per-sensor metadata over /meta and iOS does not, even though
    iOS models the same values (Metadata.sensor) and serves them to network
    connections. A client cannot tell a phone without the data from a phone that
    does not report it.

- id: fft-non-power-of-two-input
  title: FFT output for input lengths that are not a power of two
  area: file-format
  status: decided
  permanent: true
  canonical: >-
    fft uses the fastest transform each platform offers, so only a
    power-of-two number of input samples is guaranteed to give identical
    results on both platforms - an experiment that needs a portable FFT must
    provide that. Any other length is
    implementation-defined. For exact transforms of arbitrary length a
    separate, slower dft module is planned; until it exists, non-power-of-two
    input is simply outside the guaranteed contract.
  affects:
    android: >-
      FFTW transforms the input length directly, and the Java fallback
      zero-pads internally but truncates back, so the output length always
      equals the input length (analysis.cpp fftw3complex, Analysis.java
      fftAM).
    ios: >-
      vDSP_DFT only accepts lengths of the form f*2^n with f in {1, 3, 5,
      15}, so other inputs are zero-padded to the next supported length and
      the padded, longer spectrum is returned (FFTAnalysis.swift,
      nextFFTSize).
  summary: >-
    A non-power-of-two number of input samples yields a different output
    length and different values on the two platforms; a power-of-two input
    gives identical results on both.