ECTLogger TUI/Packet Radio Client
Status: Concept / Stretch Goal
Purpose: Terminal-based client for low-bandwidth and packet radio operations
Overview
A terminal-based client that communicates with the ECTLogger API, designed to work over:
- Direct terminal (SSH, local console)
- Packet radio (via TNC/terminal node controller)
- Winlink (as a form-based message exchange)
- Low-bandwidth links (HF digital modes, satellite)
This would enable net control operations in austere environments where web browsers arenβt available or bandwidth is extremely limited.
User Interface Concept
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β ECTLogger TUI Client β
β ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β β NET: LA County ARES Training Net Status: ACTIVE ββ
β β Freq: 147.435+ (Active) | 223.96 | D-STAR REF033C ββ
β βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€β
β β # β CALL β NAME β STATUS β FREQ β TIME ββ
β β 1 β W6ABC β John β β IN β 147.435 β 19:02 ββ
β β 2 β KN6XYZ β Maria β β IN β 223.96 β 19:03 ββ
β β 3 β N6TEST β Bob β π LSN β 147.435 β 19:05 ββ
β β 4 β K6EMT β Sarah β π¨ TFC β D-STAR β 19:07 ββ
β βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€β
β β CMD> _ ββ
β ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Command Interface
Full Commands (Terminal Mode)
CMD> ci W6NEW John Pasadena # Check in W6NEW
CMD> co W6ABC # Check out W6ABC
CMD> st W6NEW tfc # Set status to "has traffic"
CMD> freq 2 # Switch active freq to #2
CMD> list # Refresh check-in list
CMD> chat Net is moving to 223.96 # Send chat message
CMD> close # Close the net
CMD> help # Show commands
Abbreviated Commands (Packet Mode)
For packet radio where bandwidth is ~1200 baud:
ECT>C W6NEW,JOHN,PASADENA,IN # Check in
ECT>OK 5 # Response: check-in #5
ECT>L # List check-ins
ECT>1:W6ABC:JOHN:IN:19:02
ECT>2:KN6XYZ:MARIA:IN:19:03
ECT>3:W6NEW:JOHN:IN:19:08
ECT>END
Packet Radio Optimizations
- Compressed updates - Only send diffs, not full state
- Abbreviated commands -
C W6NEW J PASAinstead of full text - Polling mode - Client requests updates vs WebSocket push
- Message batching - Queue multiple check-ins, send in one burst
- Offline queuing - Store commands when link is down, sync when connected
Tech Stack Options
| Approach | Pros | Cons |
|---|---|---|
| Python + Rich/Textual | Matches backend, easy API integration | Requires Python runtime |
| Go + Bubble Tea | Single binary, fast, works everywhere | Separate codebase |
| Rust + Ratatui | Tiny binary, ultra-low resource | Steeper learning curve |
| Pure shell + curl | Works on anything with bash | Limited UI, tedious |
API Endpoints (Already Available)
The existing ECTLogger API supports everything needed:
| Endpoint | Purpose |
|---|---|
POST /api/auth/magic-link/request |
Auth (or add API key support) |
GET /api/nets/?status=active |
List active nets |
GET /api/nets/{id} |
Get net details |
POST /api/check-ins/nets/{id}/check-ins |
Check in station |
PUT /api/check-ins/{id}/status |
Update status |
PUT /api/nets/{id}/active-frequency |
Change active freq |
POST /api/chat/nets/{id} |
Send chat message |
PUT /api/nets/{id}/close |
Close net |
Authentication Considerations
For automated/packet systems, consider:
- API keys instead of JWT tokens (simpler for automated systems)
- Station callsign auth - Trusted callsigns with pre-shared keys
- Gateway mode - One authenticated station relays for others
Winlink Integration
Could work as a Winlink form-based message:
To: ECTLOGGER
Subject: CHECKIN
NET_ID: 42
CALLSIGN: W6ABC
NAME: John
LOCATION: Pasadena
STATUS: IN
A gateway service would parse incoming Winlink messages and submit to the API.
Use Cases
- Field deployment - NCS runs TUI on laptop connected via packet
- Remote check-ins - Field stations send check-ins via Winlink
- HF operations - Low-bandwidth HF digital modes (JS8Call, Winlink)
- Backup capability - When internet is down, packet network still works
- Training - Practice packet operations with real-world application
Implementation Phases
Phase 1: Basic TUI
- Read-only net view
- Simple check-in command
- Works over SSH
Phase 2: Full NCS Control
- All net management commands
- Real-time updates via polling
- Status changes and frequency control
Phase 3: Packet Integration
- Abbreviated command protocol
- TNC integration (KISS protocol)
- Offline queue and sync
Phase 4: Winlink Gateway
- Form template for check-ins
- Gateway service to process messages
- Reply messages with net status
This concept supports ECTLoggerβs mission of serving emergency communications where traditional internet connectivity may not be available.