
06-08-2004, 13:11
|
 |
BSEE, MSEE, JD
AKA: employed
no team
Team Role: Alumni
|
|
Join Date: Jun 2001
Rookie Year: 2000
Location: Saint Petersburg, FL
Posts: 1,144
|
|
|
Re: Using and Coding an ultrasonic sensor
Quote:
|
Originally Posted by dlavery
We are currently trying to resolve a small problem with an alpha particle x-ray spectrometer on our robot that is being used as an in-situ sensor to determine the elemental composition of targeted compounds and other materials under investigation. Prior to full operational use, the spectrometer was stored in a cold soak, reduced pressure environment, with the devie powered on to monitor system health and emission source strength, for approximately seven months. For the past seven months, the sensor has been used on an intermittent basis, and returned to an environment similar to the long-term storage conditions for at least half of the operational period. Total device duty cycle is less than five percent. Data sets from this device are fused with data from a vertically-mounted mini thermal emissivity spectromter, to provide additional discrimination information for environmental characterization and identification of investigated materials.
During recent utilization of the spectrometer the device attempted to execute a number of standard operations, with anomalous results. When the sensor payload software attempted to turn on the payload FPGA, the FPGA failed to power on before the FPGA Power On Timer timed out. Subsequently, the payload software issued a MTES image command. The MTES image command failed due to an MTES interface timeout. Further MTES image commands failed similarly, and generated several more instances of the FPGA Power On Timer timeout EVR. A fault EVR was then generated due to the failure of the PMA azimuth actuator to move. However, since there is a hardware level handshake between MTES and PMA, this is likely to be a secondary failure due to the failure of the FPGA to power on during the original attempt. Initial analysis of the anomaly indicates it is likely due to an insufficient interval between the MTES_ABORT_IMAGE command from e3383 and the subsequent MTES_IMAGE command from p3576. If the timing is "just right", the pyld software can be put into a state such that all subsequent attempts to power the FPGA will fail. Only a reboot clears the condition. We are currently attempting to recreate the anomaly on the spare backup robot to better understand the condition. In the interim, use of the APXS and other spectrometers, as well as the PMA, is precluded until the anomaly is resolved.
-dave
|
oh man that's an easy one....i just....don't wanna answer right now, yeah yeah that's the ticket 
|