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:
- Decawave DWM1001 RF TXRX Module UWB/Bluetooth RTL
- BNO080 9DOF IMU
- Espressif ESP32 Microcontroller
- U-Blox ZOE-M8B GNSS Positioning Module
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
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.
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.
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.
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.
There are four stages to a TLV transaction:
- 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.
- Process Request: The DWM1001, no longer accepts any requests during processing and will reply with "0x00" upon receiving one.
- 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.
- 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.
Meaningful data was successfully acquired as shown below (From Bottom to Top: CS, MOSI, MISO, SCK):
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.
The whole response is shown below with a total transmission period of approximately 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.
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:
- GPS module connected through an SMA connector to an external GPS antenna. This antenna will be visible to the customer, and should be placed along the outside of the enclosure. Serial communication to this device will be handled through I2C.
- Inertial Measurement Unit (IMU) module. The module being used to track movement of the device on-board will be a BNO080. The measurement unit will be responsible for determining relative distance of the unit for the case where the node leaves network range. Serial communication to this device will be handled through I2C.
- Decawave Ultra-Wide-Band Electromagnetic wave propagation timing device. This will be the main unit used to determine distancing. UWB waves will be propagated from the device when acted on by the microcontroller. Serial communication to this device will be handled through SPI.
- FTDI USB to UART SoC. This system is implemented in order to include USB as a functional communication to directly communicate with the ESP32. This is mainly used for debugging purposes, and will not be a usable port for customers receiving a finished product.
- Battery will be lithium-polymer, running at around 2600mAh, which will be enough for max current draw rated for each device.
Bill of Material (BOM)
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.
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.