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 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. But 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 20.10 with prerequisites installed. See in the compilation instructions why 20.10 is preferred over 20.04 LTS. 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

An 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 environments for which the artifacts are built. There are just two of them:

• Linux Ubuntu 20.10
• 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 and Delivery

At present this is done using Appveyor and is driven by the .appveyor.yml file. The first two builds are run at Appveyor premises on virtual machines which profile may be found here:

• Linux Ubuntu 20.04 from v4.14.10
• Windows with Visual Studio 2019
• A Docker image build using this Dockerfile is run at the owner premises.

For every release on master branch the resulting artifacts are uploaded to the releases section.

You can check SDRangel project in Appveyor where all builds and artifacts may be consulted.

Repository branches

• master: this is the default branch and is the most up to date that will eventually make the next release. This is the branch used to produce release artifacts.
• 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 development are made publicly available before being merged to master
• v5: this was SDRangel version 5 and is the used to be the tip of development before merge back to master into v6.It is kept for referencein case something is found missing in the now master branch