Checked against ADIF 3.1.7 (2026-03-22, the current release) rather than my own reading. Two of my rules were wrong. Char.isDigit() is Unicode-aware and covers the whole Nd category - some 600 characters. So Arabic-Indic, Devanagari, Persian and fullwidth digits all passed as a square pair, which a localised keypad produces without the operator seeing any difference. The spec is explicit: "Digit - an ASCII character whose code lies in the range of 48 through 57, inclusive." Wavelog stores GRIDSQUARE verbatim, so such a value would never match a real grid in any statistics or VUCC query - the exact failure this validation exists to prevent. Two-character locators are legal. The GridSquare type is "a case-insensitive 2-character, 4-character, 6-character, or 8-character Maidenhead locator" and the GRIDSQUARE field description repeats all four. My comment claimed Maidenhead had no other lengths, and a test name asserted there was no two-character form. Both were wrong. It is accepted now with a note that a field is accurate to about 1000km - the same treatment four characters already had. That also uncovered a latent crash: the square-pair check read index 2 of a string that may only have two characters. What survived the check: the A-R field range is right, verified by replicating qthToPosition's arithmetic - SS12AA decodes to 92N 182E, past both the pole and the antimeridian, while RR99 is the last cell inside the world. Wavelog's own Qra.php validates with the same range. The subsquare A-X range and digits in positions 7-8 are also correct. On 10 and 12 character locators the spec says store the first 8 in GRIDSQUARE and the rest in GRIDSQUARE_EXT. Neither WavelogQso nor Wavelog's field list carries GRIDSQUARE_EXT, so the extra pair has nowhere to go; the field clips at 8, which produces the spec-correct GRIDSQUARE value. Recorded in a comment rather than pretended to be deliberate. 17 tests now, including the four non-ASCII digit families and the two-character boundary.
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.





