Indiana University-Purdue University Fort Wayne Department of Engineering ECE ECE 406 Capstone Senior Design Project Report #2

Transcription

1 Indiana University-Purdue University Fort Wayne Department of Engineering ECE ECE 406 Capstone Senior Design Project Report #2 Project Title: Team Members: Faculty Advisor: Wireless Electrically Commutated Motor System Sukaynah Abu-Mulaweh Adam Contino Dylan Wolf Dr. Abdullah Eroglu Date: May 5,

2 Table of Contents Acknowledgement....3 Abstract/Summary.4 Section I: Problem Statement...5 Section 1.1: Problem Statement Overview..6 Section 1.2: Requirements & Specifications...7 Section 1.3: Given Parameters.7 Section 1.4: Design Variables..8 Section 1.5: Limitations and Constraints.9 Section 1.6: Additional Considerations...9 Section II: Design Process...11 S e c t i o n 2. 1 : B l u e t o o t h Chipset S e c t i o n 2. 2 : P o w e r Components S e c t i o n 2. 3 : C o m m u n i c a t i o n C omponents Section 2.4: Bread boarding..16 Section 2.5: Software Development..17 Section 2.6: PCB Design Section 2.7: Assembly & Debugging Section III: Testing and Evaluation.. 25 Section 3.1: Free Space Testing Section 3.2: Unit Testing Section 3.3: Maximum Communication Distance 31 Section 3.4: Longevity Test Section 3.5: Temperature Testing..34 Section 3.6: RFduino Voltage and Current Test 36 Section 3.7: Power Analysis.. 37 Section IV: Cost Analysis/Estimation...39 Section 5.1: Bill of Materials Section 5.2: Cost Estimation...40 Section 5.3: Cost Analysis...41 Conclusions...42 Recommendations...43 References

3 Acknowledgment The team would like to extend its sincere gratitude to Electric Motors and Specialties Inc. (EM&S) for the sponsorship of this project. The team is also appreciative of the guidance received from Dr. Abdullah Eroglu, who met with the team each week to render his technical support, advice, and direction throughout the design process. The team would like to thank the IPFW Engineering Department for their support of this project and for allowing the team to utilize their lab facilities. The team would also like to express thanks to Tom Wolf, Randall Mayberry and IPFW IT Services for their help with various parts of the project. 3

4 Abstract/Summary Electrically commutated motors (ECM) have been around for a number of years now. In the refrigeration industry in particular, they provide the necessary air flow in condenser units to allow for the cooling of the product within the refrigeration unit. Currently, the only connection to these motors for maintenance or data collection is a wired connection via a port on the back side of a motor. This project looks to further the industry by adding a wireless data acquisition and control feature to these motors, allowing them to communicate with a smartphone device through an extremely simple and straightforward application. The added wireless system will consist of an appropriate wireless communication chipset with all of the necessary external surface mounted components needed to operate and collect data through inputs. The circuitry for the chipset will need to either be an existing module unit, or completely designed by the team. This circuitry will mount onto the existing control circuitry already present within the motor and will draw its power from that circuitry so as to not impede its normal operation. It will observe outputs from various critical points on the control circuitry in order to obtain the current RPM that the motor is running. It will also have inputs into the microcontroller on the control circuitry in order to have the capability to specify a RPM value for the motor to change to. With those features, the smartphone application will have the ability to provide a current RPM readout and also allow the user to specify a new RPM for the motor to run. Other data point readouts, such as critical voltages and power dissipation readings, may be added to the system as well, cost allowing. Energy saving features such as a temperature sensor may be added, which will allow for the motor to vary the RPM based on the current temperature of the product in the refrigeration unit. This feature may be added on a cost and or time basis as well. 4

5 Section I: Problem Statement 5

6 Section 1.1: Problem Statement Overview The most current, front running design in the refrigeration industry is a motor unit that can be used in many applications requiring many different speeds. Currently, this motor requires a plug in handheld device to observe the speed of the motor and then change it. To do this, access to the back of the motor is required to connect the speed change unit. This speed change unit is also a separate unit that must be purchased along with the motor. The second option would be to purchase an expensive control unit for the motor. In order to further the industry, a wireless ECM (electronically commutated motor) connection that does not require the purchase of a separate handheld unit must be designed. Such a system would allow for maintenance personnel to connect directly to a motor using only a smartphone instead of removing the motor and using a cable. The main objective of maintenance personnel who maintain the cooling units with these fan motors is to get a running motor into the unit where one has failed. They do not focus on what speed the new motor is running, just that it is running. Due to this fact, the unit may not be cooling as efficiently as it can if the new motor is not running the right speed specified by its manufacturer. With a wireless ECM system one could check the speed of other motors in the unit and select the speed of the new motor to match with the press of a few buttons. This allows for faster and better maintenance that maintains the efficiency of the cooling unit. Adding data acquisition to the wireless ECM system will allow for quicker troubleshooting in the engineering department of the company and also allow for field troubleshooting of the motor. It will also allow for greater research into the improvement of the control board design. The options are almost endless when choosing what data to observe, but the more observable points added to the design of the wireless ECM system, the higher the overall cost of the motor will increase. As few critical points as possible, if any, must be chosen to observe in order to keep the cost of the wireless ECM system reasonable. Electric Motors and Specialties already has a working variable speed thermally controlled motor prototype. This, if refined and added to the wireless ECM as an extra feature, would allow for the selection of higher efficiency. When the feature is selected, the motor would enter a mode where it constantly observes the temperature within the cooling unit and adjusts its speed accordingly (higher RPM if the temperature is too high and lower RPM if the unit is at the desired temperature). Such a feature could be purchased as an addition to the wireless ECM 6

7 system as it would only better the efficiency of enclosed cooling systems and not air curtain cooling systems. Another feature to be added to the wireless ECM system will be the creation of a file containing information about the motor which can then be sent to the company for review. Section 1.2: Requirements & Specifications - Antenna: An antenna must be designed or chosen based on cost, size and signal strength. - Frequency Range: The wireless ECM (electronically commutated motor) system must have a frequency within the range of GHz for Bluetooth low energy and ZigBit; 915MHz for RFID - Hardware Interface: The wireless ECM system must interface with an Android phone and iphone. - User Interface: The wireless ECM system must be as simple as pressing a button for desired action (read speed, change speed, troubleshooting). - Software Program: The wireless ECM system must have a programmed Android and or iphone app and the wireless connection must be programmed to use that app. - Output: The wireless ECM system must change the speed of the motor to desired speed and then check to make sure it s been achieved. - Display: The display of the application should be clean and easy to follow. Section 1.3: Given Parameters The following fixed parameters form the guidelines for the design of the wireless ECM system. - Must interface with current ECM control circuitry - Must be wireless connection from motor to smartphone 7

8 - Must read the current RPM of a running motor - Must be able to specify a change in RPM of a motor - Must be located within the motor. Section 1.4: Design Variables In the design of the wireless ECM system, there will be flexibility due to numerous variables. The hardware consists of the components and the overall construction of the system, whether it be contained in the motor housing or outside the motor housing. Data transfer refers to the wireless transmission characteristics, and the software refers to the programming of the motor control board and the programming of the smartphone application. Hardware - Antenna Location: Depending on the quality of the signal the antenna may either be inside or embedded into external components of the motor. There are many different antenna implementations available. - Antenna Type: The antenna type shall be planar, surface mount, or embedded in an existing external component of the motor. - Components: A Bluetooth Low Energy chipset or ZigBit chipset will be chosen and components needed for the implementation of either chipset will be needed. Other components will be added as needed for the data acquisition characteristics of the project. The quality of components used will be selected in a way to keep the cost to a minimum while still maintaining the necessary quality of the end product. - Power: The system must be designed to work off of the available power on the existing control circuit without impeding on the normal operation of the circuit. Data Transfer - Transfer Rate: The rate of data transference should be under one minute. 8

9 - Communication: 2-way communication between motor and wireless device is necessary to read and adjust RPM of motor. - Operating distance: The operating distance for the Wireless ECM system should be at least feet. Software - Control Board Program: The program on the motor control board will need to be tailored to work with the Bluetooth circuitry and subsequently the Android application. - Application: An Android and or iphone smartphone application will be designed to send and receive signal between the phone and the motor. Section 1.5: Limitations and Constraints - Frequency Range: Bluetooth frequency range of GHz is to be used to conform to ISM standards. - Size: The system should fit within the current motor housing if possible. If not it should be as small as possible so as to be mounted onto the outside of the motor. - Operational Temperature: The ambient temperature for the system ranges from 0-80 Celsius. The system must also endure abnormal temperatures as high as 200 degrees Celsius without causing fire or shock hazards. - Cost: The project budget is $5000. Every purchase requisition must be reviewed and approved by the VP of Engineering at the company. - Safety: System will be used by consumers so it must be safe in many environments. Section 1.6: Additional Considerations - Time: Due to a time restriction of a school year to design and build the system, the design must be manageable within the time allotment. 9

10 - Standards: The system must adhere to IEEE standards for wireless communications. - Features: If possible within the time constraints of the project the following features will be added iphone compatibility Variable speed temperature sensing with user defined speed per temperature ranges Digital serial numbering and date stamping of motors Data acquisition, formatting, and transference to the company 10

11 Section II: Design Process 11

12 Section 2.1: Bluetooth Chipset The RFduino RFD22301 chipset was chosen as the preferred chipset for the two way communication necessary for this system. This chipset is compatible with both Android as well as iphone platforms, with example applications available. The list below lists the important specifications of the RFduino chipset that led to the decision to utilize it. Figure 2.1, seen below, pictures the chipset to be used with the pins labeled. Figure 2.2 seen below illustrates the relative size of the chipset. RFduino RFD22301 Chipset Bluetooth 4.0 Low Energy Compatible Built in Microcontroller and Bluetooth Antenna Reprogrammable Small Chip Size Low Voltage 3 V Android and iphone Compatible Sample Applications for both Android and iphone IC and FCC Approved and Certified CE (ETSI) Compliant 12

13 Figure 2.1: RFduino RFD22301 chipset with labeled pins Figure 2.2: Size of RFduino RFD22301 chipset compared to the tip of a finger Shown below in Figure 2.3 is a layout example for the RFduino chipset. From the legends, it is observed that in the area around the antenna no copper or components can be present. This is to ensure that the signal strength of the antenna is optimal. Figure 2.3: RFduino footprint and antenna specifications Shown below in Figure 2.4 is an example of the RFduino chipset layout within a plastic enclosure. From the example you can see that the antenna is best placed at the edge of the 13

14 enclosure so that no copper or components can interfere with the signal. This also makes the antenna as close as possible to free air space to ensure good signal strength. The one-inch length copper area is optional, however it does improve the range if it is added. Figure 2.4: Antenna positioning with regards to enclosure Section 2.2: Power Components In order to provide power to the RFduino chipset, the original chosen design implemented a linear voltage regulator integrated circuit. This regulation/voltage step down circuit was designed to draw power directly from the motor control circuit s 5V rail without impeding the normal operation of the control circuit. During initial testing of the RFduino power supply, it was determined that the linear voltage regulator integrated circuit required more current than the motor s 5V line could source. As a result of this fact, neither the RFduino power supply nor the motor were operating properly. At this point in the design, a new integrated circuit regulator was specified. This regulator was of the switching buck topology and provided the greater efficiency that the project required. Once the MCP I switching buck voltage regulator was integrated, the power supply design performed exceptionally well compared to 14

15 its linear counterpart. Along with its added performance capabilities, this voltage regulator was much smaller physically and only required one extra component over the linear regulator. The recommended circuit for the switching buck regulator included two smoothing shunt capacitors on the input and output lines and a buck inductor. The recommended buck inductor was a 4.7uH inductor; however, a 3.3uH inductor was found to perform to the project needs and cost less than the recommended 4.7uH. Figure 2.5 shows the recommended supplementary circuitry shown in the regulator datasheet. Figure 2.5: Recommended regulator circuitry. The traces shown in red are recommended to be as short and as wide as possible to achieve the maximum performance out of the regulator. Section 2.3: Communication Components In the original chosen design, the communication lines consisted of resistive networks between the motor control board microcontroller and the RFduino. While this resistive network worked initially, there were bouts of unacceptable errors in the communication signal. Once this issue was observed with an oscilloscope, the decision was made that the signal degradation was much too high and a bi-directional voltage level translator was needed in the adapter circuit. The TXB0104 voltage level translator was chosen for the communication between the two microcontrollers. It required only a pull down resistor and two smoothing shunt capacitors to operate. It was powered by the 5V and 3V lines in the adaptor circuit. The recommendations in the datasheet called for not only the complementary components but the shortest trace lengths possible for the communication lines. This was due in part to the outputs of the 15

16 translator being weak by design as it is a low power device. Figure 2.6 shows the recommended circuit for the voltage level translator. Figure 2.6: Recommended voltage level translator circuitry Section 2.4: Bread boarding Once all the correct components were specified for the design, the adaptor was put onto a breadboard for testing. On the initial testing of the breadboard circuit, the power regulation from 5 volts to 3.3 volts was operating around 2.5 volts and not at its maximum potential of 3.3 volts. The test was halted, and the wiring of all points in the regulation circuit was minimized as much as possible. Figure 2.7 seen below depicts the breadboard at this state. Figure 2.7: Breadboard after wire minimization 16

17 As a result of this minimization, the supplied voltage increased to around 2.7 volts. This supported the regulator s datasheet recommendations and was the first indication that a printed circuit board was a necessity for the project. The supplied 2.7 volts was enough to run the RFduino chipset and continue testing the rest of the adaptor board; however, it adversely resulted in difficulties with the digital communication between the microcontrollers as the voltage was near the lower threshold of the translator. Another obstacle with the bread boarded circuit was the fact that the communication lines were orders of magnitude too large for the level translator to provide an accurate communication of the speed readout signal from the motor. With this observation, it was concluded that a printed circuit board was an absolute necessity to achieve the smallest possible trace length for both the regulator and the voltage level translator and the most accurate communications between the two circuits. Section 2.5: Software Development In the software development process for the smartphone applications, there were standard example Bluetooth Low Energy (BLE) 4.0 connection applications for each operating system. These standard connection applications were chosen to speed up the design process and the different software languages were learned. The applications created for this project used the standard connection applications and were built off of them for the specific needs of the project. The sponsor company only specifically required an Android application for this project; however, to increase the usability of the product, it was decided that an ios application would be created as well. In this manner, there would be no specific device that the customer would be required to purchase in order to access the motor. It would be compatible with the main devices currently on the market. Both applications were designed to be as simple as possible for both the user and the programmer. The applications served only as a wireless display for the RFduino chipset so as to simplify the programming work that needs to be done for them. The applications only receive float data points from the RFduino, format them for display on the smartphone screen and send byte values to the RFduino to specify the correct speed index value to be sent to the motor. All of the signal processing and calculations were addressed in the RFduino programming. The bi-directional communication line was used and observed by the RFduino. When the RFduino was not in a state of sending a speed index byte to the motor, it was observing a signal being sent from the motor that corresponded to one half revolution of the rotor. This signal is a digital square wave signal and the original processing code in the RFduino program only counted the signal highs and calculated from there the speed that motor was running. This signal processing method did work but was not precise. At times, it varied in 17

18 20 revolution per minute intervals. Due to the large interval of uncertainty in the reading, a different signal processing method was chosen and implemented. This method was the reciprocal frequency counter method. This code is set up to observe one full period of the input motor speed signal and count the amount of time that has passed in microseconds. Then, the microseconds count is used to calculate the revolutions per minute of the rotor using Equation 1 below. rrr = ( 1 mmmmmmmmmmmm ppp pppppp ) 30,000,000 (1) The data that resulted from this equation was then sent to the smartphone application to be displayed. This new signal processing method provided very accurate and extremely precise readings of the rotors RPM to decimal resolution. The only other observed input by the RFduino in the final circuit design is the sponsor company s temperature sensor analog signal. In order to perform signal processing on the temperature signal, it had to be converted into a useable voltage level after the analog read function was used. The RFduino has 10 bit resolution for its analog inputs, so the read value was transformed into useable voltage data by using the following conversion seen in Equation 2 below. ssssss vvvvvvv = aaaaaaaaaa(ssssss ppp) ( ) (2) The 2.88 value seen in equation 2 is the peak voltage through a resistive network between the RFduino and the temperature sensor. The 1023 value seen in equation 2 is due to the 10 bit resolution of the analog read. Now that the analog temperature signal had been converted into a useable voltage signal, correlation testing with a calibrated type K thermocouple thermometer was performed as outlined in the testing section of this paper. The correlation tests yielded Equation 3 seen below and was used to relate the sensor voltage to the actual temperature. ttttttttttt = ( (ssssss vvvvvvv ).2836 ) (3) The data yielded by this equation was then sent to the smartphone for display and also used by the RFduino if the user selects the temperature sensing mode. This mode would then observe 18

19 the temperature values and change the speed of the motor accordingly, faster for higher temperatures and slower for lower temperatures. For the receiving code of the RFduino, the smartphone application sends out a byte value equaling anywhere from zero to eight. The RFduino subtracts one from the received value and then multiplies it by two to obtain the correct hexadecimal speed index value to be sent to the motor to change its speed. This operation ensures that the speed is only changed in 100 rpm increments from 1000 to 1600 rpm. This code can easily be changed to specify 50 rpm increments from 1000 to 3000 rpm; however, the physical characteristics of the motor used for this project could only support the original 1000 to 1600 rpm range and the company only required 100 rpm increments. For all modes of operation, once the RFduino has determined the correct speed index value to send it sets the interrupt line low to begin communication with the motor s PIC16F676 microcontroller. It changes the previous speed input pin to a data output pin, sets it low and then sets the clock line low. From this point on, the motor will read the state of the data line (high = 1, low = 0) on every rising edge of the clock signal from most significant bit to least significant bit until eight bits have been sent. At this point the clock will remain high, the data line will be switched back to a signal input and the interrupt line will be brought high to signal the end of the communication. A diagram of the data transmission signal can be seen below in Figure 2.8. A flowchart of the RFduino code can also be seen below in Figure 2.9. Figure 2.8: Data transmission diagram 19

20 Figure 2.9: RFduino code flowchart Section 2.6: PCB Design As stated earlier in the project during the bread boarding phase of the design process, a printed circuit board was absolutely necessary for this system to operate at its highest potential. For the design of the PCB the most necessary restrictions that needed to be observed and adhered to were those of the antenna, regulator, and level translator. The only other main consideration was that the board must fit within the motor housing with the only allowance being that the plastic front cap of the motor could be extended if needed. With all restrictions in consideration a PCB was laid out in PCB Artist following the radii of the motors control board. The circuit topology was laid out so that the RFduino antenna was close to the outer radius of the board and the majority of the communication pins were close to the 8 pin connection to the motor PCB. The bidirectional voltage level translator was then placed in line between the RFduino communication pins and the 8 pin connection to the motor PCB. The switching regulator was placed as far away from the RFduino antenna without creating excessively large loops as specified its datasheet, and all external components were placed as close as possible to the regulator to minimize the trace length and loops areas. The only larger loops were created by the ground trace to the regulator and the 3.3 volt output line which went to the RFduino and level translator. The 5 volt to 3 volt analog input port for the temperature sensor was laid out in the available space in the center of the board, and the 5 pin programming port/3 volt analog 20

21 input ports were placed on the furthest side of the RFduino to allow for in circuit programming and 3 volt inputs. The circuit diagram for the system can be seen below in Figure Figure 2.10: Circuit diagram The circuit was laid out in PCB Artist and can be seen below in Figure Figure 2.11: PCB layout of circuit 21

22 The resulting manufactured PCB can be seen in Figure 2.12 below. Figure 2.12: Manufactured PCB (without components populated) 22

23 Section 2.7: Assembly and Debugging Once the PCB had returned from the manufacturer it had to be cut from the main PCB, as many iterations of the project board were fitted onto the ordered board space. Once a board was cut free, it was populated with all components and soldered to a newly built motor. The entire wireless ECM system can be seen assembled below in Figure Figure 2.13: Wireless ECM system assembled on motor During testing of the system the most notable accomplishment of the debugging process was the addition of a shunt RC filter from the data transmission line to board ground. This addition was implemented due to the fact that whenever the data signal was being observed by means of an isolated channel oscilloscope, it became much cleaner. As a result, the speed readout became more stable and precise. The equivalent circuit that represented the oscilloscope probe was researched in the oscilloscope s data sheet and implemented on the circuit with parts relatively similar in value that the sponsor company already had in house. Once the 2.2 megaohm resistor in parallel with a 1nf capacitor was added, the signal quality improved even more than the oscilloscope probes had improved it. 23

24 Due to the added height that Bluetooth adapter board presents, the original plastic front cap of the motor housing would not fit over the circuitry. The company was consulted at an earlier time and gave their approval to extend the front cap, so as to achieve the goal of keeping the system enclosed in the motor housing. To achieve this, an AutoCAD 3D model of the existing front cap was made and then extended to the length needed. This 3D model was then saved into a.stl file and 3D printed utilizing a MakerBot Replicator 2 3D printer at the university. The finished 3D printed cap can be seen below in Figure Figure 2.14: 3D printed extended front cap 24

25 Section III: Design Testing and Evaluation 25

26 Section 3.1: Free Space Testing The communication between the motor system and phone applications were first tested in open air conditions, to assure the best possible conditions for wireless communication. To perform this test, the motor was placed in a location without any material that could interfere with a wireless signal, as shown in Figure 3.1 below. In this setup, the speed on the motor was changed wirelessly at various distances. While performing this test, the temperature sensor is reading at or near its maximum value since the open space is not temperature controlled. The temperature data is recorded as this data is also being sent through wireless communication to the phone application. Seen below in Tables 1, 2, and 3 are the test results for the free space testing at 5, 10, and 20 feet respectively. The tests were performed at these distance to comply with the specification of wireless communication from feet. From these tests, it can be observed that the wireless communication system works as defined in the design specifications. The system sends the correct motor speed to the phone application, and the phone application can change the speed of the motor using wireless communication in free space conditions. Figure 3.1: Free space test setup 26

27 Table 1: Free space communication test at 5 feet, with fan blade Desired Speed Speed Displayed by App (RPM) Stroboscope Speed (RPM) Time to Change Speed (seconds) Temp Displayed by App (`F) Actual Temp (`F) Table 2: Free space communication test at 10 feet, with fan blade Desired Speed Speed Displayed by App (RPM) Stroboscope Speed (RPM) Time to Change Speed (seconds) Temp Displayed by App (`F) Actual Temp (`F)

28 Table 3: Free space communication test at 20 feet, with fan blade Desired Speed Speed Displayed by App (RPM) Stroboscope Speed (RPM) Time to Change Speed (seconds) Temp Displayed by App (`F) Actual Temp (`F) Section 3.2: Unit Testing To test the system in a more realistic environment, the system while attached to a motor was put inside a refrigeration unit for additional communication testing. While mounted in the refrigeration unit, the motor is surrounded on multiple sides by metal plates, which could potentially interfere with the wireless communication signals. This setup can be seen below in Figure 3.2. With this in mind, the range testing was again conducted to test the communication between the motor system and phone application. While performing this test, the temperature sensor is reading at or near its maximum value since the refrigeration unit was not operational on the day of testing. The temperature data is recorded as this data is also being sent through wireless communication to the phone application. The testing was again done at 5, 10, and 20 feet to correspond to the design specifications. The test results can be seen below in Tables 4, 5, and 6. From these tests, it can be observed that the wireless communication system works as defined in the design specifications. The system sends the correct motor speed to the phone application, and the phone application can change the speed of the motor using wireless communication while inside the refrigeration unit, simulating the motors normal operating environment. 28

29 Figure 3.2: Refrigeration unit testing Table 4: Refrigeration unit communication test at 5 feet Desired Speed Speed Displayed by App (RPM) Stroboscope Speed (RPM) Time to Change Speed (seconds) Temp Displayed by App (`F) Actual Temp (`F) ± ± ± ± ± ± ±

30 Table 5: Refrigeration unit communication test at 10 feet Desired Speed Speed Displayed by App (RPM) Stroboscope Speed (RPM) Time to Change Speed (seconds) Temp Displayed by App (`F) Actual Temp (`F) ± ± ± ± ± ± ± Table 6: Refrigeration unit communication test at 20 feet Desired Speed Speed Displayed by App (RPM) Stroboscope Speed (RPM) Time to Change Speed (seconds) Temp Displayed by App (`F) Actual Temp (`F) ± ± ± ± ± ± ±

31 Section 3.3: Maximum Communication Distance Tests were also performed to determine the maximum wireless communication distance of the system. This test was performed while the motor was in free space and within the refrigeration unit. The connectivity was tested at different points within a building and distances from the motor was calculated. RSSI is the relative received signal strength in a wireless environment between the motor and the smartphone. The closer the RSSI number is to 0dBm, the stronger the signal. Below, in Table 7 and 8, the results of this testing can be seen. In free space the wireless communication system performed better than expected with a range of 79 feet. With the motor installed in the refrigeration unit, a stable connection was achieved at 52 feet. This far exceeds the design specifications set out for the project. See Figure 3.3 below for the floor plan of the building that the motor was tested in. Table 7: Free space distance communication testing Test Point Distance from unit (ft.) RSSI (dbm) Speed Change? Direct front of unit 5 65 Yes Doorway of tool room Middle of work room Yes Yes Work room wall Yes Middle of test room Yes Test room wall Yes Furthest corner Yes Storage room wall Yes Office wall Yes Middle of machine shop Yes Machine shop wall Yes 31

32 Table 8: Refrigeration unit distance communication testing Test Point Distance from unit (ft.) RSSI (dbm) Connected? Direct front of unit 5 75 Yes Doorway of tool room Middle of work room Yes Yes Work room wall Yes Middle of test room Yes Test room wall Yes/intermittent connection Furthest corner 79 - Out of range Storage room wall Yes Office wall Yes Middle of machine shop Yes/intermittent connection Machine shop wall Yes/intermittent connection 32

33 Figure 3.13: Floor plan layout of the engineering lab with testing points marked. - Indicates Scan, Connect, Send data, and Receive data test point. - Freezer Unit the Bluetooth device is contained within. Note: The building is a steel structure with aluminum siding. All internal walls and external walls have steel framing with the exception of the wall that the right side of the freezer is touching. That wall is cinderblock. The machine shop has a number of large metallic machines of which most are larger than a person, and there is a large amount of scrap metal on a large shelf in between the machine shop wall test point, and the unit. Section 3.4: Longevity Test This test was performed to determine if the wireless communication still functions as expected over a longer period of time. This test was also performed to check if any timing errors are more prevalent or appear over a longer period of time. Shown below in Table 9 is the test data for the longevity test. The test was performed over a 4 hour period, with readings taken once every hour. The test data shows that over a 4 hour period, the speed displayed by the application does not change appreciably. This indicates there are no timing errors in the program that might make it fail over time. 33

34 Table 9: Longevity testing for wireless data transfer Desired Speed (RPM) Speed Displayed by App (RPM) Initial Speed 1 Hour 2 Hour 3 Hour 4 Hour Section 3.5: Temperature Testing The systems temperature sensor was tested against a calibrated temperature sensor to check its accuracy. The RFduino readout was observed and every half a degree the Type K thermocouple readout was recorded. The equation of the line is relatively close to y=x. The difference in the temperature readouts could be due to physical location of the thermocouple relative to the LM35CZ temperature sensor device on the sensor board. Also, the temperature sensing element of the LM35CZ is within the IC chip while the Type K thermocouple was within superglue on top of the LM35CZ. Another factor to consider would be the physical position of the two sensing elements relative to one another, although that is relatively small. Shown below in Figure 3.4 is a graph depicting how the readouts from the system s temperature sensor and a type k thermocouple temperature sensor compare. Shown below in Figure 3.5 is the temperature with a Type K thermocouple attached. 34

35 Figure 3.4: Temperature sensor readout vs Type K Thermocouple Figure 3.5: Temperature sensor with Type K thermocouple attached 35

36 Section 3.6: RFduino Voltage and Current Test Tests were done to ensure that the voltage and current into the RFduino chipset did not exceed the limits set by the manufacturer. These values were taken with two Fluke 179 true RMS multimeters that were last calibrated and are due for calibration on Thus, they are within calibration. The 5 volt line to the RFduino adapter board was severed and one multimeter was connected in series to measure the current draw of the board. The other was used to measure the voltages over the 5 volt line and the output of the adapter board power supply. This setup can be seen in Figure 3.6 below. Figure 3.6: Setup of RFduino voltage and current test The voltage and current were recorded for every speed of the motor, as shown in Table 10. The voltage to the RFduino and PIC were constant and below the maximum at all speed levels. The current to the RFduino does increase as the speed increases, but it does not exceed the maximum value set by the manufacturer. 36

37 Table 10: RFduino input voltage and current from rpm Speed PIC Voltage (V) RFduino Current (ma) RFduino Voltage (V) Unconnecte d Section 3.7: Power Analysis The motor with adapter board attached was submitted to dynamometer testing. It was interfaced with a Magtrol Hysteresis Dynamometer Model HD-500-6N last calibrated on and due on The dynamometer was controlled by a Magtrol Dynamometer Controller Model DSP last calibrated on the same date. The power analysis was performed using a Magtrol Single Phase Power Analyzer Model 6510e that was last calibrated on and due on Thus, all instruments are within calibration. For the first set of data, the speed was selected using the smartphone application, and then the torque load was adjusted until the motor broke speed. The maximum torque load that the motor could keep at speed was recorded along with the continuous input power and current and the continuous output power. The maximum torque value for the motor to be able to run all programmable speeds can be deduced as 5 oz. in. from the first set of data, which leads to the second set of data. In this second set of data, the torque load was kept at a constant 5 oz. in. The speeds were again selected, and the same values recorded. This data illustrates that with a constant torque load, the continuous input power decreases with rpm. This supports the power saving 37

38 claim that the self-programming motor that varies speed according to ambient temperature of the product enclosure will save energy. The efficiency values shown are the simple ratio of output powers to input powers. The third set of data is simply focusing on the continuous power consumed by the motor with a fan blade that equals a 5 oz. in. torque load at 1600 rpm. The fan on the motor for this test was an 8 inch diameter 5 petal blade. The speed was varied, and the current and continuous input powers were recorded. Due to the nature of a fan load, the power savings at lower speeds is greater than a constant torque load over all speeds. See Table 11 below for the test data. Table 11: Power analysis aata 38

39 Section V: Cost Analysis 39

40 Section 5.1: Preliminary Testing Parts/Equipment Table 12 seen below lists out the parts/equipment purchased for preliminary testing. Although the parts were not utilized in the final system developed, they were a necessary aspect of the complete design process. This is due to the fact that preliminary testing was required to ensure that the final design had the capability to achieve all the parameters set. The only equipment utilized in the final design was the Apple developer license in order to create the ios application. Table 12: Preliminary testing parts/equipment costs Description Mouser Part Number Quantity End Price Button shield 975-RFD $13.99 Battery shield 975-RFD $16.99 USB RFduino 975-RFD $42.65 CR2032 batteries 658-CR $2.93 Apple developer license N/A 1 $99 Section 5.2: Final System Parts/Equipment Table 13 seen below lists the equipment that was purchased and utilized in the final design of the working system. As is illustrated in Table 13, numerous parts did not have to be purchased by the team directly. The sponsoring company, EM&S, was kind enough to allow the team to utilize various components (specifically capacitors and resistors) that they already had in supply. 40

41 Table 13: Final design of system costs Part Part Number Supplier Cost for One Part 931 kω resistor 475 kω resistor 4.7uF 6.3V capacitor.1uf 50V capacitor 1uF 6.3V capacitor 1uF 250V Capacitor 3.3uH 2.15A 35mohm Inductor 1nF capacitor 2.2MΩ resistor Header P931KHCT-ND RMCF0603FT47 5KCT-ND ND ND ND ND ND BC1089CT-ND 2.2MGBCT-ND SAM ND Digi-Key Electronics Digi-Key Electronics Digi-Key Electronics Digi-Key Electronics Digi-Key Electronics Digi-Key Electronics Digi-Key Electronics Digi-Key Electronics Digi-Key Electronics Digi-Key Electronics 41 Cost for 500 $0.10 $3.12 ( each) $0.10 $2.88 ( each) $0.10 $11.90 (.0238 each $0.10 $6.35 (.0127 each) $0.23 $28.50 ( each) $1.43 $ ( each) $1.63 $ ( each) Cost to Us per Motor QNTY Used in Design QNTY Purchased for Development $0 1 0 $0 2 0 $ $0 2 0 $ $ $ $0.31 $26.18 ( each) $0 1 0 $0.53 $51.42 $0 1 0 ( each) $1.09 $ $0 1 0 ( each) $1.18 $370 (.74 $ each) $1.63 $388.5 $ (.777 each) $14.99 $12.79 $ V buck regulator MCP1603T- 330I/OSCT-ND Digi-Key Electronics 5V to 3.3V Digi-Key level ND Electronics translator RFduino 975-RFD22301 Mouser Electronics PCB N/A Advanced $2.062 N/A $

42 Section 5.3: Cost Analysis Circuits 5 5 The total cost was calculated to be $384.39, without the inclusion of shipping costs. The total additional cost per prototype motor is projected to be $24.83, not including in house surplus parts. The total additional cost per motor at 500 units is projected to be $19.36, including all parts as newly purchased. From Tables 12 and 13 above, it can be analyzed that the most expensive aspect of this system is the Apple developer license which costs $99 for one year. The most expensive aspect of the board for the final system is observed to be the RFduino chipset, although it is a relatively low cost, comparatively it is high. Thus, it is observed that the final system designed cost much less than the budget of $5,000 that was provided. Conclusions A wireless ECM system was designed that meets the specifications and limitations set forth by the problem statement. With this design, the RPM of the existing motor can be read and changed wirelessly using an Android and/or iphone application. For this system, the team selected an appropriate chipset, the RFduino, which is a low power chipset; thus, it does not interfere with normal motor operations. The RFduino has its own reprogrammable microcontroller and antenna. Thus, tests can be easily run and the lengthy process of designing and building an antenna can be avoided. The RFduino has excellent signal strength, as is evident by the testing of the RFduino communication range, which resulted in a distance much further than the required feet. The RFduino is also compatible with both Android and iphone platforms, which has been tested using simple example applications and had positive results with custom built applications as well. The output signals from the motor have also been tested and produce a square wave signal. The frequency of that square wave can be related to the speed of the motor. With this knowledge, the RFduino chipset can be interfaced with the existing motor control circuit so that the RFduino microcontroller can read the frequency of the square wave and then send the speed wirelessly to the Android or iphone application. Lastly, the cost of the project is $384.39, which is far below the project budget of $5,000 that was provided by Electric Motors and Specialties Inc. 42

43 Recommendations The system that was designed can be easily adapted to other CMOS motor control circuits. To adapt this system, all that is needed is a modification to the PCB layout of the circuit to better interface with different layouts and to reprogram the RFduino to send/receive the appropriate signals to the motor control. A wireless monitoring system could be coded to be an early warning system for motor malfunction. With this system in place, many motors could be controlled and monitored simultaneously for extensive testing and analysis. Additional lines on the RFduino chipset are available to send/receive signals to the motor, so additional information could be processed or sent wirelessly through the RFduino. 43

44 References - RFduino chipset resources RFduino DIP Datasheet RFDP8 RF Modules Datasheet Android resources Microcontroller resources - ios resources Parts and data sheet information