For reference, my phone is a Beta Edition Convergence PhonePhone (1.2b hardware). I am running Mobian with the following modifications:
- Running 5.11 kernel
- Flashed the anx7688 with the latest firmware
- Installed crust-firmware package
In all of this, I was calling a land line.
Today, I had my first chance to see the PinePhone in action with phone calls in a location with very poor reception. Many places there have no reception. Many other places a phone has to drop to 2G. 4G in a few places, though it is marginal. This was the pattern with my old phone (Nexus 5), and is the pattern with my new PinePhone. At first glance, it looks like my PinePhone is doing a bit better reception wise than my Nexus 5.
Yesterday, I called the landline from a location with good reception and there were no problems. I also did the same earlier tonight at the same location to check, and had no problems.
But in the location today with bad reception, there were major problems that were strongly correlated with the reception.
On my end, there was a loud sound coming from inside the PinePhone case near the earpiece. The sound seemed like PWM whine. So I think it is a switching power supply and a capacitor combination. It quite bad in one location. I moved to another location with better reception and it decreased some. I ended the call and tried again in a location outside with slightly better and the sound was a lot quieter, and I could make it slightly quieter by rotating myself so it would aim in certain directions. My Nexus 5 makes a similar sound but much quieter even in poor reception, and has a similar pattern.
On the other person's end was much worse. They said a very loud sound was coming through on their end which made it even harder to understand me than the sound on my end made it hard to understand them, though my voice was coming through better than on my old Nexus 5 except for the added loud sound. The intensity of the sound decreased as the signal quality improved. From how they described the sound later, it seems like it might have been RF pickup in the microphone line or the sound connection line to the modem. Tomorrow, we are going to attempt to record the sound on their end so I can listen to it and try to figure out more.
Based on the pattern, I think that the sound on my end and the pickup causing loud sound to be transmitted to the other end are due to the increased transmission power as the signal quality decreases. In the worst reception area, the modem is operating at maximum and the problem is at its worst.
For the PWM whine on my end, I am doubtful there is a software solution. Only possibility would be if the PWM frequency is controllable from software. But the PWM whine on my end isn't too terrible (it is tolerable). For the noise transmitted to the other end, it is possible that the settings of the modem, CPU, and sound hardware may have some tangible effect; but I don't know. There is more likely to be a solution, though than for my end.
Hardware wise, assuming I am not the only one with this problem and that the electronics causing it are not inside the modem itself, it might be possible to reduce by finding the particularly switching supply and changing it to a different one as well as changing the capacitor to one that will make less noise (hopefully the capacitor is easy to get to because then it would be possible for the brave to desolder it and solder a new one on). That by itself my reduce the problem to no longer be an issue. The RF pickup can probably also be reduced in other ways.
Anyone have any ideas on this and/or have experienced it?
This is a really weird but important issue, thank you for describing it in detail! Maybe you could try using a wired headset to make a test call to the landline under the same circumstances, instead of using the built-in microphone and the earpiece? It would be interesting to see it that makes a difference.
hi, i'm still working on getting my cellular network to function reliably but based on the few calls i did make people complained about a loud, echo-y sound on their end to the point where they just hung up on me.
An update. I did the same tests again today but coordinated with the other person to make sure one of my calls went to the recorder to be recorded so I could listen to it later.
First, the issue was a little better today on both ends. The connection was a little better based on the connection indicator. May have been the weather (more water weakening the signal from my carrier's tower enough that the modem decided to roam to another carrier's tower that was closer), less phones connecting to the same tower, or something else. Not sure. Calls consumed less power too, which further supports the hypothesis that the signal was stronger today.
But the issue was still there.
Listening to the recorded call, it is definitely sounds like pickup from a switching power supply. It isn't quite a pure tone like some 5 kW frequency drives can make, but more smeared out around a central frequency like a small switching power supply. What is interesting is that the intensity was inversely correlated with how loud I was speaking. During pauses in my speech or if I spoke in a lower volume, the sound got louder. When I was speaking at high volume, it was quieter. From this, I think the pickup is occurring before the amplifier. The gain is auto adjusted based on the volume. When I speak louder than the pickup, the gain is reduced and the pickup is quieter since it isn't amplified as much. When I stop speaking, the gain is increased and the pickup is amplified. It is of course possible there is some pickup after the amplifier, but it seems like most of it is before the amplifier.
Now, this does suggest a possible software mitigation. If the gain is set low, or at the very least the software is set to increase it only very slowly except at the beginning of a call; then the noise shouldn't be amplified too much. One way to do it would be to let the autogain setting run at the beginning, find the lowest gain needed in say the first few seconds or so, and then lock the gain or only let it increase very slowly but decrease quicker.
(05-18-2021, 06:50 AM)dsimic Wrote: This is a really weird but important issue, thank you for describing it in detail! Maybe you could try using a wired headset to make a test call to the landline under the same circumstances, instead of using the built-in microphone and the earpiece? It would be interesting to see it that makes a difference.
I don't have a wired headset to test with, sadly. I do have wired headphones. But, your suggestion made me realize a potentially important catch. I've had DIP switch 6 set to UART instead of headphone/microphone. It is possible that the particular setting of this switch affects how much pickup can occur. I will make another test tomorrow with the switch set to headphone/microphone mode, and if I remember I will also try with headphones.
On the hardware front, in future revisions, if changing the board for better isolation isn't possible or doesn't do quite enough, another possible mitigation would be switching whichever power supply to one with a sharper frequency spectrum and putting a notch filter for that frequency on the microphone line either right before the amplifier or right before the digitizer (that way there is little room for pickup after the filter). Such a filter could in principle be done in software as well, but that would consume more power. Also, a stronger filter right before and after the switching power supply would also do the job (may not be forward propagated noise, but instead noise propagated backwards to the power source) and maybe a small RF can if absolutely necessary (though that adds space, weight, and cost).
I am also going to see if I can find a way to record the sound to a file so I can get the spectrogram. The spectrogram might help determine which component on the board is causing the sound, and also how to mitigate it (knowing the frequency is needed for a hardware or software filter, and is useful for any potential board revisions).
(05-18-2021, 07:58 AM)Rainer Wrote: hi, i'm still working on getting my cellular network to function reliably but based on the few calls i did make people complained about a loud, echo-y sound on their end to the point where they just hung up on me.
I was hoping I was the only one (i.e. better that my phone has a defect and no one else is effected than everyone being effected), but it seems that I am not the only one. Guess this was good to bring up.
05-19-2021, 11:30 AM
(This post was last modified: 05-19-2021, 11:31 AM by vortex.
Edit Reason: Forgot to include my estimate of the sound's frequency
)
Tested again with DIP switch 6 set to enable microphone/headphone jack with and without headphones. Note, my headphones do not have a microphone.
Having the DIP switch set to enable headphone/microphone did not make the sound better on either end. It might have been even worse on the other end, but it is hard to tell.
When I did the call with headphones, no sound went through at all virtually and the recorder decided that there was no one on the line and didn't record (the other person was listening and filled me in). So, putting in the headphones caused the microphone jack to be read but there was nothing there to inject sound. But there was little to no pickup since if there had been any, it would have been the loudest sound.
I still need to test a proper headset, but it would seem the problem is pickup in the builtin microphone wiring some where between the microphone and the amplifier.
Another thing I forgot to mention. [EDIT] Forgot something. The sound sounds like it is in the 2 kHz to 4 kHz range.
05-23-2021, 11:24 AM
(This post was last modified: 05-23-2021, 11:37 AM by vortex.
Edit Reason: Corrected a mistake about filtering
)
Was able to reproduce the issue by calling another phone number, this time someone else's cellphone. So it definitely is not the receiving phone.
I did some digging in the sound system. I started with the schematics for the 1.2b revision and megi's page Audio on PinePhone to understand the system. The CPU's audio unit handles all audio routing and mixing. The microphone essentially connects directly the the CPU (see pages 5 and 8 of the schematic), meaning that the amplifiers in megi's diagram are inside the CPU itself rather than external. Sound is transmitted to the modem from the CPU via its PCM interface (page 15), passing through a TXB0104YZT level shifter (can find the part on the PinePhone component list).
So the pickup is happening between the CPU and the microphone and there is no external amplifier involved, for better or worse.
One good news is that the connection between the CPU and the modem is digital, so short of really really bad noise that connection is immune to pickup.
I am assuming that Mobian at the present time (and likely other distros) are using either the sound routing scheme in megi's page Audio on PinePhone or a similar one where the CPU's audio unit is doing the heavy lifting and the CPU cores are doing nothing since that saves power. A brief look at callaudiod suggests that this is the case since Arnaud Ferraris says in Issue #13
Arnaud Ferraris Wrote:No, as the signal is only routed in hardware, pulseaudio never "sees" the audio data.
Based on how it looks the the CPU's audio unit works, it looks like it should be possible to instead read the microphone into userspace, filter it with a notch/band-stop filter, and then send it back into the audio unit to send to the modem. I still need to record the audio and look at the spectrogram to see what frequency needs to be filtered out and how wide the band would need to be. My guess, from playing around with some Butterworth filters with scipy.signal, is that a 2nd to 5th order notch/band-stop IIR filter would probably be sufficient and would be relatively cheap to compute, though it would need to have small and/or constant lag.
Luckily, it seems like pulseaudio can do lowpass filtering ( https://askubuntu.com/questions/869822/h...io-profile), so there might be a notch/band-stop. So it is possible that no pulseaudio filters would have to actually be written.
[EDIT- I mistakenly said that a notch/band-stop filter could be made by combining a lowpass and a highpass filter. This does not actually work. They can be combined to make a bandpass filter. I usually work with bandpass filters rather than notch/band-stop filters, so I spoke before I thought.]
Once I get a spectrogram, I am going to try to see if I can hack a filtering solution together. Though, I am really out of my depth since I would need to figure out both pulseaudio and callaudiod enough to hack the latter to do it.
The filter would obviously cut out some useful audio, but the pickup is overwhelming the useful audio in that frequency range anyways and making it hard to hear other frequencies. Luckily, people's voices' fundamental frequencies are below 1 kHz and vowels stay in the low range. It is consonants that have the high frequency tails that might suffer a bit.
[EDIT- I mistakenly said that a notch/band-stop filter could be made by combining a lowpass and a highpass filter. This does not actually work. They can be combined to make a bandpass filter. I usually work with bandpass filters rather than notch/band-stop filters, so I spoke before I thought.]
05-23-2021, 02:54 PM
(This post was last modified: 05-23-2021, 03:00 PM by dsimic.
Edit Reason: Wording improvements
)
You've performed a very good analysis. Thumbs up!
Based on the way audio is routed, wouldn't it be expected to make the issue reproducible with no actual call in place, if the root cause is the microphone or something along the microphone-to-SoC path? If that ends up as not reproducible, something must be wrong either along the CPU-to-modem path, which is probably unlikely, or within the modem itself. It could also be something up to the way power is supplied to the modem, but it's highly unlikely because the modem is pretty much directly connected to the battery.
If the root cause turns out to be the modem itself, the microphone could be placed out of the picture entirely, by having the CPU play a .wav file or something else containing a "test pattern" for the call, so to speak. Playing a "test pattern" instead of speaking into the microphone would also make it possible to perform precise and repeatable analysis of the audio received on the other end of the call.
Going to break things into smaller pieces.
(05-23-2021, 02:54 PM)dsimic Wrote: Based on the way audio is routed, wouldn't it be expected to make the issue reproducible with no actual call in place, if the root cause is the microphone or something along the microphone-to-SoC path?
Yes, it could be done. The modem's transmit power would need to be gotten to high levels by some other means, but it would work. In such a scenario, the phone could do the recording itself. Not only is it a good check, it also makes it easier to get a spectrogram. Getting the transmit power high is just a matter of using mobile data in the background at a sufficient rate, particular upload (though it is possible that download would be sufficient).
(05-23-2021, 02:54 PM)dsimic Wrote: If that ends up as not reproducible, something must be wrong either along the CPU-to-modem path, which is probably unlikely, or within the modem itself.
Within the modem itself is possible if the sound ever goes back to analog where it would be vulnerable. I would think that that isn't done, but who knows.
(05-23-2021, 02:54 PM)dsimic Wrote: It could also be something up to the way power is supplied to the modem, but it's highly unlikely because the modem is pretty much directly connected to the battery.
It could be a DC-DC converter inside the modem itself if the transmitting unit needs a different voltage than the modem as a whole. Sadly, that would mean that it isn't possible to simply change out the part generating the noise in a board revision (still possible to better isolate microphone system from it).
(05-23-2021, 02:54 PM)dsimic Wrote: If the root cause turns out to be the modem itself, the microphone could be placed out of the picture entirely, by having the CPU play a .wav file or something else containing a "test pattern" for the call, so to speak. Playing a "test pattern" instead of speaking into the microphone would also make it possible to perform precise and repeatable analysis of the audio received on the other end of the call.
Playing a sound directly to the modem is also a good idea. Would make it easier to ascertain where exactly the problem is. If pickup is between the microphone and the CPU, then there should be no issues listening to the transmitted audio file on the receiving phone. If there is an issue listening to it, then there is a problem in the CPU to transmission end (possibly in addition to the microphone to CPU part).
Both of these are good ideas to narrow down the problem.
I am going to attempt the first one (record audio without a phone call) first. I will setup a download of something big in the background. Already have the software.
Second idea is a bit harder to pull off. I will need to research the appropriate pulseaudio and AT commands to do it.
05-23-2021, 05:49 PM
(This post was last modified: 05-23-2021, 05:52 PM by dsimic.)
(05-23-2021, 04:13 PM)vortex Wrote: Yes, it could be done. The modem's transmit power would need to be gotten to high levels by some other means, but it would work. In such a scenario, the phone could do the recording itself. Not only is it a good check, it also makes it easier to get a spectrogram. Getting the transmit power high is just a matter of using mobile data in the background at a sufficient rate, particular upload (though it is possible that download would be sufficient).
Exactly, divide the problem into pieces and conquer. You'd be able to do the testing of the microphone-to-SoC path much faster, easier and more often, with no need for someone (or something) to answer the call, do the recording of the call, and provide you with the recorded audio file.
(05-23-2021, 04:13 PM)vortex Wrote: Within the modem itself is possible if the sound ever goes back to analog where it would be vulnerable. I would think that that isn't done, but who knows.
Right, there should be no reasons for the audio to go back to analog inside the modem, but who knows what happens inside that black box? Maybe there's even some weird bug in the modem's DSP code, who knows? If all else fails, you could also try changing the parameters of the PCM between the SoC and the modem, and see if that makes a difference. It wouldn't be easy to do, but might be worth a try.
(05-23-2021, 04:13 PM)vortex Wrote: It could be a DC-DC converter inside the modem itself if the transmitting unit needs a different voltage than the modem as a whole. Sadly, that would mean that it isn't possible to simply change out the part generating the noise in a board revision (still possible to better isolate microphone system from it).
Right, there isn't much that could be done to the power supplied to the modem by the phone, but the power-related issue might very well be inside the modem itself, which would make things rather difficult. However, you could check out the latest results of the reverse engineering of the modem, and see if there are any exposed "knobs" that might be interesting. I doubt there are any, because the audio processing isn't performed on the modem's ARM core, but it might be worth ckecking anyway.
Let's hope that the microphone-to-SoC path will turn out to be free from interference etc.
(05-23-2021, 04:13 PM)vortex Wrote: Playing a sound directly to the modem is also a good idea. Would make it easier to ascertain where exactly the problem is. If pickup is between the microphone and the CPU, then there should be no issues listening to the transmitted audio file on the receiving phone. If there is an issue listening to it, then there is a problem in the CPU to transmission end (possibly in addition to the microphone to CPU part).
As a note, configuring the required audio routing should be possible by using or modifying the audio configuration program that's available on Ondrej's web page. I haven't researched that in detail, but I think it's rather easily doable once you get a grasp on the entire audio subsystem. The hard part, dissection of the PinePhone's audio subsystem, has already been done by Ondrej.
Also, the modem has a built-in text-to-speech generator, which I've tried out some time ago and it worked rather well, but for some reason the generated speech didn't seem to reach the other end of the call. It might be worth having a look at that as well.
(05-23-2021, 04:13 PM)vortex Wrote: I am going to attempt the first one (record audio without a phone call) first. I will setup a download of something big in the background. Already have the software.
Second idea is a bit harder to pull off. I will need to research the appropriate pulseaudio and AT commands to do it.
As already noted right above, I think that configuring the required audio routing shouldn't be too hard.
(05-23-2021, 05:49 PM)dsimic Wrote: (05-23-2021, 04:13 PM)vortex Wrote: Yes, it could be done. The modem's transmit power would need to be gotten to high levels by some other means, but it would work. In such a scenario, the phone could do the recording itself. Not only is it a good check, it also makes it easier to get a spectrogram. Getting the transmit power high is just a matter of using mobile data in the background at a sufficient rate, particular upload (though it is possible that download would be sufficient).
Exactly, divide the problem into pieces and conquer. You'd be able to do the testing of the microphone-to-SoC path much faster, easier and more often, with no need for someone (or something) to answer the call, do the recording of the call, and provide you with the recorded audio file.
Yes.
(05-23-2021, 05:49 PM)dsimic Wrote: (05-23-2021, 04:13 PM)vortex Wrote: Within the modem itself is possible if the sound ever goes back to analog where it would be vulnerable. I would think that that isn't done, but who knows.
Right, there should be no reasons for the audio to go back to analog inside the modem, but who knows what happens inside that black box? Maybe there's even some weird bug in the modem's DSP code, who knows? If all else fails, you could also try changing the parameters of the PCM between the SoC and the modem, and see if that makes a difference. It wouldn't be easy to do, but might be worth a try.
If the other things don't isolate the problem, these are possibilities.
(05-23-2021, 05:49 PM)dsimic Wrote: (05-23-2021, 04:13 PM)vortex Wrote: It could be a DC-DC converter inside the modem itself if the transmitting unit needs a different voltage than the modem as a whole. Sadly, that would mean that it isn't possible to simply change out the part generating the noise in a board revision (still possible to better isolate microphone system from it).
Right, there isn't much that could be done to the power supplied to the modem by the phone, but the power-related issue might very well be inside the modem itself, which would make things rather difficult. However, you could check out the latest results of the reverse engineering of the modem, and see if there are any exposed "knobs" that might be interesting. I doubt there are any, because the audio processing isn't performed on the modem's ARM core, but it might be worth ckecking anyway.
Let's hope that the microphone-to-SoC path will turn out to be free from interference etc.
If the problem is a DC-DC converter inside the modem itself, there might be a hardware mitigation (beyond making the microphone lines more immune to pickup by caging or something similar) depending on how the noise gets into the microphone line (assuming it is that). Something a simple as a filter on the power connection to the modem itself might help. DC-DC converters send a lot of noise backwards to the source in addition to propogating it forward. Essentially, adding a line filter in a potential future 1.2c revision.
(05-23-2021, 05:49 PM)dsimic Wrote: (05-23-2021, 04:13 PM)vortex Wrote: Playing a sound directly to the modem is also a good idea. Would make it easier to ascertain where exactly the problem is. If pickup is between the microphone and the CPU, then there should be no issues listening to the transmitted audio file on the receiving phone. If there is an issue listening to it, then there is a problem in the CPU to transmission end (possibly in addition to the microphone to CPU part).
As a note, configuring the required audio routing should be possible by using or modifying the audio configuration program that's available on Ondrej's web page. I haven't researched that in detail, but I think it's rather easily doable once you get a grasp on the entire audio subsystem. The hard part, dissection of the PinePhone's audio subsystem, has already been done by Ondrej.
That is what made me think it is doable and how to do it. Set things up like there with maybe a tweak or two to insert audio and start the call from mmcli with AT commands (can't use the call program since that would override the audio settings). But there will be quite a bit to learn in order to do it.
(05-23-2021, 05:49 PM)dsimic Wrote: Also, the modem has a built-in text-to-speech generator, which I've tried out some time ago and it worked rather well, but for some reason the generated speech didn't seem to reach the other end of the call. It might be worth having a look at that as well.
Didn't know it had one. Rather interesting. Not sure it would be useful.
(05-23-2021, 05:49 PM)dsimic Wrote: (05-23-2021, 04:13 PM)vortex Wrote: I am going to attempt the first one (record audio without a phone call) first. I will setup a download of something big in the background. Already have the software.
Second idea is a bit harder to pull off. I will need to research the appropriate pulseaudio and AT commands to do it.
As already noted right above, I think that configuring the required audio routing shouldn't be too hard.
Hope so.
|