05-24-2021, 10:21 AM
(This post was last modified: 05-24-2021, 10:39 AM by vortex.
Edit Reason: Added a note at the end about finding comb filters and realizing something about the requencyy
)
Was able to successfully record the sound, but it had to be a phone call. It is definitely in the microphone line. The person who I called that first time confirmed this was the sound they had heard when I played the recording to them. It also matches what I heard on the recorder when it had been recorded earlier.
There is good and bad news, which I will get into at the end.
First, methods. I tried your suggestion:
It did get a more steady transmit power, but not quite enough to be able to reliably get the sound. The resulting sound was similar to the sound that is send over the phone during a call, but not an exact match. So, it can still be used for simple testing, but doesn't quite match the characteristics. Namely, it is very pulsed and has all the spectral properties that entails along with some other differences.
So, I forced the modem into 2G mode (weaker 2G reception where I am at than 4G), took a landline at the same location, setup the call, and recorded the sound with the Sound Recorder app installed by default on Mobian. To make the signal worse and increase the transmit power, I held the phone in a metal enclosure with the door slightly ajar so I could hold it and see it (the kind of metal enclosure circuit breakers are put in).
It recorded the sound like a charm and the recorded sound matched the noise. That is the good news.
I transferred the FLAC file to my computer and converted to WAV.
I then wrote a short python script to open the file, take the spectrogram, export it to a CSV and as a plot. I put the code as well as my CSV file and plot on a public git repository pinephone_call_noise_investigation so others may do the same analysis and look at my data and possibly add their own spectrograms.
The resulting spectrogram, which is where the bad news starts, is
![[Image: spectrogram_Freja_Nordsiek_2021_05_24_2G...al_box.png]](https://raw.githubusercontent.com/frejanordsiek/pinephone_call_noise_investigation/main/plots/spectrogram_Freja_Nordsiek_2021_05_24_2G_call_partially_enclosed_by_metal_box.png)
What I interpreted that I heard on the recorder is vastly different from what the noise actually is, in a bad way. It is a frequency comb instead of a narrow band sound. Worse yet, the comb starts at 220 Hz which is in the range of where human voice fundamental frequencies lie.
So no simple single notch/band-stop filter would work. Instead a filter that eliminates a frequency comb is needed, and it must be very sharp to eliminate the frequency comb and still preserve enough of the actual audio that a person can be understood. Hopefully such a filter exists.
And then there is an important question. How widespread is this phenomena among PinePhones in low cellular signal conditions? For those that have it, is the frequency the same? This latter one is important for implementing any filter in a widespread fashion. If each phone with the problem has a different frequency, each phone will require tuning of the filter. If it is the same, then the parameters can be found very accurately using one or a handful of phones and used for all with the problem.
EDIT - Adding two things
I despaired a bit too early. Turns out there are IIR comb notch filters (https://docs.scipy.org/doc/scipy/referen...rcomb.html), though the order would be quite high (CPU intensive).
Second, 220 Hz is almost identical to 44 kHz / (2 * 100). The sound appears to be recorded at 44 kHz, and the sound is 1/100 the Nyquist frequency. Could be a coincidence. Might be related.
There is good and bad news, which I will get into at the end.
First, methods. I tried your suggestion:
(05-24-2021, 04:04 AM)dsimic Wrote:(05-24-2021, 03:31 AM)vortex Wrote: I tried recording sound while downloading a large file over 2 G (needed to be slow and bandwidth heavy) and it didn't work. Problem is, when downloading, the transmit power is only very intermittently high and when it pulses high, there is an audible sound (probably from a capacitor charging) that is extremely broadband that limits the ability to pick anything else up.
How about trying to upload a large file under the same network circumstances? A large file upload should crank the modem's transmit power to the max, and keep it at that level for as long as the upload keeps going. It should even suffice to run "speedtest-cli --no-download --server <id>" (maybe with the "--single" flag as well) on the phone in a simple "for" loop, so you don't have to search for a fast server that accepts large file uploads.
It did get a more steady transmit power, but not quite enough to be able to reliably get the sound. The resulting sound was similar to the sound that is send over the phone during a call, but not an exact match. So, it can still be used for simple testing, but doesn't quite match the characteristics. Namely, it is very pulsed and has all the spectral properties that entails along with some other differences.
So, I forced the modem into 2G mode (weaker 2G reception where I am at than 4G), took a landline at the same location, setup the call, and recorded the sound with the Sound Recorder app installed by default on Mobian. To make the signal worse and increase the transmit power, I held the phone in a metal enclosure with the door slightly ajar so I could hold it and see it (the kind of metal enclosure circuit breakers are put in).
It recorded the sound like a charm and the recorded sound matched the noise. That is the good news.
I transferred the FLAC file to my computer and converted to WAV.
I then wrote a short python script to open the file, take the spectrogram, export it to a CSV and as a plot. I put the code as well as my CSV file and plot on a public git repository pinephone_call_noise_investigation so others may do the same analysis and look at my data and possibly add their own spectrograms.
The resulting spectrogram, which is where the bad news starts, is
What I interpreted that I heard on the recorder is vastly different from what the noise actually is, in a bad way. It is a frequency comb instead of a narrow band sound. Worse yet, the comb starts at 220 Hz which is in the range of where human voice fundamental frequencies lie.
So no simple single notch/band-stop filter would work. Instead a filter that eliminates a frequency comb is needed, and it must be very sharp to eliminate the frequency comb and still preserve enough of the actual audio that a person can be understood. Hopefully such a filter exists.
And then there is an important question. How widespread is this phenomena among PinePhones in low cellular signal conditions? For those that have it, is the frequency the same? This latter one is important for implementing any filter in a widespread fashion. If each phone with the problem has a different frequency, each phone will require tuning of the filter. If it is the same, then the parameters can be found very accurately using one or a handful of phones and used for all with the problem.
EDIT - Adding two things
I despaired a bit too early. Turns out there are IIR comb notch filters (https://docs.scipy.org/doc/scipy/referen...rcomb.html), though the order would be quite high (CPU intensive).
Second, 220 Hz is almost identical to 44 kHz / (2 * 100). The sound appears to be recorded at 44 kHz, and the sound is 1/100 the Nyquist frequency. Could be a coincidence. Might be related.
