Articlets

IST Hardware Tech Tip 
October 1999 
Daniel Burk 
IST Applications Enginering 
mailto: support@isthq.com

Greetings from IST Applications Engineering!

I have recently finished troubleshooting some technical troubles for a few customers, and thought that I ought to pass them on in the form of an editorial. It is my hope that by making you aware of these troubles, you will be able to avoid them in your own daily use of your IST equipment. 

The Lock Switch Blues:

The first problem that we have noted is the use of the LOCK switch: the original purpose of the lock switch was to reduce the likelihood of a test failure due to use of the SELECT button by unauthorized or untrained personnel. This was an especially important feature on the EDR-1 recorder. When the EDR3-series was developed, the LOCK switch transferred to the new design, even though it was rendered redundant by the top cover. Unfortunately, the LOCK switch has caused more problems than it has solved, especially with the advent of the EDR3C recording engine. I have seen several customers who tried to use the LOCK switch in conjunction with a delayed start: It just doesn’t work in the EDR3C architecture! The LOCK switch locks the recorder in the Active-Standby mode: When the start time elapses, the system will not switch to Active mode. Thus, if you plan on using a delayed start, Don’t use the lock switch! In fact, I suggest NOT using the lock switch at all. Use the top cover to prevent tampering. Once the cover is bolted in place, you can’t get at the select button to switch modes. The LOCK switch still serves a useful function: That of entering manual commands. IST is considering switching to a spring-loaded toggle that in essence removes the LOCK switch function but preserves the ability to enter manual commands.

Tripped up by High-frequency, High-amplitude acceleration:

The next problem surfaced with a customer who was using an EDR3D recorder for measurement of vibration on a small tractor. The recorder was equipped with 510 Hz anti-aliasing filters, and the sample rate was turned up to 3200 samples/second. The system was equipped with 10 g single-axis external accelerometers that were placed on the engine block and engine mounts on the frame. The data that was recorded was very puzzling. There were these half-sine impulses that went to full-scale, and were synchronized with the firing frequency of the engine. Even though the accelerometers were placed in different locations (not orthogonally mounted), the data was always in phase, and always uni-polar. The spikes always went negative.  An investigation began: EMI/RFI was suspected at first, but tests confirmed that the phenomenon was mechanically related. The suspected problem was high-amplitude, high-frequency acceleration such as would be created by pre-ignition. This is that “coke-bottle rattle” you hear when you get a tankful of bad gasoline. An EDR4 with a 200g accelerometer block was added to the test, sampling at 15 Kilosamples / second. This revealed a startling amount of acceleration: Typically 45 g with a frequency component up to 3.5 Kilohertz. The problem was that the 10 g accelerometer was being saturated by this level of acceleration, and could not accurately track it. This manifested itself as a period where the output of the accelerometer went to zero: This zero output was of sufficient duration to pass through the anti-aliasing filters.  Once a higher-range accelerometer was implemented, the problem spikes were reduced. They didn’t entirely go away, however, and the investigation is still ongoing. The moral of the story: Even though a system may have anti-aliasing filters, we cannot ignore the possibility of high-frequency acceleration. The filters are not by any means “brick-wall”: they simply reduce the amplitude of high-frequency acceleration and minimize the effects. In addition, Since the accelerometer sits on the OTHER END of the filter, we must be sure that the accelerometer is matched to the environment for it to function properly.

Improving Your Chances of Getting Good Data:

What happens when a set of standard RCPs are just too aggressive for a modified test? In any case, what can you do when your test yields no data?

NASA Goddard Space Flight Center’s Transportation Engineering department has implemented a modification to their RCPs that helps them prevent just this circumstance: They turn on the “Temperature Sample Interval” as a trigger source. The temperature sample interval is set to 30 minutes.

Thus, once per 30 minutes, along with the temperature sample, an acceleration event is also recorded regardless of the level of that acceleration. Now, whenever a test is executed, there will exist some kind of acceleration record.  This helps alleviate questions of whether or not the recorder was really operational during the test. Acceleration records that show no perceptible motion can be safely removed from the test data during post-processing.

How is this accomplished? Through the use of the temperature sample interval as a "triggerable source". When using DynaMax to set up your recorder, note that there are several ways to record an acceleration event. Firstly, an even can be stored in memory whenever an accelerometer measurement exceeds a certain pre-determined amplitude of acceleration. Secondly, there is the external trigger bus, which is usually used in conjunction with a trigger box like the HRT-3, or with another data recorder. Lastly, there is the temperature sample interval, which is time-based. Any (or even none!) of these may be used to affect an acceleration measurement. If the time-triggered event condition is enabled, an acceleration event will be placed in memory at a certain preset time interval, until the overwrite event limit is reached. At this time, the impulse sum criteria applies, and the potential event is judged against existing events with regard to impulse sum. See the DynaMax or recorder hardware user manual for more information.