It seems that the cost of equipment and the engineering knowledge to do it properly are both significant barriers to having more torsional vibration analysis done on PSRUs that are in development or that are being adapted to a different engine than what the manufacturer may have tested. Or even to be done as a baseline for products in the field that while in production, may never have had any TV analysis done on them.
Grounding the conversation, I am a mechanical engineer and what little I know about electronics is self taught because as can be imagined, any machine today incorporates sensors and feedback and has a control system, so unless one is part of a multi disciplined team who is working on a project, one is frequently on your own to determine how best to handle the controls and software through outside vendors and software contractors and if you are particularly bad at it, you get fired and if you are good at it, you either get tolerated (in a technically un-savvy company) or if you have a good employer then you might be rewarded or get promoted. I have developed a lot of manufacturing equipment in my time including a very fast laser measurement system which Daimler thought was state of the art for its time. A lot of the controls I used were from National Instruments, but in recent years NI has gone a bit off the rails, especially on cost, both for hardware and their software development system and it is a system with a very steep learning curve. Thus the equipment I will be suggesting (that I will be buying myself with my own funding) is below the level of the typical NI hardware/software price point.
So lets define the basic system:
1)Sensors: For the sake of cost and complexity, I am going to assume that all speed sensors will be Variable Reluctance type sensors. This is the same sort of hardware used to measure the camshaft and crankshaft speed and position on the majority of engines in production. I have not yet identified a source, I have started discussions with Rotec but the Michigan rep gave the impression they would not sell sensors as individual components, only as part of a complete system. He was also very disparaging about any data acquisition system other than from Rotec which suggested a degree of industry blindness and being unaware of the great progress that has been made with FPGA systems in the last 15-20 years. I have not found any US sources for Zebra tape which is applied to exposed shaft surfaces and then scanned with laser sensors. I also believe that the laser sensors are going to end up being cost prohibitive. Fine for the test departments of Billion $ corporations but out of reach of the hobbiest/layman.
On my own gearbox, I would drill and tap 2 holes in the gear housing into which the VR sensors could be inserted so that they can read the tops of the gear teeth on the gearbox input shaft and output shaft. Typically the sensor needs to be 0.5-1.0mm from the gear tooth and the orientation of the windings and magnetic core basically aligned with the tooth helix angle for best response. Because of this the test sensors usually have fine pitch threads to allow for rotating the sensor for best response without materially changing the axial clearance to the tooth (if the thread pitch is 1mm then 90º of rotation is only an axial shift of 0.25mm). For a gearbox belonging to someone else, who may be understandably reluctant to have holes drilled into his gear housing, one would need to add encoder wheels to the shafts of interest by clamping on rings that have teeth cut in them for sensing. These would be made as light as feasible while still being of ferromagnetic material. Brackets for the pickup sensor would also have to be added. Worst case scenario brackets could be glued to the gearbox or engine with bondo which could then be knocked off after the fact.
2) VR signal conditioner / schmitt trigger. The output of the VR sensor will need to be conditioned to convert it from a strange AC waveform to a DC square wave that is either CMOS of TTL compatible to match the digital counter timer input.
Above is an example of what the output of a typical VR sensor looks like as the sensor is passed by the tips of gear teeth. The blue trace below the VR signal represents the ideal DC square wave signal that one wants to feed a data acquisition system. Sometimes the input circuit of a digital acquisition board may have built in filtering to help with converting the signal, but for now I am assuming that I will build a 4 channel signal conditioning board for the application. I have yet to decide which input signal is considered the reference, it may in fact be the output shaft of the system (prop shaft) but I will accept advice from those with more experience than I. There are a multitude of purpose made IC's for processing VR signal data into clean square wave outputs like MAX9924 to MAX9927, LM1815 or NCV1124
3) Data acquisition system: As previously discussed, I cannot afford a PXI or cRio system from NI that would run something like $5000-$20000 and then would still be useless until another $20k worth of programming is done for it to make it do what is needed. Both of those systems are very powerful and capable of high speed acquisition, digital signal processing and even calculation of the data through algorithms like FFT to convert time based data directly into frequency spectrum data to be displayed on a waterfall plot. I am assuming our equipment will capture timing data digitally (not storing analog signals taken at a certain timing rate) and then we would post process that data to get the results we are looking for. So in my searching so far, the best I have come up with is the Measurement Computing USB-CTR high speed timer counter. They are sold through Digilent, which is an NI company, but the 4 channel unit is only $419
The block diagram is shown below and you can note that there is an embedded FPGA system on it which makes it very powerful for signal processing. The system has a lot of advanced features almost unthinkable just 10 years ago (especially at this price point). The system internal clock runs at 96Mhz and that determines the resolution of the acquisition system. One "tic" of the system clock is 20.83 ns and when timing the VR sensor signals the system is counting clock tics from one point on the incoming waveform to the next. So one can see that none of the usual analog shenanigans like oversampling (to capture the actual waveform) is needed to get sensible data. The signal conditioning board converts the AC waveform of the VR sensor into a train of square waves and the acquisition board then counts the clock tic from the rising edge of one pulse to the next. Each is 1 tooth on the gear. If the time interval gets shorter, the gear is rotating faster and so on.
The Measurement Computing board is supplied with software that is covered in the purchase price which allows you to configure and operate the board through a connected USB cable and you can start and stop acquisition and then export those data files for post processing. It is possible to write custom software for the board on a variety of different platforms, which include Labview and C code. They have software libraries and some application code available. I may not end up being the guy to get deep into the custom software, but the guy who may coule be one of us lurking in the background... But for now as a basic system I believe that the supplied software is probably going to be all that is needed.
4) Post processing: Here is where I will probably need the most help because I am not a vibration test engineer, although I do know such people. The data acquisition system is going to output a file containing timing data for the crankshaft, gearbox input shaft and gearbox output shaft as a minimum. We have a 4 channel system so with a 4th sensor and provided one has a suitable encoder object one could acquire that too. This timing data is going to be loaded into a program like Mathcad or an analog like open source GNU Octave. There one can perform FFT (Fast Fourier transform) which is an easy way to say very painful calculus that makes ordinary people faint or cry for their safe space... But software has come a long way since the days of 123 and excel and the fact is that the average user only uses 1/10 of a % of what even those tools can do. But I will admit that in my career so far I have not had to concern myself with FFT analysis but it is needed for this application. More than likely once one knows how the data needs to be processed one just has to insure that the data is in the appropriate channel and can then run a script to process it, sit back and wait (if that is even needed) and it will pop out the result.
Wikipedia link to FFT Fast Fourier transform - Wikipedia
Waterfall plot Waterfall plot - Wikipedia
5) Test Method, even though the process starts with acquiring data, I put it last because one has to work though a lot to even be ready for this step.
So we have the engine and gearbox instrumented to get what amounts to encoder data from the crankshaft, gearbox input shaft and gearbox output shaft. So we start the testing with the biggest mass in the system removed, the prop. By removing the prop the system is unloaded, and it will take very little power to drive the engine and gearbox to Max RPM without a large load being applied to anything, minimum torque and very low likelihood of having any strong torsional vibrations. The reason for doing this is to get a baseline check of the sensors and acquisition system from idle to max rpm. When this data is post processed one would expect to see virtually identical timing on all the signals with no phase shifts. This will confirm that the timing signals of each sensor through the cables and then through the signal conditioner and finally acquisition system "front end" are all uniform and there is no time shift occurring. One can use a 4 channel oscilloscope to look at the analog sensor signals and the output of the signal conditioning board to confirm the absence of glitches or any other strangeness.
Then, after that is squared away and signed off, then we can put the prop back on and now we would do some run ups "for real". One would start near idle because that is when one is expecting to have resonant behavior and progressively increase engine speed to reach static RPM (plane would have to be safely tied down). One would acquire data throughout the run and the runs can be short, less than 1 minute from idle to static RPM and back down to idle. This process is repeated a few times since no 2 runs would be identical. Then one takes the data home and post processes it through GNU Octave or similar code and makes your waterfall plots to see where any resonant behavior is at and how high the peaks are. Then one is able to make any mechanical changes in the system (mass of flywheel, mass of prop, properties of the flexible coupling etc) and make data driven decisions on the optimization of the system. With some experience one would have a good idea of how good it can be and know when to stop. Hopefully any resonance is at a low RPM which one can try to avoid on the ground and in flight and no resonances in the middle of the "power band" which one might frequently use. It may be necessary to change timing or other engine parameters to mitigate some of the vibration issues depending on where they fall.
OK, hope that is a start to this subject, its certainly where I am starting at...
Grounding the conversation, I am a mechanical engineer and what little I know about electronics is self taught because as can be imagined, any machine today incorporates sensors and feedback and has a control system, so unless one is part of a multi disciplined team who is working on a project, one is frequently on your own to determine how best to handle the controls and software through outside vendors and software contractors and if you are particularly bad at it, you get fired and if you are good at it, you either get tolerated (in a technically un-savvy company) or if you have a good employer then you might be rewarded or get promoted. I have developed a lot of manufacturing equipment in my time including a very fast laser measurement system which Daimler thought was state of the art for its time. A lot of the controls I used were from National Instruments, but in recent years NI has gone a bit off the rails, especially on cost, both for hardware and their software development system and it is a system with a very steep learning curve. Thus the equipment I will be suggesting (that I will be buying myself with my own funding) is below the level of the typical NI hardware/software price point.
So lets define the basic system:
1)Sensors: For the sake of cost and complexity, I am going to assume that all speed sensors will be Variable Reluctance type sensors. This is the same sort of hardware used to measure the camshaft and crankshaft speed and position on the majority of engines in production. I have not yet identified a source, I have started discussions with Rotec but the Michigan rep gave the impression they would not sell sensors as individual components, only as part of a complete system. He was also very disparaging about any data acquisition system other than from Rotec which suggested a degree of industry blindness and being unaware of the great progress that has been made with FPGA systems in the last 15-20 years. I have not found any US sources for Zebra tape which is applied to exposed shaft surfaces and then scanned with laser sensors. I also believe that the laser sensors are going to end up being cost prohibitive. Fine for the test departments of Billion $ corporations but out of reach of the hobbiest/layman.
On my own gearbox, I would drill and tap 2 holes in the gear housing into which the VR sensors could be inserted so that they can read the tops of the gear teeth on the gearbox input shaft and output shaft. Typically the sensor needs to be 0.5-1.0mm from the gear tooth and the orientation of the windings and magnetic core basically aligned with the tooth helix angle for best response. Because of this the test sensors usually have fine pitch threads to allow for rotating the sensor for best response without materially changing the axial clearance to the tooth (if the thread pitch is 1mm then 90º of rotation is only an axial shift of 0.25mm). For a gearbox belonging to someone else, who may be understandably reluctant to have holes drilled into his gear housing, one would need to add encoder wheels to the shafts of interest by clamping on rings that have teeth cut in them for sensing. These would be made as light as feasible while still being of ferromagnetic material. Brackets for the pickup sensor would also have to be added. Worst case scenario brackets could be glued to the gearbox or engine with bondo which could then be knocked off after the fact.
2) VR signal conditioner / schmitt trigger. The output of the VR sensor will need to be conditioned to convert it from a strange AC waveform to a DC square wave that is either CMOS of TTL compatible to match the digital counter timer input.
Above is an example of what the output of a typical VR sensor looks like as the sensor is passed by the tips of gear teeth. The blue trace below the VR signal represents the ideal DC square wave signal that one wants to feed a data acquisition system. Sometimes the input circuit of a digital acquisition board may have built in filtering to help with converting the signal, but for now I am assuming that I will build a 4 channel signal conditioning board for the application. I have yet to decide which input signal is considered the reference, it may in fact be the output shaft of the system (prop shaft) but I will accept advice from those with more experience than I. There are a multitude of purpose made IC's for processing VR signal data into clean square wave outputs like MAX9924 to MAX9927, LM1815 or NCV1124
3) Data acquisition system: As previously discussed, I cannot afford a PXI or cRio system from NI that would run something like $5000-$20000 and then would still be useless until another $20k worth of programming is done for it to make it do what is needed. Both of those systems are very powerful and capable of high speed acquisition, digital signal processing and even calculation of the data through algorithms like FFT to convert time based data directly into frequency spectrum data to be displayed on a waterfall plot. I am assuming our equipment will capture timing data digitally (not storing analog signals taken at a certain timing rate) and then we would post process that data to get the results we are looking for. So in my searching so far, the best I have come up with is the Measurement Computing USB-CTR high speed timer counter. They are sold through Digilent, which is an NI company, but the 4 channel unit is only $419
The block diagram is shown below and you can note that there is an embedded FPGA system on it which makes it very powerful for signal processing. The system has a lot of advanced features almost unthinkable just 10 years ago (especially at this price point). The system internal clock runs at 96Mhz and that determines the resolution of the acquisition system. One "tic" of the system clock is 20.83 ns and when timing the VR sensor signals the system is counting clock tics from one point on the incoming waveform to the next. So one can see that none of the usual analog shenanigans like oversampling (to capture the actual waveform) is needed to get sensible data. The signal conditioning board converts the AC waveform of the VR sensor into a train of square waves and the acquisition board then counts the clock tic from the rising edge of one pulse to the next. Each is 1 tooth on the gear. If the time interval gets shorter, the gear is rotating faster and so on.
The Measurement Computing board is supplied with software that is covered in the purchase price which allows you to configure and operate the board through a connected USB cable and you can start and stop acquisition and then export those data files for post processing. It is possible to write custom software for the board on a variety of different platforms, which include Labview and C code. They have software libraries and some application code available. I may not end up being the guy to get deep into the custom software, but the guy who may coule be one of us lurking in the background... But for now as a basic system I believe that the supplied software is probably going to be all that is needed.
4) Post processing: Here is where I will probably need the most help because I am not a vibration test engineer, although I do know such people. The data acquisition system is going to output a file containing timing data for the crankshaft, gearbox input shaft and gearbox output shaft as a minimum. We have a 4 channel system so with a 4th sensor and provided one has a suitable encoder object one could acquire that too. This timing data is going to be loaded into a program like Mathcad or an analog like open source GNU Octave. There one can perform FFT (Fast Fourier transform) which is an easy way to say very painful calculus that makes ordinary people faint or cry for their safe space... But software has come a long way since the days of 123 and excel and the fact is that the average user only uses 1/10 of a % of what even those tools can do. But I will admit that in my career so far I have not had to concern myself with FFT analysis but it is needed for this application. More than likely once one knows how the data needs to be processed one just has to insure that the data is in the appropriate channel and can then run a script to process it, sit back and wait (if that is even needed) and it will pop out the result.
Wikipedia link to FFT Fast Fourier transform - Wikipedia
Waterfall plot Waterfall plot - Wikipedia
5) Test Method, even though the process starts with acquiring data, I put it last because one has to work though a lot to even be ready for this step.
So we have the engine and gearbox instrumented to get what amounts to encoder data from the crankshaft, gearbox input shaft and gearbox output shaft. So we start the testing with the biggest mass in the system removed, the prop. By removing the prop the system is unloaded, and it will take very little power to drive the engine and gearbox to Max RPM without a large load being applied to anything, minimum torque and very low likelihood of having any strong torsional vibrations. The reason for doing this is to get a baseline check of the sensors and acquisition system from idle to max rpm. When this data is post processed one would expect to see virtually identical timing on all the signals with no phase shifts. This will confirm that the timing signals of each sensor through the cables and then through the signal conditioner and finally acquisition system "front end" are all uniform and there is no time shift occurring. One can use a 4 channel oscilloscope to look at the analog sensor signals and the output of the signal conditioning board to confirm the absence of glitches or any other strangeness.
Then, after that is squared away and signed off, then we can put the prop back on and now we would do some run ups "for real". One would start near idle because that is when one is expecting to have resonant behavior and progressively increase engine speed to reach static RPM (plane would have to be safely tied down). One would acquire data throughout the run and the runs can be short, less than 1 minute from idle to static RPM and back down to idle. This process is repeated a few times since no 2 runs would be identical. Then one takes the data home and post processes it through GNU Octave or similar code and makes your waterfall plots to see where any resonant behavior is at and how high the peaks are. Then one is able to make any mechanical changes in the system (mass of flywheel, mass of prop, properties of the flexible coupling etc) and make data driven decisions on the optimization of the system. With some experience one would have a good idea of how good it can be and know when to stop. Hopefully any resonance is at a low RPM which one can try to avoid on the ground and in flight and no resonances in the middle of the "power band" which one might frequently use. It may be necessary to change timing or other engine parameters to mitigate some of the vibration issues depending on where they fall.
OK, hope that is a start to this subject, its certainly where I am starting at...
