One old Apple's bug and its remedy.

*The problem I am going to explain now has been always there as far as I know. Thus, I don't know whether this problem appeared some day, or has been there since its beginning, or has been fixed very recently while I haven't noticed. However, I highly suspect that the problem is still there from the beginning to now, and no one seems to be interested in addressing or fixing this issue while it is very annoying problem in practical use.

In Apple's API, Gyro data is represented in CMAttitude 3D Euler angle object, and this has 2 different representations, rotation matrix and quaternion. Mathematics proves that there shall be 2 singularities, north and south pole. Due to Apple's weird coordinate definition (Getting Raw Gyroscope Events | Apple Developer Documentation), those singularities happens at very annoying position: as far as I remember, it is upright position. Anyway, I remember that the position was in very frequent daily use area.

Now, when you want to measure relative rotation, you may use 

• CMMotionManager.startDeviceMotionUpdates(using referenceFrame: CMAttitudeReferenceFrame, ...)

or

• CMAttitude.multiply(byInverseOf: CMAttitude)

but any of these move singularities. I think this seems that Apple internally performs operation between two CMAttitude object by converting into quaternions and multiplying them. As the conversion to quaternion is not a one-to-one function, quaternion operations seems not to move singularities.

If you replace CMAttitude.multiply(byInverseOf: CMAttitude) to explicit CMMatrix multiplication, you can confirm that the singularities move to the farthest points from the reference attitude.

IEC Standard Weightings

Transfer functions:

\(H_A(s)=\dfrac{(12194\,\mathrm{Hz})^2\:\left(\frac{s}{2\pi}\right)^4\:\big/\: e^{-2.0000/20}}{(\frac{s}{2\pi}+20.6\,\mathrm{Hz})^2\,(\frac{s}{2\pi}+107.7\,\mathrm{Hz})\,(\frac{s}{2\pi}+ 737.9\,\mathrm{Hz})\,(\frac{s}{2\pi}+12194\,\mathrm{Hz})^2}\)

\(H_B(s)=\dfrac{(12194\,\mathrm{Hz})^2\:\left(\frac{s}{2\pi}\right)^3\:\big/\:  e^{-0.1697/20}}{\left(\frac{s}{2\pi}+20.6\,\mathrm{Hz}\right)^2\:\left(\frac{s}{2\pi}+158.5\,\mathrm{Hz}\right)\:\left(\frac{s}{2\pi}+12194\,\mathrm{Hz}\right)^2}\)

\(H_C(s)=\dfrac{(12194\,\mathrm{Hz})^2\:\left(\frac{s}{2\pi}\right)^2\:\big/\:  e^{-0.0619/20}}{\left(\frac{s}{2\pi}+20.6\,\mathrm{Hz}\right)^2\:\left(\frac{s}{2\pi}+12194\,\mathrm{Hz}\right)^2}\)

\(H_Z(s)=\dfrac{(2\pi\cdot 46066\,\mathrm{Hz})^2\:s^2}{(s+2\pi\cdot 4.34\,\mathrm{Hz})^2\:(s+2\pi\cdot 46066\,\mathrm{Hz})^2}\)

\(H_K(s)=\dfrac{1.5848634463348217\,s^2+18886.914378028894\,s+1.1260607147003824\times10^8}{s^2+15004.846526655707\,s+1.1259450726979023\times10^8}\)

\(\times\dfrac{1.0049948987146884\,s^2}{s^2+478.91221140843305\, s+57414.259359025615}\times 10^{-0.691/20}\)

\(\times\dfrac{(2\pi\cdot 46066\,\mathrm{Hz})^2}{(s+2\pi\cdot 46066\,\mathrm{Hz})^2}\)

*only A,C,K are standard

For RMS, after squaring, averaging technique may be RC LP filter.

for VU meter standard, RC = 0.0651442s equiv 2.44312 Hz

for loudness RMS (LKFS standard) RC = 0.392323 equiv 0.405674 Hz

https://en.wikipedia.org/wiki/A-weighting

https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf

https://www.dsprelated.com/freebooks/filters/Low_High_Shelving_Filters.html

https://en.wikipedia.org/wiki/LKFS

Baseus Charger may damage your iPad

Seems some ESD? cause iPad malfunction during charging by Baseus 65W 2C1A charger. I am scary that this may someday damage my iPad. I continued to use it because another Baseus charger is USB-IF certified (no dual charger is certified. Maybe dual charging chip is outside of the standard in any way.) But now my Apple Pencil started to glitch all over the screen to I may have to stop to use.

CMAttitude singularity

 By experiment, you can figure out q = (cos(yaw/2) + k sin(yaw/2)) * (cos(pitch/2) + i sin(pitch/2)) * (cos(roll/2) + j sin(roll/2)) where yaw and roll are in \([-\pi, \pi]\) and pitch is in \([-\pi/2, \pi/2]\). 

Since quaternion <-> rotation matrix is not one-to-one, we have to play with original expression, matrix. As apple's rotation matrix is active rotation, (current rotation matrix) = (relative matrix) * (reference frame rotation matrix). This gives proper singular points, 90deg and -90deg pitch from the reference attitude. If you just use quaternion i.e. CMAttitude system API, singularities are at the fixed point, absolute 90, -90deg pitch point. 90deg pitch point is right at the attitude when you are holding phone right up, which is pretty annoying.

little tips to close overlay on SwiftUI

 This is about the architecture of SwiftUI.

Objective: I want to open and close little overlay message box.

When closed, I don't want to use system resource, and additionally I'll be happy if I can use onAppear and onDisappear.

Also, I want my closing animation work properly.

Implementation:

1. Use complete object destruction by defining 

func View.overlay(_ view: View?) -> View {
    if view == nil{

        self

    }else{

        self.overlay(view)

    }

}

In this way, when I started closing animation by withAnimation{overlayView = nil}, the screen shows preview of the main view, so I see all the blinks and glitches.

2. opacity -> 0

By this method, I am worried that I cannot achieve the objective. It is wasting my resources and I think I cannot use onDisappear.

3. hidden(_ bool: Bool)

Define this function for View. This worked perfectly so I did not tested 2nd option. I think this is supposed to do, designed by Apple developers.

In this way, onAppear is called *when the mainview.overlay() is called * when overlay is unhidden *but not when overlay is not completely hidden but new appearance is called. onDisappear is called *when overlay is completely hidden (end of animation) *but not when overlay hiding animation is over but new overlay unhiding is called.

iOS 14.4.1 critical bug

 Local paths are inaccessible in Files app. When you try to access it, app freezes.

Calculation of crosstalk in common ground cable (e.g. 3.5mm)

 Cross talk is roughly the voltage difference made by the resistance of common ground cable.

For example, let's assume AWG 24 1m cable. Single thread of it has R_(CG)=83.4mOhm.

Also let's assume 75dBA listening sound in 105dB/mW, R=47Ohm headphone.

Then, V = 6.856mV = -43dBV = -41dBu 

I = 145.9uA.

The crosstalk = I*R_(CG)/V = R_(CG)/R. (in voltage ratio i.e. dB = 20 log(V/V))

If we aim for -85dB crosstalk in 47ohm headphone, 3.5mm cable must have less than 2.6mOhm.

This is from TI's crosstalk guideline.

83.4mOhm is 32x of 2.6mOhm so -85dB+30dB = -55dB crosstalk in 47ohm headphone with AWG24 1m cable.

One more example. Take best case Silver AWG18 0.5m cable. Cable resistance is 10mOhm. Take 600Ohm headphone. Then the crosstalk is 20log(0.01/600) = -96dB.

Difference between copper and silver is 0.5dB. Best thing to do is to make sure cable thick.