Deep redesign: move to SDRangel #7. Updated readme

This commit is contained in:
f4exb 2015-08-31 01:24:04 +02:00
parent 7f35fdeb89
commit 031b4cb1bd
1 changed files with 54 additions and 43 deletions

View File

@ -1,21 +1,23 @@
========
SDRangel
========
![Channel analyzer plugins](https://github.com/f4exb/sdrangel/blob/f4exb/doc/img/sdrangel_banner.png)
SDRangel is a Qt5/OpenGL SDR frontend to various hardware
![SDR Angel banner](https://github.com/f4exb/sdrangel/blob/f4exb/doc/img/sdrangel_banner.png)
===================
Repository branches
===================
**SDRangel** is an Open Source Qt5/OpenGL SDR and signal analyzer frontend to various hardware.
Although it keeps the same look and feel as its parent application **SDRangelove** it is a major redesign from it hitting more than half the lines of the code. Therefore the code base cannot be kept in sync anymore with its parent. It also contains enhancements and major differences. So it should now fly with its own wings and with its own name: **SDRangel**
<h1>Source code</h1>
<h2>Repository branches</h2>
- master: the "production" branch
- rtlsdrangelove: the master from hexameron rtl-sdrangelove
- legacy: the modified rtl-sdrangelove before major redeisign
- rtlsdrangelove: the master branch from the parent application [hexameron rtl-sdrangelove](https://github.com/hexameron/rtl-sdrangelove)
- legacy: the modified rtl-sdrangelove before a major redeisign of the code was carried out.
================================================
Plugins unsupported but still in the source tree
================================================
<h2>Unsupported plugins</h2>
These plugins come from the parent code base and are still present in the source tree but are not part of the build:
- Channels:
- tetra
@ -25,25 +27,33 @@ Plugins unsupported but still in the source tree
- v4l-msi
- v4l-rtl
==============
Funcube Dongle
==============
<h1>Supported hardware</h1>
Only the original Funcube Dongle Pro is supported. Funcube Dongle Pro+ will come later
<h2>BladeRF</h2>
=======
BladeRF
=======
BladeRF is supported through the libbladerf library that should be installed in your system for proper build of the software and operation support.
A complete new plugin has been written for the BladeRF that interfaces libbladeRF directly. Osmosdr/GnuRadio interface is not implemented correctly and has a lot of bugs as mentioned previously and was not reasonably usable with the BladeRF.
If you use your own location for libbladeRF install directory you need to specify library and include locations. Example with `opt/install/libbladerf` with the following defines on `cmake` command line:
If you use your own location for libbladeRF install directory you need to specify library and include locations. Example with `/opt/install/libbladerf` with the following defines on `cmake` command line:
`-DLIBBLADERF_LIBRARIES=/opt/install/libbladeRF/lib/libbladeRF.so -DLIBBLADERF_INCLUDE_DIR=/opt/install/libbladeRF/include`
==========
For Ubuntu
==========
<h2>Funcube Dongle</h2>
Only the original Funcube Dongle Pro is supported. Funcube Dongle Pro+ will come later.
The interface is built in the software and do not require additional libraries other than USB support with libusb.
<h2>RTL-SDR</h2>
RTL-SDR based dongles are supported through the librtlsdr library that should be installed in your system for proper build of the software and operation support.
If you use your own location for librtlsdr install directory you need to specify library and include locations. Example with `/opt/install/librtlsdr` with the following defines on `cmake` command line:
`-DLIBRTLSDR_LIBRARIES=/opt/install/librtlsdr/lib/librtlsdr.so -DLIBRTLSDR_INCLUDE_DIR=/opt/install/librtlsdr/include`
<h1>Software build</h1>
<h2>For Ubuntu</h2>
`sudo apt-get install libqt5multimedia5-plugins qtmultimedia5-dev qttools5-dev qttools5-dev-tools libqt5opengl5-dev qtbase5-dev libusb-1.0 librtlsdr-dev libboost-all-dev`
@ -69,9 +79,7 @@ For non standard installations of RTL-SDR library, the GNU Radio runtime and gr.
There is no installation procedure the executable is at the root of the build directory
==========
For Debian
==========
<h2>For Debian</h2>
For any version of Debian you will need Qt5.
@ -85,15 +93,15 @@ Assuming Debian Jessie is used:
Then the same remarks as for Ubuntu apply...
============
Known Issues
============
<h1>Known Issues</h1>
- You will need to stop input before changing preset then start again
- The message queuing model supports a n:1 connection to an object (on its input queue) and a 1:1 connection from an object (on its output queue). Assuming a different model can cause insidious disruptions.
- As the objects input and output queues can be publicly accessed there is no strict control of which objects post messages on these queues. The correct assumption is that messages can be popped from the input queue only by its holder and that messages can be pushed on the output queue only by its holder.
========================
Changes from SDRangelove
========================
<h1>Changes from SDRangelove</h1>
<h2>New features, enhancements and fixes</h2>
- Added ppm correction for the LO of RTL-SDR. This uses the corresponding function in the librtlsdr interface (range -99..99 ppm)
- Added a preset update button (the diskette with the yellow corner) to be able to save the current settings on an existing preset
@ -134,20 +142,23 @@ Changes from SDRangelove
- Coarse and fine trigger level sliders
- Minimalist recording (no file choice)
- File sample source plugin (recording reader) not working
- Major redesign:
- Make the DSP engine global static
- Fixed startup initialization sequence. New initialization phase in DSP engine and new ready state
- Synchronous messaging class to push message to thread and wait for completion
- Message queuing and handling redesign
- Many other little things...
<h2>Major redesign</h2>
- Make the DSP engine global static simplifying access to it
- Fixed startup initialization sequence. New initialization phase in DSP engine and new ready state
- Synchronous messaging class to push message to thread and wait for completion relieving the message queuing mechanism from this role
- Message queuing and handling redesign. Still not completely satisfactory
- Objects have their own input and output message queues
- Dedicated message queue to communicate to the GUI for objects coupled with a GUI
- Many other little things...
=====
To Do
=====
<h1>To Do</h1>
- Level calibration
- Enhance presets management (Edit, Move, Import/Export from/to human readable format like JSON)
- Tx channels for Rx/Tx boards like BladeRF
- Enhance WFM (stereo, RDS?)
- Even more demods ...
- Even more demods ...
- Support for Airspy and Funcube Dongle Pro+