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.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

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.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 and Delivery

At present this is done using Appveyor and is driven by the .appveyor.yml file. The build is 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 2017

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 hosts SDRangel version 4. It is the default branch and most stable. This is the branch used to produce release artifacts.
• dev: this is the development branch related to master. This can also serve as an integration branch. The continuous integration runs on this branch but artifacts stay in the CI/CD system.
• v5: this hosts SDRangel version 5 and is the tip of development. It contains latest developments and features. New features can occasionally make their way to master. However MIMO support stays specific to this branch. No artifacts are provided on this branch you will have to compile from source or build a Docker image.