Merge branch 'master' into maint-3.9

.github/workflows/build-ubuntu.yml

@@ -0,0 +1,16 @@
+name: build-ubuntu
+
+# Controls when the action will run.
+on:
+  push:
+  pull_request:
+  workflow_dispatch:
+
+jobs:
+  build-ubuntu:
+    runs-on: ubuntu-latest
+
+    steps:
+      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
+      - uses: actions/checkout@v2
+      - uses: daniestevez/gr-satellites-ci-action@v1.2.1

CHANGELOG.md

@@ -6,6 +6,25 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## Unreleased
 
+## [4.4.0], [3.11.0] - 2021-11-03
+
+### Added
+- Support for BINAR-1
+- Support for CUAVA-1
+- Support for CUTE
+- CCSDS Uncoded Deframer block
+
+### Changed
+- Default output path for file receiver changed to current directory
+- Added 9k6 mode to BEESAT-1
+
+### Fixed
+- CSP header parsing in AAUSAT-4 and BY70-1 telemetry parsers
+- YUSAT deframer
+
+### Removed
+- Deleted unused test_satellites.cc test code
+
 ## [4.3.1], [3.10.1] - 2021-09-11
 
 ### Changed
@@ -417,13 +436,17 @@ Large refactor release bringing new functionality and improvements. This is an o
 ## [1.0.0] - 2018-08-02
 First gr-satellites release using semantic versioning
 
-[Unreleased]: https://github.com/daniestevez/gr-satellites/compare/v4.3.0...master
+[Unreleased]: https://github.com/daniestevez/gr-satellites/compare/v4.4.0...master
+[4.4.0]: https://github.com/daniestevez/gr-satellites/compare/v4.3.1...v4.4.0
+[4.3.1]: https://github.com/daniestevez/gr-satellites/compare/v4.3.0...v4.3.1
 [4.3.0]: https://github.com/daniestevez/gr-satellites/compare/v4.2.0...v4.3.0
 [4.2.0]: https://github.com/daniestevez/gr-satellites/compare/v4.1.0...v4.2.0
 [4.1.0]: https://github.com/daniestevez/gr-satellites/compare/v4.0.0...v4.1.0
 [4.0.0]: https://github.com/daniestevez/gr-satellites/compare/v4.0.0-rc1...v4.0.0
 [4.0.0-rc1]: https://github.com/daniestevez/gr-satellites/compare/v3.7.0...v4.0.0-rc1
-[3.9.0]: https://github.com/daniestevez/gr-satellites/compare/v3.9.0...v3.10.0
+[3.11.1]: https://github.com/daniestevez/gr-satellites/compare/v3.11.0...v3.11.1
+[3.11.0]: https://github.com/daniestevez/gr-satellites/compare/v3.10.0...v3.11.0
+[3.10.0]: https://github.com/daniestevez/gr-satellites/compare/v3.9.0...v3.10.0
 [3.9.0]: https://github.com/daniestevez/gr-satellites/compare/v3.8.0...v3.9.0
 [3.8.0]: https://github.com/daniestevez/gr-satellites/compare/v3.7.0...v3.8.0
 [3.7.0]: https://github.com/daniestevez/gr-satellites/compare/v3.6.0...v3.7.0

CMakeLists.txt

@@ -43,8 +43,9 @@ list(INSERT CMAKE_MODULE_PATH 0 ${CMAKE_SOURCE_DIR}/cmake/Modules)
 
 # Set the version information here
 set(VERSION_MAJOR 4)
-set(VERSION_API 3)
-set(VERSION_ABI 1)
+set(VERSION_API 4)
+set(VERSION_ABI 0)
+set(VERSION_PATCH 0)
 
 cmake_policy(SET CMP0011 NEW)
 

CODE_OF_CONDUCT.md

@@ -0,0 +1,142 @@
+# gr-satellites Code of Conduct
+
+As a GNU Radio out-of-tree module and a project which is part of the GNU Radio
+community understood in a wide sense, gr-satellites follows the same code of
+conduct as GNU Radio. This is a copy of the Code of Conduct. It might be out of
+date. The latest version can be found [on the gnuradio/gr-governance
+repository](https://github.com/gnuradio/gr-governance/blob/main/CODE_OF_CONDUCT.md).
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, caste, color, religion, or sexual identity
+and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the
+  overall community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or
+  advances of any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email
+  address, without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting Daniel Estevez at daniel@destevez.net (who is the
+gr-satellite main developer) or the GNU Radio project Code of Conduct team at
+conduct@gnuradio.org (only if applicable; gr-satellites is related to the GNU
+Radio project and community, but formally not part of the GNU Radio project and
+governance).  All complaints will be reviewed and investigated promptly and
+fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series
+of actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or
+permanent ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior,  harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within
+the community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.0, available at
+[https://www.contributor-covenant.org/version/2/0/code_of_conduct.html][v2.0].
+
+Community Impact Guidelines were inspired by 
+[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
+
+For answers to common questions about this code of conduct, see the FAQ at
+[https://www.contributor-covenant.org/faq][FAQ]. Translations are available 
+at [https://www.contributor-covenant.org/translations][translations].
+
+[homepage]: https://www.contributor-covenant.org
+[v2.0]: https://www.contributor-covenant.org/version/2/0/code_of_conduct.html
+[Mozilla CoC]: https://github.com/mozilla/diversity
+[FAQ]: https://www.contributor-covenant.org/faq
+[translations]: https://www.contributor-covenant.org/translations
+

CONTRIBUTING.md

@@ -0,0 +1,70 @@
+# Contributing to gr-satellites
+
+These guidelines are based on the [contributing guidelines for GNU
+Radio](https://github.com/gnuradio/gnuradio/blob/master/CONTRIBUTING.md). Since
+gr-satellites is a GNU Radio out-of-tree module, we follow the same guidelines
+for consistency wherever it makes sense: coding style, code of conduct, etc.
+
+## Coding Guidelines
+
+gr-satellites follows the same coding guidelines as GNU Radio. These are
+described in [GREP1][grep1].
+
+For C++, clang-format is used. Formatting is checked in the CI pipeline and
+can also be checked locally with the `tools/clang_format.py` helper script.
+
+For Python, we follow PEP8. In contrast to GNU Radio, which doesn't use a Python
+formatting checker, since a large amount of the gr-satellites code base is
+Python, we use pycodestyle to check PEP8 formatting. This is part of the
+CI pipeline and can be checked locally by running pycodestyle. Note that there
+are some [folders that are excluded]
+(https://github.com/daniestevez/gr-satellites-pycodestyle-action/blob/master/Dockerfile)
+from pycodestyle checking.
+
+## Python or C++?
+
+While GNU Radio has most of its code base written in C++, gr-satellites has the
+majority of its code base written in Python. This allows for a faster
+development, and performance is often not so critical, since small satellites
+typically transmit using low data rates. In particular, telemetry parsing is
+always written in Python using [construct](https://construct.readthedocs.io/).
+
+However, some kinds of blocks are equally simple to implement in C++ or in
+Python, so C++ should be preferred for those.
+
+## Git commit messages are very important
+
+The same guidelines as for GNU Radio apply regarding commit messages:
+- Keep the lines below 72 characters
+- Avoid empty git commit messages
+- The git commit message explains the change, the code only explains the current
+  state
+
+## Include Unit Tests
+
+If you have an obvious test, that might speed up the time it takes to convince
+reviewers that your code is correct.
+
+## Adding support for a new satellite
+
+Adding support for a new satellite can be as easy as writing a [SatYAML
+file](https://gr-satellites.readthedocs.io/en/latest/satyaml.html) describing
+the satellite if the satellite only uses protocols already supported by
+gr-satellites. Since most satellites use a custom telemetry format, a new telemetry
+parser should be written using
+[construct](https://construct.readthedocs.io/). See the
+[python/telemetry](https://github.com/daniestevez/gr-satellites/tree/master/python/telemetry)
+folder for some examples, and take note that your new parser should be added
+both to `python/telemetry/__index__.py` and to
+`python/telemetry/CMakeLists.txt`.
+
+For satellites using new or ad-hoc custom protocols, some
+[components](https://gr-satellites.readthedocs.io/en/latest/components.html)
+will need to be written to support them. Most likely, a new deframer will need
+to be written. Examples can be found in
+[python/components/deframers](https://github.com/daniestevez/gr-satellites/tree/master/python/components/deframers).
+
+See also the [note to satellite teams] planning to use gr-satellites for their
+mission.
+
+[grep1]: https://github.com/gnuradio/greps/blob/master/grep-0001-coding-guidelines.md

README.md

@@ -85,8 +85,11 @@ how to build and install gr-satellites are given in the
 
 Support for gr-satellites is handled only through
 [Github issues](https://github.com/daniestevez/gr-satellites/issues)
+and [Github discussions](https://github.com/daniestevez/gr-satellites/discussions)
 so that the whole community can benefit, rather than through private
 channels such as email. Please understand this when asking for support.
+Take a look [here](https://github.com/daniestevez/gr-satellites/discussions/304) to
+check whether a new topic fits better in the issues page or in the discussions page.
 
 ## Satellite teams
 

debian/changelog

@@ -1,3 +1,9 @@
+gr-satellites (3.11.0-0) hirsute; urgency=medium
+
+  * Mainstream release v3.11.0
+
+ --  <daniel@destevez.net>  Sat, 03 Nov 2021 18:40:00 +0000
+
 gr-satellites (3.10.1-0) hirsute; urgency=medium
 
   * Mainstream release v3.10.1

docs/source/components.rst

@@ -380,16 +380,21 @@ Reed-Solomon codeword and is used by SMOG-P and ATL-1.
 CCSDS deframers
 """""""""""""""
 
-The CCSDS Concatenated deframer and CCSDS Reed-Solomon deframer blocks implement
-some of the CCSDS protocols defined in the TM Synchronization and Channel Coding
-Blue Book (see the `CCSDS Blue Books`_).
+The CCSDS Uncoded deframer, CCSDS Concatenated deframer, and CCSDS Reed-Solomon
+deframer blocks implement some of the CCSDS protocols defined in the TM
+Synchronization and Channel Coding Blue Book (see the `CCSDS Blue Books`_).
+
+The CCSDS Uncoded deframer implements uncoded TM frames.
 
 The CCSDS Reed-Solomon deframer implements Reed-Solomon TM frames, which use a
 Reed-Solmon (255, 223) code (or a shortened version of this code) and the CCSDS
-synchronous scrambler. There is support for several interleave Reed-Solomon codewords.
-The CCSDS Concatenated deframer implements
-concatenated TM frames, which add an r=1/2, k=7 convolutional code as an inner
-coding to the Reed-Solomon frames. The usage of both deframers is very similar.
+synchronous scrambler. There is support for several interleave Reed-Solomon
+codewords.
+
+The CCSDS Concatenated deframer implements concatenated TM frames, which add an
+r=1/2, k=7 convolutional code as an inner coding to the Reed-Solomon frames.
+
+The usage of all three of these deframers is very similar.
 
 The figure below shows an example flowgraph of the CCSDS Concatenated deframer
 block. This example can be found in

docs/source/conf.py

@@ -26,7 +26,7 @@
 # The short X.Y version
 version = ''
 # The full version, including alpha/beta/rc tags
-release = '4.3.1'
+release = '4.4.0'
 
 
 # -- General configuration ---------------------------------------------------

docs/source/satyaml.rst

@@ -136,6 +136,8 @@ The framings allowed in the ``framing`` field are the following:
 * ``AO-40 FEC CRC-16-ARC short``, AO-40 FEC protocol with short frames and a
   CRC-16 ARC, as used by SMOG-1
 
+* ``CCSDS Uncoded``, uncoded CCSDS codeworks (see :ref:`CCSDS deframers`)
+
 * ``CCSDS Reed-Solomon``, CCSDS Reed-Solomon TM codewords (see :ref:`CCSDS deframers`)
 
 * ``CCSDS Concatenated``, CCSDS Concatenated TM codewords (see :ref:`CCSDS deframers`)
@@ -239,6 +241,8 @@ The framings allowed in the ``framing`` field are the following:
   with custom synchronization and a PLS based on DVB-S2.
 
 * ``DIY-1``, the custom framing used by DIY-1, which uses an RFM22 chip transceiver.
+
+* ``BINAR-1``, the custom framing used by the BINAR-1 satellite.
 
 Some framings, such as the CCSDS protocols need the additional field
 ``frame size`` to indicate the frame size.