mckero
08f9106749
The symbol table and code were free-text fields with no validation and no hint. Only the first character was ever used, and only at packet-build time, so an operator could type "satellite" into the table field, watch it persist, and beacon as "/" - the field lied about what it did. aprs.fi's troubleshooting guidance puts transmit-side symbol misconfiguration among the first things to check when a station never appears correctly. The single strongest argument for a list: \S is Satellite/Pacsat but /S is SHUTTLE. One keystroke apart, and both look right to someone typing from memory. Fourteen entries covering fixed, on-foot, field, four vehicle classes, satellite, yagi, phone, internet-only and handheld. Renderings are from aprs.org/symbols/symbolsX.txt (WB4APR, Nov 2015) rather than recalled. A symbol the operator already set that is not on the list appears first in the menu and stays selected, so opening the picker cannot silently change an existing station's appearance. The default changes from "/>" (CAR) to "/-" (House). The old default's own comment conceded it was "a reasonable stand-in for a phone", but it showed every non-driving operator as a vehicle. A house is right for most users and obviously wrong rather than misleading for the rest. This cannot disturb an existing install: saveConfig writes every key unconditionally and the enable switch calls it, so anyone who has ever turned APRS on has both symbol keys on disk and the changed fallbacks cannot reach them. All three sites move together - AprsStore's load fallback, AprsCard's blank-field fallback, and AprsBeacon.DEFAULT_SYMBOL - because leaving one behind would substitute a car whenever the stored code was unusable. The list lives in core:domain as pure data holding resource names rather than text, so the wording stays in the locale files. Tests assert that every entry survives the transmit sanitiser, that the pairs and description keys are unique, and that a pair off the list reports as absent rather than resolving to something near it.
Look4Sat: Satellite tracker
Radio satellite tracker and pass predictor for Android, inspired by Gpredict
Track satellite passes with ease!
Thanks to Celestrak and SatNOGS you have access to over 9000 active satellites.
You can search the entire database by NORAD Catalog Number or the satellite's name.
Orbital positions and passes are calculated relative to your location.
To get reliable data make sure to set the station position via the app Settings.
The application is built using Kotlin, Coroutines, Jetpack Compose and Navigation.
It is now and always will be completely ad-free and open-source.
Main features:
- Predicting satellite positions and passes for up to 10 days
- Showing the list of currently active and upcoming satellite passes
- Showing the active pass progress, polar trajectory and transceivers info
- Showing the satellite positional data, footprint and ground track on the map
- Custom TLE satellite data import is available via Three Line Element .txt files
- Offline first: calculations are made offline. Weekly TLE data update is recommended.
License
The Look4Sat application code is licensed under the GNU General Public License v3.0.
The CW decoder in feature/cw bundles the DeepCW
neural decoding model, licensed under the GNU Affero General Public License v3.0 only
(AGPL-3.0-only). Because the combined work incorporates an AGPL-3.0 component, the
combined work is distributed under the
GNU Affero General Public License v3.0 — GPL-3.0 Section 13 permits the
combination, and AGPL-3.0 Section 13 applies to the combined work as a whole.
Model provenance and attribution are documented in
feature/cw/licenses/NOTICE.md; the original GPL-3.0
text is preserved at feature/cw/licenses/Look4Sat-GPL-3.0.txt. The CW model runs
locally on-device and does not provide services over a network.