This guide outlines the pieces GatewayPulse expects and the order that makes setup easiest. Exact COM ports, CI-V addresses, radio settings and optional integrations vary by station, so verify your own hardware values before applying changes.
Use a dedicated serial/CI-V path where possible. Match the radio model, CI-V address, baud rate and COM port to the station. GatewayPulse monitoring should remain read-only and must not fight the gateway software for the same port.
The LP-100A integration supplies forward power, reflected power, SWR and RF transmission history. Configure its serial connection in GatewayPulse and verify that telemetry changes during a test transmission.
GatewayPulse can surface battery voltage, current, state of charge and charging state through the Victron monitoring module. Complete the Victron pairing/configuration before relying on power alerts.
Configure only the alerts you actually want. Typical conditions include scanner stopped, radio offline, high SWR and low battery. Test each route before depending on it for unattended monitoring.
The local GatewayPulse service should work first. Remote access can then be exposed through your secure tunnel/domain design. Keep the public website separate from the operational dashboard and API. Remote API access uses the configured mobile Bearer token; do not publish that token.
The native SwiftUI companion consumes GatewayPulse JSON endpoints rather than scraping the dashboard. Configure the public API base URL and mobile API token, then use the app’s connection test before enabling normal refresh and alerts.
Contact GatewayPulse / DadCanMakeIT and include your GatewayPulse version, radio model, enabled integrations, and the step that is failing.