Known inconsistencies¶
phyphox exists as several independent implementations: the Android app, the iOS app, the Blockly editor, and the Arduino and MicroPython libraries. They are written separately, by different people, at different times. Where they disagree about the experiment file format or the remote-interface API, that disagreement is a bug, not a platform difference you should design around.
This page lists the divergences we know about. Each one also raises a warning on the documentation page it affects, so you find out where it matters rather than only here. Once a divergence has been corrected in every implementation, its entry is removed; the fix is announced in the release notes of the version that carries it.
This list is not complete
It records what has been checked so far. The absence of an entry for some corner of the format means nobody has compared the implementations there yet, not that they agree. Reconciling them is ongoing work spanning several releases.
If you hit a difference that is not listed, please open an issue - a concrete report with the file or request that behaves differently is genuinely useful.
Permanent platform differences¶
These differences are the intended contract - a platform limitation or a deliberate design choice. They will not be reconciled; account for them when writing portable experiments.
FFT output for input lengths that are not a power of two¶
fft-non-power-of-two-input · file-format
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.
Correct behaviour: 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.
| Implementation | Current behaviour |
|---|---|
| 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). |
Sensor metadata in /meta¶
meta-sensors · remote-interface
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.
Correct behaviour: 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.
| Implementation | Current behaviour |
|---|---|
| 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"). |
Observed on real devices: 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.