Hi Nikolaus,
Couple of thoughts below.
On Wed, 2020-07-29 at 19:19 +0200, H. Nikolaus Schaller wrote:
Am 29.07.2020 um 18:58 schrieb H. Nikolaus Schaller < hns@goldelico.com>:
Am 29.07.2020 um 18:04 schrieb David Shah dave@ds0.me:
Hi all,
I tried adding a 470nF 0402 capacitor in what I hope was the right place (see attached),
yes, from a first glance it looks to be right!
and replacing the associated resistor with a short. Sadly that made no difference, but maybe 470n isn't high enough (I also have 4.7u 0805 but I suspect that might be too tall.
Hm. I hope I find some minutes to open my sample and try the same. Then we know.
Here is a full picture where I tried tp mimic the colours:
Yes, that matches what I did.
Maybe the copper trace between the C and the R is too small. So a wire directly across all three solder pads could be better. Or scratching off the solder mask from the ground plane around and soldering the capacitor directly to GND.
In my second attempt with 4.7u, I did effectively end up with one solder blob all the way across that should be pretty low impedance.
If I find time (which is unfortunately unlikely) I could add two wires to the pads of the capacitor and get them outside the Pyra to be able to measure the voltage with the oscilloscope.
Some thoughts about the software side: I remember that Peter Ujfalusi long time ago mentioned different clocks. Maybe the 32kHz clock or the McPDM clock which could be used as a reference. And there was a kernel version where sound became a little better (but I wouldn't bet for it). So there may still be another effect in software. Maybe in addition so that what we observe is the sum of several effects.
Interesting, the clocking definitely isn't quite right in the latest as high power mode also used to work on 4.19 but doesn't seem to any more.
One question about the loopback: does it show if the PCM data is coming in the right and stable timing? E.g. speed may fluctuate but still provide perfect data mirroring. Nevertheless, fluctuating speed may become audible.
This is true, there is some possibility for "common mode failure" that would symmetrically affect both directions.
But it is difficult to see how this would be influenced by the Vibra. Well, the Vibra is also controlled through some PCM channel because the motor can "play" the bass sound...
The Vibra seems to be set to "Input FF" mode by default AIUI it is controlled by I2C not the PDM stream when using vibra.py. But you can set it to PDM mode in alsamixer which seems to turn it always on (presumably a 1 is sent in the PDM stream for that channel by default?) noise that always goes away as soon as you turn it off again rather than glitching the stream.
It also seems to differ significantly less depending on the volume setting - it isn't directly scaled by volume in the same way as Vibra Right glitching is; as if it is affecting something later in the signal path.
Strange that an unconnected channel also makes a difference, but the H- bridge is still presumably still switching and any H-bridge does produce some shoot-through noise.
I am wondering now if some config issue is making the TWL much more sensitive than it should be for some reason.
Best
David
I'm still proud to own the first modded Pyra, even though it didn't work :D
++
BR, Nikolaus
Best
David
On Wed, 2020-07-29 at 17:37 +0200, Michael Mrozek wrote:
Am Mittwoch, den 29.07.2020, 17:25 +0200 schrieb H. Nikolaus Schaller:
Hi,
What I have seen is that there is room for an optional LED on the backside of the CPU board directly connected to these pins. It was left there from initial hardware debugging. It should be not too difficult to try to add a 4.7uF or 10uF capacitor there to test the result.
Oh, that's good news! Can you let me know where to solder them so I'll try that here?
I am not sure if that would be a good mass production solution, because it sticks to the battery bay plastics and/or the heat shield and slows down the production process and/or must be hand-soldered.
Well, we tested various materials between the CPU board and the plastics - but the best solution is to put NOTHING in between.
If we put a metal sheet in there, the heat goes into the metal and heats the battery - whereas almost nothing moves into the heatsink (where it should).
So there's a gap of 0.4mm between the CPU board and the backside, and as the keymat acts a bit like a cushion as well, I guess a small part like a capacitor could even use up to 0.6 to 0.7mm.
So there should be enough space to put a small capacitor in there.
But there would be room and easy access on component side of the LC15 processor board to add such capacitor(s) by modified copper trace layout. So it could be something for the next mass production run (unless ED has already ordered thousands of PCBs).
We have 500 already-produced PCBs - so I guess we'd need to fix these manually. But hey, MWeston had to replace 500 capacitors on the Pandora PCBs manually as well.
Only bigger downside would be that we have another setup costs for the next CPU boards... that's around 5000 EUR alltogether :/
<photo_2020-07-29_17-03-18.jpg>
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel