She/Her/Hers
Lesbian
|
|
EMILY PRATT SLATIN | About | Press Kit | Notebook | Music Playlist | She/Her/Hers Lesbian |
Retired Career Fire and EMS Lieutenant-Specialist, Writer, and Master Photographer, living in Vermont.
MIDDLETOWN SPRINGS VERMONT PUBLIC CHANNEL INFORMATION
CHANNEL: MTSmesh
KEY: 5P6LE1IHfr8WBnoiOfEtSA==
Middletown Springs Community Mesh Network: A town-wide Meshtastic communications system for public participation, municipal support, and emergency backup communications.
The Middletown Springs Community Mesh Network is a proposed town-wide communications infrastructure project using Meshtastic-compatible LoRa radio technology to provide decentralized messaging coverage throughout Middletown Springs, Vermont.
The project seeks to establish reliable wireless coverage across all populated areas of the town, including residences, farms, businesses, municipal facilities, remote properties, and major travel corridors. The system is intended to supplement existing communications systems while providing an alternate method of information exchange during power outages, internet failures, severe weather events, road closures, cellular congestion, and other situations where standard communications may become unavailable or unreliable.
Unlike conventional communications systems that depend upon centralized infrastructure, the proposed mesh network spreads communications capability across many interconnected nodes. Each node can send, receive, and relay messages for other nodes, allowing information to move across town even when two users cannot communicate directly.
The long-term vision is to create a sustainable, community-supported communications resource that serves residents, municipal departments, emergency responders, technical volunteers, and visitors.
Important: This network is not proposed as a replacement for 911, public safety radio systems, cellular service, landline service, amateur radio, or official emergency communications. It is proposed as an additional backup layer for low-bandwidth text-based communication, local awareness, and community coordination.
The primary design goal is to create a reliable, low-cost, low-power, town-wide communications mesh that can remain useful during normal conditions and during communications failures.
Middletown Springs includes valleys, ridgelines, forested roads, rural properties, and uneven terrain. Radio coverage will be shaped heavily by line-of-sight conditions. A property that appears close on a map may be difficult to reach if a ridge, wooded hollow, or terrain fold blocks the signal path.
Vermont forest cover may reduce signal strength, particularly during the growing season when leaves are present. Wet foliage, snow, and ice may further reduce performance in certain locations.
Some ideal radio sites may not have utility power. These sites may require solar power, batteries, charge controllers, and winter-rated power budgets. Battery sizing must account for long nights, snow cover, cold temperatures, and repeated cloudy days.
Internet-connected nodes may use MQTT or other internet-based backhaul methods where available. However, the core network should not depend on internet service. The system must remain useful when broadband, cellular data, and commercial power are unavailable.
Funding may be limited. The project may require a combination of municipal support, grants, donations, resident-hosted nodes, volunteer labor, and phased deployment.
Some of the best node locations may be on private land, farms, barns, garages, homes, or other privately owned structures. Long-term access, permission, liability, mounting arrangements, and maintenance agreements should be handled before permanent installation.
All fixed outdoor nodes must be designed for Vermont weather, including wind, rain, heavy snow, ice loading, freeze-thaw cycles, summer heat, insects, and ultraviolet exposure.
Mesh networks can become less effective when too many nodes transmit too often. Configuration choices should reduce unnecessary traffic, keep message behavior predictable, and avoid turning every device into an overly aggressive relay.
A town-wide mesh network needs clear expectations. The project should define who maintains infrastructure nodes, who distributes private channel keys, who responds to abuse or spam, who updates documentation, and how changes are approved.
During emergencies, all non-essential traffic shall yield immediately to emergency, public safety, incident management, and life-safety communications.
Network operators may temporarily restrict, mute, rate-limit, or disconnect nodes generating non-essential traffic that interferes with emergency communications, but only when necessary to preserve life-safety, public safety, incident management, or emergency communications capability.
The declaration and deactivation of emergency traffic should be stated in short, standardized text in all capital letters that avoids special characters. It should be agreed upon as the exact text, sent three times in rapid succession, is to be the only accepted and enforceable method to declare and/or cancel an emergency.
It is suggested that the text state only one of the following:
EMERGENCY, ALL UNITS RESTRICT NON-EMERGENCY COMMUNICATIONS UNTIL FURTHER NOTICE.ALL UNITS MAY NOW RESUME NORMAL RADIO TRAFFIC.
The proposed network uses LoRa radio technology and Meshtastic software to create a low-bandwidth, long-range, text-based mesh communications system. LoRa is well suited for small packets of information sent over long distances using relatively low power. Meshtastic adds routing, device management, channels, encryption keys, GPS position sharing, and user-friendly access through mobile applications and web tools.
In a mesh network, devices do not need to communicate only through a central tower or single base station. Instead, each participating node may relay messages for other nodes. If one path is blocked or unavailable, messages may move through another path, depending on node placement, configuration, and signal quality.
LoRa performance is strongly influenced by antenna placement, antenna height, terrain, and obstructions. High-ground sites, clear views, quality antennas, and low-loss feedline can improve performance dramatically. Poor antenna placement can make even good radios perform badly.
The system should not depend on one central node. A town-wide design should include multiple fixed backbone nodes, mobile municipal nodes, community-hosted nodes, and portable user devices. The goal is to create many possible paths across town.
The proposed communications model separates public participation from private coordination. A public community channel can be advertised openly to encourage resident adoption. Separate private channels can be used by infrastructure maintainers, municipal coordinators, emergency management personnel, and other approved users.
Internet backhaul may be used where available, particularly at backbone sites. MQTT connectivity can help connect distant sections of the network or provide additional paths when internet is functional. However, internet backhaul should be considered supplemental. The local RF mesh should remain useful without it.
A five-node backbone is proposed as the minimum starting point for town-wide service. This includes one central village node and four high-site nodes placed around town to provide wider reach, route diversity, and coverage into surrounding areas. This backbone is not the final network. It is the starting structure upon which community nodes, vehicle nodes, and additional fill-in nodes can be added.
The Middletown Springs Community Mesh Network is designed as a layered communications system consisting of fixed infrastructure nodes, mobile municipal nodes, community-hosted nodes, and user devices. Each layer performs a specific function while contributing to overall coverage and reliability.
The backbone infrastructure layer forms the foundation of the network. A minimum of five strategically located fixed nodes is proposed as the initial deployment target.
A primary node located near the village center should provide coverage to the highest concentration of residents, businesses, municipal facilities, and public gathering areas. This node may also serve as a convenient site for onboarding, testing, and public demonstration.
It is suggested that placement include, but shall not be limited to: town hall, school, library, fire department, Mineral Springs Park, and any tower or building steeple.
Four additional infrastructure nodes should be placed at high-ground or otherwise advantageous sites distributed around town. These sites should be selected based on coverage potential, line-of-sight value, year-round access, available power, structure suitability, and willingness of the host.
The purpose of these nodes is to connect valleys, reduce terrain shadowing, improve redundancy, and create overlapping coverage zones.
Where internet service is available, backbone nodes may use MQTT or another internet backhaul method to improve routing options. Internet service should not be required for basic town-wide communications. The RF mesh remains the core system.
Municipal vehicles provide an important opportunity to improve network coverage through mobile infrastructure. Permanent Meshtastic installations are recommended for town-owned or public service vehicles where appropriate.
Recommended vehicle classes include:
Fire apparatus should be very high-priority mobile node platforms. Fire trucks often respond to remote properties, structure fires, storm damage scenes, brush fires, road incidents, and mutual aid calls. A fire truck with a permanently powered Meshtastic node and a quality external antenna can act as a temporary communications asset at an incident scene, even if no one is actively monitoring the device.
Vehicle nodes do not need to be constantly monitored to provide value. As vehicles travel through town, they may bridge weak areas, temporarily connect isolated nodes, and create added routing paths. When parked at a work site or incident scene, they may provide localized mesh coverage.
Aquisition of node hardware should prioritize Send & Store, GPS, and MQTT compatability.
Community participation is essential for full coverage. Residents may voluntarily host nodes on homes, barns, garages, workshops, farm buildings, silos, commercial buildings, and other suitable structures. These nodes increase network density and help fill coverage gaps.
Recruitment should prioritize:
The end user layer consists of handheld and portable Meshtastic devices used by residents, volunteers, visitors, and municipal personnel. These may include pocket nodes, vehicle nodes, solar field units, emergency kits, and phone-linked devices.
A public channel should be created for general town use. The channel key may be publicly shared if the town intends the channel to be open. This channel can support onboarding, testing, public messages, coverage reports, and general community use. The centeralized town node should be placed at town hall, have redundant battery backup, and have an MQTT gateway established.
Public channel information may be distributed through:
A private operations channel should be created for infrastructure maintainers, technical volunteers, and approved municipal coordinators. This channel keeps maintenance and coordination traffic separate from public conversation.
A separate private backup channel may be created for emergency management, designated municipal users, fire leadership, and approved incident coordination personnel. This channel should not be treated as a replacement for official public safety communications, but it may provide an additional text-based fallback during outages.
The five-node backbone is the proposed minimum. Reliable coverage across every house, farm, road, and property may require, at minimum approximately 40 to 60 total nodes after adding community nodes, vehicle nodes, fill-in nodes, and portable devices. Actual requirements must be determined through field testing.
The network should use commercially available hardware, open-source software, and readily obtainable installation materials. Equipment choices should favor reliability, maintainability, affordability, and long-term availability.
Backbone nodes are critical infrastructure assets. They should be designed for continuous operation and should use robust enclosures, external antennas, stable power, and backup power.
Community-hosted nodes may be simpler than backbone nodes, but should still be designed for reliable operation. These nodes may be hosted by residents, farms, businesses, or civic organizations.
Mobile nodes should be permanently installed in municipal vehicles when possible. Vehicle nodes should include reliable power, a secure mounting location, and a good external antenna.
Portable nodes may include handheld devices, personal emergency kits, field units, and phone-linked devices. These devices should be simple enough for residents and volunteers to use without advanced technical knowledge.
Hardware should be Meshtastic-compatible and should support the appropriate regional LoRa frequency plan. Radios should be selected based on reliability, external antenna support, low power consumption, battery options, GPS needs, firmware support, and ease of configuration.
Potential hardware classes include:
Antenna choice and placement may have a greater effect on performance than the radio model itself. Backbone and vehicle installations should use external antennas suitable for their environment.
Utility-powered nodes should include surge protection and backup battery capability. Power supplies should be sized conservatively and placed in protected locations.
Solar-powered nodes should be sized for Vermont winter conditions. Designs should account for cold temperatures, cloudy periods, short winter days, snow cover, and battery aging.
A solar node may include:
Outdoor enclosures should protect equipment from rain, snow, ice, dust, insects, wind-driven moisture, temperature extremes, and ultraviolet exposure. Enclosures should be serviceable without requiring complete disassembly. Plastic NEMA enclosures are preferrable.
Mounting materials may include poles, masts, brackets, clamps, roof mounts, wall mounts, tower hardware, stainless fasteners, guy wire, grounding hardware, and weatherproof cable glands.
All significant outdoor antenna installations should include grounding, bonding, surge suppression, and lightning arrestors where appropriate. No system can be made immune to direct lightning strikes, but careful installation can reduce equipment loss and safety risk.
The project should maintain a small inventory of spare radios, antennas, cables, power supplies, batteries, solar parts, connectors, fuses, and mounting hardware. This reduces downtime when a node fails.
The construction process should be phased. A phased approach allows the town and volunteers to test assumptions, control costs, document results, and expand based on observed coverage rather than guesswork.
Install the central village node and at least one high-site node as the first pilot. Confirm that the two locations can communicate reliably. Add additional high-site nodes one at a time, documenting signal strength, hop behavior, packet success, and coverage changes after each installation.
Complete the minimum backbone consisting of one village node and four high-site nodes. Each backbone site should be tested for power reliability, antenna performance, weather protection, and maintenance access.
Install mobile nodes in fire apparatus, highway department vehicles, and other municipal vehicles. Each vehicle node should be tested while parked, while moving, and while located in known weak-signal areas.
Invite residents and property owners to host additional nodes. Priority should be given to locations that fill known coverage gaps, improve route diversity, or provide useful coverage to remote farms and road corridors.
Create resident-friendly instructions for joining the public channel. Create separate maintainer documentation for node configuration, channel management, troubleshooting, power systems, and site maintenance. A list of all permantly installed nodes will need to be kept privately and maintained. Such list should ideally have a street address, and GPS coordinates for the location of the node. Ideally, a brief description of the node and where it is installed can be immensely helpful for locating it.
Establish a recurring maintenance schedule. Review node health, battery status, physical condition, antenna condition, firmware versions, and channel settings. Update the coverage map whenever new nodes are added or old nodes are removed.
Because this document is written as a planning proposal, the following section identifies expected problems and likely field issues rather than completed project failures. These issues should be tracked during pilot deployment and updated with actual findings.
Valleys, ridges, and uneven ground may create locations where nearby nodes cannot communicate reliably. Some homes and farms may require local fill-in nodes even if they appear close to the backbone on a map.
Coverage may change between winter and summer due to foliage, moisture, ice, snow, and changing ground conditions. Testing should be repeated across seasons.
Solar sites may perform well during summer but fail during long winter cloud periods or after snow covers panels. Solar systems should be oversized and tested conservatively.
A radio placed indoors, low to the ground, behind metal siding, or under a roof may perform poorly. Antenna placement should be treated as a critical design factor, not an afterthought.
If volunteers configure devices independently, settings may become inconsistent. This can create routing problems, channel confusion, poor performance, or difficulty troubleshooting. A standard configuration profile should be maintained.
Too many devices transmitting location updates, telemetry, or repeated test messages can reduce network usefulness. Public guidance should encourage responsible traffic levels. GPS location updates and automated pings should enable smart positing to limit the number of duplicate reports.
A public channel may attract spam, nuisance messages, or inappropriate content. The town should set expectations for public use and maintain separate private channels for critical coordination. At no time should any commercial activity be allowed over public channels.
A volunteer-built system may fail over time if maintenance responsibility is unclear. Each infrastructure node should have an assigned owner or maintainer.
Internet-connected nodes may improve normal operation, but the system should not assume internet availability during emergencies. Testing should include internet-disabled scenarios.
Residents may assume the system replaces emergency services or guarantees message delivery. Documentation should clearly state that the mesh is a backup text communications tool, not a substitute for 911 or official dispatch systems.
Testing should confirm that the network performs acceptably under realistic local conditions. The project should test fixed coverage, mobile coverage, battery performance, internet-failure behavior, and user onboarding.
Coverage testing should include both stationary and mobile tests. Volunteers should record whether messages are received, how many hops are required, which nodes relay messages, and where failures occur.
Each backbone node should be tested for message reliability, power stability, physical weather protection, antenna performance, and access for maintenance.
Vehicle nodes should be tested in three conditions:
Infrastructure nodes should be tested without utility power to confirm backup battery behavior. Solar nodes should be monitored through extended cloudy periods and cold weather.
Internet-connected nodes should be tested with internet service disabled. The local RF mesh should continue passing messages without depending on MQTT or any outside service.
Public onboarding should be tested with nontechnical users. A successful public test means that a resident can follow instructions, join the public channel, send a test message, receive a response, and understand basic use expectations.
| Test Area | Method | Success Standard | Notes |
|---|---|---|---|
| Village Coverage | Stationary and walking tests | Messages pass reliably through the central node | Test near public buildings and main roads |
| Backbone Connectivity | Node-to-node message tests | Each backbone node has at least one reliable path to the mesh | Multiple paths are preferred |
| Remote Properties | Field tests from farms and rural homes | Messages can reach the mesh or identify need for fill-in nodes | Permission required for private property tests |
| Vehicle Nodes | Drive tests and parked incident-style tests | Vehicle nodes improve coverage in weak areas | Fire apparatus should be high priority |
| Power Backup | Disconnect utility power | Node remains online for target backup duration | Repeat in cold weather where possible |
| Internet Loss | Disable internet backhaul | Local RF messaging continues | Confirms backup value |
| Public Onboarding | Resident setup trial | User can join and send a message using written instructions | Instructions should be revised after test feedback |
At the proposal stage, final measured results are not yet available. This section should be updated after pilot deployment, backbone installation, vehicle testing, and community rollout.
The proposed five-node backbone is expected to provide the first usable town-wide structure. It should improve communication between the village center and major high-ground areas while revealing the specific valleys, roads, farms, and properties that require fill-in nodes.
Municipal vehicle nodes, especially nodes mounted on fire apparatus, are expected to improve temporary coverage during incidents, road work, storm response, and routine vehicle movement through town.
The full network, including backbone nodes, vehicle nodes, community-hosted nodes, and portable user devices, may ultimately require approximately forty to sixty total nodes for reliable town-wide coverage. This estimate should be revised after coverage testing.
Recommended reporting format: Results should be documented as maps, tables, and plain-language summaries. The goal is to make the network understandable to town officials, technical volunteers, and residents who do not have radio experience.
Future versions of the network should be based on measured coverage, real usage patterns, maintenance experience, and community feedback.
Add fill-in nodes in confirmed weak areas. Priority should be given to farms, remote homes, road corridors, and areas that become isolated during storms.
Add more high-site nodes if testing shows that the original five-node backbone cannot provide enough route diversity or reliable reach into certain sections of town.
Install nodes on every fire truck, where feasible. Apparatus-based nodes should be standardized, labeled, and powered reliably from the vehicle.
Highway department vehicles may provide valuable coverage during snowstorms, washouts, tree-down events, and road closures. These vehicles often travel precisely where situational information is most useful.
The town or volunteer group may maintain a small set of loaner nodes for public events, training sessions, storm response, shelter operations, and residents who want to test coverage before hosting a permanent node.
A public coverage map may help residents understand where the network works well and where additional hosts are needed. Exact private node locations should be shown only with host permission.
Short training sessions can help residents install apps, join the public channel, send messages, understand limitations, and use the system responsibly during emergencies.
Infrastructure maintainers may create a simple monitoring process to track node uptime, battery voltage, solar behavior, and missing nodes. This should be kept simple enough for long-term volunteer maintenance.
Portable emergency kits may include a Meshtastic node, battery pack, charging cable, printed instructions, spare antenna, and laminated channel information.
Public and private channel policies should be reviewed periodically. The public key may remain published for community use, while private keys should be limited to approved participants and changed when necessary.
The general public should be allowed, and encouraged to use the public channel for community wide chats, direct messages, and announcements, except during emergencies. Emergent, urgent, or public messages must always take priority over non-emergency ones.
Users should use their full names, or for privacy reasons, may use family names to identify nodes, and the naming should be standardized. To maintain clarity, users should be required to name their node(s) using standardized conventions.
A town-wide Meshtastic network for Middletown Springs is technically realistic if it is treated as infrastructure rather than a casual gadget project. The five-node minimum backbone provides a sensible starting point: one central village node and four high-site nodes placed around town. That minimum backbone should be followed by field testing, municipal vehicle installations, fire apparatus nodes, community-hosted nodes, and targeted fill-in coverage.
The strongest design is not a single tower, a single repeater, or a single internet-connected node. The strongest design is a layered system: fixed backbone sites, mobile municipal assets, private operations channels, a public community channel, resident participation, and clear maintenance responsibility.
Publishing a public channel key can make sense for broad community adoption, provided everyone understands that the public channel is public. Private backup channels should remain separate for municipal coordination, infrastructure work, and emergency management use.
The system should be presented honestly. It will not replace emergency dispatch, public safety radio, cellular networks, landlines, or the internet. It will, however, provide another path for short text-based communication when other systems are unavailable, overloaded, or inconvenient.
For a rural Vermont town with hills, hollows, farms, storms, long roads, and uneven cellular coverage, that additional path may be very much worth building.
| Channel | Access | Purpose | Key Handling |
|---|---|---|---|
| Public Community | Open to residents and visitors | General use, testing, onboarding, public coordination | May be published if the town wants open access |
| Operations | Approved maintainers and coordinators | Infrastructure work, testing, maintenance, outage coordination | Private distribution |
| Emergency Backup | Approved municipal and emergency management users | Backup text coordination during incidents or outages | Private distribution with controlled updates |
Node names should be short, readable, and consistent. They should identify nodes by individual/family without exposing unnecessary private information. Each node name must be unique.
MTS-Town-Hall-01MTS-North-BackboneMTS-South-BackboneMTS-Fire-Engine-1MTS-Highway-Truck-2MTS-Community-014Emily-Slatin-01Amelia-Desertsong-01Slatin-Family-01| Site Name | |
|---|---|
| Property Owner / Contact | |
| General Location | |
| Power Available | Yes / No / Solar Required |
| Internet Available | Yes / No / Unknown |
| Mounting Option | Roof / Barn / Mast / Pole / Tower / Other |
| Approximate Antenna Height | |
| Maintenance Access | Year-round / Seasonal / Limited |
| Weather Concerns | Wind / Ice / Snow / Trees / Animals / Other |
| Initial Test Result | |
| Recommended Node Type | Backbone / Community / Fill-In / Temporary / Not Recommended |
The Middletown Springs Community Mesh Network public channel is intended for community communication, testing, local information, and backup messaging. Users should keep messages brief, courteous, and relevant. The system does not replace 911, public safety radio, cellular service, landline service, or official emergency alerts. Message delivery is not guaranteed. Before sending any message, the sender should consider the usefulness of the information prior to sending it. The sending of non-emergent messages during a known emergency is strictly prohibited.
Private channels are intended for approved municipal, emergency management, infrastructure, and technical coordination users. Private channel keys should not be posted publicly or shared without authorization.
| Item | Quantity | Purpose |
|---|---|---|
| Backbone node kit | 5 | Minimum village and high-site backbone |
| Vehicle node kit | As available | Fire apparatus, highway trucks, and municipal vehicles |
| Community node kit | 10 to 20 initial units | Fill weak areas and recruit resident hosts |
| Portable test node | 3 to 5 | Coverage testing and public demonstrations |
| Spare radio | 2 to 5 | Rapid replacement and troubleshooting |
| Spare antenna and cabling | Multiple | Maintenance and field repair |
Potential coordination partners may include neighboring municipalities, mutual aid agencies, emergency management organizations, regional planning entities, and other public or private organizations whose operations overlap the geographic area served by the network.
The goals of intermunicipal coordination are to share information about the network concept and its limitations, encourage compatible planning practices, identify potential high-ground or border-area node locations, support mutual aid awareness, reduce unnecessary duplication of infrastructure, and improve regional resilience during communications outages or emergencies. Coordination efforts should also reinforce the understanding that the mesh network is a supplemental communications tool and not a replacement for 911, dispatch services, public safety radio systems, cellular networks, landline telephone service, amateur radio systems, or official emergency alerting systems.
Each municipality should maintain control of its own network infrastructure, channel structure, operational policies, and user access. A shared regional channel may be established for testing, interoperability exercises, public information sharing, or mutual aid coordination if participating communities determine that such a channel would be beneficial. Any shared channel should have clearly documented expectations regarding access, usage, moderation, and key distribution. Private municipal, emergency management, infrastructure, and operations channels should remain under the control of their respective organizations and should not be publicly distributed.
Because LoRa communications are heavily influenced by elevation, terrain, antenna placement, and line-of-sight conditions, certain infrastructure sites may provide coverage benefits to multiple municipalities simultaneously. High-ground locations, towers, municipal buildings, barns, silos, ridgelines, and other advantageous sites near municipal boundaries should be evaluated not only for local coverage benefits, but also for their potential contribution to regional communications resilience. Any permanent installation affecting multiple municipalities should be coordinated with the appropriate property owners, municipal officials, technical volunteers, and emergency management representatives.
The mesh network may provide useful support during mutual aid incidents, severe weather events, flooding, road closures, utility outages, search operations, shelter operations, public gatherings, and other situations where neighboring communities benefit from the exchange of basic text-based information. Emergency, public safety, incident management, and life-safety traffic shall always take priority over non-essential communications. Public channels shall not be used for confidential information, protected personal information, medical information, law enforcement-sensitive information, or any communication that would be inappropriate for public distribution.
As the network develops, project stakeholders should notify neighboring municipalities of significant infrastructure deployments, major coverage improvements, interoperability testing opportunities, and planned exercises. Municipal representatives should be encouraged to participate in coverage testing, field evaluations, and planning discussions when appropriate. Documentation of coordination efforts should be maintained privately and may include municipal contacts, technical contacts, emergency management contacts, interoperability notes, shared testing results, and agreed-upon operating practices.
Participating municipalities remain responsible for compliance with all applicable federal communications regulations, equipment requirements, and operational policies governing the use of the network.
Exact infrastructure locations, private channel information, encryption keys, municipal coordination procedures, and other sensitive operational details should not be publicly disclosed without documented and logged authorization. Publicly available documentation should provide sufficient information to support interoperability and community participation without compromising network security, privacy, or operational effectiveness.
Intermunicipal coordination agreements, contact information, interoperability plans, and shared operating practices should be reviewed periodically and updated as personnel, infrastructure, and operational requirements change.
The Middletown Springs Community Mesh Network may coordinate with neighboring municipalities to improve regional backup communications, mutual aid awareness, interoperability, and community resilience. Such coordination is intended to promote compatibility and preparedness while preserving the independence of each participating municipality. Each municipality shall remain responsible for its own communications policies, infrastructure, equipment, maintenance, emergency procedures, operational decisions, and public information activities.
|
Copyright © 1998-2026 Emily Pratt Slatin. All Rights Reserved. About | Archives | Biography | EMD Codes | Notebook | Press Kit | Pronouns.page | RSS Feed | Sitemap | YouTube Made with grit in Middletown Springs, Vermont. |
