Skip to content

Commit

Permalink
Updated Documentation
Browse files Browse the repository at this point in the history
- Updated Documentation
  • Loading branch information
asankaSovis committed Jan 15, 2024
1 parent 1486fef commit 0fffec9
Show file tree
Hide file tree
Showing 31 changed files with 459 additions and 53 deletions.
113 changes: 85 additions & 28 deletions Documentation/Bill_of_Material.md

Large diffs are not rendered by default.

13 changes: 13 additions & 0 deletions Documentation/Conclusion.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
# Conclusion
Project Prometheus v2.0 turned into such an exciting and inspiring pet project for me. It encouraged me to learn so many new things and to experiment with things that I never would've had access to before. On this submission day, I'm confident about what I managed to achieve with this project. Prometheus came so far; yet there's more to look forward to. I'm excited and looking forward to seeing where Project Prometheus will go in the future. After a small break, I will be back with its development.

> ![](./Figures/PCB_Design.png)
> View of the PCB design of Prometheus PCB

## Thanks
This four-month journey was a journey filled with a lot of ups and downs. I would not be able to achieve this level of improvement without the help of countless people. The biggest support came from the people at my former workplace who encouraged, advised, continuously asked about the progress and even offered technical guidance and help.
This goes without mentioning the awesome people who helped me whenever I posted dumb questions on the [Nordic DevZone](https://devzone.nordicsemi.com/) forum and Discord server. Thank you for tolerating my newbie questions and annoying mistakes.

Thanks to the people who had been posting content on Youtube and other platforms guiding people through Matter, the nRF platform, Zephyr and related fields. Without you, this project would not be able to flourish.
Finally to the awesome people at Nordic Semiconductors and Hackster.io for organizing such a valuable opportunity. I would never have been able to afford to own something like nRF7002 DK if not for this project. Thank you for allowing me to enter into this world of innovative technology.
Binary file added Documentation/Figures/ADC.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added Documentation/Figures/Communication_Protocol.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added Documentation/Figures/Cost_Breakdown.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added Documentation/Figures/Digital_IO.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added Documentation/Figures/Hardware_Giveaway_Email.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added Documentation/Figures/Level_Shifter.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added Documentation/Figures/Poster.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added Documentation/Figures/Power_Supply.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added Documentation/Figures/Prometheus_PCB.drawio.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added Documentation/Figures/Relay.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added Documentation/Figures/Schematic.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added Documentation/Figures/Software_SS1.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added Documentation/Figures/Software_SS2.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added Documentation/Figures/Software_SS3.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added Documentation/Figures/Software_Working.drawio.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added Documentation/Figures/nRF_7002_DK.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
78 changes: 78 additions & 0 deletions Documentation/Hardware_Specifications.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,78 @@
# Hardware Specification
The PCB of the Prometheus Fire Alarm System was designed and developed in-house. The PCB is a double layer PCB with sensors and indicators on the bottom and the rest of the components at the top. The PCB was manufactured and assembled by JLCPCB and the cost breakdown can be found in the [Bill of Material](./Bill_of_Material.md) section.
## Interface
> ![PCB layout on both sides](./Figures/Prometheus_PCB.drawio.png)
> PCB layout on both sides
The interface between the Prometheus PCB and the nRF7002 DK is the most important part of the whole hardware design. This is why every control signal from the board is sent from a single location throughout the board. All of these signal have probing locations attached for debugging purposes. The pins are situated in the following order from left to right.

1. GND - Common ground.
2. LS_EN - Enable the level shifter. Active high, this pin has to be pulled up for the whole PCB to start working.
3. M_DAT - Digital out of the MQ-135 sensor. This is not used as the reading is sent through the ADC.
4. M_CS - Chip Select for the ADC recording the MQ-135 readings.
5. M_CLK - Clock signal for the ADC recording the MQ-135 readings.
7. M_MISO - Master In Slave Out for the ADC recording the MQ-135 readings.
8. LED - LED control signal.
9. BUZZ - Buzzer control signal.
10. VALVE - Valve control signal.
11. D_DAT - Data out of the DHT-11 sensor.
12. MA_3V3 - 5V analog output of the MQ-135 sent through a voltage divider to translate to a 3.3V output. This is here for experimental purposes and not used.
13. RESET - Reset signal from the reset button.
14. 3V3_O - 3.3V output to power the nRF7002 DK.

## Signalling
The nRF 7002 DK operates with standard 3.3V, however, the logic on the board is designed to operate in the 5V. This is because almost all the components used are 5V components. Thus all the logic goes through the TXS0108EQ Level Shifter. This translates the 3.3V signal from the nRF end to 5V on the PCB end and vice versa. The TXS0108EQ has the following structure.

> ![The structure of the level shifter layout on the PCB](./Figures/Level_Shifter.png)
> The structure of the level shifter layout on the PCB
By enabling the chip by pulling the LS_EN up, we turn on the TXS0108EQ for communication with the PCB. Firmware details of this operation can be found in the [Software Specifications](./Software_Specifications.md) section.

## DHT-11 Reading
The DHT-11 uses UART to communicate with the controller. Therefore, the device only needs one data line to go to the microcontroller. As discussed, this line is simply routed through the level shifter to the nRF board.

## MQ-135 Reading
The MQ-135 is a bit more tricky. It has two signals coming out. One is the analog reading while the other is a digital one. Digital signal goes high when the analog signal reaches a certain threshold which can be set by the pot on the sensor itself. However, I wanted to get the analog reading to the nRF board and only use the digital pin as a backup.

Thus, the digital pin was simply routed through the level shifter and not used. This left me with the option of how to use the analog signal of the MQ-135. Using the ADC of the nRF means I have to step down the voltage to 3.3V which is not ideal for an analog signal. Therefore, I opted to use a voltage divider circuit just as another backup and sent this output directly to the nRF. However, if you check carefully, this is never used.

This is because I used a 5V ADC instead to take the reading of the MQ-135 and send it to the nRF as an SPI signal.

> ![The XD549 ADC used for the MQ-135 analog signal](./Figures/ADC.png)
> The XD549 ADC used for the MQ-135 analog signal
The XD549 is a 5V ADC and it sends the reading to the host controller as an SPI signal. For this we have three signal lines: CS, SDA (MISO) and CLK. Since the XD549 is a 5V device, these data lines have to be level shifted through the level shifter as well and since these are only carrying digital signals, there's no need to worry about shifting levels anymore. Firmware details of this operation can be found in the [Software Specifications](./Software_Specifications.md) section.

## Digital Output Devices
The PCB also features three digital IO devices. The buzzer and LED are quite straightforward and the circuit is simple. The signal from the nRF is passed through the level shifter to the IRLML6246 MOSFET and the MOSFET drives these two outputs.
> ![Indicator LED and Buzzer design](./Figures/Digital_IO.png)
> Indicator LED and Buzzer design
The valve operates in pretty much the same way but the MOSFET does not drive the valve directly. The valve is a high current device and thus needs a relay for its operation. For this reason, the MOSFET drives a relay and that relay is what drives the valve in turn. The valve is connected via a MOLEX connector to the board.
> ![Valve control design](./Figures/Relay.png)
>
> Valve control design
## Powering Up the System
The device needs to operate in three main voltage levels: 12V, 5V and 3.3V. The valve is controlled by a 12V signal, the nRF operates at 3.3V and the rest of the components operate at 5V. This means that 12V should come into the board as this is the highest required voltage level. In order to get the other two voltage levels, LM7805 and LMS1585 voltage regulators are used respectively for 5V and 3.3V.
> ![Power supply for the PCB](./Figures/Power_Supply.png)
>
> Power supply for the PCB
The 12V can be provided through a 12V power supply and the device operates well below 500mA of current which makes it possible to use any 12V power supply. A typical power supply in this range comes with a barrel jack so the PCB has a barrel jack power input.

## Resetting the Device
The reset button simply connects the 3.3V to the reset of the nRF board. This allows for resetting the device from the PCB itself.

## The nRF 7002 DK
All required signals from the interface connect directly to the nRF 7002 DK as shown below.
> ![nRF 7002 DK interface pins](./Figures/nRF_7002_DK.png)
> nRF 7002 DK interface pins *(Source: [developer.nordicsemi.com](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.2.0/nrf/_images/nrf7002dk.jpg))*
The built-in LED 01 is also used for debug messaging. The default SPI line 3 of the SoC is used for the ADC while the rest of the GPIO was selected for convenience. 3.3V and GND from the power supply is also provided to the board from their respective pins. Additionally, the reset pin is also used however, in debug mode, this cannot be used. Firmware details of the operation of the nRF 7002 DK can be found in the [Software Specifications](./Software_Specifications.md) section.

## Schematic
> ![The complete schematic view of the Prometheus PCB](./Figures/Schematic.png)
> The complete schematic view of the Prometheus PCB
The complete schematic of the PCB is given in the above diagram. This is available in the `Hardware/Prometheus v2.0` directory of the repository. The design was done using KiCad and all components used were available at JLCPCB at the time of manufacture. The complete Bill of Material and cost breakdown can be found in the [Bill of Material](./Bill_of_Material.md) section.
27 changes: 27 additions & 0 deletions Documentation/Introduction.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
# Introduction
> ![3D view of the enclosure design](../Enclosure//Assembly_View_07.png)
> 3D view of the enclosure design
**Prometheus Fire Alarm System** is a fire alarm system and an extinguishing system that allows real-time monitoring via software. It can perform smart extinguishing on-site while simultaneously providing connectivity to multiple devices via the control panel. Prometheus is designed to be as simple and resilient as possible while making it safe to use and operate within a household.

**Prometheus 2.0** is the next generation of [Prometheus Fire Alarm System](https://github.com/asankaSovis/prometheus-fire-alarm); the future of household safety and monitoring. Developed on the nRF7002 platform, it brings all the features of v1.0 to the nRF platform along with additional features made possible by the nRF platform.

> [![First demo of the Prometheus Fire Alarm System v2.0 in operation](https://user-images.githubusercontent.com/46389631/192273259-fb92e6f6-b95d-4e68-a962-5505359a668c.png)](https://youtu.be/ORGNmy9aDy0 "Prometheus Fire Alarm System - Demonstration")
> First demo of the Prometheus Fire Alarm System v2.0 in operation
## Project Overview
The project spanned from October 5, 2023, to January 14, 2024. Since, enrolling on the project, I have been tirelessly working on the development of the Prometheus Fire Alarm System. Since its inspection, it has been one of my pet projects that I did in my free time after completing it as a project for the university. It brought me a lot of knowledge, experience and fun. The Make it Matter contest had been a great opportunity for me to share my pet project with the world, and to integrate it with a well-renowned platform such as the nRF platform.
Juggling between academic work, full-time employment and personal life, I am proud of my achievements. However that I have come up with. However, I still feel like there's a long way for Prometheus to go.

> ![First look at the Prometheus PCB v2.0 after arriving from JLCPCB](./Figures/Designed_PCBs_After_Print.jpeg)
> First look at the Prometheus PCB v2.0 after arriving from JLCPCB
## The Journey and the Future
The journey started without any idea about Nordic, nRF or Matter. With limited access to resources and a limited budget, the project continued with days of researching online to discussing in online forums. However, with this limited budget and time, I am proud of what I've achieved. It had been a great opportunity to work with the nRF platform.

This will not be the end of my journey with Nordic or the nRF platform as I have planned to continue the devlog of the Prometheus Project. I also have tutorials planned on the issues I faced while working on this platform. One of the biggest hurdles I faced was the limited availability of resources online and outdated information. nRF and Matter are evolving rapidly but the internet has not yet been able to keep up with this growth and expansion. I'd like to pay my part and share my knowledge with others in hopes that they might not run into the same issues that I had to face.

In terms of Project Prometheus, there is a lot of work planned, even after the end of the **Make it Matter** contest. And I welcome everyone to continue the journey on [my Blog](https://asanka.hashnode.dev/).

> ![First look at the nRF7002 DK](./Figures/nRF_7002_DK_First_Time.jpeg)
> First look at the nRF7002 DK
19 changes: 15 additions & 4 deletions Documentation/Operational_Details.md
Original file line number Diff line number Diff line change
@@ -1,32 +1,43 @@
This section will introduce the basic operational details of the Prometheus Fire Alarm System v2.0. It will cover topics of [Operational Architecture](# Operational Architecture), [Features and Advantages of the System](# Features and Advantages of the System), [Technical Limitations](# Technical Limitations) and [Communication Architecture](# Communication Architecture).
# Operational Details
This section will introduce the basic operational details of the Prometheus Fire Alarm System v2.0. It will cover topics of [Operational Architecture](< # Operational Architecture >), [Features and Advantages of the System](< # Features and Advantages of the System >), [Technical Limitations](< # Technical Limitations >) and [Communication Architecture](< # Communication Architecture >).

For comprehensive introduction about the hardware architecture, refer to the Hardware Architecture section. Likewise, refer to the Software Architecture of a comprehensive introduction to the Software Architecture.

# Operational Architecture
This fire alarm system is designed to detect, indicate and extinguish fire by using necessary precautions. The system is expected to consist of three main stages.

1. Fire sensing and extinguishing system
2. Control stage
3. Alarming and notification stage

There are four main sections and components for the proper functioning of the system. It will help to complete that all the stages that mentioned above.

1. Fire sensors
2. Extinguishing valves
3. Control unit
4. Software system
5. Structural design
The system is designed to support as many of the Fire Alarm Modules as required according to the implemented environment. For example, if we are implementing in a school, each classroom can have individual modules. But accordingly, we will have to upgrade the control system used.

![[Design.drawio.png]]
The system is designed to support as many of the Fire Alarm Modules as required according to the implemented environment. For example, if we are implementing in a school, each classroom can have individual modules. But accordingly, we will have to upgrade the control system used.

> ![Operational Structure](./Figures/Design.drawio.png)
> Operational Structure
# Features and Advantages of the System
From a design standpoint, Prometheus Fire Alarm System v1.0 had a unique design philosophy that allowed it to be capable of evolving it into an IoT based fire alarm system. This is because a key importance was given to make it not just a monitoring and extinguishing device, but to go even further and become a user interactable and customizable system.
This is what was capitalized to integrate the Prometheus Fire Alarm System with the Matter protocol. For a comprehensive discussion on Matter and Prometheus Fire Alarm System, refer to [Limitations and Future](./Limitations_and_Future) section. Some features and advantages will be discussed below.

This is what was capitalized to integrate the Prometheus Fire Alarm System with the Matter protocol. For a comprehensive discussion on Matter and Prometheus Fire Alarm System, refer to [Project Management](./Project_Management.md) section. Some features and advantages will be discussed below.

- Real-time monitoring of the environment
- Real-time detection and reaction system
- Complete operation done within the system itself without offloading (Safer and more reliable operation)
- Real-time stats can be accessed via the control panel/matter home network
- Flexibility to integrate newer communication systems to increase functionality
- Fully open-sourced hardware and software architecture allowing transparency and learning opportunities

# Technical Limitations
Above advantages does come with some limitations. Everything was done by myself alone in my spare time juggling both work, studies and my personal life. With the limited time and budget available, I am proud of what I've achieved. However, it is important to acknowledge the limitations that currently exist in the developed system.

- Incomplete Matter integration
- No method to handle power loss
- No checks in place to indicate if water line goes dry
Expand Down
7 changes: 7 additions & 0 deletions Documentation/Preface.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
# Preface
One of the key requirements for a smart home is the safety and well-being of the inhabitants. This is why it's important to have devices to actively monitor and rectify any threats that occur within the house. One such threat is the hazard of fire. According to the WHO, more than 300,000 deaths occur every year due to fire-related hazards [1](https://scholar.google.com/scholar_lookup?journal=MMWR:+Morbidity+and+Mortality+Weekly+Report&title=Prevention.+Deaths+resulting+from+residential+fires+and+the+prevalence+of+smoke+alarms--United+States,+1991-1995&author=CfD+Control&volume=47&issue=38&publication_year=1998&pages=803-6&pmid=9776167&).

Thus we see the importance of incorporating a fire monitoring and extinguishing system into the modern smart home. This should actively monitor the environment for critical changes in the levels of humidity, temperature and carbon dioxide and take necessary precautions to rectify any fires that get detected. The residents should also get the convenience of actively monitoring the state of the alarm and extinguishing system whenever they require it. This is the premise of the Prometheus Fire Alarm System v2.0.

> ![Final assembly render](../Enclosure/Assembly_View_01.jpeg)
> Final assembly render
Loading

0 comments on commit 0fffec9

Please sign in to comment.