Analog I/O Connectivity Design

3.6 Analog I/O Connectivity Design

Pros: This plan would cover all our ADC I/O need. In addition, it would leave a lot of extra ADC I/O available should we have to add more sensors or some other ADC I/O device.

Cons: We would have to continually iterate through the 30 force sensor inputs connected to the multiplexer. Since we need to collect data from all the sensors each data collection cycle, we would be using the processor inefficiently. There would now be a large delay time between collections of data from the other ADC I/O sensors. Additionally, we would not be taking advantage of the fact that the dsPIC33EP512MU810 can handle four analog I/O accesses simultaneously. Any delay we removed, improved max data collection speed capabilities. In addition, had the multiplexer failed, we would have had a lot of problems.

Conclusion: Although using a 32:1 multiplexer is a viable option, it is not an optimal one. This strategy would cover all of our ADC I/O; however, we are giving up on efficiency for no particular reason. If the microcontroller’s ability to do four simultaneous reads was taken advantage of, it would take 33 read cycles to retrieve all the values provided by our sensors. In addition, this strategy puts heavy reliance on the multiplexer resource in order to be able to collect data from the force sensors. As the saying goes, “Don’t put all your eggs in one basket.” For these reasons, we have decided that this strategy would not be used.

Pros: Again, this plan would cover all our ADC I/O needs. We were also able to take advantage of the dsPIC33EP512MU810 capability of handling four analog I/O accesses simultaneously.

Cons: We only left one direct ADC I/O open should more analog I/O devices need to be connected. This restricts the expandability of our current design. In addition, we have the same problem as before in Strategy 1 where we had some delay when having to iterate through the 8:1 multiplex to obtain data from its sensors.

Conclusion: In this strategy, although it is also a viable option just as Strategy 1 was, the disadvantages still outweigh the benefits. Although if we time our reads correctly we can obtain the values from the sensors in only nine read cycles, we still have the issue of very few extra ADC I/O connectors. In addition to the complication that would occur should we have to add another analog I/O device, should multiple of the I/O ports on the microcontroller fail, we would have a large problem as far as trying to find a workaround. It is always better to be over prepared than under; therefore, we have decided this strategy would not be used for splitting up the ADC I/O.

Pros: With this strategy, we can divide the 30 analog I/O used for the force sensors between four 8:1 multiplexers. Because the microcontroller allows for four simultaneous analog I/O accesses, we can iterate through all the force sensors in eight read cycles through parallel reads. Then for the other four analog sensors, we can read those simultaneously also. This allows us to get reading from all of our sensors in nine read cycles. Therefore, it is much easier to account for potential ADC I/O failures should one happen to occur.

Cons: The only con that comes from this strategy is the fact that multiplexers are used which cause a small delay in obtaining the sensor readings.

Conclusion: Although there is some delay that comes with using a multiplexer, this is a problem which occurs with both Strategy 1 and Strategy 2 as well. Nonetheless, this strategy has a higher benefit to hindrance ratio than the other two strategies. With this strategy we can account for potential ADC I/O failure which the other strategies do not account much for. Therefore, we have decided Strategy 3 is our best option for splitting our ADC I/O readings.

4. Project Hardware and Software Design Details

4.1. Initial Design Architecture

It was decided that we would build hardware that wouldn’t be an autopilot because that would impose extra requirements of the project, so the autopilot has its own block. Also the as seen the autopilot or the R/C transmitter has control of the plane at any given time by controlling the motor and bank of servos that control the flight surfaces. The Sensory bank is really what we are responsible for designing and recording from them with the microcontroller. The Data Communications bank is in anticipation of an optional requirement of transmitting the sensory bank information over-the-air to ground, so no sensory information would have to be stored in the microcontroller. This is for much the same benefit as why our autopilot; the ArduPilot Mega has ground station transmitting and receiving information about the flight plan and aircraft orientation and position. Our hardware design is outlined in Figure

Figure : Hardware Diagram

Directory: seniordesign
seniordesign -> Executive Summary 4
seniordesign -> Hvac control and Feedback System 0 Group 2 Steve Jones Mathew Arcuri Elroy Ashtian, Jr
seniordesign -> Group 5 Spr-Sum 2011
seniordesign -> Senior Design II paper
seniordesign -> Remote Touchscreen-Controlled Defense Turret Senior Design Documentation Courtney Mann, Brad Clymer, Szu-yu Huang Group 11
seniordesign -> Amphibious vehicle
seniordesign -> T-100 Watch Dog (Autonomous Security Vehicle)
seniordesign -> Ehvac: Wireless Modular Multi-Zone hvac controller Group b javier Arias Ryan Kastovich Genaro Moore Michael Trampler
seniordesign -> Table of Contents Executive Summary 2

Download 0.61 Mb.

Share with your friends: