garry@fang.dsto.oz (Garry White) (06/13/91)
The following letter is a summary of a letter I received from Michael Houston. Michael's letter detailed a problem his group is facing and a request for information/assistance from the "world". The problem relates to the acquistion of Thermoelastic Scan Data. ------------------------------------------------------------- The Applied Mechanics Group here at Aeronautical Research Lab are using a technique where the change in temperature at many points within a dynamically loaded structure may be used to describe the stresses within the structure. A problem they have encountered is that the changes in temp. range near the the minimum resolvable temps of commercially available Infra-Red camera. In order to improve the clarity of their measurements they intend to do some averaging (either on line or off line) over many (up to 10000) frames. The problem they now encounter is a function of the fact that they wish to capture the digital data stream before video processing and D/A translation. The problem being that they now have very high rates of data transfer and enormous storage requirements. Michael outlined a set of specifications and information for a "high-end" system. The objective of the group is to obtain or build a system which will accommodate this set of specs. Below is a summary of the proposed solution involves. The camera is equipped with a 512 X 512 sensor array. The array is scanned twice and the fields interlaced to produce one frame in 1/25th of a second, and the infra-red flux measurement taken by each sensor is quantified in an 11-bit word (after A/D conv.) (Note that this becomes and 8-bit word after transformation in the LUT. This may be an acceptable alternative for some applications). This signal is available after some corrective processing at a GPIB interface which has sufficient onboard memory for one frame. The intention is to send the digital info via the GPIB interface to some appropriate storage device. This may be a set of parallel winchestor disks, or RAM (very expensive) or some other alternative, each with their own difficulties and costs. Such a proposal results in a figure of 9.01M/sec incoming data rate and a total storage requirement of some 3.6 Gigabytes (assuming 10000 frames - 6 mins 40 secs of recording time. A solution based on 8-bit words results in 6.5M/sec and 2.6G. Options to reduce these big numbers include discarding some of the data (eg. every i-th frame) but ideally this would be avoided. Data compression may also be possible once more is known about the incoming info. Michael and his group would be most appreciative of any advice, suggestions (including those which, at the time may have seemed only remotely feasible), or expressions of interest. Any and all questions concerning the info supplied here are most welcome. Michael Houston can be contacted at myh@dstos3.dsto.oz.au if and only if this fails you can mail to kenjones@munmurra.cs.mu.oz.au