Skip to content

feat(logging): show long-path distance & bearing on the logging form#247

Merged
patrickrb merged 1 commit into
mainfrom
optio/task-c667d75d-f77c-4d09-8b79-c2342dd5fd1c
Jul 24, 2026
Merged

feat(logging): show long-path distance & bearing on the logging form#247
patrickrb merged 1 commit into
mainfrom
optio/task-c667d75d-f77c-4d09-8b79-c2342dd5fd1c

Conversation

@patrickrb

Copy link
Copy Markdown
Owner

Problem

The logging form's live distance/bearing readout (added in #233) shows only the short-path great-circle heading and distance from the operator's home grid to the contact. But on HF, DX signals frequently arrive via the long path — around the other side of the globe — where the antenna must point in the opposite direction (180° from short path) and the arc covers the rest of the great circle.

During a long-path opening, operators had to compute that opposite heading in their head. The information the logger already had everything needed to show it directly.

Solution

Extend the existing short-path readout with the long-path complement:

  • src/lib/grid.ts — add three exports to the shared (client-safe) grid module:
    • EARTH_CIRCUMFERENCE_KM — the full great-circle length (2πR, R = 6371 km); short + long path always sum to it.
    • longPathBearingDeg(shortBearing) — the beam heading 180° opposed to short path, normalized into [0, 360).
    • longPathKm(shortKm) — the remaining arc, EARTH_CIRCUMFERENCE_KM − shortKm.
    • PathInfo / gridPath() now also carry longPathKm, longPathBearingDeg, longPathCompass.
  • src/app/new-contact/page.tsx — render a subtle muted LP … line beneath each of the existing Distance and Bearing values (e.g. LP 34528 km, LP 231° SW). No new network calls, no layout shift — it reuses the coordinates already resolved for the short path.

The readout still renders nothing until both endpoints resolve, so a half-typed grid never shows a bogus reading.

Testing

  • npm run typecheck — clean
  • npm run lint — clean
  • npm run build — succeeds
  • npx playwright test grid.spec.ts22 passed, including new cases for longPathBearingDeg (180° opposition + wraparound), longPathKm (sums to circumference), and gridPath reporting the long path as the opposite compass point (FN31→IO91 short = NE, long = SW) covering the far arc.

Followed TDD: added the failing tests first, then implemented until green.

Backwards compatibility

Additive only. Existing PathInfo fields are unchanged; gridPath() gains fields but drops none. No API, schema, or request/response shapes touched.

Future follow-up

  • The QuickLogCard doesn't yet show any distance/bearing readout; long path could be surfaced there too in a later pass.

🤖 Generated with Claude Code

HF DX often arrives via the long path (around the far side of the
globe), where the beam heading is 180° opposed to the short path and
the arc covers the rest of the great circle. The logging form's
distance/bearing readout only showed the short path, so operators had
to compute the long-path heading in their head during an opening.

Add long-path helpers to the shared grid module (longPathBearingDeg,
longPathKm, EARTH_CIRCUMFERENCE_KM), extend PathInfo/gridPath to carry
the complement, and render a subtle "LP …" line under each of the
Distance and Bearing readouts on the new-contact page.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@vercel

vercel Bot commented Jul 24, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
nodelog Ready Ready Preview, Comment Jul 24, 2026 12:07pm

Request Review

@patrickrb
patrickrb merged commit 8d8212e into main Jul 24, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant