home: http://starling.us/tet
by Ĝan Ŭesli Starling
copyright 2004
Here I employ the free, open source, data visualization program OpenDX to generate 3D models of an RPC-III road load data acquisition (RLDA) file. Within OpenDX itself, the 3D view may be panned, zoomed, rotated, etc.
Automotive engines are rubber mounted nowadays to isolate noise, vibration and harshness. Presented here are the actual forces recorded from one such engine mount. From among twenty-two events recorded on the proving ground, I have selected the event named pot hole number three. This contained some twenty-plus channels, of which only three pertain to the engine mount. These I’ve extracted using my very own RPC-3, time history editor written entirely in Perl. Likewise did I perfrom all subsequent editing described below.
OpenDX here displays a plot of the forces in Newtons for X (Right), Y (Rear) and Z (Up) of the engine mount during said pot hole event. The parent file was sampled at 512 Hz. But hardware constraints require that I down-sample it to 204.8 Hz for playout on a 3-axis bedplate fixture in the test lab. Below you may see the result. Color shows the force in Newtons as/per the included color bar.
Unreduced RLDA files take forever to play out on account of all those smooth places in between the interesting jouncy stuff. And even the jouncy bits are sure to include little squiggles lacking in interest. On laboratory test rigs however the whole point is to accumulate damage as fast as possible. So automatic algorithms are employed to concatenate only the pot holes, belgian blocks, panic stops, jack rabbit starts, curb island impacts and so on. Below is what pot hole event number three looks like to an elastomeric motor mount when viewed in 3D. OpenDX shows it much more clearly than would any ordinary time history plot.
My Perl program gus_rpc_edit.pl
offers two methods of data reduction: peak-slice & minimum vector envelope deletion. The editing exampled here is deliberately exaggerated so as to more clearly exemplify the characteristics of each. In both cases I have exaggerated by reducing the data too severely, employing a noise band of 20% (as compared against the signal’s own absolute maximum vector).
How to interpret: each file’s load vector path is described by colored tube. As seen above, the unedited tube is colored according to magnitude as/per the color bar at top right. It is also the smallest diameter tube. The peak-sliced data file is represented by a medium size magenta tube. The minimum-vector data file is represented by a large white tube. All three tubes are opaque. Wherever the load vector paths diverge (such that some rainbow data are seen) these are the values which have been reduced.
The edtior employs an N-plus-1 channel peak slice algorithm. Thus to peak slice X, Y and Z, a synthetic Pythagorean 4th channel sqrt( X**2 + Y**2 + Z**2 )
is temporarilly employed.
Why do I bother with this? Think... How often does the maximum peak align itself precisely with a major axis? Surely it cannot be guaranteed. But then again, no present method of damage calculation ever takse this into account. Neverthelss, it may be there.
Not evident at all in traditional, RPC-III time history plots, but really quite outstanding here is the side effect of vector path distortion resulting from time-dilated peak-slice data. On no account should this be attributed to the exessive noiseband of 20%. It cannot be since equal distortion also occurs at peaks where the unfiltered data show orange and red. No, reduction owing to the 20% noise band only effects squiggles nearer to the mean where unfiltered data show blue. All the rest is a natural result of peak slicing in general.
This method projects an imaginary sphere of radius N out from the XYZ mean. Outside of this radius the path followed by filtered data is concentric with that of the unfiltered. There no red, orange or yellow may be seen because the rainbow tube is of smaller diameter and inside the white tube. Were I to reduce the white tube’s opacity to semi-transparent (easy to do in OpenDX) then you could see lying within.
Within the invisible boundary radius the two paths diverge. Thus may be seen many a blue squiggle of the unfiltered date where the white tube traverses straight-line short-cut across the sphere until they both emerge from it, becoming concentric once again.
Here you may compare the two editing methods against one another.
Here is a link to the OpenDX Website where you may obtain OpenDX for yourself. Or if, as may happen, your favorite OS is NetBSD, then you will find in in /usr/pkgsrc/graphics/dx
. Various other flavors of Unix/Linux have it too (I just don’t know where). For Win32, you must click the button and go to their website.
Having gotten OpenDX, then you may either write your own OpenDX program, or download mine. Here it is: gus_xyz_tube_3file.net (rename it from *.txt
to *.net
after downloading).
Perhaps too you might like copies of the data exampled above (pre-extracted for your convenience): Raw ; Peak-Slice ; Min-Vector .
Just in case you just surfed in by accident, here is a link to the editor program: gus_rpc_edit.pl