DANIEL_MANLA_IT_CAPSTONE_TASK2

docx

School

Western Governors University *

*We aren’t endorsed by this school

Course

C769

Subject

Electrical Engineering

Date

Apr 3, 2024

Type

docx

Pages

Uploaded by BailiffExplorationPony34

A FREE AND PUBLIC WAN FOR WILDERNESS COMMUNICATION 1 A Free WAN for Wilderness Monitoring and Communication Daniel J Manla Western Governors University

A Free WAN for Wilderness Monitoring and Communication 2 Table of Contents Proposal Overview ...................................................................................................................................... 3 Problem Summary ................................................................................................................................... 3 IT Solution ............................................................................................................................................... 4 Implementation Plan ................................................................................................................................ 7 Review of Other Work ................................................................................................................................ 9 Project Rationale ....................................................................................................................................... 13 Current Project Environment ..................................................................................................................... 14 Methodology ............................................................................................................................................. 17 Project Goals, Objectives, and Deliverables .............................................................................................. 20 Goals, Objectives, and Deliverables Table ............................................................................................ 20 Goals, Objectives, and Deliverables Descriptions ................................................................................. 21 Project Timeline with Milestones .............................................................................................................. 28 Outcome .................................................................................................................................................... 31 References ................................................................................................................................................. 32

A Free WAN for Wilderness Monitoring and Communication 3 Proposal Overview Problem Summary The National Park Service is a government organization charged with maintaining American national parks and preserving the health and safety of the people who visit American national parks. The National Forest Service is a government organization charged with the monitoring of Americas forests. Due to the rugged and remote nature of these parks, there is limited support for data collection and monitoring. The National Park Service and the National Forest Service would like to initiate a join effort to implement a general-purpose low-power wide area network within various national parks and forests to optimize search and rescue efforts, improve forest fire response times, and enable data collection for environmental research. The task of search and rescue, which is managed and paid for by the National Park Service, significant investment of money and manpower. In 2005, a total of 2430 Search-and- Rescue operations occurred at a cost of 5 million USD (Heggie 2009). This number amounts to near 8 million when adjusted for inflation. Of that cost, 49.8% can be attributed to the cost of personnel and 49.7% can be attributed to the cost of aircraft (Heggie 2009). Cost of search and rescue operations become less impressive when compared with the costs incurred by the National Forest Service for fire suppression. In 2017 the costs of wildland suppression exceeded $2 billion, making up 55 percent of the Forest Service’s budget (USDA Press Office, 2017). As the cost of fire suppression increases, funds allocated for insect control and controlled burns decreases, leading to more fires with greater reach (USDA Press Office, 2017). The byproduct of this unbalanced budget and a possibly growing threat of climate change is reflected in the total land loss caused by forest fires. In the year 2021, 23 million acres of land was lost to forest fires (Jacobo, 2021).

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 4 Both issues are exacerbated by an inability to perform granular research on the affected environments. If research is to be done in these rugged environments, then the primary network options are Cellular and Satellite. Cellular Networks have limited coverage in unpopulated rural locations such as forests and parks. The coverage that is available comes at a non-trivial monetary cost. Satellite coverage is near universal in coverage due to the usage of low-earth- orbit satellites, but the monetary cost associated with communicating with satellite networks is largely prohibitive to deploying clusters of scattered automated research equipment. A single Iridium transceiver often exceeds $200 in initial cost ( Iridium 9602N SBD Transceiver - Beam Communications , 2023), with monthly data costs exceeding $15 for the lowest tier of data usage (Ground Control, 2023). Cellular Network expenses, assuming the area being research has cellular coverage, fare better. Low Power cellular modems are generally 30$ - 40$ with a data cost of around 5$ per month per device. These costs could be considered insignificant when compared with the amount spent on fire suppression and search-and-rescue, but become prohibitive when considered for long term research performed by non-profits and university students. To remove the need for costly networks cellular and satellite networks, and to enable expansive and scalable wilderness monitoring for fire detection and search-and-rescue, there is a substantial need for a low-cost public network. IT Solution An LPWAN is a Low-Power Wide Area Network. This form of network is characterized by far-reaching connectivity with energy usage suitable for battery powered devices. LPWAN networks come in two forms: Low-Power Cellular (NB-IoT and LTE Cat M1) or Unlicensed Spectrum Long Range Radios (SigFox and LoRa). As previously discussed, cellular involves

A Free WAN for Wilderness Monitoring and Communication 5 significant initial costs operating expenses when deployed in large amounts. The remaining option is long range radios utilizing unlicensed spectrum, of which LoRa is the most suitable. LoRa transceivers are a fraction of the cost of Cellular Modems, typically less than 20$, and have no recurring costs. The reason there is no recurring cost associated with LoRa transceivers is that there is no internet uplink inherent in the technology. To provide LoRa transceivers with an internet uplink, which is required for our application, there will need to be an internet gateway. An internet gateway is a device that tends to be located near the physical and logical center of a network. This gateway will serve two functions: Managing communication with multiple remote LoRa devices and providing an internet uplink. The internet uplink may be provided by an iridium transceiver, or a cellular modem included within the gateway. For our application, a cellular modem will be selected due to low implementation costs and the high likelihood that these networks will be near locations with cellular coverage. To upload data through the uplink provided by the gateway, all LoRa devices must be within 5 miles of the gateway or within 5 miles of another LoRa device. By implementing the LoRa devices as a mesh network, each LoRa device will be able to use surrounding LoRa devices as if they were signal repeaters, with all data routing back to the uplink. The network topology described offers easy scalability with minimal supporting infrastructure. To serve the needs of the National Forest Service, each LoRa device within the network will need to include hardware to support early fire detection. Fire detection hardware should cameras, carbon dioxide sensors, and carbon monoxide sensors. A camera will provide periodic images that are analyzed internally to determine likelihood of fire. These images will not be transmitted over the network unless there is a high likelihood of fire. The carbon dioxide sensor

A Free WAN for Wilderness Monitoring and Communication 6 will allow the detection of significant increases in ambient carbon dioxide. The carbon monoxide sensor will serve the same purpose but for detecting carbon monoxide. These sensors will enable to device to detect flames that are beyond the site of the device camera. To serve the search and rescue needs of the national park service, each device will be equipped with a push button to request immediate assistance. Because the LoRa devices are in fixed locations, the search and rescue team will be able to locate the user based on the device that was pressed. To further aid search-and-rescue teams, people who frequent national parks and forests may acquire an emergency transponder device. The emergency transponder will be a custom device that contains a GPS and LoRa transmitter. If a user is in distress, they may activate their transponder which will then leverage the surrounding LoRa network to send location information to emergency services. By providing location data, the need for large search parties and aircraft will decrease significantly. To facilitate research and conservation efforts it is crucial that the network be made available to the public. For the network to be public, anybody with a LoRa transceiver should be able to send data. For example, if a team wanted to collect humidity and temperature metrics then they may purchase a LoRa transceiver and a Humidity Sensor and write code to transmit that data over the network at recurring intervals. To prevent the network from becoming over- burdened, their will need to be a registration service that provides a user with secure keys for enabling their device to communicate on the network. All devices will need to be registered with expected data usage. If an emergency occurs such as a forest fire or a distressed individual, then all research data transmissions will be deprioritized. In addition to allowing users to connect custom and registered devices to the network, the LoRa infrastructure devices will include their own sensors that can be viewed by any member of the public without any form of registration.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 7 Implementation Plan The project should begin with a discussion of objectives and scope from the stakeholders. The goal of this discussion should be to set expectations for what the network will initially be capable of and what timeframes are reasonable. Once expectations regarding network performance and device features are set, a minimum viable product must be created. This minimum viable product should consist of a scalable LoRa Device design and a scalable Internet Gateway device. These designs should consist of parts that are readily available and can be wired together to serve the purposes of the network. Note that the initial design only needs to be suitable for small scale demonstrative deployments consisting of less than 20 devices. It is possible that LoRa infrastructure devices already exist that service the needed purposes for a small-scale test deployment. These devices are likely to require some hardware modification to integrate sensors and a camera. Once suitable hardware has been sourced, open-source software will need to be found to service the functionality of the network. This software is likely to consist of a minimal Linux distribution with applications for managing internet uplinks and LoRa data transactions. Protocols such as LoRaWAN will need to be investigated for suitability. Interoperability with data encryption should also be considered. With hardware and software products sourced, it is now possible to considering how the network will be powered. To remove the need for additional wiring, a battery paired with a solar panel should be sourced. The power output of the solar panel and the size of the battery will need to be determined based on the power usage of the device hardware and the power-saving features offered by the software.

A Free WAN for Wilderness Monitoring and Communication 8 With all the above determined, it should now be possible to begin assembling and deploying devices. To determine where devices should be deployed, first the National Park Service and National Forest Service should be consulted to determine a suitable location for a demonstrative deployment of the network. Once a location is determined, geographic data will need to be collected such as elevations, natural barriers, and foliage density. This data will enable a network designer to place devices where they will provide the best possible coverage. Once the LoRa infrastructure devices are placed, a network uplink will need to be placed. A network uplink needs to be placed in a location that receives cellular coverage that is also central to the network so that LoRa infrastructure devices can access the uplink. Once devices for network devices is mapped, devices can be placed. While devices are being placed in the defined locations, a cloud service should be configured as a repository for all uploaded data. This data repository will allow engineers to view all data that is uploaded by the devices to determine device functionality and data throughput. Suitable cloud platforms include Microsoft Azure and Amazon AWS. With a cloud service provider in place and devices deployed the development team will be able to study network behaviors and determine device reliability. This initial installation will serve as a proof of concept and will be a reference for all additional network deployments.

A Free WAN for Wilderness Monitoring and Communication 9 Review of Other Work 1. “Forest fire detection system using wireless sensor networks…” (Dampage et al., 2022) The article titled “Forest fire detection system using wireless sensor networks and machine learning” discusses the implementation of a network of low-power devices to monitor forest environments, detect forest fires, and notify relevant parties. The proposed device for this network has significant parallels with the implementation proposed in the previous section “IT Solution”. Among those parallels is the usage of multiple environmental sensors. These sensors include the DHT22 for humidity and temperature, LDR for light intensity, and the MQ9 for Carbon monoxide detection (Dampage et al., 2022). The sensors used in my initial proposal include a Carbon Monoxide Sensor, Carbon Dioxide Sensor, and a Camera. The solution described in this article is likely more energy efficient by using an LDR (Light Dependent Resistor) for flame detection instead of a camera. While this solution is very simple and cost effective, it has potential shortcomings. The potential shortcoming is that the LDR can be easily deceived by a flashlight, a laser pointer, or a bolt of lightning. Also, the flame would need to be close to the device to cause a significant change in ambient brightness. The use of a camera has the benefit of being able to scan an image for things that look like flames rather than depending on changes in brightness. The solution proposed by Dampage et al. (2022) mitigates the potential for deception by non-flame light sources by using multiple sensors for flame detection. While it is easy for a flashlight to fool the LDR, it is less trivial to generate Carbon Dioxide and Carbon Monoxide in substantial enough quantities to simulate a forest fire. I believe that the effectiveness of an LDR instead of a camera should be considered and tested for viability.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 10 2. LORAWAN Network for fire monitoring in rural environments (Sendra et al., 2020) The article titled “LORAWAN Network for fire monitoring in rural environments” discusses the implementation of a network of LoRa nodes with temperature, humidity, wind speed, and carbon dioxide sensors for the monitoring of forest fires in rural environments. The proposed network of devices shares significant parallels with the solution proposed in the previous section “IT Solution”. The LoRa node is the primary device used for monitoring the rural environment. This node includes a low-power microcontroller, a LoRa transceiver, a Carbon Dioxide Sensor, Temperature and Relative Humidity Sensors, and a wind speed sensor. The intent of this collection of sensors is to accurately predict if a forest fire is occurring. A significant difference between this implementation and the implementation discussed by Dampage et al. (2022) is the lack of any light sensing capabilities. Sendra et al. (2020) does not describe why there is no light sensing capability, but it can be assumed that they felt there was no need. Another discrepancy is the way that data is processed. In the solution proposed by Sendra et al. (2020) the data is only compared with thresholds rather than passing through a machine learning algorithm. The use of static thresholds will decrease the cost and energy usage of the solution significantly but may be a prohibitive downgrade to overall performance. The network proposed by Sendra et al. (2020) also includes a gateway. The author mentions that they use a gateway offered by ThingsNetwork. The exact model is not stated but there is a reference to “The Things Indoor Gateway” which includes a LoRaWAN Gateway and WiFi capabilities. This device would not be suitable for rural applications. The Things Network also offers an Outdoor Gateway which includes a cellular uplink. This Outdoor Gateway is more suitable for our application.

A Free WAN for Wilderness Monitoring and Communication 11 3. “LoRaMoto: A communication system to provide safety…“(Centelles et al., 2021) The article titled “ LoRaMoto: A communication system to provide safety awareness among civilians after an earthquake ” discusses the implementation of a network of LoRa devices to assist emergency response services during earthquakes. The proposed network is called “LoRaMoto”. Much like the previously described networks, LoRaMoto depends on a cluster of distributed devices collecting local data from the environment. Also like previously discussed implementations is the usage of an internet gateway that is responsible for uploading data received from the surrounding LoRa devices. The LoRaMoto network depends on other LoRa devices to forward data, enabling the network to expand at a low cost without any infrastructure prone to damage by natural disasters. Each device is powered by an uninterruptible power supply that consists of a battery, charger, and the ability to be plugged into a wall. By including a battery, like the device proposed in our section “IT Solution”, the network removes external power loss as a point of failure. Another similarity is the proposal of user owned devices for communicating with the network. In our network, it was proposed that users be provided a LoRa transponder with a push-button for notifying the network that the user is in distress. The LoRaMoto networks depends on the users being equipped with a Wi-Fi enabled device such as a smartphone. The smartphone can use Wi-Fi to send messages to a LoRa node equipped with Wi-Fi support. Once a message is received over Wi-Fi, the message can then be forwarded through the LoRa network to emergency services.

A Free WAN for Wilderness Monitoring and Communication 12 This implementation supports the idea that LoRa networks are ideal for locations where infrastructure is either unavailable or likely to be a point of failure (such as in an earthquake or forest fire). 4. LORAWAN Mesh Networks: A Review and…” (Cotrim & Kleinschmidt, 2020) The article titled “ LORAWAN Mesh Networks: A Review and Classification of Multihop communication ” discusses the implementation of a LoRa network that utilizes multi-hop communication. Many of the protocols described are similar or identical to the ones that will be used with the proposal found in section “IT Solution”. Cotrim & Kleinschmidt (2020) describe a typical LoRaWAN network as a “star-of-stars” topology (Cotrim & Kleinschmidt, 2020). A star-of-stars topology is like what was described for our solution but in addition to internet gateways, there are also relay-gateways. A relay-gateway is a LoRa infrastructure device that serves to collect data from multiple nodes and forward that data to the internet gateway. The usage of relay-gateways is where the title “star-of-stars” comes from, since each relay is a single star, and the main internet gateway has a single connection to each of these stars. The benefit of this topology is that there is potential for lower cost devices since rather enabling each device to act as a relay or forwarding device, only one device needs to have this capability. If only one device needs advance LoRa capabilities, then the surrounding sensor devices can be simplified. A negative to this topology is the need for additional network configuration and complexity. Each relay-device is an additional piece of equipment that will need to be configured to receive data only from devices in its cluster (or star). For our network, I believe the usage of relays should be considered. The addition of relays will allow network segmentation and greater scalability. Network segmentation means that the network is organized into segments (or clusters, or stars) that are only able to communicate

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 13 internally. This shrinks the collision domain of the wireless network and improves security by limiting the ability for malicious communications to propagate through the network. Project Rationale The implementation of a highly reliable and public network for wilderness communication is interesting due to the substantial costs incurred by the National Forest Service and National Park Service for protecting our nations environment. These costs are incurred in the form of search-and-rescue efforts, fire suppression, and property destruction. This project can improve budget utilization for the listed organizations while also providing a public service in the form of a public network that is easily accessible and extensible. This project is also interesting due to its implications beyond the use cases described. An additional use case of the network described is secure and private communication. As of now the only way to wirelessly communicate in rural areas is using cellular networks. Even if a user communicating with a cellular network uses data encryption, their location and usage is still logged by the cellular service provider using Assisted-GPS and the modems IMEI. This raises security concerns because a cellular provider could distribute this data similarly to how many social media sites sell data. If somebody were to create a private network of LoRa devices for sending secure and private messages, then there would be no concern of for-profit data logging. Additionally, these devices could operate with perfect forward security which ensures that if the government were to subpoena the network for user data, all data would be obscure and useless. Owning the network infrastructure and implementing proper security measures is the only way to guarantee privacy and security for data transmission. The rationale for the implementation selected is the scalability offered by this type of network. A LoRa network with the correct network protocols can add up to 20 miles of reach by

A Free WAN for Wilderness Monitoring and Communication 14 adding a single LoRa node. This capital expenditure is dwarfed by the costs associated with alternative networks such as satellite and cellular. The very low cost to expand the network ensures that if the National Forest Service or National Park service wish to grow the network into new locations, this can be done at a low cost. The reason scalability is important for this project is because all the problems being solved are dependent on their being a lot of communication devices. In the case of early forest-fire detection, the only way to ensure that a forest fire is detected is by having a lot of nodes scattered across a wide geographic area. Additionally, the best way to ensure that a person in distress can locate a node or use an emergency transponder is by ensuring the network has six-sigma levels of coverage. This extreme amount of coverage can only be achieved with a large quantity of LoRa network devices. Current Project Environment The current environment relies primarily on personnel-based solutions for fire detection and search-and-rescue operations. For internet access the environment relies on cellular and satellite networks. For fire detection, a personnel-based solution is the usage of fire-watch towers. These towers have been in use for nearly a century with most towers still leveraging the same technologies that were available in the mid-1900’s (Luckhurst 2021). Among those technologies is the Osborne Fire Finder. The Osborne Fire finder served to determine the coordinates of a fire or smoke plume. The Osborne Fire Finder was fully analog, meaning no digital processors or sensors. Fire-watch towers are also equipped with a radio for communication with emergency personnel and binoculars for observing distant locations with enhanced detail. Watchtowers were typically placed at the highest elevation in the region of coverage. Each watchtower houses a fire-lookout professional who often lives in the tower between 10-hour shifts (Luckhurst 2021).

A Free WAN for Wilderness Monitoring and Communication 15 In locations where forest fires are more destructive, forest protection groups have turned to technology to improve the spotting of forest fires. The California Department of Forestry and Fire Protection has implemented cameras equipped with artificial intelligence to provide automated 24/7 coverage of the state’s forests. (Elam 2023). The cameras work by detecting the presence of smoke in the viewable landscape. Once smoke is viewed, the video stream can be closely monitored by California fire personnel for signs that the flame is spreading in a manner that is damaging to the environment. This solution has proven highly effective at early detection of fires and is currently being expanded through California’s highly fire prone forests (Elam 2023). Further research is being done to determine the viability of drone-based solutions. For search-and-rescue operations, the national park service uses a sequential process for locating missing persons. The search begins after a subject is reported missing (Phillips et al., 2014). Once a subject is reported as missing, search-and-rescue personnel are dispatched to complete the following tasks: investigation, containment, and search efforts (Phillips et al., 2014). For the investigation step, data is manually collected about the user from friends, family, and various digital records. From these data points, search management intends to determine the point last seen (PLS), last known point (LKP), and the initial planning point (IPP). These points are used as references to determine where the search should begin. The next step is containment. Containment involves dispatching personnel to “strategic locations such as trailheads, roads, trail junctions, or lookout points serve to limit the subject’s movement” (Phillips et al., 2014). These locations are generally near the border of the intended search area. Cell phone records and financial records are continuously monitored to ensure the subject remains within the search area. The final step is the search and is the most personnel intensive step. During the search step personnel are deployed within the search area in teams. Each team handles a segment of the search area. This is generally when the subject is found. Most searches are resolved within the first 24 hours (Phillips et al., 2014). If the search is unsuccessful within a 24-hour period, then the search may be

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 16 escalated to include aircraft. These aircraft may be owned by the National Park Service or contracted from a 3 rd party. For internet access in rugged environments, there is not a publicly available and extensive network infrastructure to support long range communication. There are three options available for those who wish to perform data collection or communication in rugged environments: Cellular, Satellite, and Shortwave Radio. Cellular coverage depends on cell tower placement and geography. Due to the low concentrations of people in rural environments, these environments often lack robust cellular coverage. In areas that do have coverage, the modems most often used for data collection are NB-IOT and LTE-CAT M1. NB-IOT and LTE CAT-M1 are optimized WAN radio technologies for low power applications. These low power cellular technologies are ideal places with scattered cellular coverage but are not an option for areas that have no cellular coverage. For areas where no cellular coverage is available, satellite communication is the primary method of digital data transfer. This data transfer comes at a high initial cost and monthly cost. The data transferred may be sensor data for performing research, or voice data for performing emergency communications. A lower-tech and more affordable option for emergency communications is short-wave radio, which requires a license to operate. Short-wave radio has theoretically complete coverage of the planet earth. The reason for this is the ability for short-wave radio transmissions to ricochet off the ionosphere, also known as “skywave propagation” (Berry, 2022). Short- wave radio is primarily for voice communications and is already used by emergency personnel. Short- wave radio can be used for digital data transmission but requires a license for access. There is a publicly available system for transmitting automated data packets over short-wave radio known as APRS. The APRS uses packet radio technology to transmit formatted data at a constant rate of 1200 baud (Martens 2018). These packets are considered connectionless, like UDP, meaning there is no guarantee of successful delivery. APRS is public and accessible to anybody with the proper licensing and access to a radio transceiver.

A Free WAN for Wilderness Monitoring and Communication 17 Methodology The methodology that best fits this project is the Waterfall methodology. The waterfall methodology is made up of five phases: Requirements, Design, Implementation, Verification, and Maintenance (Hoory, 2022). This method is best used for instances where there is clearly defined project outcomes and a sequential implementation plan. This project has predefined outcomes and an implementation plan that is well defined. The requirements phase consists of the development team meeting with project stakeholders to determine what the big-picture requirements are for the project. This step has already been partially completed by receiving requirements from the National Park Service and the National Forest Service. The big-picture requirements for this project is that the network should act as an early warning system for fires, provide an emergency communications system for search-and-rescue, and enable improved research by acting as a publicly accessible network. Prior to completing the requirements phase there should be some broad quantitative metrics also. These quantitative metrics may be the length of time it should take for the network to respond to a controlled fire that is 5 square feet. Additionally, the stakeholders may want six-sigma (99.9999%) wireless network coverage of the initial test deployment. The design phase is when a solution is outlined and documented to serve as a solution to the previously defined requirements. For this project, the design phase will consist of a discussion of the currently available wireless solutions that require minimal amounts of power while enabling long-range communication. The communication distance should be far enough so that devices can be spaced miles apart. By minimizing the number of devices needed for coverage the project can minimize the implementation cost and the operational costs. The

A Free WAN for Wilderness Monitoring and Communication 18 wireless solution selected should also have devices readily available from third parties. In this project, LoRa has been selected as the primary wireless technology. There are plenty of third parties producing LoRa equipment which removes the need to complete a new hardware design prior to having hardware for software testing. Hardware sensors will also need to be sourced to serve the fire detection requirement. These sensors will need to have a visual component such as infrared or camera, and a non-visual component like a carbon dioxide or carbon monoxide sensors. The data from theses sensors will need to be combined to make inferences regarding whether a fire is occurring. Software should also be defined for enabling data transmission and reading from fire detection sensors. The software selected should be open-source and actively maintained. By selecting open-source software, it is possible to adjust the software to better meet the needs of the project. This phase would also be the time to determine which location will be used for the initial deployment of the network. After a location is determined, a network map should be created that defines where LoRa nodes need to be placed to support coverage and fire detection requirements. The implementation phase is when the design is developed into a useable product. For this project, the implementation phase will consist of purchasing the necessary networking equipment, assembling LoRa devices that act as the network infrastructure, sourcing software to run on these devices and making any necessary modifications, and then deploying the network in a test location defined by either the Nation Park Service or the National Forest service. This step should involve basic tests such as sending data through the network, triggering the fire detection sensors, or sending a search-and-rescue message with location data to emergency services. These tests are primarily to ensure that all required functionality is available. This does not yet validate the functionality is able to meet quantitative metrics.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 19 The verification phase is when the implementation created in the previous phase is thoroughly tested to ensure all defined quantitative metrics are met. Verification forest-fire detection would include creating a controlled fire within range of the network and measuring the time it takes for a notification to be sent to emergency services. Verification for search-and- rescue functionality will involve a person entering the wilderness within range of the network and attempting to trigger a search-and-rescue message. This should be doable either by interacting with a push button on one of the LoRa nodes or by using a LoRa emergency transponder. The message sent should include accurate GPS data to enable near immediate finding of the subject. The network should also be tested with LoRa enabled sensors that send data at recurring intervals. This test would need to occur in parallel with one of the above emergency transmissions. The goal should be that emergency transmissions are always prioritized over non-emergency transmissions. This ensures that once the network is available to the public, user devices will be unable to interfere with emergency notifications and requests. The maintenance phase is when the system is constantly monitored for issues and anomalies. This is also the phase when a long-term support contract may be created to ensure that the developers of the project are able to provide support through patches and improvements. In this project, this phase would begin with a discussion between internal and external stakeholders to determine what level of support is needed for the project to maintain viability and meet and requirements. This would likely be in the form of a ticketing system so that users can submit bugs and request information. There would also need to be a platform for users to request access to the network for research purposes. This may all be done through the same platform. The project may transition to an Agile SCRUM methodology at this time to ensure sustainable

A Free WAN for Wilderness Monitoring and Communication 20 long-term maintenance of the project. Agile SCRUM is better suited for variable changes made without a fixed timeline. Project Goals, Objectives, and Deliverables Goals, Objectives, and Deliverables Table Goal Supporting objectives Deliverables enabling the project objectives 1 Design the LoRa Nodes 1.a. Define a hardware platform 1.a. i. Hardware Flow Chart 1.a. ii. Hardware Specifications Document 1.a. iii Hardware Parts List 1.b. Define a software platform 1.b. i. Software Component Flow Chart 1.b. ii. Software Specifications Document 1 b. iii. Software Component List 1.c. Define an assembly plan 1.c. i. Bill of Materials 1.c. ii. Assembly Procedure 1.c. iii. Software loading procedure 2 Enable LoRa Nodes to perform early forest-fire detection 2.a. Define Fire Detection Method 2.a. i. Fire Detection Flow Chart 2.a. ii. Fire Detection Part Specifications 2.a. iii Fire Detection Component List 2.b. Integrate Fire Detection Hardware Implementation 2.b. i. Fire Detection Bill of Materials 2.b. ii. Fire Detection Assembly Instructions 2.c. Define Fire Detection Software Implementation 2.c.i. Fire Detection Software Component List 2.c. ii. Fire Detection Software Integration Instructions 3 Enable LoRa Nodes to perform search-and- rescue assistance 3.a. Define Search-and-Rescue Assistance Method 3.a. i. Search-And-Rescue Flow Chart 3.a. ii. Search-And-Rescue Specifications 3.a. iii Seach-And-Rescue Component List 3.b. Integrate Search-and-Rescue Hardware Implementation 3.b. i. Search-And-Rescue Bill of Materials 3.b. ii. Search-And-Rescue Assembly Instructions 3.c. Define Search-and-Rescue Software Implementation 3.c. i. Search-And-Rescue Software Component List 3.c. ii. Search-And-Rescue Software Integration Instructions 4 Enable LoRa Nodes to act as a public WAN 4.a. Define Public Access Rules 4.a. i. Acceptable Use Policy 4.a. ii. Public Access Instructions 4.b. Define Software Implementation 4.b. i. Software Flow Chart 4.b. ii. Software Specifications 4.b. ii. Software Integration Instructions

A Free WAN for Wilderness Monitoring and Communication 21 5 Deploy the LoRa Node Network in a National Park 5.a. Build a network diagram 5.a. i. Elevation Map of the Location 5.a ii. Network Infrastructure Placement with Heatmap 5.b. Install the network 5.b i. Installation Map 5.b ii. Network Coverage Statistics Goals, Objectives, and Deliverables Descriptions 1. Design the Lora Nodes The first goal is to “ Design the Lora Nodes”. This is the first goal because it will form the basis for the remaining goals in the project. This goal is creating the infrastructure that will support the remaining goals. To create a LoRa Node, three things must be defined. These three things are the supporting objectives for this goal. The first supporting objective is the definition of the hardware platform. This step involves first creating a flow-chart to outline what hardware and interconnections are necessary to fulfill project requirements. Once a flow chart is generated, the specifications must be defined. The specification document will include the intended range of the LoRa Transceiver, Power Usage Maximums, Software Compatibility, ease of purchase, and availability of hardware support in the form of forums and documentation. Once specifications are determined, a list of hardware that meets those specifications must be created. This list should include a list of parts and sources of those parts. Each part on the list should also include a list of that parts specifications. The specifications within the list will be used for validation against the specifications list previously generated. These deliverables enable the purchasing of hardware that will be easy to purchase, possible to assemble, and guaranteed to be capable of meeting product requirements. Once hardware is selected, it is possible to complete the next objective: Define a software platform. The software is what will run on the previously defined hardware and will enable the hardware to perform functionalities required by the project. The first step is to create a flow-chart to outline what

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 22 software and integrations are necessary to fulfill project requirements. Once a flow chart is generated, the software specifications must be defined. The specification document will include a list of necessary features, operating system compatibility, software interoperability, software licensing, and availability of software support in the form of forums and documentation. Once specifications are determined, a list of software that meets those specifications must be created. This list should include a list of software components, repositories where the code is viewable, and a place to download compiled binaries. Each software component on the list should also include a list of that software’s features and specifications. The specifications within the list will be used for validation against the specifications list previously generated. These deliverables enable access to software that will be easy to acquire, possible to modify, and guaranteed to be capable of meeting product requirements. Once hardware and software are defined, the next objective is to create an assembly plan. The assembly plan is the procedure that will be used to create the LoRa nodes needed to support the network. An efficient assembly plan is crucial to ensure that the required number of nodes can be created in a reasonable amount of time. The first step is to create an accurate and concise bill of materials. The bill of materials will be used to purchase the parts need to build the hardware platform. The bill of materials should include a primary purchasing source as well as a secondary purchasing source. In addition to purchasing sources, unit cost and quantities should be listed. The quantity should correspond with the amount needed to assemble a single LoRa node. Once a bill of materials is generated, assembly instructions can be created. These instructions must reference parts from the bill of materials. Each step should be clear and concise. Each step should be either a single action or multiple iterations of the same action. It is crucial that these instructions be easy to follow to ensure it can be distributed to those in charge of assembly with little risk of confusion or incorrect assembly. The assembly plan will provide a method for attaching the hardware but will not include details on loading the software. To

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 23 accomplish software loading, a software loading procedure must be created. This procedure will provide step-by-step instructions for loading software onto the device. The steps may be as simple as inserting an SD Card with all the software on it, powering on the device, and validating that all components are present. Clear and concise instructions for software loading are crucial to ensure that all software is loaded to the device correctly and consistently. All these deliverables assist in ensuring that these devices can be built in large enough quantities for a network. 2. Enable LoRa Nodes to perform early forest-fire detection. The second goal is to enable the LoRa nodes to perform early forest-fire detection. This is the second goal because it depends on the existence of the deliverables from the first goal. This goal is creating the design of the fire detection subsystem. To enable fire detection, three things must be defined. These three things are the supporting objectives for this goal. The first supporting objective is the definition of the fire-detection method. This step involves first creating a flow-chart to outline what types of sensors and data interconnections are necessary to fulfill fire-detection requirements. Once a flow chart is generated, the sensor specifications must be defined. The specification document will include the minimum detection range, types of sensors needed, sensitivity of each respective sensor, interfaces supported by the defined hardware platform, and availability of support in the form of forums and documentation for the sensors selected. Once specifications are determined, a list of fire-detection sensors that meets those specifications must be created. This list should include a list of parts and sources of those parts. Each part on the list should also include a list of that parts specifications. The specifications within the list will be used for validation against the specifications list previously generated. These deliverables enable the purchasing of sensors that meet product requirements and can be easily integrated with the already established hardware platform using available interfaces. Once fire detection sensors are selected, the next objective is to create an integration plan to integrate the fire detection method with the already established hardware platform. The first step is to create an accurate and concise bill of materials. The bill of materials will be used to

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 24 purchase the sensors needed to accomplish the fire-detection requirements. The bill of materials should include a primary purchasing source as well as a secondary purchasing source. In addition to purchasing sources, unit cost and quantities should be listed. The quantity should correspond with the amount needed to add fire-detection to a single LoRa node. Once a bill of materials is generated, assembly instructions can be created. These instructions must reference parts from the bill of materials. Each step should be clear and concise. Each step should be either a single action or multiple iterations of the same action. It is crucial that these instructions be easy to follow to ensure it can be distributed to those in charge of assembly with little risk of confusion or incorrect assembly. The assembly plan will be an updated version of the LoRa node assembly plan with instructions for adding the fire detection hardware. Once hardware is selected and a plan is generated for integrating that hardware, it is possible to complete the next objective: Define Fire Detection Software Implementation. The software is what will run on the previously defined hardware and leverage the newly added fire-detection sensors to perform fire-detection functionalities required by the project. The first step is to modify the initial software flowchart with new integrations for interfacing with the fire detection sensors. This updated flow-chart will be the basis for generating software specifications. The new software component specifications must be defined. The specification document will include a list of necessary features, operating system compatibility, software interoperability, software licensing, and availability of software support in the form of forums and documentation. Once specifications are determined, a list of software that meets those specifications must be created. This list should include a list of software components, repositories where the code is viewable, and a place to download compiled binaries. Each software component on the list should also include a list of that software’s features and specifications. The specifications within the list will be used for validation against the specifications list previously generated. These deliverables enable the integration of the new fire-detection functionality with the already defined software platform.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 25 3. Enable LoRa Nodes to perform search-and-rescue assistance. The third goal is to enable the LoRa nodes to perform search-and-rescue assistance. This is the third goal but there is no necessity to complete this goal after the second goal. These goals are interchangeable as they are not codependent, but they are both dependent on goal 1. To enable search- and-rescue assistance, three things must be defined. These three things are the supporting objectives for this goal. The first supporting objective is the definition of the search-and-rescue assistance method. This step involves first creating a flow-chart to outline what types of actuators and data interconnections are necessary to fulfill search-and-rescue assistance requirements. Once a flow chart is generated, the hardware specifications must be defined. The specification document will include the type of push-button, whether a backlight is needed, connector type, the interface method used by the push-button, GPS requirements, and availability of support in the form of forums and documentation for the needed parts. Once specifications are determined, a list of search-and-rescue assistance parts that meets those specifications must be created. This list should include a list of parts and sources of those parts. Each part on the list should also include a list of that parts specifications. The specifications within the list will be used for validation against the specifications list previously generated. These deliverables enable the purchasing of parts that meet search-and-rescue requirements and can be easily integrated with the already established hardware platform using available interfaces. Once search-and-rescue hardware is selected, the next objective is to create an integration plan to integrate the search-and-rescue hardware with the already established hardware platform. The first step is to create an accurate and concise bill of materials. The bill of materials will be used to purchase the parts needed to accomplish the search-and-rescue requirements. The bill of materials should include a primary purchasing source as well as a secondary purchasing source. In addition to purchasing sources, unit cost and quantities should be listed. The quantity should correspond with the amount needed to add search-and-rescue functionality to a single LoRa node. Once a bill of materials is generated, assembly instructions can be created. These

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 26 instructions must reference parts from the bill of materials. Each step should be clear and concise. Each step should be either a single action or multiple iterations of the same action. It is crucial that these instructions be easy to follow to ensure it can be distributed to those in charge of assembly with little risk of confusion or incorrect assembly. The assembly plan will be an updated version of the LoRa node assembly plan with instructions for adding the search-and- rescue hardware. Once hardware is selected and a plan is generated for integrating that hardware, it is possible to complete the next objective: Define the Search-and-Rescue Software Implementation. The software is what will run on the previously defined hardware and leverage the newly added hardware to search-and- rescue functionalities required by the project. The first step is to modify the initial software flowchart with new integrations for interfacing with the search-and-rescue hardware. This updated flow-chart will be the basis for generating software specifications. The new software component specifications must be defined. The specification document will include a list of necessary features, operating system compatibility, software interoperability, software licensing, and availability of software support in the form of forums and documentation. Once specifications are determined, a list of software that meets those specifications must be created. This list should include a list of software components, repositories where the code is viewable, and a place to download compiled binaries. Each software component on the list should also include a list of that software’s features and specifications. The specifications within the list will be used for validation against the specifications list previously generated. These deliverables enable the integration of the new search-rescue functionality with the already defined software platform.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 27 4. Enable LoRa Nodes to act as a public WAN. The fourth goal is to enable the LoRa nodes to act as access points to a public WAN supported by the LoRa nodes. This is the fourth goal and is dependent on all previous goals. To enable the LoRa nodes to act as a public WAN, two things must be defined. These two things are the supporting objectives for this goal. The first supporting objective is to define the rules for access and usage of this network. The base document for supporting public access is the acceptable use policy. This policy should state that this network should not be used for any illegal activities, or any commercial activities. The acceptable use policy should also discreetly state that denial-of-service through excessive network usage is strictly prohibited. The network must be used only for research and monitoring purposes of our nation’s forests and national parks. The second document required to define access rules is a set of instructions for how users can gain access. This document should detail the registration process, how users can identify the sensors they place on the network, and how much data usage is acceptable per user. It may require that user devices connected to the network implement certain security measures such as a TPM 2.0 or a Security and Encryption Coprocessor. These hardware requirements will ensure that devices on the network have security measures in place to prevent malicious parties from modifying the device to perform malicious activities. Once rules and instructions for usage are defined, it is possible to complete the next objective: Define the Public Network Software Implementation. The software is what will run on the previously defined hardware and leverage the LoRa transceivers to provide uses free access to all nodes on the network. The first step is to modify the initial software flowchart with new integrations for interfacing with message prioritization software and generic user-device access. This updated flow-chart will be the basis for generating software specifications. The new software component specifications must be defined. The specification document will include a list of necessary features, operating system compatibility, software interoperability, software licensing, and availability of software support in the form of forums and documentation. Once specifications are determined, a list of software components that meets those

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 28 specifications must be created. This list should include a list of software components, repositories where the code is viewable, and a place to download compiled binaries. Each software component on the list should also include a list of that software’s features and specifications. The specifications within the list will be used for validation against the specifications list previously generated. This component list will also include methods of integration for the new software components. These deliverables enable the integration of the public network functionality with the already defined software platform. 5. Deploy the LoRa Node Network in a National Park The fifth goal is to deploy the LoRa nodes in a national park to serve as an initial deployment of the network. This is dependent on all previous goals. To build this network, there are two supporting objectives. The first object is to complete a comprehensive network diagram. To create a comprehensive network diagram, three things must be generated. This first document should formalize the selection of an initial location for the network. This must be generated first because it is a dependency of the next deliverables. Once a location is selection, an elevation map of the location must be acquired. This elevation map will indicate ideal locations for network infrastructure placement. Generally, higher altitudes will decrease the number of network obstructions and improve the line-of-site to the device. Once an elevation map is acquired, a map of ideal network infrastructure placement can be generated. This map should list where devices will be placed. In addition to device placement, there should be a coverage heat-map indicating where coverage is expected. A heatmap will also indicate locations where coverage may not be as good. The network infrastructure placement document will aid in the completion of the next goal. The second goal is the installation of the network. The network infrastructure must be installed according to the ideal network infrastructure placement document generated for the previous goal. An installation map should be generated to indicate exact locations where devices will be placed, how the devices will be mounted, and a sign-off for indication when that piece of infrastructure was successfully

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 29 installed. This installation map will act as an assurance that devices have been deployed in the correct locations. Once the installation map is created and devices have been installed with the proper signoff’s, network coverage statistics must be generated. These statistics will be based on actual coverage rather than the theoretical or planned coverage offered by the network heatmap. This should be similar visually to the installation map but instead of location signoffs, there will be a series of points placed on the map where coverage must be tested. Coverage should include data for fire-detection, search-and-rescue, and general data transmission. Each location will have signoff with a signature and date to indicate that coverage in this location has been validated by going to the location and attempting to transmit data. Search and rescue testing will use the same points as general data testing but with an added statistics for time it took for emergency services to receive the notification. Fire-detection coverage validation will require the addition of fire placement locations on the map. These must be locations where a controlled burn can be accomplished with a high degree of safety. For fire-detection coverage validation, these controlled burn locations will be used and statistics will be provided indicating how long it took a controlled burn in each location to trigger the fire detection notifications. This process ensures that the actual coverage of the network aligns with product requirements. These goals will provide assurance and validation of this network by providing a real implementation of the network with data and statistics to support its viability.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 30 Project Timeline with Milestones Milestone or deliverable Duration (hours or days) Projected start date Anticipated end date Business Requirements Document 5 Days 01/01/2024 01/05/2024 Define the wireless technology to be used 1 Day 01/08/2024 01/08/2024 List of network devices to purchase 4 Days 01/09/2024 01/12/2024 Operating System for LoRa nodes selected 2 Days 01/15/2024 01/16/2024 LoRaWAN Routing Software selected 3 Days 01/17/2024 01/19/2024 Network Devices Received 1 Day 01/22/2024 01/22/2024 First LoRa Packets Transmitted 4 Days 01/23/2024 01/26/2024 First Multi-hop Packet Transmitted 5 Days 01/29/2024 02/02/2024 Fire Detection Implemented 19 Days 02/05/2024 02/29/2024 Search and Rescue Assistance 21 Days 03/01/2024 03/29/2024

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 31 Implemented Generate Network Map 2 Days 04/01/2024 04/04/2024 Generate Network Coverage Heat Map 1 Day 03/05/2024 04/05/2024 Deploy Network according to Network Map 4 Days 04/06/2024 04/11/2024 Network validated for fire detection requirements 10 Days 04/12/2024 04/22/2024 Network validated for search-and-rescue requirements 5 Days 04/25/2024 04/29/2024 Network validated for transmission prioritization and coverage 5 Days 05/01/2024 05/07/2024 Project Sign-off on all defined requirements 1 Day 05/08/2024 05/08/2024 Project hand-off 4 Days 05/09/2024 05/14/2024

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 32 Long-Term Support Contract Defined 2 Days 05/15/2024 05/16/2024 Long-Term Support Contract Signed 1 Day 05/17/2024 05/17/2024 Outcome The project has multiple outcomes that will each be measured based on different metrics. If the forest-fire detection functionality is successful, then the network should be able to detect a 10 square foot flame within 10 minutes of the flame being started. This metric is selected to ensure that forest fires are caught prior to causing excessive damage to the environment. If the search-and-rescue notification system is functional then a push button, whether it be on a LoRa emergency transponder or on a LoRa node, should notify emergency personal within 30 seconds of the message being sent. This message must include accurate location information. If the general-purpose public network aspect of the project is successful, then it should be possible to deploy an infinite number of sensors without causing any delays to emergency transmissions. This coexistence of public messaging with emergency messaging is crucial to the long-term viability of the network as a publicly useable wide area network for sensors and research.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 33 References Berry, J. (2022, February 10). Ground wave, space wave and skywave . Ham Radio Engineering. https://hamradio.engineering/ground-wave-space-wave-and-skywave/ Centelles, R. P., Meseguer, R., Freitag, F., Navarro, L., Ochoa, S. F., & Santos, R. (2021). LoRaMoto: A communication system to provide safety awareness among civilians after an earthquake. Future Generation Computer Systems , 115 , 150–170. https://doi.org/10.1016/j.future.2020.07.040 Cotrim, J. R., & Kleinschmidt, J. H. (2020). LORAWAN Mesh Networks: A Review and Classification of Multihop communication. Sensors , 20 (15), 4273. https://doi.org/10.3390/s20154273 Dampage, U., Bandaranayake, L., Wanasinghe, R., Kottahachchi, K., & Jayasanka, B. (2022). Forest fire detection system using wireless sensor networks and machine learning. Scientific Reports , 12 (1). https://doi.org/10.1038/s41598-021-03882-9 Elam, S. (2023, September 23). How California is using AI to snuff out wildfires before they explode. CNN . https://www.cnn.com/2023/09/23/us/fighting-wildfire-with-ai-california- climate/index.html Ground Control. (2023, December 7). Iridium Short Burst Data (SBD) Pricing & Service | Ground Control . https://www.groundcontrol.com/us/products/iridium/short-burst-data- range/short-burst-data-service-plans/

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 34 Heath, J. (2023, August 31). New drone research advances wildfire monitoring . University of California. Retrieved December 12, 2023, from https://www.universityofcalifornia.edu/news/new-drone-research-advances-wildfire- monitoring Heggie, T. W., & Amundson, M. E. (2009). Dead Men Walking: Search and rescue in US national parks. Wilderness & Environmental Medicine , 20 (3), 244–249. https://doi.org/10.1580/08-weme-or-299r.1 Hoory, L. (2022, March 25). What is waterfall methodology? Here’s how it can help your project management strategy. Forbes Advisor . https://www.forbes.com/advisor/business/what-is- waterfall-methodology/ Iridium 9602N SBD Transceiver - Beam Communications . (n.d.). Retrieved December 9, 2023, from https://www.beamcommunications.com/satellite/15-iridium-9602n-sbd-transceiver Jacobo, J. (2022, August 17). Forest fires destroyed nearly 23 million acres of land in 2021, and it’s expected to get worse, experts say. ABC News . https://abcnews.go.com/International/forest-fires-destroyed-23-million-acres-land-2021/ story?id=88400813 Martens, M. (2018, September 17). Introduction to APRS- the Automated Packet Reporting System . KB9VBR Antennas. https://www.jpole-antenna.com/2018/09/17/introduction-to- aprs-the-automated-packet-reporting-system/

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

A Free WAN for Wilderness Monitoring and Communication 35 Phillips, K., Longden, M. J., Vandergraff, B., Smith, W. R., Weber, D. C., McIntosh, S., & Wheeler, A. R. (2014). Wilderness search strategy and tactics. Wilderness & Environmental Medicine , 25 (2), 166–176. https://doi.org/10.1016/j.wem.2014.02.006 Sendra, S., García, L., Lloret, J., Bosch, I., & Vega-Rodríguez, R. (2020). LORAWAN Network for fire monitoring in rural environments. Electronics , 9 (3), 531. https://doi.org/10.3390/electronics9030531 USDA Press Office. (2017, September 14). Forest Service wildland fire suppression costs exceed $2 billion . USDA. Retrieved December 9, 2023, from https://www.usda.gov/media/press-releases/2017/09/14/forest-service-wildland- fire-suppression-costs-exceed-2-billion

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

DANIEL_MANLA_IT_CAPSTONE_TASK2

Related Documents