1. Telemetry System for RF cable interconnect monitoring sensors Design 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 Lightning arresters Connectors 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. 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-Wire tm protocol developed by Dallas Semiconductor was selected according to project requirements and assumptions

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

7. 1-Wire tm Protocol: Overview Protocol Waveforms

8. 1-Wire tm Components DS9490R DS2450DS2406 To a USB PC portTo 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 Active pull-up: - load-dependant current pulse - up to 30 mA - duration of pulse is SW controlled Pull-down slew rate control: - faster speed - steeper slew rate -various speed support: -Regular: 70 µs -Overdrive: 6-16 µs -Flexible: 66 - 80 µs

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 feedback Channel A can sink 50 mA Channel B can sink 8 mA With 1024 bits of EPROM CRC Concept Schematic PCB Layout

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

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

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 -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 Graph Pane -Displays the graph -Maintains queue of needed events: re-scaling graph, refreshing data, etc. Sensor Wrapper -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

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 This will make integration easy Saves some time for a last round of testing after final integration. Iterative! Using prototype HW to develop SW Using original demo SW and development SW to test the HW components Team-oriented, backed-up

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.