Repository navigation
FoxSDR 0.99.78: an aircraft at the edge of range no longer blinks off the ADS-B map between its bursts - with ADS-B plugin 1.9.1 or newer its position is carried forward along its last course and speed for up to 180 s after the last fix, drawn with a thin ring and listed with the word "estimated" beside its id, and the plugin itself no longer lists aircraft invented by noise and places cruise-altitude aircraft from one frame once it knows how far the station reaches. On Linux, a start-up death at the window now says how the process ended and which window system it was using, the log carries the window library's own error text and the graphics driver's name, and FOXSDR_WINDOW_PLATFORM=x11 or wayland makes FoxSDR use that window system instead of the window library's own choice.
Still not fixed, and not a fault in FoxSDR: an aircraft the receiver does not hear cannot be shown. The measurements behind this release (five minutes of recorded sky on a B200 with an unfiltered 1090 MHz antenna) found the decoder hearing 6 of the 23 aircraft an aggregator placed within 100 nautical miles, and the 17 it never heard produced no decodable signal at all; a 1090 MHz filter and amplifier at the antenna is the remedy, not a setting. The Microsoft Store copy stays at 0.99.77 until the next submission is certified.
SHA-256 of foxsdr-setup-0.99.78.exe:
1973cb97a28d75a3dcab52f5d2ae8df3e5e26659383b6e85b8f6059fdddc75e2
SHA-256 of FoxSDR-0.99.78-x86_64.AppImage:
1b5c36c0994b360a1cd392751ea1fc805def416f0c44e1cb0642d40906cfbe51
SHA-256 of foxsdr-0.99.78-linux-x64.tar.gz:
d68e51c1d2d2e59491b74d8a44d795c0d41ef7408b2a903361c4c9c2f7ecc575
SHA-256 of FoxSDR-0.99.78-aarch64.AppImage:
f285026ac9a01b6a3a7ddaebdef12b77f758ebd7f866d62ed00bbd069bac5d2a
SHA-256 of foxsdr-0.99.78-linux-arm64.tar.gz:
c463a0e722a37cd36bd86a2e281f9f910bec9736083563cbc7a613ec36bfc8fd
Features and fixes, 2026-10-14
An aircraft at the edge of range no longer blinks off the map between its bursts: with ADS-B plugin 1.9.1 or newer, its position is carried forward along its last course and speed for up to 180 s after the last fix, drawn with a thin ring and listed with the word "estimated" beside its id. On 2026-10-13 a 31,000 ft airliner 42 nm from the owner's B200 vanished from the map while still airborne: its frames arrived tens of seconds apart and the map drops an aircraft 60 s after its last fix. Two new plugin-ABI definitions carry the change: CASCADE_TRACK_FLAG_ESTIMATED on a track whose coordinates the source carried forward (its ageMs is still the age of the real fix), and CASCADE_STATE_HOLDS_ESTIMATED_TRACKS, set in every receiver state this host fills, which tells a plugin it may publish such positions - an older host never sees one. A flagged aircraft fades from 30 s as before and is dropped at 180 s (kTrackDropMsAircraftEstimated); every other kind of track, and an unflagged aircraft, is unchanged, and the target counts still count what is drawn. The details block says "estimated from the last fix" under the coordinates. The single visibility rule now takes the track's flags (trackPresentation(const CascadeTrack&)), and every caller that draws, lists or counts a track uses that form.
On Linux, a start-up death at the window now says how the process ended and which window system it was using, the log carries the window library's own error text and the graphics driver's name, and FOXSDR_WINDOW_PLATFORM=x11 or wayland makes FoxSDR use that window system instead of the window library's own choice. A Linux user on 0.99.75 (Ubuntu 24.04, the AppImage in extract-and-run mode, a fresh install) sent report A0E0967441A8E6B4: audio opened, no plugins were found, and FoxSDR ended in the phase "creating the window" with no seconds of silence. The report could not say whether that was a signal, an abort or an exit - its reason ended "exit status not available on this platform" and its code was unknown - nor which window system was chosen, because the window library's error text went to standard error, which an AppImage does not keep. The watcher on Linux is FoxSDR's child and the kernel gives a process's exit status to its parent only, so it cannot ask; FoxSDR now writes down how it is ending itself, into the 64-byte page of numbers the watcher already reads - the status of an exit (or a return from main), the number of a fault signal (from the crash handler), and the number of SIGHUP, SIGINT, SIGQUIT, SIGTERM or SIGPIPE (a small handler that records it and lets the signal end the program exactly as before). The report then says exit code 1 (the process ended itself) or killed by signal 11 (SIGSEGV), with the number in code behind a fixed tag (0x50580101 is an exit with status 1, 0x5058020B signal 11), and the previous-session line in the log classifies it the same way (a program ending itself or faulting "died", a signal somebody sent "killed"). What cannot be known is an ending by SIGKILL (the out-of-memory killer, kill -9): a process cannot write down its own SIGKILL, and for that the report keeps its old words and now names the two sources it asked: exit status not available on this platform (no exit record; not its parent). The start of the window is also in the log now, one flushed line per step, each beginning window:: which window systems this build supports, whether DISPLAY and WAYLAND_DISPLAY are set (never their values - an SSH-forwarded DISPLAY names a computer, and GLFW's "Failed to open display " has the name taken out), the session type, the window system chosen, the window library's error messages, the graphics driver's vendor, renderer and version, and the moment the window is shown; the failures of glfwInit and glfwCreateWindow, which went only to standard error, are in it too. If FoxSDR ends before its window appears on Linux, run it with FOXSDR_WINDOW_PLATFORM=x11 (or wayland) in front of the command and send the log lines that begin window:; any, the default, leaves the choice to the window library, and a value that names nothing, or a system this build does not have, is noted in the log and ignored.
Checked on Windows: all 319 headless tests pass, as do the real-program tests of the sentinel, the previous-exit classifier, health, slow frames and the new window test (the other real-program tests were not run), test_sentinel now holds 2,708,380 checks (2,705,308 of them ran red against stubs first: 145 failed, among them the report of an exit with status 1 in the phase "creating the window" saying "not available on this platform"), the new window test holds 184 and the real-program one 29 (a default run, =bad, =any, x11 and wayland refused on Windows, in order before the first frame, DISPLAY not in the log). Each new behaviour was removed once and its test went red (16 removals, listed in the commit message). Not verified: any of the Linux side has run on Linux. The Linux files (exit_record.cpp, crash_handler_posix.cpp, sentinel_host_posix.cpp, and the Linux half of tests/test_sentinel_proc.cpp with its three new scenarios) pass GCC 16.1 -fsyntax-only -Wall -Wextra against stand-in declarations of the Linux calls, which checks syntax and types as declared by those stand-ins, not that glibc and the kernel behave as assumed. Whether forcing x11 or wayland cures the field report is not known - its cause is not. An exit with a status while the window is drawing is filed as a crash and sent, as Windows' exit code 0 before the shutdown finished already was; a kernel 6.15 or newer can give the exit code of a process that is not one's child through a pidfd, which is not used (the reporting machine runs 6.8 and it could not be tried here).