# Meshtastic Resources

## Community-run Web Tools

These tools use data reported to our MQTT server by nodes across the state.

- Meshtastic Map - live map of Meshtastic nodes CT Mesh has heard
- Global Map - Meshtastic nodes around the world
- Malla - deeper packet-level metrics and mesh performance insights fed from MQTT
- PotatoMesh NEW! - packet, chat, node list, and map fed from RF on Box Mountain
- MeshInfo legacy, partially broken - MQTT gateway setup info, secondary map, graphs, message history, etc.

## Mesh Channels

### Default (Primary) Channel

Most CT chatter occurs on the default LongFast channel.

Name: `LongFast` or (blank)

Key: `AQ==`

Key size: Default or `1 byte`

### CT's established community secondary channel

Name: `ConnNet`

Key: `pJgk5XqJY8Ar+jSqC5W81g==`

Key size: 128 bit

## MQTT

Our MQTT broker is uplink-only and designed for fixed nodes across the state to serve as gateway nodes. Its purpose is not to bridge gaps or extend mesh coverage, but to report local traffic to our own map and other web-based tools for analytical data and metrics to assess the mesh's performance. This role is best suited for stable, well-placed nodes with reliable coverage. If that describes your setup, follow the steps at on this page to get set up.

### Key Settings

    MQTT > Enabled > ON
    MQTT > Encryption Enabled > ON
    MQTT > Map Report > OFF
    MQTT > Root Topic > msh/US/CT
    MQTT > Address > mqtt.ctmesh.org
    MQTT > Username > meshdev
    MQTT > Password > large4cats
    MQTT > TLS Enabled > OFF
    Channels > Primary Channel > Positions Enabled > ON
    Channels > Primary Channel > Approximate Location > (set as desired)
    Channels > Primary Channel > MQTT Uplink > ON
    Channels > Primary Channel > MQTT Downlink > OFF
    Settings > Modules > Neighbor Info > ON
    LoRa > Ok to MQTT > ON

Note: CT Mesh's MQTT server is bridged and uplinks to the MQTT servers for both meshtastic.liamcottle.net and meshmap.net

## Infrastructure Nodes

Important: Infrastructure roles like `ROUTER`, `REPEATER`, `ROUTER_CLIENT`, or `ROUTER_LATE` are rarely appropriate. Unless your node is sitting on top of one of the tallest buildings in Hartford with clear line-of-sight across the region, using these roles will hurt more than help. For almost everyone, the correct choice is `CLIENT`. If you think you've got a node that truly warrants an infrastructure role, reach out first - we'd rather make sure it benefits the mesh than inadvertently weakens it.

Back to CT Mesh