This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Microphone measurements together with other sensors
#1
Good afternoon, I'd like to suggest to add a feature: I would like to add the possibility to measure raw microphone data together with accelerometer raw data in "simple experiment" feature, to have the possibility to make their measurement at the same time.
Thank you!
Andrea
Reply
#2
Unfortunately, recording raw microphone data is not well supported in phyphox. You might have noticed that our "Audio oscilloscope" is limited to 500ms. This is because phyphox internally treats all data the same, meaning it converts everything to double precision floating point numbers. This format is great for precise calculations and for accelerometer data at up to 500 Hz, but for audio data at 48.000 Hz, this is quite excessive and inefficient. Regular "audio recorder" apps use 16bit integer format (or similar) instead, which only takes up 2 bytes per sample, while phyphox wastes 8 bytes. This alone would not be much of a problem, but phyphox also keeps everything in memory and organizes data in a way that allows for efficient and interactive plotting. In other words, phyphox tries to allow you to zoom into any data at any time, which is something you will not find in an audio recorder app - if such app even shows the waveform, you will notice that it usually does not allow zooming and simply creates the waveform by only recreating the newest data.

All this means, that phyphox is rather bad at handling longer audio recordings. It might work fine for 10 seconds or maybe a minute, but a minute of audio data in phyphox already means roughly 3 million data points that are treated just like any data (and possibly be exported in a massive Excel sheet).

With this being said, the answer is in fact that it is already possible to record the microphone and acceleration at the same time (for example by using our editor at https://phyphox.org/editor), but you will most likely run out of memory, having trouble to plot the data and/or not being able to export your data.

Can you tell us what you want to do? Maybe this works for you as you only need short periods or maybe we can find a different approach that minimized the data that is actually stored.
Reply
#3
Woooow thanks a lot, I'm impressed by the effort you put in this forum!

I didn't know the editor, it opened me a world. I'll try to explore. Maybe i'll find the solution by myself, but you seems very kind and interested, so I share here my experiment.

I would like to collect like 10 smartphones and put them on the ground spaced by, let's say, 10 meters each, coupled with the ground, as they were geophones.
Then, I do a shot on the ground with a big hammer near smartphone #1, and if sufficiently strong its seismic waves should be recorded by every smartphone far away. It's like a seismic survey, i don't know if you are familiar with. In any case, the time at which the seismic waves arrive at each phone is very important, and I want to record it with precision: it depends on the wave speed that is different for each type of soil. 10 accelerometers at 500 Hz are ok.
The problem is: every smartphone has it's clock, so I have to give them a common and known impulse to set a common starting time: a sound impulse seemed great because I know it's speed (340 m/s) so, after little computation, I can easily define a common starting time of all smartphones who detected the sound impulse.

So, I don't need much audio information, I don't mind of audio quality, I only would like to detect a strong initial impulse (audio sampling rate should be similar to that of accelerometer (500 Hz is great)


if you have some idea, i'll explore them.
Thank you very much, have a nice weekend!

Andrea
Reply
#4
(02-07-2020, 06:07 PM)andrea Wrote: Woooow thanks a lot, I'm impressed by the effort you put in this forum!

Thanks - I cannot ignore a good question Wink

Interesting use case. Synchronizing multiple phones is always a bit tricky and many users expect that the phones are just in sync by default, which is far from true - at leat for these time scales. I often recommend knocking on a table with all phones, so the peak can be recognized in all recordings for later synchronization.

This of course would not make sense for your experiment (unless you can move the phones after giving a reference signal with the phones in the same place), so your idea make a lot of sense. Unfortunately, there are also difficulties when it comes to synchronizing event within the phone. When looking into alternatives to synchronize phones, one finds that sensor events do not have a time stamp from the realtime clock (because this can skip when it is adjusted and it has a lower resolution), but instead we get sensor events relative to the time at which the system was started. This already makes it difficult to give precise real-work timestamps and complicates synchronization even if phones have well-synchronized real-time clocks.

When it comes to audio data, the situation is even more complicated. The data from the microphone is neither a stream of values with timestamps nor are audio samples necessarily delivered to an app at the time they have been recorded. What happens is that phyphox sends the command to record audio and from then on, we get the audio data in packages of few hundred or thousand samples. There is no timestamp, but from the sample rate we can calculate exactly the time of each sample - relative to the first one. And here is the problem: The time of the first sample. The delay between the recording command to the first sample depends on the device and the delay between the actual recording of a sound to it actually reaching phyphox is typically around 10ms on Android (although newer Android systems supposedly can achieve 3ms and iOS seems to be better generally in this area). Most applications only care about the latter value as it affects the perceived delay for audio effects.

In any case, the time of an audio sample is nothing that is automatically delivered (although I think it should be possible to obtain it) and so far, phyphox did not really care about this. In phyphox you can get the timestamp for each sensor event (time since startup adjusted to the beginning of the experiment), but audio data is only a block of samples. Tools like our "acoustic stopwatch" calculate a relative time difference by counting the samples, but you do not get a starting time. The best phyphox can do here at the moment is using the time at which the current data batch started processing, which is subject to the phone's performance and which will always be worse than the buffer size used by the device.

So, it might be possible to get precise audio timing (at least a quick search showed that there are more people discussing latency for audio processing), but at least at the moment phyphox does not provide anything which will allow you to synchronize the audio to the accelerometer data.

The only things that can be directly synchronized this way (at least at the moment in phyphox) are sensor events from the sensor API (see the list here https://developer.android.com/guide/topi...s_overview). Is there any way, you could synchronize your devices through something detected by the accelerometers? Either by synchronizing them in one place and then moving them (although I have to admit that this will open the question about long-time stability of the internal clocks, which I cannot answer) or maybe by sending seismic impulses from different directions, similar to how we determine the speed of sound (actually, we do it like this because of pretty much the same problem, see here: https://phyphox.org/experiment/speed-of-sound/).
Reply
#5
Ok, thanks to your reply I understood the lot of issues about audio recording, and that only API sensors can synchronize well.

I like much your idea of knocking them on a table and then put them together on the field, it can work if the long-time stability of internal clocks is ok for every device used. In fact, it takes several minutes to place the smartphones in the correct place. But, this long-time stability check can be an interesting experiment itself!
Another ideas: getting measurements in the evening and synchronize with a big big flash detected by the light sensor... or connecting the smartphones with a wire making a little electric coil near each magnetometer, and then closing the circuit to make a magnetometer detection (this appears more tricky logistically)

One problem of the clock could also be that maybe I should get only smartphones of the same model to make them behave similarly? Also, I heard from someone that each sensors is different from another and everyone has to be calibrated separately, so maybe having the same model of smartphone is not a warranty.

I found that my iphone 6 and my wiko y80 cannot go over 100 Hz (I'm writing 500 in the simple experiment sample rate tab). According to your experience is a matter of smartphone model or I'm missing some way to increase sample rate? For geoseismic surveys this increase in sampling rate is quite fundamental.

I hope you are always interested in this ideas, thank you for your time and helpful suggestions! Have a nice day

Andrea
Reply
#6
The maximum rate is determined by the smartphone. I do not have much experience on how similar the results on identical phones are, but we have a database of many smartphones that gives you information on the maximum available rate for each model and sensor:
http://phyphox.org/sensordb

In phyphox, you should probably just set the rate to 0 which means "no limit". This ways you get the sensor events as they are generated by the phone at the fastest rate supported.
Reply
#7
That table is very useful, it seems that the Umidigi X is the best for this experiment, in terms of frequency and standard deviation. I should buy one to test, and a bunch of them for the real experiment. I don't know if I can afford eheheh.
But, now that many things are clear in my mind, I thinks that i'll try in the future to do that experiment and I will remember to let you know.

Thank you for all the support Sebastian!! love you
Reply
#8
Glad I could help.

Just be a bit careful about the details in the database. This data is generated by users who use the "Sensor DB" experiment (white entry at the bottom of the main menu in phyphox) and we have no way to verify it. The frequency should be accurate, but it does not mean that you get "good data" at that rate. The standard deviation depends on whether the users actually did not touch the phone while testing. Phyphox tries to prevent submission if it does not get a more or less constant standard deviation, but there is only so much we can check and sometimes drifting messes up the noise estimate. So, unless there is a bit more statistics than the report of a single user, it is hard to compare the standard deviation across devices.
Reply


Forum Jump: