SatNOGS Satellite Ground Station Client

This lab explores the configuration, operation, and data collection workflows of an automated satellite ground station client using the open-source SatNOGS platform. Students deploy and configure a Linux-based Python client daemon that interfaces with software-defined radios and antenna rotators to automate satellite pass scheduling, radio frequency signal capture, Doppler frequency shift correction, and signal demodulation. Working with live downlinks from CubeSats, weather satellites, and amateur radio spacecraft, learners observe orbital pass dynamics, generate waterfall spectrograms, and record demodulated observation data. Through this practical experience, students gain foundational skills in aerospace communications, SGP4 orbital tracking algorithms, software-defined radio data acquisition, and distributed ground station network operations.

satellite communications software-defined radio SDR ground station SatNOGS CubeSat Doppler correction Doppler shift orbital tracking SGP4 amateur radio telemetry RF reception radio frequency signal demodulation weather satellites aerospace engineering pass prediction

Uploaded by demo on 2026-09-03 · ready · Electronics · Original source ↗

Files: pyproject.toml · requirements.txt · satnogs_client_README.md · setup.cfg

Readiness checks

  • complete 2026-09-03 03:49 🛡 Cybersecurity: Review before networking · 8 findings 2 searches · 12 pages
    view · PDF

Latest report — 2026-09-03 03:49

Readiness: SatNOGS Satellite Ground Station Client

Verdict: Ready · 2026-09-02 · est. parts cost: none — software-only upload, no bill of materials Cybersecurity — software & network: Review before networking

This is the cold check for this lab: no previous readiness report exists, so this report establishes the baseline that future checks measure drift against. The verdict is about sourcing, and this upload has nothing to source. The snapshot records no bill of materials, no schematics or board files, and nothing to fabricate — it is the satnogs-client software package: packaging files, metadata and Python manifests. With no part numbers, no quantities and no purchase path, there is nothing that can go obsolete, out of stock or overpriced between now and the next check. The external resources the lab genuinely depends on to be usable were confirmed reachable this run: the GitLab source repository (30 entries listed on branch master, seven project files fetched from it) and the documentation site both responded. One caveat is outside the instructor's control: the community forum carried a maintenance banner at check time announcing intermittent availability of SatNOGS Network, the service this client pulls its observation jobs from.

Action required

None — this lab has no bill of materials, so there are no parts to source.

Cybersecurity — software & network

Review before networking — Eight findings on a network-connected client, including known flaws in the HTTP stack behind every SatNOGS API call and a base operating system past its standard end-of-life, with three of the five library issues blocked from a straightforward upgrade by the project's own version pins.

Component Version How known Support status
satnogs-client (the lab's application) not determined not determined (the package version is generated at build time by versioneer from git metadata; no release is pinned in any fetched file) —
Debian (base OS of the reference container) 12 read from project (base image debian:bookworm-slim pinned as ARG DEBIAN_IMAGE_TAG in fetched/08-Dockerfile (docker-gnuradio); the same file adds the SatNOGS apt repository for Debian_12) extended/LTS support only until 2028-06-30
Python interpreter 3.11 inferred (setup.cfg declares a lower bound, python_requires = >=3.11, and a Programming Language :: Python :: 3.11 classifier - a floor, not an exact pin) supported until 2027-10-31
GNU Radio (SDR framework, container base image) 3.10.5.1-satnogs read from project (ARG GNURADIO_IMAGE_TAG=3.10.5.1-satnogs in fetched/06-Dockerfile) —
urllib3 1.26.20 read from project (pinned in fetched/01-requirements.txt and fetched/03-constraints.txt) —
requests 2.28.2 read from project (pinned in fetched/01-requirements.txt and fetched/03-constraints.txt) —
sentry-sdk 1.9.10 read from project (pinned in fetched/01-requirements.txt and fetched/03-constraints.txt) —
pillow 12.2.0 read from project (pinned in fetched/01-requirements.txt and fetched/03-constraints.txt) —
python-dotenv 0.21.1 read from project (pinned in fetched/01-requirements.txt and fetched/03-constraints.txt) —
APScheduler 3.9.1.post1 read from project (pinned in fetched/01-requirements.txt) —
numpy 1.26.4 read from project (pinned in fetched/01-requirements.txt) —
matplotlib 3.8.4 read from project (pinned in fetched/01-requirements.txt) —
h5py 3.13.0 read from project (pinned in fetched/01-requirements.txt) —
skyfield 1.54 read from project (pinned in fetched/01-requirements.txt) —
sgp4 2.25 read from project (pinned in fetched/01-requirements.txt) —
satnogs-predict 0.6 read from project (pinned in fetched/01-requirements.txt) —
versioneer 0.28 read from project (pinned in fetched/04-pyproject.toml build-system requires and in fetched/01-requirements.txt) —
setuptools (build system) not determined unpinned (fetched/04-pyproject.toml requires setuptools>=40.8.0 - a lower bound only, so the build takes whatever is current) —
wheel (build system) not determined unpinned (fetched/04-pyproject.toml requires wheel with no version constraint at all) —
Debian system packages (packages.debian) not determined unpinned (fetched/07-packages.debian lists 9 apt packages with no versions; the installed versions are whatever the Debian 12 archive serves at build time) —
Component Finding Severity Fix available?
pillow The image library used to render observation waterfalls carries 13 known advisories at the pinned version 12.2.0, several of them memory-corruption bugs reachable by processing a malformed image, the most severe scoring 8.2. — GHSA-xj96-63gp-2gmr, GHSA-jjj6-mw9f-p565, GHSA-6r8x-57c9-28j4, GHSA-9hw9-ch79-4vh6 (+2 more) high Yes - update to 12.3.0, which fixes all of them; nothing in setup.cfg constrains Pillow (it arrives through matplotlib), so this needs only a regenerated requirements.txt and constraints.txt.
sentry-sdk The crash-reporting client that sends error telemetry off the ground station to a remote service can leak sensitive session information when the send-default-PII option is switched on, and exposes environment variables to processes it spawns. — GHSA-29pr-6jr8-q5jm, GHSA-g92j-qhmh-64v2 high No - project pins sentry-sdk ~=1.9.0 in setup.cfg, a compatible-release range that excludes the fixed 1.14.0 and later releases.
urllib3 The HTTP library that carries every call the ground station makes to the SatNOGS network has five known flaws at the pinned version 1.26.20, including decompression-bomb protections being bypassed on redirects and sensitive headers being forwarded to a different origin during proxied redirects. — GHSA-38jv-5279-wg99, GHSA-qccp-gfcp-xxvc, GHSA-2xpw-w6gg-jr37, GHSA-gm62-xv2j-4w53 (+1 more) high Mitigation only - every fixed release is in the urllib3 2.x line while the project pins urllib3==1.26.20 in both requirements.txt and constraints.txt, so clearing these means regenerating both lockfiles onto 2.x, not a drop-in bump.
python-dotenv The configuration loader at the pinned 0.21.1 follows symbolic links when writing a key back to the settings file, which lets a local attacker who can place a symlink cause an arbitrary file to be overwritten. — GHSA-mf9w-mj56-hr94 moderate No - project pins python-dotenv ~=0.21.0 in setup.cfg, which excludes the fixed 1.2.2.
requests The HTTP client the software uses to pull observation jobs and upload results has four known issues at the pinned 2.28.2, including a proxy-credential header leaking on redirect and certificate verification not being reapplied on a reused session. — GHSA-j8r2-6x86-q33q, GHSA-9wx4-h78v-vm56, GHSA-gc5v-m9x4-r6x2, GHSA-9hjg-9r4m-mvj7 moderate No - project pins requests ~=2.28.0 in setup.cfg, a compatible-release range that excludes every fixed version (2.31.0 and later).
Debian (base OS of the reference container) The reference container is built on Debian 12 (Bookworm), which passed the end of its standard support on 2026-07-11 and now receives only Debian LTS security updates, scheduled to end 2028-06-30. posture Mitigation only - make sure the host actually pulls the Debian LTS security updates, and plan the move to Debian 13 well before June 2028 rather than at the deadline.
satnogs-client container image The image creates the client's state directory /var/lib/satnogs-client world-writable (mode 1777), so on a shared ground-station host any other local account can write into the directory that holds observation artifacts and client configuration. posture Mitigation only - if that path is bind-mounted onto a shared host, tighten it to the satnogs-client user (0700 or 0755) rather than leaving it world-writable.
setuptools / wheel (build system) The build configuration pins only versioneer==0.28: setuptools carries a >=40.8.0 lower bound and wheel has no constraint at all, so every rebuild of the client pulls whatever those build tools happen to be that day and the build step has no checkable security state. posture Mitigation only - pin the build-system requirements to exact versions in pyproject.toml, or build only from the checked-in constraints.txt.

What this means for your lab

This software is a client, not a server: it dials out to the SatNOGS network, and nothing in the project files opens a listening port, sets a default password, or exposes an admin page, so someone else on your network has no obvious front door into it. The risk sits in what the client pulls in. The versions the project locks are old enough that five of its libraries carry publicly known flaws, and the ones that matter most are in the very code that fetches and uploads data over the network and in the image library used to draw observation waterfalls. In practice that means a malformed or hostile response from the network could crash an observation or, in the worst reported cases, corrupt memory in the client. Three of the five cannot simply be upgraded, because the project's own version rules pin them to the old line; the image library is the exception and has a clean fix available. The reference container's operating system, Debian 12, also passed its normal end-of-life this July and now gets only long-term security patches. What to do: put the ground station on its own network segment rather than the main campus network, keep it pulling Debian LTS updates, and if you rebuild the client, regenerate its locked requirements so at least the image library moves to the fixed release. Two things worth knowing: the separate developer and test requirements file, which a normal deployment does not install, carries its own known issues, so keep development work off the station machine; and if you install on bare metal or a Raspberry Pi instead of using the container, the project never states which operating system version you should be on, so we could not judge that host's support state at all.

Not checked

  • POSIX Linux host OS for a bare-metal or Raspberry Pi install: the snapshot's target platform is recorded only as 'POSIX Linux, version not stated'; no fetched file names a host OS version for a non-container install, so its support state is unknown. Only the reference Docker image's base OS (Debian 12) could be determined.
  • GNU Radio 3.10.5.1-satnogs: no vulnerability database covers a GNU Radio build distributed as a container image and openSUSE Build Service packages; the version is pinned and known, but there is nothing to check it against
  • SatNOGS apt packages from the openSUSE Build Service repository (home:librespace:satnogs2, Debian_12): installed from an external apt repository at image build time; no versions are pinned in any fetched file, so there is no exact version to check
  • 9 Debian system packages in packages.debian (git, python3-gps, python3-hamlib, libhdf5-hl-100, libhdf5-103-1, libaec0, libsz2, libgfortran5, libopenblas0-pthread): listed with no version constraints; the versions actually installed are whatever the Debian 12 archive serves at build time
  • USRP FPGA images downloaded by uhd_images_downloader at image build time: fetched over the network during the container build with no version or checksum recorded in any fetched file
  • setup.cfg abstract dependency ranges (install_requires and the dev extras): declared as compatible-release ranges (~=) and, for pytz, with no constraint at all, so no exact version could be checked from that file. The concrete versions actually installed come from requirements.txt and constraints.txt, which were fetched and fully checked. Note the automated parse of setup.cfg also counted plain configuration keys (author, classifiers, line_length) as dependencies, which is why its unpinned count reads 60.

Parts

None. The snapshot's "Bill of Materials" section contains no entries: "There are no physical resistors, capacitors, semiconductors, connectors, heatsinks, or hardware sub-assemblies to inventory."

No part is listed as "not checked", because no part exists to check. This is an empty bill of materials, not an unchecked one — if a future re-ingest of this lab produces parts, they are new, not previously missed.

Substitutes

None needed.

Verify any substitute against its datasheet before ordering.

Other dependencies

The snapshot lists six external resources. All the load-bearing ones were fetched this run:

  • Project source repository — gitlab.com/librespacefoundation/satnogs/satnogs-client: live. Listed via the GitLab API, 30 entries on branch master; seven project files were fetched from it successfully. This is the lab's single most important external dependency — it serves the code.
  • Project documentation — docs.satnogs.org/projects/satnogs-client: live, fetched this run. Currently serves the User guide, Developer guide, "Working with Docker" and the module reference.
  • Community Discourse forum — community.libre.space/c/satnogs: live, fetched this run; Hardware and Software support categories both present. Note the page carried an operational banner at fetch time: "Scheduled maintenance to reconfigure Docker service. Intermittent service availability is expected. Affected services: SatNOGS Network, SatNOGS DB, SatNOGS Dashboard." Because the client pulls its observation jobs from SatNOGS Network, confirm that service is up before treating a failed session as a station fault.
  • Organization website — librespacefoundation.org: live, fetched this run.
  • Matrix channel — https://app.element.io/#/room/#satnogs:matrix.org: not checked. A single-page web client whose room state a text fetch cannot observe.
  • IRC channel — https://web.libera.chat/?channels=satnogs: not checked, same reason — a browser-based IRC client rather than a fetchable resource.

Both unchecked entries are community chat conveniences, not materials the lab depends on to run.

Fabrication: none. No Gerber, drill, layer stackup or board dimensional data exists in this upload.

Watch list

  • SatNOGS Network service availability — the client is useless without it, and it was under announced maintenance at check time. The most likely cause of a "broken lab" session in the near term, and not something an instructor can fix locally.
  • The GitLab source repository — the lab's only code source. A rename, archive or move of this project would break the lab outright; it is the first thing to re-confirm at the next check.
  • The documentation site — docs.satnogs.org is a separate host from the repository and can drift independently; the lab's setup instructions live there.
  • A future re-ingest producing a hardware BOM — this upload is the client software only, but a real ground station needs an SDR, antenna and rotator. If the lab materials are ever re-uploaded with that hardware included, the next check will be sourcing parts from a cold start with no price baseline.
Snapshot What the lab depended on when it was uploaded — the baseline the readiness checks research against.

The SatNOGS Satellite Ground Station Client (satnogs-client) is an open-source Python daemon developed by the Libre Space Foundation to automate satellite signal reception, Doppler correction, demodulation, and data observation for CubeSats, amateur radio satellites, and weather satellites as part of the satnogs.org network. The software runs on a generic POSIX Linux host platform (such as a Raspberry Pi, embedded compute module, or x86 server) interfacing with peripheral software-defined radios (SDRs) and antenna rotators. No custom printed circuit boards, electronic component designs, schematics, or CAD files are included in this upload. Consequently, no specific operating voltage rails or board-level power constraints are defined in the repository source files.

Bill of Materials

No circuit board files, schematics, wiring diagrams, or physical electronics component lists exist in this upload. The package consists entirely of software packaging files, metadata, and Python manifests. There are no physical resistors, capacitors, semiconductors, connectors, heatsinks, or hardware sub-assemblies to inventory.

Software and network dependencies

The application relies on a POSIX Linux host environment running Python 3.11 or higher, build-system utilities declared under PEP 518, core runtime libraries, and development/testing dependencies.

Operating System and Platform:

  • POSIX Linux: Target operating system environment declared under Trove classifiers in setup.cfg (Operating System :: POSIX :: Linux). Version: not stated. Check plan: support-status lookup: Linux POSIX
  • Python Interpreter: Runtime runtime engine specified in setup.cfg (python_requires = >=3.11) and classified as Programming Language :: Python :: 3.11. Version: >=3.11 (lower-bound pinned in setup.cfg). Check plan: support-status lookup: Python 3.11

Build System Dependencies (Manifest: pyproject.toml):

  • setuptools: Build backend packaging tool specified in pyproject.toml. Version: >=40.8.0. Where the version came from: pinned in pyproject.toml (lower bound). Versions are not pinned to an exact release. Check plan: not checkable: unpinned version (minimum bound >=40.8.0)
  • wheel: Build utility specified in pyproject.toml. Version: unpinned. Where the version came from: not stated. The dependency is completely unpinned. Check plan: not checkable: unpinned version
  • versioneer: Git-based versioning tool specified in pyproject.toml. Version: 0.28. Where the version came from: pinned in pyproject.toml. Check plan: vulnerability lookup: versioneer / PyPI / 0.28

Locked Runtime Dependencies (Manifest: requirements.txt): The concrete production environment is fully locked in requirements.txt (generated from setup.cfg via refresh-requirements-docker.sh):

  • APScheduler: Advanced Python Scheduler library. Version: 3.9.1.post1. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: APScheduler / PyPI / 3.9.1.post1
  • certifi: Mozilla CA bundle for Python. Version: 2026.5.20. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: certifi / PyPI / 2026.5.20
  • charset-normalizer: Character encoding detector. Version: 3.4.7. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: charset-normalizer / PyPI / 3.4.7
  • contourpy: Contour plotting library. Version: 1.2.1. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: contourpy / PyPI / 1.2.1
  • cycler: Composable cycle engine for matplotlib. Version: 0.12.1. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: cycler / PyPI / 0.12.1
  • decorator: Decorator tool library. Version: 5.3.1. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: decorator / PyPI / 5.3.1
  • fonttools: Font manipulation library. Version: 4.63.0. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: fonttools / PyPI / 4.63.0
  • h5py: HDF5 binary data format interface. Version: 3.13.0. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: h5py / PyPI / 3.13.0
  • idna: Internationalized Domain Names in Applications support. Version: 3.18. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: idna / PyPI / 3.18
  • jplephem: JPL ephemerides calculation engine. Version: 2.24. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: jplephem / PyPI / 2.24
  • kiwisolver: Fast implementation of the Cassowary constraint-solving algorithm. Version: 1.4.9. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: kiwisolver / PyPI / 1.4.9
  • matplotlib: 2D plotting library. Version: 3.8.4. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: matplotlib / PyPI / 3.8.4
  • numpy: Array computing library. Version: 1.26.4. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: numpy / PyPI / 1.26.4
  • packaging: Core utilities for Python packages. Version: 26.2. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: packaging / PyPI / 26.2
  • pillow: Python Imaging Library. Version: 12.2.0. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: pillow / PyPI / 12.2.0
  • pyparsing: Python parsing grammar library. Version: 3.3.2. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: pyparsing / PyPI / 3.3.2
  • python-dateutil: Extensions to standard Python datetime. Version: 2.8.2. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: python-dateutil / PyPI / 2.8.2
  • python-dotenv: Environment variable loading from .env files. Version: 0.21.1. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: python-dotenv / PyPI / 0.21.1
  • pytz: World timezone definitions. Version: 2026.2. Where the version came from: pinned in requirements.txt (note: unpinned in setup.cfg install_requires). Check plan: vulnerability lookup: pytz / PyPI / 2026.2
  • requests: HTTP client library. Version: 2.28.2. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: requests / PyPI / 2.28.2
  • satnogs-predict: Satellite orbital pass prediction module. Version: 0.6. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: satnogs-predict / PyPI / 0.6
  • sentry-sdk: Crash reporting and error telemetry client. Version: 1.9.10. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: sentry-sdk / PyPI / 1.9.10
  • sgp4: Simplified General Perturbations satellite tracking algorithm. Version: 2.25. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: sgp4 / PyPI / 2.25
  • six: Python 2 and 3 compatibility utilities. Version: 1.17.0. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: six / PyPI / 1.17.0
  • skyfield: High precision astronomy and satellite tracking library. Version: 1.54. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: skyfield / PyPI / 1.54
  • tzlocal: Timezone information for the local machine. Version: 5.3.1. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: tzlocal / PyPI / 5.3.1
  • urllib3: HTTP client service for Python. Version: 1.26.20. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: urllib3 / PyPI / 1.26.20
  • validators: Data validation library. Version: 0.20.0. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: validators / PyPI / 0.20.0
  • versioneer: Version manager extracted at runtime. Version: 0.28. Where the version came from: pinned in requirements.txt. Check plan: vulnerability lookup: versioneer / PyPI / 0.28

Abstract Runtime Dependencies (Manifest: setup.cfg install_requires): Declared with compatible release ranges (~=) or bare names:

  • APScheduler ~= 3.9.0
  • python-dotenv ~= 0.21.0
  • requests ~= 2.28.0
  • validators ~= 0.20.0
  • python-dateutil ~= 2.8.0
  • satnogs-predict ~= 0.0
  • pytz (completely unpinned in setup.cfg)
  • numpy ~= 1.26.0
  • h5py ~= 3.13.0
  • matplotlib ~= 3.8.0
  • sentry-sdk ~= 1.9.0
  • versioneer ~= 0.28.0

Development and Testing Dependencies (Manifest: setup.cfg options.extras_require: dev): Declared with compatible release ranges (~=):

  • build ~= 0.10.0: PEP 517 build tool. Where the version came from: pinned in setup.cfg. Check plan: not checkable: compatible release range ~=0.10.0
  • flake8-quotes ~= 3.3.0: Linting plugin. Where the version came from: pinned in setup.cfg. Check plan: not checkable: compatible release range ~=3.3.0
  • flake8 ~= 4.0.0: Style guide enforcement. Where the version came from: pinned in setup.cfg. Check plan: not checkable: compatible release range ~=4.0.0
  • isort ~= 5.10.0: Import sorter. Where the version came from: pinned in setup.cfg. Check plan: not checkable: compatible release range ~=5.10.0
  • pylint ~= 3.3.6: Static code analyzer. Where the version came from: pinned in setup.cfg. Check plan: not checkable: compatible release range ~=3.3.6
  • pytest ~= 7.1.0: Testing framework. Where the version came from: pinned in setup.cfg. Check plan: not checkable: compatible release range ~=7.1.0
  • pytest-xdist ~= 3.3.0: Distributed testing plugin. Where the version came from: pinned in setup.cfg. Check plan: not checkable: compatible release range ~=3.3.0
  • pytest-forked ~= 1.6.0: Isolated process test runner. Where the version came from: pinned in setup.cfg. Check plan: not checkable: compatible release range ~=1.6.0
  • robotframework-httpctrl ~= 0.3.0: Robot Framework HTTP testing library. Where the version came from: pinned in setup.cfg. Check plan: not checkable: compatible release range ~=0.3.0
  • robotframework-tidy ~= 2.6.0: Robot Framework code formatter. Where the version came from: pinned in setup.cfg. Check plan: not checkable: compatible release range ~=2.6.0
  • robotframework ~= 5.0.0: Acceptance test framework. Where the version came from: pinned in setup.cfg. Check plan: not checkable: compatible release range ~=5.0.0
  • sphinx_rtd_theme ~= 1.2.0: Documentation theme. Where the version came from: pinned in setup.cfg. Check plan: not checkable: compatible release range ~=1.2.0
  • tox ~= 4.5.0: Environment orchestrator. Where the version came from: pinned in setup.cfg. Check plan: not checkable: compatible release range ~=4.5.0
  • twine ~= 6.1.0: Package publishing utility. Where the version came from: pinned in setup.cfg. Check plan: not checkable: compatible release range ~=6.1.0
  • yapf ~= 0.40.0: Code formatter. Where the version came from: pinned in setup.cfg. Check plan: not checkable: compatible release range ~=0.40.0

Unpinned Dependencies Summary:

  • setup.cfg lines 21-32 specify abstract compatible ranges (~=) rather than strict equality pins, and leaves pytz completely unpinned.
  • pyproject.toml specifies wheel with no version constraint and setuptools with only a lower bound (>=40.8.0).
  • setup.cfg dev extras specify compatible release ranges (~=) rather than strict pins.

Network Exposure:

  • Network Role: satnogs_client_README.md states this package "automates the reception of signals from satellites... for the satnogs.org network". It behaves primarily as an outbound network client communicating with the SatNOGS Network API using requests, and sends telemetry/error reports using sentry-sdk.
  • Listening Ports: Not stated in the sources. The repository files do not specify any open inbound TCP/UDP ports or daemon socket bindings.
  • Default Credentials: Not stated in the sources. No default usernames, passwords, API tokens, or keys are declared in the uploaded files.
  • Remote Access / Management: Not stated in the sources. The uploaded manifests do not configure SSH, telnet, or a local administrative web server.

Downloads, URLs, and External Resources

Fabrication

No printed circuit boards, mechanical housings, or physical substrates are associated with this upload. No Gerber, drill, layer stackup, or board dimensional data exists.