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. Note: Here, alas I can show only JPEGs. So please excuse the too-dark thumbnails, and the slightly fuzzy, larger graphics which they link to. To conserve space (not to mention download time) I’ve had to convert them from their 1280 x 1024 resolution TIFF format originals.
Data Reduction Methods
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.
Peak Slice
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.
Off-diagonal View
XY View
XZ View
ZY View
Minimum Vector
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.
Off-diagonal View
XY View
XZ View
ZY View
Both Methods Compared
Here you may compare the two editing methods against one another.
Off-diagonal View
XY View
XZ View
ZY View
Off-diagonal View
XY View
XZ View
ZY View