Home

(work in progress...)

Mission and expectations

This software project is committed to Open Source that is you as a visitor, collaborator, simple user... will always be guaranteed access to the source code. You may fork this repository, change the code, take bits to use in another project or just run it. It is important to realize that source code is THE value of this software. Artifacts are considered as accessory. This is NOT free software as in free lunch and when you run it a collaborative attitude is expected.

This software is provided in the hope it will be useful. Its main goal is to provide a Software Defined Radio platform that is committed to:

• be efficient: code should be written to be conservative on CPU resources it is not because the CPU power of machines constantly increase that this power should be wasted
• have fast paced instrumental graphics. Thanks to OpenGL spectrum, signal graphics and images can be rendered responsively
• give power to the user by letting him/her control all aspects of the DSP processing chain. But as you know with greater power comes greater responsibility therefore it is expected that you already have some experience with SDR applications and digital signal processing in general
• be an experimental platform for amateur radio or anyone interested in matters related to electromagnetism or communication based on electromagnetic waves. It is in no way intended for production moreover mission critical usage.

Guidelines to report issues

As the principal author, owner and maintainer of this software I spend a good part of my free time working on this software, and I do it (mostly) for fun and learning new things. The principal contributors have the same motivation I think. One thing that I can tell you is no fun, is losing time hunting bugs that I cannot reproduce. I have more fun in developing new things, improving existing things or fixing defective things I can fix. And fun is the fuel to keep this project going.

Therefore I ask you (as a User or Collaborator) to take the role of first level support. It means you have to help me and not the opposite: you have to help me understand the problem or what you think is a problem. Hence I would like to enforce the following guidelines.

Reporting compilation issues

Compilation instructions are given in a particular reference context: Ubuntu 22.04 with prerequisites installed. It is very unlikely that problems occurring in this context will reach the master branch. However as this is source code I (as the Maintainer) cannot prevent you (as the User or Collaborator) from trying to compile it in a different context. However in this case you must show evidence that something is wrong in the code. Throwing out the compiler output is clearly not sufficient.

Reporting run time issues

A SDR application is complex having close interaction with hardware devices most often connected via USB and running in real time. Many things can happen that are related to your environment and the purpose is to extract what is relevant to the software itself. You may also consider an issue what is just a limitation. You must describe the conditions and scenario that leads to what you consider an issue the best possible so it can be reproduced in the Maintainer's reference environment.

Reference environments

This corresponds to the reference development environment and environments for which the artifacts are built:

• Linux Ubuntu 22.04
• Windows 10

Snap and Flatpak

You will find flatpak and snap folders in the source tree. They have been contributed and kept in case someone finds it useful. However Flatpak and Snap are not supported and even not recommended.

Continuous Integration

Linux and Docker

This is done using Appveyor and is driven by the .appveyor.yml file. The builds are run at the owner premises.

The Docker image is built using this Dockerfile.

You can check SDRangel project in Appveyor.

Windows

This is done via the Actions Github feature and based on this file The build is based on MSVC 2019 and Qt 5.15.2

Repository branches

• master: this is the default branch and is the most up to date that will eventually make the next release.
• next_release: this branch may appear temporarily when a lot of feature branches need to be merged together before being merged to master for the next release. This avoids polluting the master branch with versions that are not mature enough or may break.
• feature-nnn: feature branches are current developments related to issue nnn when these developments are made publicly available before being merged to master or next_release