AVS Forum | Home Theater Discussions And Reviews (https://www.avsforum.com/forum/)
-   DIY Speakers and Subs (https://www.avsforum.com/forum/155-diy-speakers-subs/)
-   -   An rpi based DIY Vibration meter (https://www.avsforum.com/forum/155-diy-speakers-subs/2681865-rpi-based-diy-vibration-meter.html)

3ll3d00d 09-04-2019 01:28 PM

a 0.3.0 release should be up in the next 30mins or so which contains the aforementioned changes (to let you load/save measurements, and hence share them, easily)

3ll3d00d 09-06-2019 03:44 PM

0.3.1 is out with assorted fixes (mostly to the spectrogram view)

3ll3d00d 09-07-2019 03:39 AM

1 Attachment(s)
0.3.2 has changes to the RTA view which mean you can independently choose whether to show the live view (i.e. the very latest data), the average (of all the data for the last x seconds) and the peak (like the average but the maximum values), the age of the data to keep is also configurable as well as the amount of smoothing to apply

https://www.avsforum.com/forum/attac...1&d=1567852707

3ll3d00d 09-07-2019 08:21 AM

Example from my system playing white noise


You might be able to see how the hold time affects averaging so that it gives a decent view on a steady state signal

LastButNotLeast 09-07-2019 08:54 AM

Is that the "test tone" we settled on? It would be nice to establish a standard or two.

3ll3d00d 09-07-2019 09:02 AM

Quote:

Originally Posted by LastButNotLeast (Post 58526012)
Is that the "test tone" we settled on? It would be nice to establish a standard or two.

Yes, that (white noise band limited from 0 to Nyquist) is what I have recommended for years so it is a standard as far as I am concerned :)

3ll3d00d 09-07-2019 12:37 PM

to explain what the graphs show....

sensor is collecting data at 500Hz, i.e. every 2ms

The app analyses, by default, this data to yield a frequency resolution of approx 1Hz. In order to achieve this, we need 512 (a power of 2 value is used for various reasons) samples, i.e. approximately 1s of data. This means every line drawn on the RTA is the result of 1s worth of measurements.

However the recorder is streaming this data to recorder in real time, it is configurable but by default it will send about 8 samples at a time (the way the data is transmitted means this is about enough to fill a single packet hence making efficient use of the network). The analyser therefore receives about fresh data every ~16ms. This equates a refresh rate of about 60Hz so if we wanted to maintain this refresh rate on screen, we'd need to complete the analysis & push the data to the screen in under 16ms. I don't think this is likely to be achievable in general so the analyser has a config option for a target refresh rate. By default, this is set to 20Hz (which gives us 50ms to process the data and update the screen). The analyser therefore snaps data every 50ms, runs it through the analysis and pushes it to the screen.

i.e. every time the curve updates in the RTA, it represents about 50ms of data

In the video above I show the average & peak views and the hold time is set to 2s. This means we take the last 2s worth of snapshots (which were taken every 50ms) and average them (at each frequency) and calculate the peak (at each frequency) for the peak.

i.e. we have 40 (2s / 50ms = 40) separate magnitude response curves which are averaged or max'ed to produce the graph shown above.

If you show the live view then you're always just seeing that latest snapshot (i.e. the last 50ms of data).

This applies to all analysis types (avg, peak and psd). Note that avg is equivalent to the A in a PvA (in BEQD) and peak is the same as the P in a PvA (in BEQD) so if you're comparing to the source track then remember to compare to the right target curve depending on whether you're looking at avg or peak (PSD is slightly different so isn't directly comparable).

To recap

sensor
-> pushes data to the analyser every 16ms
-> every 50ms analyser calculates avg/peak view for data that has arrived since the last snap (i.e. the last 50ms of data if everything is keeping up)
-> graph updates

make sense?

Nalleh 09-07-2019 12:43 PM

^^^ Yup, that makes sense :) It is truly a remarkable job you have done here, man! Inspiring to say the least :)

LastButNotLeast 09-07-2019 01:02 PM

I have no idea what you're talking about.
But I don't have to.
I don't know how my car works, either, but I know how to use it and to whom to take it when it doesn't.
I expect I'll do the same thing here.
Once I get mine working. :rolleyes:
But if Nalleh's impressed, that's more than good enough for me. :)
Michael

LastButNotLeast 09-08-2019 05:30 AM

No joy.
I tried resoldering both mpus and still get the readings bouncing between 80dB and 100dB.
So I'll wait for the one to arrive from China (pre-soldered) and see if that works.
Otherwise, the zero is damaged from attaching the header; unlikely, but possible.
In which case I'm done.
In the meantime, if anyone wants to try my 6050 just for grins, let me know.
Michael

3ll3d00d 09-08-2019 09:50 AM

Quote:

Originally Posted by LastButNotLeast (Post 58528812)
No joy.
I tried resoldering both mpus and still get the readings bouncing between 80dB and 100dB.
So I'll wait for the one to arrive from China (pre-soldered) and see if that works.
Otherwise, the zero is damaged from attaching the header; unlikely, but possible.
In which case I'm done.
In the meantime, if anyone wants to try my 6050 just for grins, let me know.
Michael

highly unlikely to a problem with the rpi, sensor is more likely. ISTR reading about some people getting mpu6050's that produced some dodgy data, e.g. https://forum.arduino.cc/index.php?topic=394691.0 (wrong size capacitor on the breakout board in that case). It's hard to say what is going on with yours though without seeing the actual data. I suggest the following

place the sensor flat on a table in a quiet (vibrationally speaking) room
capture 10-15s of data in qvibe
save it as a measurement and share it

once we see this then we see whether to look at the logs from the recorder itself, one thing I'm not surfacing yet is whether the recorder itself is overflowing (typically indicates an overloaded pi or bad wiring IME)

LastButNotLeast 09-08-2019 12:57 PM

After a long while running, I have sometimes noticed an overload error (ie, it stops saying FIFO). Hasn't happened often, though.
Not going to bother doing anything else until new mpu arrives.
Michael

3ll3d00d 09-09-2019 02:41 PM

0.3.5 up soon with

- target curves (from FRDs)
- export to FRD
- reference curves (i.e. the equivalent of A / B in REW)

This lets you do something like

- extract a demo clip into BEQD
- export the response as an FRD
- import it into qvibe as a target
- measure the same clip
- set the target as a reference
- easily see the delta between your system and the source material

or

- measure your system
- save that data
- tweak some stuff
- measure again
- easily see the difference between the two measurements

I'll add https://github.com/3ll3d00d/qvibe-analyser/issues/29 at some point (which would improve the latter by automatically doing A / B against the matching reference axis)

3ll3d00d 09-10-2019 02:39 PM

Quote:

Originally Posted by 3ll3d00d (Post 58534900)
I'll add https://github.com/3ll3d00d/qvibe-analyser/issues/29 at some point (which would improve the latter by automatically doing A / B against the matching reference axis)

0.3.6 has this feature

LastButNotLeast 09-10-2019 03:11 PM

If you're having trouble finding the updates, it's here:
https://github.com/3ll3d00d/qvibe-an...ases/tag/0.3.6

3ll3d00d 09-10-2019 03:16 PM

0.3.7 will flash up an error dialog if the sensor overflows, this will be annoying but if it happens regularly but I think this is the best approach (i.e. make it really distracting and annoying) as this is a strong signal that something is very wrong with your sensor and/or rpi and you should try to fix it.

3ll3d00d 09-10-2019 03:20 PM

1 Attachment(s)
Quote:

Originally Posted by LastButNotLeast (Post 58539926)
If you're having trouble finding the updates, it's here:
https://github.com/3ll3d00d/qvibe-an...ases/tag/0.3.6

fwiw the app itself gives you this link

https://www.avsforum.com/forum/attac...1&d=1568153906

the github link there is to the binary for your platform

put another way, once you are using the app then it should take care of you :)

LastButNotLeast 09-10-2019 03:23 PM

If anyone's just starting, finding that link was not easy.
Just trying to make it easy!
:)
Michael

3ll3d00d 09-10-2019 03:32 PM

I think it is feature complete now

There are some cosmetic improvements that could be made but otherwise I will just leave it till there is any feedback from people using it for real

LastButNotLeast 09-10-2019 07:54 PM

Any minute now, right folks?
:p

3ll3d00d 09-20-2019 02:07 PM

Quote:

Originally Posted by 3ll3d00d (Post 49038585)
refer to https://qvibe.readthedocs.io/en/latest/ for documentation about how to install and configure the app & the required hardware

added some docs around setup/config, user guide to follow


All times are GMT -7. The time now is 08:56 AM.

Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
vBulletin Security provided by vBSecurity (Pro) - vBulletin Mods & Addons Copyright © 2019 DragonByte Technologies Ltd.

vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2019 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging (Pro) - vBulletin Mods & Addons Copyright © 2019 DragonByte Technologies Ltd.