P19251: Local Positioning System
/public/

Preliminary Detailed Design

Table of Contents

Team Vision for Preliminary Detailed Design Phase

During this phase, we sought after trying to understand how we will try to make this project a reality. After choosing to use EM signals instead of ultrasound signals in System design review, we started digging into seeing how we choose components that will fulfil our requirements as well as work with the other components. The current component list is:

We split into two teams

Team A: Anmol, jai, Mena

Team A is comprised of a hardware/software capable member and 2 software capable members. They were chosen to head the proof of concept team as they were the most experienced and prepared to take the software and "prototype" to then next level. With Anmol's knowledge of the individual components as well as his software knowledge , combined with the programming and mathematical capabilities of Jai and Mena, this team should complete a system POC by the end of the semester

Team B: Dean,Mike

Team B is comprised of 2 Hardware design capable members who have experience designing, laying out, and populating PCBs. They are to work together to design and layout the PCB with Dean focusing on the circuit design and Mike focusing on the PCB layout. They should have a circuit design and board layout completed by the end of the semester

Calculations

Hand Calculations

public/Detailed Design Documents/TriangulationMath/triangulation explanation - Copy.jpg

public/Detailed Design Documents/TriangulationMath/triangulation explanation - Copy.jpg

public/Detailed Design Documents/TriangulationMath/triangulation part 1.jpg

public/Detailed Design Documents/TriangulationMath/triangulation part 1.jpg

public/Detailed Design Documents/TriangulationMath/triangulation Part 2 - Copy.jpg

public/Detailed Design Documents/TriangulationMath/triangulation Part 2 - Copy.jpg

Battery Calculations

In order to calculate the power draw from each node, the total power for each device in the node needs to be calculated. This is done through a series of additions of maximum power draws for each device. The following equation shows the total power draw in the system.

public/Detailed Design Documents/BatteryCalc1.png

public/Detailed Design Documents/BatteryCalc1.png

The power draw for each device implemented in the system is calculated through the max rated current draw found times the voltage used. In this case, every device in the system is using 3.3V. This measurement is determined by the individual device manufacturers, through the datasheet provided.

public/Detailed Design Documents/BatteryCalc2.png

public/Detailed Design Documents/BatteryCalc2.png

Feasibility Tests

Decawave DWM1001 Interface

Communicating with external devices is only possible through UART, SPI, or Bluetooth Low Energy (BLE). In our case, SPI will be used. The maximum operating clock frequency of the DWM1001 is 8MHz however it was found to produce a stable communication at around 1MHz. The device is powered by 5V with a maximum current draw of 500mA and logic level is 3.3V. Communication is done in the message form of Type-Length-Value (TLV). Below is the declaration of SPI TLV communication from an external device to the DWM1001 for dwm_gpio_cfg_output, this sets the requested pin as an output and whether it should output high or low.

dwm_gpio_cfg_output TLV request

dwm_gpio_cfg_output TLV request

To visualize the full transaction, the figure below shows how an external device would send a request, wait for a response and then receive the response.

TLV transaction

TLV transaction

There are four stages to a TLV transaction:

  1. Request: The host device sends a message in type-length-value format to the DWM1001, upon receiving the request, the DWM sends out an acknowledgement of "0xFF"s matching the request byte length.
  2. Process Request: The DWM1001, no longer accepts any requests during processing and will reply with "0x00" upon receiving one.
  3. Finish Processing: If it is done processing the request and receives any data from the host side, the DWM will send out a single byte that represents the response length.
  4. Respond: The DWM has prepared a response of x amounts of bytes where x is the value of the length byte it sent prior. The host side communicates with an amount of "dummy bytes" equal to x to receive the full response.

When applying the above logic to communicate with the device, the function dwm_cfg_get was used as it is a simple request, it obtains the configuration of the node which is stored in two bytes.

dwm_cfg_get example TLV transaction

dwm_cfg_get example TLV transaction

Meaningful data was successfully acquired as shown below (From Bottom to Top: CS, MOSI, MISO, SCK):

Stage 1 & 2

Stage 1 & 2

Stage 2

Stage 2

Stage 3 - SIZE(0x07)

Stage 3 - SIZE(0x07)

Stage 4 - Response(0xC0, 0x01, 0x00, 0x46, 0x02, 0x5A, 0x04)

Stage 4 - Response(0xC0, 0x01, 0x00, 0x46, 0x02, 0x5A, 0x04)

Note that the first byte is supposed to be "0x40" and not "0xC0", this is not an invalid response but a slight hiccup in the system as there was some slight jitter as can be seen below.

Data anomaly

Data anomaly

The whole response is shown below with a total transmission period of approximately 0.5ms.

Total transmission ~0.5ms

Total transmission ~0.5ms

IMU and OLED Test

To Test the BNO080 IMU, ran a program accessing data from the IMU at 50Hz. The beauty of the BNO080 sensor is it does onboard IMU filteration and sensor fusion. Many IMU's out there are able to only output raw IMU data. This becomes a problem where the data needed is not what is being collected. Processing the data is much harder and would need special filters (Kalman Filters and Complementary filters) to make sense of what data is available. For example, The Gyroscope in the IMU outputs radians/sec. To anyone who needs to collect angular information about the device, knowing angular velocity is useless and should be converted to angular displacement or absoulte orientation. This can't be done easily if not for the BNO080. Onboard is a controller that will calculate this as quickly as it can minimizing calculation error and noise in the data. Absolute positioning can be extracted form the device using simple libaries that read from particular registers.

In the example shown below, the IMU data was recorded at the full 50Hz. This infomation was stored internally and sent to the OLED diplay every 1 second. This was accomplished by using a timer interrupt which would update the display. Updating OLED displays is difficult as it can't be done quickly. Because of the different sample rates, by using interrupts, each event could be run at its own rate.

public/Detailed Design Documents/code.png

public/Detailed Design Documents/code.png

public/Detailed Design Documents/OLED1.jpg

public/Detailed Design Documents/OLED1.jpg

public/Detailed Design Documents/OLED2.jpg

public/Detailed Design Documents/OLED2.jpg

public/Detailed Design Documents/OLED3.jpg

public/Detailed Design Documents/OLED3.jpg

Drawings, Schematics, Flow Charts, Simulations

The high level circuit diagram is shown below. This is the high level implementation of our main processor, the ESP32 MCU, along with its associated peripherals. The ESP32 is responsible for handling communication to all of its peripherals through serial communication which will vary between I2C and SPI, depending on the device. The ESP32 will be run in low power mode for most of its operation, as the battery life capacity needs to be extended in order to achieve 8 hours run-time specification. The following peripherals include:

High Level Circuit Diagram

High Level Circuit Diagram

Bill of Material (BOM)

Bill of Materials

Bill of Materials

Design and Flowcharts

We came across this product design after we discussed the BOM and the preliminary circuit design. The final circuit would be rather small compared to the previous case concepts we developed. So instead of having a bunch of unnecessary space, we decided to make a smaller case, modeled after a GoPro Hero 3. It would be small enough to mount on emergency responders while robust enough to withstand shock from getting dropped.

Cad Model

Cad Model

For the thermal analysis, I used the law of conservation of energy and set it to steady state, so that the total energy generated and coming in would equal the energy leaving the system. For this process, since the node had to operate between 70 and -40 C, I split up the problem into a hot and a cold scenario. I first decided to make the enclosure out of Acrylic, which has a thermal conductivity of about 0.2 W/mK, which would make it a great insulator against the cold in the second scenario. I also decided to make the wall thickness about 5mm for the analysis, as that would still leave enough clearance to mount the circuit once its finished. While this analysis is only have finished, it determined that a readily available and cheap material such as acrylic would be feasible to protect against cold conditions while also allowing communication signals through without interference.

Thermal Calcs

Thermal Calcs

Plans for next phase


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