Telemetry System for RF cable interconnect monitoring sensors Design Review

1. Telemetry System for RF cable interconnect monitoring sensorsDesign Review Mike Iannacone & Dmitri Yudanov Senior Project II

2. The Agenda Overall Project Description - Purpose - Team - Requirements Hardware Section - Protocol of communication - Network Software Section -Needs -Software design -Reliability -Testing and development strategy Possible Problems

3. Project Description: The Purpose Connectors are exposed to weather, they become loose and rusty RF signal degrades over time Need to monitor looseness of connectors and humidity inside relative to outside ADIML lab at RIT does this research. Current stage: functional demo with RF signal off. Lightning arresters Connectors http://www.ee.rit.edu/research/adiml.html

4. Project Description: The Team Integrated team: - Mechanical Engineers - Electrical Engineers - Computer Engineers

5. Project Description: The Requirements 1-Wiretmprotocol developed by Dallas Semiconductor was selected according to project requirements and assumptions

6. 1-Wiretm Protocol: Overview 1-Wiretmis a bus: where each slave uses parasite power: • No need for power supply: master provides it • - Each device is addressable and can be accessed via binary search converting it to a voltage:

7. 1-Wiretm Protocol: Overview Protocol Waveforms

8. 1-Wiretm Components DS2450 DS2406 DS9490R To a USB PC port To sensors To LEDs • Two types of slave network nodes • One type of master

9. Network Topology: Dataflow • Minimum six branches with six slaves each • Scalable • - Could be mixed slaves on each branch

10. Network: The Master • Pull-down slew rate control: • faster speed - steeper slew rate • various speed support: • Regular: 70 µs • -Overdrive: 6-16 µs • -Flexible: 66 - 80 µs • Active pull-up: • load-dependant current pulse • up to 30 mA • - duration of pulse is SW controlled

11. Network: The ADC node 4 Channels with dual functionality: - analog ADC input - open-drain switch Low power: 0.5-0.6 mA during conversion Alarm control, local threshold Programmable input voltage range and ADC resolution CRC

12. Network: The LED node With 1024 bits of EPROM PCB Layout With feedback CRC Channel A can sink 50 mA Channel B can sink 8 mA Schematic Concept

13. Network: The Medium Andrew Heliax LDF5-50A For 1000 feet we have

14. Hardware: putting it all together LED Node Sensor Node USB Hub Master 1 Master 2

15. From hardware to software Master devices are organized in the box Software takes care about integration of OSI layers with in a single java application using 1-Wire API

16. UI Overview • UI needs to provide the user (a field technician) with information • on the current state, and past values of each sensor • - Goals: intuitive, simple, informative

17. API details Java API is very capable - Provides classes for each device type - Provides functionality specific to that device - poll, toggle switches, etc - Configuration of data rate and other settings - Detection of all devices and their IDs Limitations: - Still relatively low-level functionality - Does not include functionality specific to this project - Ex. Reads input as a voltage, not pressure -Same limitations any similar API would have - its just a framework for using the underlying device

18. Demo Application Provided Architecture was largely determined by the structure of the demo code – wanted to minimize un-needed modification All device interfacing was initially done with the One Wire API – we needed to add a wrapper with significant added features Program is organized into classes for left and right components – left portion selects device, right portion displays info This basically works for us.

19. Software Architecture - Structure based off of demo software (OneWire Viewer) - Needs significant modification: - GUI modifications – add/remove components, etc - Logging capability, ability to poll logs for past values - Wrappers for sensor class to add needed functionality - Site-specific information and tower configuration info - Ability to modify above info through UI - Unexpected or missing devices must be handled - Support for multiple one-wire busses in parallel - Many others. - Using this still saves time over writing from scratch

20. Device Panel Sensor Wrapper -Maintains list of objects present -Displays all objects and their status -Displays site-specific information, such as tower arrangement graphic -Listens for new devices, creates corresponding objects -Parses XML for settings, site info, etc -Polls regularly, queues for the graph to use -Updates the status in the Device Panel -Maintains log for each sensor -Converts voltage values into meaningful units -Controls LEDs -Displays the graph -Maintains queue of needed events: re-scaling graph, refreshing data, etc. Graph Pane

21. Reliability and Crash Recovery • Reliability is important • User may not be present to restart the application • Data from previous sessions must be kept! • Crash Recovery and Mitigation • Need to back up lists periodically while application is running • -Its better to lose some data points than all of them. • All logs, etc. done using Java’s serialization, so just write out a second copy periodically while in use. • When the program starts, it will find the most recent log and ignore all old ones • All settings and configuration use XML, and are written to disk after user makes any changes

22. Development Process: Testing, Prototyping, Integrating Team-oriented, backed-up Iterative! This will make integration easy Saves some time for a last round of testing after final integration. Using original demo SW and development SW to test the HW components Using prototype HW to develop SW

23. Anticipated Problems • Some functionality is going to be more difficult than other aspects • – ex. Tower site configuration tool may be difficult. • - Late completion of final sensor HW – if research group experiences delays in the analog sensor components, we are stuck. • - Using demo code – using someone else’s source code is always a risk.