P20251: Mesh Network Localization
/public/

Detailed Design

Table of Contents

Team Vision for Detailed Design Phase

We planned to lock down hardware requirements and begin finalizing PCB designs. We also intended to continue testing of subsystems including ultrasound and communications.

We were able to determine practically all hardware requirements and conceptualize the final PCB layout. We did not test as much as planned but our previous results demonstrate the effectiveness of our designs. We have also conceptualized the software and routing processes to be implemented in the network.

Radio Frequency Localization

Limitations of MUSIC

The multiple signal classification (MUSIC) algorithm, while very effective and accurate, was shown to be too restrictive on size requirements for our design. The accuracy of array and beamspace methods such as MUSIC depends almost entirely on the number of elements and their spacing (ideally one-half wavelength). At 2.4 GHz, with 10 elements and only one-quarter wavelength spacing, this would still require a length of approximately 30 cm. Our desired diameter for the device is 6 inches, about half of the requirement for MUSIC to work. Because of this, the idea was scrapped for triangulation using distance measurements from the DWM1001.

public/Detailed Design Documents/music_ideal.PNG public/Detailed Design Documents/music_bad.PNG

Distance Measurement and Triangulation

The DWM1001 is capable of measuring distances from "tags" to "anchors". Each device is specified as a tag or anchor in the firmware and any change in this state flashes the device requiring potentially hundreds of milliseconds. As such, the firmware will need to be edited for our purposes so that either tags can measure distances between themselves or anchors are able to move. The DWM1001 API, written in C, is available online with descriptions of the functions and examples of their use.

The DWM1001 should be positioned perpendicular to the azimuth plane for the best radiation pattern for our application. Placement parallel to the azimuth plane introduces two significant nulls in the radiation pattern which will limit accuracy and range.

public/Detailed Design Documents/dw1001_radiation_patterns.PNG

Time-Division Multiplexing

An efficient method of time synchronization between devices called "Stitch" for the purpose of time-division multiplexing is described in a paper from the University of Utah. Ultra wide-band transceivers like the DWM1001 are inefficient for time synchronization. The paper describes the use of a narrowband transceiver very similar to the CC2500 we are using in addition to a BeagleBone Black, much like our BeagleBone, for the purpose of synchronizing DW1000 modules. If this method of synchronization is to be implemented, the DW1000 would be more desirable than the DWM1001 because of the simplicity of adding an external local oscillator for Stitch. The local oscillator is labelled X1 in the DW1000 application circuit schematic below.

public/Detailed Design Documents/dw1000_circuit.PNG

[Detailed Design Documents/DDR_BillOfMaterials.pdf BOM File]

Ultrasonic Localization

The ultrasound subsystem is moving forward. Currently all schematic designs are complete based on the feasibility analysis completed in prior phases. Board layout has began but is blocked by other subsystem completion as well as time constraints.

Approximate BOM cost of the ultrasound subsystem is $12, less than 15% of complete BOM cost.

Schematics

Full Subsystem Schematic

public/Detailed Design Documents/Schematics/USSS.png

Filter and Amplification Section

public/Detailed Design Documents/Schematics/USFILT.png

Trigger Generation Section

public/Detailed Design Documents/Schematics/USTRIG.png

Data Radio Section public/Detailed Design Documents/schematic-cc2500.jpg

Communication

Prototyping, Engineering Analysis, Simulation

Each device will broadcast a heart beat every ~1 sec. Channel 0, address 0 will be the broadcast channel.

Devices in range will update their routing tables with RSSI information about the sender from that broadcast.

After sending the heartbeat, devices will send a second packet with a single sync byte. The sync byte will be used to determine the TDoA of the ultrasonic pulse.

Radios will operate by default in RX. When software sends a heartbeat, the radio will switch to TX mode temporarily. Before TX, firmware will check the CTS bit in the PKTSTATUS register, to verify that the air is clear. If the topology update packet has completed but the sync packet has not yet been received, the device will wait until it has received the sync packet from the other device before attempting its own heartbeat.

The heartbeat will consist of the device's simplified 1st order routing table, which is every device that that node as seen with an RSSI above a predetermined threshold.

The sync pulse will be used to time the ultrasonic pulse.

If a device is waiting for a sync packet, but receives another node's heartbeat, the device assumes it fell out of range and will ignore the previous heartbeat.

Software and Routing

Drawings, Schematics, Flow Charts, Simulations

Software Flowchart

public/Detailed Design Documents/P20251 Software Flowchart.png

The above flowchart represents the sequence flow of the system software. Both the core functions of network communication and localization are ongoing processes that are regularly repeated.

Drawings, Schematics, Flow Charts, Simulations

The full system schematic has been started, with the OSD3358 MCU integrated. PCB layout has been started, pending other subsystem completion.

public/Detailed Design Documents/Schematics/TLD.png

public/Detailed Design Documents/Schematics/BRD.png

public/Detailed Design Documents/Schematics/BRD2.png

Bill of Material (BOM)

public/Detailed Design Documents/DDR_BOM.png

Test Plans

public/Detailed Design Documents/dw1001_dev.PNG

The DWM1001 Development Board will allow for testing of the DWM1001 ranging and communications with the BeagleBone. The board is affordable and we are looking into obtaining free samples. Additionally, the firmware and communication methods are designed to be simple and easy to use so testing should move quickly.

Risk Assessment

public/Detailed Design Documents/risk_manag_final.png

Plans for next phase

Before the end of the semester we need to make significant progress on PCB layouts and finish ordering necessary components to begin testing immediately next semester. We need to complete an overview of the system as a team to begin piecing everything together. Each of the components of the project rely on each other and the process of integrating them should begin now.

We should also begin looking into user-centered designs from the GUI network link to the physical device design.

Projected Schedule for MSDII

public/Detailed Design Documents/MSD2_Sched1.png

public/Detailed Design Documents/MSD2_Sched2.png


All Embedded Documents: Detailed Design Documents

Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Customer Handoff & Final Project Documentation