Skip to content

Add aprs.to station lookup to context menu#11

Open
fromalexx wants to merge 12 commits intona7q:masterfrom
fromalexx:aprs-to
Open

Add aprs.to station lookup to context menu#11
fromalexx wants to merge 12 commits intona7q:masterfrom
fromalexx:aprs-to

Conversation

@fromalexx
Copy link
Copy Markdown

Adds an "aprs.to" option to the long-press context menu alongside the existing aprs.fi and QRZ.com links.

Changes

Tapping "aprs.to" on any station opens https://aprs.to/station/<callsign-ssid>/ in the device browser.

fromalexx added 12 commits April 1, 2026 21:33
AudioBufferProcessor.java and PacketCallback.java were stored as
plain-text path pointers (Unix symlinks) which break on Windows.
Replaced with actual file contents from PacketDroid submodule.
Packets arriving via igate (TYPE_IG) were only parsed and added to the
map if the unrelated 'send my position to APRS-IS' (p.positiontois)
preference was also enabled. This meant stations heard over igate showed
in the log but never on the map unless that option was on.

Fix: parse all TYPE_IG packets unconditionally, same as TYPE_POST and
TYPE_INCMG packets.
- New checkbox in IGate settings: 'Auto-prepend GPS range filter'
- New field: GPS filter radius in km (default 100)
- When enabled, prepends r/lat/lon/radius to the custom filter string
  on login, so APRS-IS starts sending nearby traffic immediately
- While connected, re-sends #filter command over the live socket
  whenever position changes by more than 5km (no reconnect needed)
- Custom filter field still works normally; GPS filter is prepended
- Falls back gracefully if no GPS fix is available
APRS-IS protocol requires the #filter command to be sent AFTER the
server confirms login with '# logresp'. Sending it before (as part
of sendLogin()) caused the server to silently ignore it, resulting
in '# filter active' never appearing in the log and no range-based
traffic being delivered.

Fix: sendLogin() now only sends the 'user' line. A new sendFilterCommand()
is called from the message loop when '# logresp' is detected.
sendFilterUpdate() was firing on the very first incoming packet because
lastFilterLat/Lon were still 0,0. After sendFilterCommand() sends the
filter on logresp, immediately sync lastFilterLat/Lon from GPS so
shouldUpdateGpsFilter() won't trigger again until we actually move 5km.
- Add filterJustSent flag to skip shouldUpdateGpsFilter() on the same
  loop iteration that sendFilterCommand() ran, eliminating the duplicate
  '# filter active' line in the log
- Replace fixed 5km threshold with 5% of the user's configured radius
  (e.g. 200km radius -> update every 10km, 50km -> every 2.5km)
- Uses getLastKnownLocation() only, no additional GPS polling/battery use
Added check: if lastFilterLat/Lon are still 0.0/0.0, return false.
This prevents sendFilterUpdate() firing on the first server message
(aprsc banner) before sendFilterCommand() has run and set the baseline
coordinates, which was causing the duplicate filter send.
…contents"

This reverts commit 78b5dc10212813b6b059c947a25194bc0b9f49d6.
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