Add heard_repeats to API payload and fix timer sequence to post after listening window

[Copilot]

The app was posting to MeshMapper API in parallel with the 7-second RX listening window, causing API payloads to lack heard repeats/echoes data. Additionally, the API payload did not include heard repeats information.

Changes

API Payload Enhancement

• Added heard_repeats field to MeshMapper API payload
• Reuses existing formatRepeaterTelemetry() for consistency with session log
• Format: "4e(1.75),b7(-0.75)" or "None" if no echoes heard

Timer Sequence Refactored

• Replaced parallel 7s timers (API post + RX listening) with sequential flow
• New sequence: ping → listen 7s → finalize repeats → post API with data
• Removed apiCountdownTimer, added rxListeningCountdownTimer
• Status now shows: "Listening for heard repeats (7s)" with active countdown

Implementation Details

• Modified postToMeshMapperAPI(lat, lon, heardRepeats) to accept heard_repeats parameter
• Refactored scheduleApiPostAndMapRefresh() into postApiAndRefreshMap() called after listening completes
• Updated sendPing() to schedule sequential execution via single timeout
• Changed formatRepeaterTelemetry() to return "None" (capital N) per spec

// Old flow (parallel - incorrect)
setTimeout(() => postToAPI(lat, lon), 7000);
startRepeaterTracking();

// New flow (sequential - correct)
state.meshMapperTimer = setTimeout(async () => {
  const repeaters = stopRepeaterTracking();
  const heardRepeatsStr = formatRepeaterTelemetry(repeaters);
  await postApiAndRefreshMap(lat, lon, accuracy, heardRepeatsStr);
}, 7000);

All new code includes debug logging via existing debugLog() pattern.

Original prompt

You are an AI coding agent working in the GitHub repository: MrAlders0n/MeshCore-GOME-WarDriver (JavaScript/CSS/HTML).
Goal: implement two changes: (1) include heard repeats/echoes data in the API payload, and (2) fix timer/order-of-operations so the app only posts after the heard repeats window completes.

Context

• The app currently posts to the MeshMapper API on every ping via postToMeshMapperAPI with this payload:

  const payload = {
  key: MESHMAPPER_API_KEY,
  lat,
  lon,
  who: getDeviceIdentifier(),
  power: getCurrentPowerSetting() || "N/A",
  test: 0
  };

• A new PR (already merged last night) added logic that listens to the RX log and tracks heard channel repeats/echoes.

• That new logic already has access to:

  • pathHex (hex identifier for a heard repeat path)
  • data.lastSnr (the last SNR for that heard repeat)

• The app already appends these heard repeats to the session log in this exact comma-separated format:
  4e(1.75),b7(-0.75)

• If there are no heard repeats/echoes, the session log uses:
  None

Task 1: Add heard_repeats to the API payload

1. Modify the payload sent by postToMeshMapperAPI to include a new field named heard_repeats.
2. heard_repeats must be a string formatted exactly like the session log:
   • Example: heard_repeats: "4e(1.75),b7(-0.75)"
   • Ensure it is wrapped in quotes as a string.
3. If there are no heard repeats/echoes during the listening window, send:
   heard_repeats: "None"
4. Use the same source-of-truth data that is already being used to write the session log (do not invent a second tracker). If there is already a function/variable that produces the session log string, reuse it so both session log and API are consistent.
5. Confirm the API post contains heard_repeats on every ping post, even when it is "None".

Task 2: Fix timers and execution order (must post AFTER listening)
Current behavior (wrong):

• Ping sent
• Start two timers at the same time:
  • API post countdown timer (7s)
  • Listen for rx_log events (7s)
• Result: API may post before the heard repeats info is finalized.

Required behavior (new flow):

• Ping sent
• Start listening for heard repeats/echoes for 7 seconds
• When the listening timer ends:
  • stop listening / finalize heard repeats string
  • then post to API
  • then continue normal app flow as it currently does

Implementation requirements:

1. Remove or refactor so there is only one 7-second timer controlling the sequence.
2. The API post must not occur until the heard repeats listening window has completed and the heard_repeats string is finalized.
3. Update status messages:
   • Remove: "Wait to post API(7s)"
   • Add/Use: "Listening for heard repeats (7s)" while the 7-second listening window is active
   • When the listening window ends and the API post begins, update status to: "Posting to API"
   • After posting, continue the normal app flow exactly as it worked previously.

Acceptance criteria

• Every ping results in an API payload that includes heard_repeats as a quoted string.
• If no repeats heard: heard_repeats is exactly "None".
• API posting happens strictly after the 7-second RX listening period finishes.
• Status messages reflect the new sequence.
• No duplicate/parallel 7-second timers remain for “post countdown” vs “rx_log listen”; the logic is sequential and simpler.
• Existing behavior outside these changes remains unchanged.

Deliverables

• Code changes implementing Task 1 and Task 2.
• Brief summary of what files/areas were changed and why.
• If there are any edge cases (multiple repeats, duplicates, late rx events), document the chosen behavior consistent with existing session log behavior.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.