P19251: Local Positioning System
/public/

Detailed Design

Table of Contents

Team Vision for Detailed Design Phase

During this phase we worked on finalizing the design of the system with respect to the customer requirements. A simple board was designed to form a general idea of what we would expect to accomplish next semester. A functioning GUI was created to show the customer how they would interact with the system. The nodes distance retrieval was developed to show exactly how we would gather the node data. Enclosure design was progressed to show how the system will last.

Drawings, Schematics, Flow Charts, Simulations

The old node configuration consisted of One DWM1001 (UWB Distancing module) where the node can switch between tag mode and anchor mode. In anchor mode, the node would pulse UWB messages and essentially act as beacons. In tag mode, the node listens for the UWB pulses and calculates it's x, y, and z coordinate based off the distance from each anchor and their respective x, y, and z coordinate (each anchor must have a known and set x, y, and z). This means that with four nodes with only 1 DWM1001 module each, the nodes would have to switch between anchor mode and tag mode in order to each update their changing x, y, and z coordinates.

When testing the time it takes to switch a DWM1001 module from tag mode to anchor mode, it was found to take roughly 877ms which would greatly reduce the system bandwidth. Additionally, because the system contains 4 DWM1001 modules, the time it would take to update the whole system's x, y, and z coordinate would be roughly 4 times the switching time. This would only increase for a system with additional nodes.

To fix this, each node will be outfitted with 2 DWM1001 modules, one configured to anchor mode, and one configured to anchor mode. This means that for a system with four nodes, there would be 4 anchors continually pulsing out UWB messages, and 4 tags that can all request their x, y, and z coordinates at the same time. This eliminate the need to do any DWM1001 module switching. The time recorded to request position information was found to be around 5ms (which was tested on a breadboard where SPI communication is non-ideal, therefore the time could be reduced further on a printed PCB). This means that the system bandwidth is theoretically 200Hz which is a drastic improvement. The only cost to adding another DWM1001 module is board size, power, and node cost, however these modules are small, don't consume as much power as the microcontroller, and only cost $26. Therefore it makes sense to add a second DWM1001 module to each node.

public/Detailed Design Documents/nodeop.png

public/Detailed Design Documents/nodeop.png

Board Design

This is the first board design. The decawave sensors needs a configuration such that the antennas are either orthogonal or 180 degrees away from each other. There is a minimum distance between the decawave sensors and other high frequency components on the board. The antenna also requires a keep-out zone where no circuitry can be present. The configuration where the antennas are facing the opposite sides and pointing away from each other allow for maximum signal integrity and minimizes space wastage.

public/Detailed Design Documents/Layout.png

public/Detailed Design Documents/Layout.png

public/Detailed Design Documents/Schematic.png

public/Detailed Design Documents/Schematic.png

public/Detailed Design Documents/High Level Circuit DiagramFINAL .png

public/Detailed Design Documents/High Level Circuit DiagramFINAL .png

Prototyping, Engineering Analysis, Simulation

The peak power input was 2.4W. However, this power was only dissipated when transfering data. To account for the worst case, we assumed that the entire system constantly dissipated 2.4W of power, and that all power was converted into heat. This would assure that the enclosure we designed would withstand extreme condtions during operation.

The proposed enclosure would be modeled after a GoPro Hero 3, since it seemed to be small enough to mount and would still have enough space to hold all our circuitry. It would be a 62 x 44.6 x 32.7 mm box with a 5 mm wall thickness.

Proposed Enclosure

Proposed Enclosure

For the thermal simulation, we simplified the enclosure to a box, and placed the 2.4W heat generation on the back wall to test how hot the enclosure would get. Since the customer requirements stated that the system should operate between -40 and 70C, we performed 2 different simulations per material, one where the ambient air was -40C and another with an ambient air temperature was 70C.

Thermal Simulation where ambient air was -40C

Thermal Simulation where ambient air was -40C

Thermal Simulation where ambient air was 70C

Thermal Simulation where ambient air was 70C

Inside the enclosure with cover removed

Inside the enclosure with cover removed

As shown in the figure, the maximum temperature always occurs at the back wall, where the components are placed. So for a material to be considered feasible, the maximum temperature had to be within operating range for the components, which was around -40 to 85C. This simulation was performed for 10 different materials with varying thermal conductivities:

Max Temperature Results for Different Materials

Max Temperature Results for Different Materials

Thermoplastics seem to perform best here, and they are very cheap. The ABS plastic used in 3D printers is readily available, and extremely cheap. However, it may be a little too hot. Acrylic wouldn't interfere with data transmission, and performs better than ABS, but it is more costly, tho not by much ($3.70/sq. ft to $2.50/sq. ft)

GUI Design

The GUI was designed to work with the node system. The minimal and simplified views allow for anyone to be able to use the system. To connect to the node mesh, one needs to be able to input the node mesh's server IP address. This allows for direct communication to the server. Once the server is connected to, the node mesh can be viewed on the map.

public/Detailed Design Documents/electron.png

public/Detailed Design Documents/electron.png

public/Detailed Design Documents/electron2.png

public/Detailed Design Documents/electron2.png

Test Plans

Plans for next phase

Next phase we plan to continue to work on PCB schematics, work on getting towards a first board layout. We will continue to prototype nodes and fix the issue that arise on a first come first serve basis.

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