A user has reported a very strange observation depending on the operating system installed on the phone - it sounds like it is an issue on the Android side, not PineTime because the raw values are similar on both:
- Watch: PineTime with the current OSD firmware
- Phone: Xiaomi Redmi 13C
- OSD version: 4.3.1 (same version used throughout)
Potential problem:
When the OS was LineageOS, the ideal power threshold was approximately 700.
After I changed the OS to Xiaomi HyperOS (on the same phone, no hardware
changes), the ideal power threshold became approximately 7000.
Looking at the (local) log files for both OS configurations, I saw that
the accelerometer data recorded by the OSD is the same range of approx.
950 under both LineageOS and HyperOS. A sample of 125 raw values from
one 5-second window would look like this:
954.9 957.4 958.7 952.5 952.5 954.9 956.8 956.8 954.6 955.3 ...
Since the raw input data fed into the FFT appears to be identical, the
large difference in power output may originate inside the OSD's own
processing, not in the PineTime or through the Bluetooth communication?
Could this possibly be caused by the handling of the gravity baseline of
~950 before or during the FFT calculation? The actual movement remained
at roughly ±15 units around the ~950 value on both OS's. I suppose that
in case the baseline of 950 is subtracted correctly, the FFT will only
work on the small ±15 signal variance. If the subtraction is done
differently, then the FFT maybe processes the full ~950 value, which
could explain that spurious variance.
Maybe LineageOS and HyperOS handle the Android API calls differently?
So my amateurish-analysis:
- Raw accelerometer log values: ~950 range are identical under both OS
versions
- Optimal power threshold: ~700 under LineageOS, ~7000 under HyperOS
- App version: identical (4.3.1)
- Hardware: absolutely identical (same PineTime watch with the same
Xiaomi Redmi 13C)
- Could the variance be produced inside the OSD's FFT processing?
A user has reported a very strange observation depending on the operating system installed on the phone - it sounds like it is an issue on the Android side, not PineTime because the raw values are similar on both:
Potential problem:
When the OS was LineageOS, the ideal power threshold was approximately 700.
After I changed the OS to Xiaomi HyperOS (on the same phone, no hardware
changes), the ideal power threshold became approximately 7000.
Looking at the (local) log files for both OS configurations, I saw that
the accelerometer data recorded by the OSD is the same range of approx.
950 under both LineageOS and HyperOS. A sample of 125 raw values from
one 5-second window would look like this:
954.9 957.4 958.7 952.5 952.5 954.9 956.8 956.8 954.6 955.3 ...
Since the raw input data fed into the FFT appears to be identical, the
large difference in power output may originate inside the OSD's own
processing, not in the PineTime or through the Bluetooth communication?
Could this possibly be caused by the handling of the gravity baseline of
~950 before or during the FFT calculation? The actual movement remained
at roughly ±15 units around the ~950 value on both OS's. I suppose that
in case the baseline of 950 is subtracted correctly, the FFT will only
work on the small ±15 signal variance. If the subtraction is done
differently, then the FFT maybe processes the full ~950 value, which
could explain that spurious variance.
Maybe LineageOS and HyperOS handle the Android API calls differently?
So my amateurish-analysis:
versions
Xiaomi Redmi 13C)