Shepard Test Stand - Future Design Discussion - v2.0 - Open Design Engine

Future Design Discussion - v2.0

Added by Jeremy Wright about 11 years ago

This has been copied from an email conversation about Shepard requirements.

Aaron Harper wrote:

I think the NAR measurement was concerned about burn-thru, otherwise there is no reason to measure temperature at those two points. I didn't see anything about sensor specs, lag and slew rates, measurement resolution, or time resolution, and I get the feeling that these may have been outside the skill set of the NAR spec writers. This means we will probably have to write our own.

Some possible specs to yield a usable dataset:

1. The temperature sensor must be used in accordance with it's design. A contact sensor such as a thermocouple must be put in contact with the motor casing, while a non-contact (IR) sensor may need to be placed a minimum distance away from the casing to form a valid thermal image.

2. The temperature sensor must be able to read 50% or more of the temperature which would destroy the motor casing, ie. if the casing will ignite at 500F, the sensor must be able to measure to 250F as a minimum. This refers to the sensor's specification, not the calibration of the measurement circuit's full scale.

3. The temperature sensor must be read as an analog value with a minimum of 8 bit precision. This will allow a very small change to be spotted even if it were to occur in a destructive event since the system could register a change as small as 0.004 degrees in the above example.

4. The temperature measurement system must read the temperature at least 32 times during the engine thrust cycle. In a 1/2A3-2T, the system must measure the temperature at least 32 times during the 3 second propellant burn. This is a measurment every 93mS or a frequency of 10.67Hz.

5. The sensor must be able to yield valid data at least 1/8 of the way through the test. This means that in the example above, the sensor may not lag more than 375mS.

Thoughts?

Replies (30)

RE: Future Design Discussion - v2.0 - Added by J. Simmons almost 11 years ago

I think we can make the necessary changes to the v2.0 structure to accommodate this sensor (and that we can probably hack the v1.0 structure to make it work during preliminary testing of the v2.0 DAQ). So, I would agree that we have a temp sensor to order and test.

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright almost 11 years ago

We have discussed ideas informally about redesigning the motor mount so more of the casing is exposed. The original thought was to minimize damage to the mount in case of a motor failure (explosion), but it would help us here too.

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright almost 11 years ago

This idea has been brewing in my head for awhile, and a conversation I had with J the other day got me thinking more about it again.

There's been discussion of using the BeagleBone Black on Shepard 2.0, and taking advantage of it's built in Ethernet interface. This brings up the questions of how do you configure the network (do you have the Bone do DHCP, etc), and what happens when a teacher (or anyone else) can't get their laptop's Ethernet interface configured properly to work with Shepard.

There are technologies like ATAoE that utilize the lower layers of Ethernet to gain speed and control, and I'm wondering if the same thing could be done with Shepard 2.0 if we use the BeagleBone.

http://aschauf.landshut.org/fh/linux/udp_vs_raw/ch01.html

I'm thinking that if we did it right, all that would be required is to connect the Bone to a laptop with a cross-over cable. I need to research it more though if folks agree that this might be a viable idea.

RE: Future Design Discussion - v2.0 - Added by Aaron Harper almost 11 years ago

The easiest way, since it is unlikely that the test stand would be connected to multiple interfaces or a network, just use a crossover Ethernet cable and have the Beaglebone run a DHCP server with a pool of one address and the subnet of 255.255.255.254 (/31). With everything on the laptop set to auto, it will hook up with no trouble.

RE: Future Design Discussion - v2.0 - Added by Jeremy Wright almost 11 years ago

The thing that worries me is that a teacher with no IT staff could have their Ethernet interface set to static and not understand why the software can't connect to Shepard.

Two things that might help though are:

1. Have the software detect a static address configuration and warn the user.
2. Just have the users rely on the forums.

« Previous 1 2 (26-30/30)