An rpi based DIY Vibration meter - Page 2 - AVS Forum | Home Theater Discussions And Reviews
Forum Jump: 
 55Likes
Reply
 
Thread Tools
post #31 of 162 Old 12-27-2016, 02:29 PM - Thread Starter
AVS Forum Special Member
 
3ll3d00d's Avatar
 
Join Date: Sep 2007
Location: London, UK
Posts: 2,866
Mentioned: 98 Post(s)
Tagged: 0 Thread(s)
Quoted: 1636 Post(s)
Liked: 607
I hadn't noticed that bit of the doc, it seems slightly ambiguous as it says

The Sample Rate is generated by dividing the gyroscope output rate by SMPLRT_DIV:
Sample Rate = Gyroscope Output Rate / (1 + SMPLRT_DIV)
where Gyroscope Output Rate = 8kHz when the DLPF is disabled (DLPF_CFG = 0 or 7), and 1kHz when the DLPF is enabled (see Register 26)


i.e. implies the DLPF can be disabled

but then register 26 says that 0 means a 260Hz filter and 7 is reserved

Ultimately we only really need up to ~100Hz so we'll just have to see what comes out when I measure.
3ll3d00d is online now  
Sponsored Links
Advertisement
 
post #32 of 162 Old 12-28-2016, 09:38 AM
Member
 
andy497's Avatar
 
Join Date: Jan 2013
Location: Michigan
Posts: 118
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 15 Post(s)
Liked: 23
The table for register 26 DLPF_CFG is confusing at best. Setting to 0 seems to indicate disabled, but where are they getting the 260 hz for accel and 256 hz for gyro from?
andy497 is offline  
post #33 of 162 Old 12-28-2016, 12:19 PM - Thread Starter
AVS Forum Special Member
 
3ll3d00d's Avatar
 
Join Date: Sep 2007
Location: London, UK
Posts: 2,866
Mentioned: 98 Post(s)
Tagged: 0 Thread(s)
Quoted: 1636 Post(s)
Liked: 607
Quote:
Originally Posted by andy497 View Post
The table for register 26 DLPF_CFG is confusing at best. Setting to 0 seems to indicate disabled, but where are they getting the 260 hz for accel and 256 hz for gyro from?
I'm not sure where the specific values come from but I guess the non defeatable nature of the filter is due to the ADC in the chip itself, i.e. a LPF is required to combat aliasing.

Click image for larger version

Name:	mpu60x0-block.png
Views:	24
Size:	92.0 KB
ID:	1858369

I read the filter is a 1st order filter so that would leave us down about 6dB at Nyquist (given a 1kHz sample rate) and attenuation would start just above the passband we're interested in (which ends in the 80-100Hz range). I think this means it's not an issue for our use case.

I also searched a bit for info on the noise problem and it seems there are (were? some batch of boards out there which used the wrong capacitors, seems fixable if you have smd soldering skills (I don't!) - https://forum.arduino.cc/index.php?topic=394691.0
3ll3d00d is online now  
 
post #34 of 162 Old 12-28-2016, 02:59 PM - Thread Starter
AVS Forum Special Member
 
3ll3d00d's Avatar
 
Join Date: Sep 2007
Location: London, UK
Posts: 2,866
Mentioned: 98 Post(s)
Tagged: 0 Thread(s)
Quoted: 1636 Post(s)
Liked: 607
I've been thinking about how to mount the chip itself without the, relatively short, cables unduly influencing how it moves. My thinking is to solder a right angle header onto the board to attach the wires to then use double sided foam tape to attach the board itself to a somewhat larger foam base. Something like this bad ascii art

Code:
                                                 |----|
                      pins     cable             |    |
             board  |-----=====------------------|  |-G------------|
            ========|                               |      RPi     |
  tape      ---------                               |--------------|
         ****************
  foam   ****************
         ****************
  tape   ----------------
  seat   ===============================================================
It might actually make sense to recess the board into the foam so the header pins and cable sit flush with the foam.

The foam could then be used as a safe base for adhering the device to the seat. I think double sided tape should work here as well (e.g. see https://www.endevco.com/wp-content/uploads/TP312.pdf for comparison of mounting methods, indicates tape works fine in this passband).

Intuitively this seems like it should work but we'll see. I could solder the wires directly to the board instead though that feels like it might be more unstable because the wires will roam free whereas the header pins serve to lock the wires into a consistent position. I suppose you could also argue the consistency of the wires aligned to the pins might introduce a systemic bias. You might also argue I'm overthinking this

Last edited by 3ll3d00d; 12-28-2016 at 03:03 PM.
3ll3d00d is online now  
post #35 of 162 Old 12-28-2016, 06:17 PM
AVS Forum Special Member
 
BassThatHz's Avatar
 
Join Date: Apr 2008
Location: Northern Okan range (NW Cascades region)
Posts: 7,585
Mentioned: 89 Post(s)
Tagged: 0 Thread(s)
Quoted: 2229 Post(s)
Liked: 1915
Quote:
Originally Posted by andy497 View Post
gyro/gps/barometer. you can imagine a plate with four spinning blades on it is pretty riddled with high frequency vibration.
I would imagine that the barometer and gps aren't greatly impacted by drone motor vibs.
I'm no drone expert but I'd imagine they only need +-0.5 degree accuracy for the gyro to facilitate pitch/yaw/roll.

Small changes in position based would have to be done via velocity/acceleration monitoring as civilian GPS isn't uber accurate (+-2ft at best). It would have to be accurate to within "inches per second" if say... they wanted to autonomously fly it through a window frame.
The largest noise source being caused by local wind, and blade turbulence off nearby objects, which would be picked up by the tilt changes in the gyro to thus reject large false-positives (as well as fan voltage I'd imagine.)

In the case of audio though, I'd imagine the gyro/gps/barometer would be completely useless.
If a bulky cellphone can register transducer vibs I'd imagine a smaller, lighter, dedicated-chip, would be even more accurate than that, by a large margin.
I'm sure the sensitivity will be just fine so the only real question remaining is: bandwidth...
You'd want at least 100hz, if not 2 or 300hz. The-more the-better obviously.

Last edited by BassThatHz; 12-28-2016 at 06:20 PM.
BassThatHz is offline  
post #36 of 162 Old 12-29-2016, 10:01 AM
Member
 
andy497's Avatar
 
Join Date: Jan 2013
Location: Michigan
Posts: 118
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 15 Post(s)
Liked: 23
Quote:
Originally Posted by 3ll3d00d View Post
I also searched a bit for info on the noise problem and it seems there are (were? some batch of boards out there which used the wrong capacitors, seems fixable if you have smd soldering skills (I don't!) - https://forum.arduino.cc/index.php?topic=394691.0
Awesome info.


Quote:
Originally Posted by BassThatHz View Post
Small changes in position based would have to be done via velocity/acceleration monitoring as civilian GPS isn't uber accurate (+-2ft at best). It would have to be accurate to within "inches per second" if say... they wanted to autonomously fly it through a window frame.
The largest noise source being caused by local wind, and blade turbulence off nearby objects, which would be picked up by the tilt changes in the gyro to thus reject large false-positives (as well as fan voltage I'd imagine.)
Yes indeed. The simple case of position hold is a good test. If you rely on gyro and accelerometer alone, it ends up doing a random walk in the sky. If you LPF that signal too much to try to smooth things, you miss wind gusts and random bumps. Adding gps will help with catching drift over long periods of time, but it can bounce around by several feet second to second, so it's not too good for holding still. So you take as many sensor inputs as you can and try to weight them according to reliability. It's an interesting problem.

But yeah, for this application, the accel is what's needed, and hopefully it has sufficient SNR and bandwidth.

Dood, 90 degree header seems smart to me. I can't really see the wires impacting the measurement unless they are pulled really tight, but I guess you'll find out.
andy497 is offline  
post #37 of 162 Old 12-30-2016, 03:15 PM - Thread Starter
AVS Forum Special Member
 
3ll3d00d's Avatar
 
Join Date: Sep 2007
Location: London, UK
Posts: 2,866
Mentioned: 98 Post(s)
Tagged: 0 Thread(s)
Quoted: 1636 Post(s)
Liked: 607
the recorder service seems ready for action - https://github.com/3ll3d00d/vibe/blo...der/service.py

I wrapped it up in a rest api and added something to report the device self test. It also allows for multiple accelerometers connected to one device (seems unlikely given the pi has a single i2c connection available but you can get expanders) and for the recording & processing of the data to run on a different machine (e.g. if you wanted to run multiple rpi's, one for each seat, so each device will then post the data back to the server).

I just need to actually test it with the device now.

I also had the idea of defining a playlist in jriver and then setting it to automatically work through that playlist while making & processing individual measurements for each track. Add another one to the backlog
3ll3d00d is online now  
post #38 of 162 Old 12-30-2016, 03:24 PM
AVS Forum Special Member
 
notnyt's Avatar
 
Join Date: Dec 2008
Location: Long Island, NY
Posts: 8,348
Mentioned: 197 Post(s)
Tagged: 0 Thread(s)
Quoted: 2538 Post(s)
Liked: 2304
Quote:
Originally Posted by 3ll3d00d View Post
the recorder service seems ready for action - https://github.com/3ll3d00d/vibe/blo...der/service.py

I wrapped it up in a rest api and added something to report the device self test. It also allows for multiple accelerometers connected to one device (seems unlikely given the pi has a single i2c connection available but you can get expanders) and for the recording & processing of the data to run on a different machine (e.g. if you wanted to run multiple rpi's, one for each seat, so each device will then post the data back to the server).

I just need to actually test it with the device now.

I also had the idea of defining a playlist in jriver and then setting it to automatically work through that playlist while making & processing individual measurements for each track. Add another one to the backlog
i2c is a bus, so as long as you can set the address of the device, you can have multiple on the same bus without issue. Otherwise, you'd need a multiplexer.

edit: looked at datasheet, you can easily add a second on the same bus by putting supplying AD0 with 5v which changes the address from 0x68 to 0x69.

If you ever need any assistance with this type of thing hit me up, I have a good deal of experience

Last edited by notnyt; 12-30-2016 at 03:28 PM.
notnyt is offline  
post #39 of 162 Old 12-30-2016, 03:56 PM - Thread Starter
AVS Forum Special Member
 
3ll3d00d's Avatar
 
Join Date: Sep 2007
Location: London, UK
Posts: 2,866
Mentioned: 98 Post(s)
Tagged: 0 Thread(s)
Quoted: 1636 Post(s)
Liked: 607
How would you physically connect 2 devices to the RPI?

I had stopped looking into using 2 on one device tbh because the cable length seemed a deal breaker and the bus bandwidth seems like it would be an issue. You could create an extender but seems cheaper, for the layman, to buy another pi instead.
3ll3d00d is online now  
post #40 of 162 Old 12-31-2016, 02:23 AM - Thread Starter
AVS Forum Special Member
 
3ll3d00d's Avatar
 
Join Date: Sep 2007
Location: London, UK
Posts: 2,866
Mentioned: 98 Post(s)
Tagged: 0 Thread(s)
Quoted: 1636 Post(s)
Liked: 607
the wiring is simpler than I thought, e.g. http://electronics.stackexchange.com...-a4-sda-and-a5

cable length still seems an issue though, I imagine making something like http://www.ebay.co.uk/itm/like/17091...7297426&crdt=0 yourself costs pennies if you have the capability to roll your own circuit boards though.
3ll3d00d is online now  
post #41 of 162 Old 12-31-2016, 11:31 AM
AVS Forum Special Member
 
notnyt's Avatar
 
Join Date: Dec 2008
Location: Long Island, NY
Posts: 8,348
Mentioned: 197 Post(s)
Tagged: 0 Thread(s)
Quoted: 2538 Post(s)
Liked: 2304
Quote:
Originally Posted by 3ll3d00d View Post
the wiring is simpler than I thought, e.g. http://electronics.stackexchange.com...-a4-sda-and-a5

cable length still seems an issue though, I imagine making something like http://www.ebay.co.uk/itm/like/17091...7297426&crdt=0 yourself costs pennies if you have the capability to roll your own circuit boards though.
keep your wiring for the signal wires twisted it'll help reduce noise. also remember they'll need a common ground and need to be powered still. Also ad0 on one will need 5v
notnyt is offline  
post #42 of 162 Old 01-01-2017, 03:05 PM - Thread Starter
AVS Forum Special Member
 
3ll3d00d's Avatar
 
Join Date: Sep 2007
Location: London, UK
Posts: 2,866
Mentioned: 98 Post(s)
Tagged: 0 Thread(s)
Quoted: 1636 Post(s)
Liked: 607
Quote:
Originally Posted by notnyt View Post
keep your wiring for the signal wires twisted it'll help reduce noise. also remember they'll need a common ground and need to be powered still. Also ad0 on one will need 5v
thanks, I'll give it a try once I get one up and running ok.

Speaking of which, I connected up one device and setup the app on the rpi. It is functional and self test passes but seems to be producing way more data than I appear to be able to consume. I don't think this is a function of my code/the rpi being too slow though. I have the bus at default speed (100kbps) and it seems to be taking ~4ms to read 30 bytes from the FIFO, this equates to ~60kbps so seems in the right ballpark. It should only be sticking 6 bytes per sample at 500Hz on the FIFO though, i.e. ~24kbps, instead the FIFO (1kB) is filling up in 35-40ms which is more like 200kbps. Obviously I must have something configured incorrectly so now time to find out what

EDIT: I guess actually setting the sample rate would help, works fine now. Next step, verify the data.

Last edited by 3ll3d00d; 01-01-2017 at 03:10 PM.
3ll3d00d is online now  
post #43 of 162 Old 01-02-2017, 03:58 AM - Thread Starter
AVS Forum Special Member
 
3ll3d00d's Avatar
 
Join Date: Sep 2007
Location: London, UK
Posts: 2,866
Mentioned: 98 Post(s)
Tagged: 0 Thread(s)
Quoted: 1636 Post(s)
Liked: 607
data seems reasonable, need to investigate the self calibration bit next. This is with the device sitting on the desk in front of me and just plots vibration against time

Click image for larger version

Name:	Screenshot_20170102_115623.png
Views:	37
Size:	123.2 KB
ID:	1867545
3ll3d00d is online now  
post #44 of 162 Old 01-02-2017, 05:42 AM
AVS Forum Special Member
 
dominguez1's Avatar
 
Join Date: Dec 2008
Posts: 3,207
Mentioned: 130 Post(s)
Tagged: 0 Thread(s)
Quoted: 1065 Post(s)
Liked: 852
Quote:
Originally Posted by 3ll3d00d View Post
data seems reasonable, need to investigate the self calibration bit next. This is with the device sitting on the desk in front of me and just plots vibration against time

Attachment 1867545
Awesome progress 3!

Will you be able to show this by frequency as well? Smoothed?

What's the parts cost in USD for this so far? Do you have a pic of the device?
dominguez1 is offline  
post #45 of 162 Old 01-02-2017, 11:30 AM - Thread Starter
AVS Forum Special Member
 
3ll3d00d's Avatar
 
Join Date: Sep 2007
Location: London, UK
Posts: 2,866
Mentioned: 98 Post(s)
Tagged: 0 Thread(s)
Quoted: 1636 Post(s)
Liked: 607
graphs are shown further up the thread, a frequency response chart (acceleration vs freq) is one of them

total cost is about £50-55 here for rpi + case + cable + mpu6050 + sd card, the major cost is the rpi and I'm not sure how much they are over there. I guess $60-70 in total?

here's my extremely high tech development platform

Click image for larger version

Name:	rpi.jpg
Views:	37
Size:	132.6 KB
ID:	1868977
3ll3d00d is online now  
post #46 of 162 Old 01-02-2017, 01:22 PM - Thread Starter
AVS Forum Special Member
 
3ll3d00d's Avatar
 
Join Date: Sep 2007
Location: London, UK
Posts: 2,866
Mentioned: 98 Post(s)
Tagged: 0 Thread(s)
Quoted: 1636 Post(s)
Liked: 607
I'm not 100% sure what to do next

the correct approach would be to calculate and remove the gravity vector from the output, the downside is this looks slightly tricky if I roll my own (or mildly tedious and time consuming if I port some code from a C++ lib).

an alternative is to exploit the fact that typical use here is "put device on seat, play track" and hack that in via the offsets as per https://www.digikey.com/Web%20Export...are-offset.pdf

this method will fail if the device is subject to significant motion (i.e. it's not firmly secured to the seat) but then the data is rubbish at that point anyway

probably I'll bodge the hack in for now and see what data I get out, if ok then apply the proper approach later
3ll3d00d is online now  
post #47 of 162 Old 01-03-2017, 02:04 PM - Thread Starter
AVS Forum Special Member
 
3ll3d00d's Avatar
 
Join Date: Sep 2007
Location: London, UK
Posts: 2,866
Mentioned: 98 Post(s)
Tagged: 0 Thread(s)
Quoted: 1636 Post(s)
Liked: 607
Further research suggests the following options;

- add support for the onboard Digital Motion Processor (DMP) which fuses gyro and accelerometer data to yield, amongst other things, linear acceleration
Pros: should be accurate.
Cons: unknown algorithm used in the processor and no ability to refine or change it if required, sample rate is limited to 200Hz at most (possibly 100Hz, it's not entirely clear).

- roll my own sensor fusion algorithm based on the raw data.
Pros: can maintain the higher sample rate, can use potentially more computationally expensive (and accurate) filters, should be accurate if I write it properly
Cons: I have to write this myself which entails some risk given that I don't know how (quite a few articles on line how to do it thoough), will be inaccurate if I do a bad job

- use a simple low pass filter to calculate gravity per axis and then subtract that from the raw values
Pros: trivial to implement
Cons: seems this must be inherently inaccurate when the sensor is in motion (as this means the actual gravity vector is changing so an estimate of gravity calculated by a low pass filter will be wrong as the estimate lags reality)

still not sure what the best way to go is, the last one is obviously easy to do and is how an app like Vibsensor does it (which means this app should have results that are no worse than VS) so will do that first. I guess it will then mean implementing both the other two options and comparing the 3 approaches to see which one works best in reality.
3ll3d00d is online now  
post #48 of 162 Old 01-04-2017, 02:40 PM - Thread Starter
AVS Forum Special Member
 
3ll3d00d's Avatar
 
Join Date: Sep 2007
Location: London, UK
Posts: 2,866
Mentioned: 98 Post(s)
Tagged: 0 Thread(s)
Quoted: 1636 Post(s)
Liked: 607
implemented the low/high pass filter approach to isolate gravity and ran a quick test to compare VS against this device. I stuck the device to the table using double sided foam tape and put my phone next to it then measured for 10s while I tapped the table repeatedly.

mpu6050 with a 1Hz 6th order butterworth high pass, 500Hz sample rate



VS in high frequency mode (which means a 1Hz corner frequency for the high pass), 100Hz sample rate



things to note;

- mpu6050 registers a larger magnitude acceleration, I would think this is due to the reduced weight of the device
- mpu6050 shows a significant oscillation early in the measurement which is the latency of the filter based estimation of gravity (i.e. I need to start each measurement at least 1s early to be able to get a stable view of the resting gravity vector)
- I think that same filter latency is visible in the VS measurement in response to the shock (i.e. me tapping the desk), look at the way Z moves around each spike, not 100% sure but it seems odd, mpu6050 doesn't have that problem as the filtered data clearly tracks the raw data more consistently (and the corresponding "tilt" data is cleaner than that shown by VS). This could also be a function of the weight of the device, i.e. heavier device is harder to fix to the surface so measurement is contaminated by motion of the device itself


tilt comparison
VS
Click image for larger version

Name:	tilt_vs.jpg
Views:	20
Size:	60.7 KB
ID:	1873929

mpu
Click image for larger version

Name:	tilt_mpu.jpg
Views:	21
Size:	58.1 KB
ID:	1873937
Attached Thumbnails
Click image for larger version

Name:	mpu6050.jpg
Views:	128
Size:	118.6 KB
ID:	1873913   Click image for larger version

Name:	vs.jpg
Views:	125
Size:	66.5 KB
ID:	1873921  
3ll3d00d is online now  
post #49 of 162 Old 01-04-2017, 08:21 PM
AVS Forum Special Member
 
derrickdj1's Avatar
 
Join Date: Sep 2011
Posts: 3,632
Mentioned: 94 Post(s)
Tagged: 0 Thread(s)
Quoted: 944 Post(s)
Liked: 660
Is it to early to give a feel on how you think this will work for the VS thread? All of us will not have this meter and yours will have to be our gold standard.
derrickdj1 is offline  
post #50 of 162 Old 01-05-2017, 04:37 AM
AVS Forum Special Member
 
dominguez1's Avatar
 
Join Date: Dec 2008
Posts: 3,207
Mentioned: 130 Post(s)
Tagged: 0 Thread(s)
Quoted: 1065 Post(s)
Liked: 852
Quote:
Originally Posted by derrickdj1 View Post
Is it to early to give a feel on how you think this will work for the VS thread? All of us will not have this meter and yours will have to be our gold standard.
My thought is that we will all need to start using this meter...and 3 could start a little side business to produce these for us, or we could make it ourselves with instructions.

I'm thinking that this will be the tool to use to graph TR and include as part of the ulf scorecard. It won't have the 50hz limit of VS and be more specific to measuring subwoofer TR.

@coolrda , thoughts?
dominguez1 is offline  
post #51 of 162 Old 01-05-2017, 10:38 AM - Thread Starter
AVS Forum Special Member
 
3ll3d00d's Avatar
 
Join Date: Sep 2007
Location: London, UK
Posts: 2,866
Mentioned: 98 Post(s)
Tagged: 0 Thread(s)
Quoted: 1636 Post(s)
Liked: 607
here's a comparison of VS using separate 0-50 and 50-100 white noise measurements stitched together vs mpu6050 with 0-100 white noise. I took the raw data from VS and ran it through the same analysis as I have written for the mpu6050. My analysis is consistent with the data produced by VS itself for these exact measurements so I'm confident this is a valid comparison. I couldn't get the graphs to be identical but tried to get it pretty close so you can flip back and forth and visually inspect them.

conclusions...

1) there are significant differences in the data above 30Hz
2) the data from the mpu6050 looks quite similar to that produced by my (analogue, 1D) accelerometer in that the response continues to rise into the mid bass

graphs are PSD graphs only

MPU6050
Click image for larger version

Name:	mpu.jpg
Views:	37
Size:	67.8 KB
ID:	1875513

VS
Click image for larger version

Name:	vs.jpg
Views:	33
Size:	64.6 KB
ID:	1875521
dominguez1 likes this.
3ll3d00d is online now  
post #52 of 162 Old 01-05-2017, 10:46 AM
AVS Forum Special Member
 
dominguez1's Avatar
 
Join Date: Dec 2008
Posts: 3,207
Mentioned: 130 Post(s)
Tagged: 0 Thread(s)
Quoted: 1065 Post(s)
Liked: 852
Quote:
Originally Posted by 3ll3d00d View Post
here's a comparison of VS using separate 0-50 and 50-100 white noise measurements stitched together vs mpu6050 with 0-100 white noise. I took the raw data from VS and ran it through the same analysis as I have written for the mpu6050. My analysis is consistent with the data produced by VS itself for these exact measurements so I'm confident this is a valid comparison. I couldn't get the graphs to be identical but tried to get it pretty close so you can flip back and forth and visually inspect them.

conclusions...

1) there are significant differences in the data above 30Hz
2) the data from the mpu6050 looks quite similar to that produced by my (analogue, 1D) accelerometer in that the response continues to rise into the mid bass

graphs are PSD graphs only

MPU6050
Attachment 1875513

VS
Attachment 1875521
Awesome work sir.

How does it subjectively feel 60hz and up? Stronger than your frequencies 40hz and below?

In my case, it is a lot stronger in the lower frequencies than upper...and VS with the downward slope seems to be what I'm feeling.
dominguez1 is offline  
post #53 of 162 Old 01-05-2017, 10:53 AM - Thread Starter
AVS Forum Special Member
 
3ll3d00d's Avatar
 
Join Date: Sep 2007
Location: London, UK
Posts: 2,866
Mentioned: 98 Post(s)
Tagged: 0 Thread(s)
Quoted: 1636 Post(s)
Liked: 607
Quote:
Originally Posted by dominguez1 View Post
and 3 could start a little side business to produce these for us, or we could make it ourselves with instructions.
I intend to publish a deb (i.e. an installable package) which wraps this up so it can run self contained on a single rpi. It will also be possible to break it apart and run n rpi's to measure at multiple and then have them talk to a server process that logs the data and provide the UI. The bill of materials is v simple; 1 rpi + sdcard for raspbian + cables + a case that gives access to the gpio pins. It's then just a question of a bit of config on the device to enable a few bits and pieces, install the deb and away you go (I hope!).
3ll3d00d is online now  
post #54 of 162 Old 01-05-2017, 11:06 AM - Thread Starter
AVS Forum Special Member
 
3ll3d00d's Avatar
 
Join Date: Sep 2007
Location: London, UK
Posts: 2,866
Mentioned: 98 Post(s)
Tagged: 0 Thread(s)
Quoted: 1636 Post(s)
Liked: 607
Quote:
Originally Posted by dominguez1 View Post
How does it subjectively feel 60hz and up? Stronger than your frequencies 40hz and below?
the wobble is still the dominant factor, the midrange effect is perceptible though nowhere near the sort of thing mentioned in some of the comments in the MBM thread (the chest pounding stuff). The measurements I've taken in the past indicate this side of things is delivered from the main subs up front btw in my setup. The near field and far field ones complement each other pretty nicely.
3ll3d00d is online now  
post #55 of 162 Old 01-05-2017, 11:15 AM
AVS Forum Special Member
 
dominguez1's Avatar
 
Join Date: Dec 2008
Posts: 3,207
Mentioned: 130 Post(s)
Tagged: 0 Thread(s)
Quoted: 1065 Post(s)
Liked: 852
Quote:
Originally Posted by 3ll3d00d View Post
the wobble is still the dominant factor, the midrange effect is perceptible though nowhere near the sort of thing mentioned in some of the comments in the MBM thread (the chest pounding stuff). The measurements I've taken in the past indicate this side of things is delivered from the main subs up front btw in my setup. The near field and far field ones complement each other pretty nicely.
So do you think a downward slope is more representative of what you are feeling then? Does something need to be adjusted in the rpi so the slopes are similar to VS? Or perhaps weight is the cause of the downward slope?
dominguez1 is offline  
post #56 of 162 Old 01-05-2017, 11:33 AM - Thread Starter
AVS Forum Special Member
 
3ll3d00d's Avatar
 
Join Date: Sep 2007
Location: London, UK
Posts: 2,866
Mentioned: 98 Post(s)
Tagged: 0 Thread(s)
Quoted: 1636 Post(s)
Liked: 607
Quote:
Originally Posted by dominguez1 View Post
So do you think a downward slope is more representative of what you are feeling then? Does something need to be adjusted in the rpi so the slopes are similar to VS? Or perhaps weight is the cause of the downward slope?
remember that the shape of the isoperception curve (for vibration) is like



i.e. you need a pretty steep increase in acceleration as frequency rises

I intend to add this as a target curve option eventually but I also need to sum the axes as well to get the total picture

I suspect the weight of the device (phone) is what causes the damped response at higher frequencies though it could also be a function of the lower sample rate. I'll take a measurement with the mpu6050 at a 100Hz sample rate at the weekend to determine which one it is.

Last edited by 3ll3d00d; 01-05-2017 at 11:37 AM.
3ll3d00d is online now  
post #57 of 162 Old 01-05-2017, 12:16 PM
AVS Forum Special Member
 
dominguez1's Avatar
 
Join Date: Dec 2008
Posts: 3,207
Mentioned: 130 Post(s)
Tagged: 0 Thread(s)
Quoted: 1065 Post(s)
Liked: 852
Quote:
Originally Posted by 3ll3d00d View Post
remember that the shape of the isoperception curve (for vibration) is like



i.e. you need a pretty steep increase in acceleration as frequency rises

I intend to add this as a target curve option eventually but I also need to sum the axes as well to get the total picture

I suspect the weight of the device (phone) is what causes the damped response at higher frequencies though it could also be a function of the lower sample rate. I'll take a measurement with the mpu6050 at a 100Hz sample rate at the weekend to determine which one it is.
Yes, but that is acceleration. If you convert that to PSD, you should see it being flattish from 40-80hz, and a rising slope from 40hz and below.

An acceleration curve with a flat PSD looks like the below I believe...

dominguez1 is offline  
post #58 of 162 Old 01-05-2017, 12:44 PM - Thread Starter
AVS Forum Special Member
 
3ll3d00d's Avatar
 
Join Date: Sep 2007
Location: London, UK
Posts: 2,866
Mentioned: 98 Post(s)
Tagged: 0 Thread(s)
Quoted: 1636 Post(s)
Liked: 607
Quote:
Originally Posted by dominguez1 View Post
Yes, but that is acceleration. If you convert that to PSD, you should see it being flattish from 40-80hz, and a rising slope from 40hz and below.
no I don't think that is correct, it's based on an erroneous interpretation of how PSD is calculated (as a normalisation method for a broadband signal).

Here's the linear spectrum (and the PSD again for comparison) for that data I showed earlier.

Click image for larger version

Name:	mpu_spec.jpg
Views:	24
Size:	81.1 KB
ID:	1875761

Click image for larger version

Name:	mpu_psd.jpg
Views:	22
Size:	90.3 KB
ID:	1875769
3ll3d00d is online now  
post #59 of 162 Old 01-05-2017, 01:08 PM
AVS Forum Special Member
 
dominguez1's Avatar
 
Join Date: Dec 2008
Posts: 3,207
Mentioned: 130 Post(s)
Tagged: 0 Thread(s)
Quoted: 1065 Post(s)
Liked: 852
Quote:
Originally Posted by 3ll3d00d View Post
no I don't think that is correct, it's based on an erroneous interpretation of how PSD is calculated (as a normalisation method for a broadband signal).

Here's the linear spectrum (and the PSD again for comparison) for that data I showed earlier.

Attachment 1875761

Attachment 1875769
Sorry if this is redundant...but can you convert that target acceleration curve to PSD? Or, is this the complex math that you described before?

In your eyes, what are you shooting for, for our target chart? Acceleration vs Frequency? PSD vs Frequency?

Whatever it is, I think it's important to compare to a reference curve.
dominguez1 is offline  
post #60 of 162 Old 01-05-2017, 01:44 PM - Thread Starter
AVS Forum Special Member
 
3ll3d00d's Avatar
 
Join Date: Sep 2007
Location: London, UK
Posts: 2,866
Mentioned: 98 Post(s)
Tagged: 0 Thread(s)
Quoted: 1636 Post(s)
Liked: 607
Quote:
Originally Posted by dominguez1 View Post
Sorry if this is redundant...but can you convert that target acceleration curve to PSD? Or, is this the complex math that you described before?
I don't have this right now, I will produce it though.

Quote:
Originally Posted by dominguez1 View Post
In your eyes, what are you shooting for, for our target chart? Acceleration vs Frequency? PSD vs Frequency?

Whatever it is, I think it's important to compare to a reference curve.
I agree that you need to start from a reference, however IMV the real use of that is as a way to inform my understanding of my preference. I don't really know what that reference is in this case, the only one I have found is an isoperception curve but I have no idea if that is a good target or not. I suppose this is one reason for me to build that bandpass sub, i.e to get the ability to deliver more TR higher up and hence have the ability to explore the shape of that preference further (well that and I like building stuff!)

in other news, here's the tri axis sum using the RSS (root sum of squares) method and with X and Y scaled as per https://dspace.lboro.ac.uk/dspace-js...REPOSITORY.pdf

Click image for larger version

Name:	mpu_sum.jpg
Views:	20
Size:	87.2 KB
ID:	1875873

I think the main thing to note here is how the dips are filled in by the XY axes. This does match my perception that my current setup feels quite smooth (i.e. no excessive peaks or dips).
3ll3d00d is online now  
Sponsored Links
Advertisement
 
Reply DIY Speakers and Subs



Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off