Many signals are not continuous (i.e. they are received in bursts) and are so short that synchronization routines just don't have enough time to recover the timing. This can be overcome with a burst inspector that allows you to record a signal for a while and handle the timing/demodulation by hand, with the help of the time view.

Showing SymView size in bits is difficult to read. Add prefix (kilo, mega...) in order to improve legibility.

This is a suggestion: maybe it's better to either have a "stop" button, or change the name of the "scan" button when it's presses, so it's easier for the user to understand (also more accessible from a UX standpoint). Or maybe implement it like a button that has on/off switch

I tried testing out the pre-compiled binaries (specifically the 3rd release) on a Linux Mint 19 system (Ubuntu 18.04 lts base). If I run this I receive the following error:
"qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem."

I think qt5/plugins/platforms/libdxcb.so needs to be included?

I tried installing it via apt qt5dxcb-plugin but the current qt core version in the distro repos is not recent (5.9.5 per qmake). I also tried deleting the bundled qt core lib to see if it would use my installed qt core lib but there is a version check that stopped that effort quickly :)

I can't say if it is the best solution for this software but have you checked out AppImage for distributing binaries? CubicSDR uses this as a reference.
Alternatively maybe sdrangel's deb pkg approach could be referenced.

This is caused by detachAllInspectors not testing whether the traversed element is null.

SymView pixels are awfully small. Add controls to make them bigger.

Hello, the Settings menu is too narrow. It would be usable if the Y axis was resizable.

Leveraging the improved PSD / Channel update rates, show the measured processing sample rate in Suscan, and display some kind of alert if it is near (or above) the effective sample rate.

Ubuntu 18.04, x64
Qt 5.12
Suscan/Messages/InspectorMessage.cpp: In member function ‘unsigned int Suscan::InspectorMessage::getBasebandRate() const’:
Suscan/Messages/InspectorMessage.cpp:84:25: error: ‘struct suscan_analyzer_inspector_msg’ has no member named ‘fs’
return this->message->fs;
^~
Suscan/Messages/InspectorMessage.cpp: In member function ‘float Suscan::InspectorMessage::getEquivSampleRate() const’:
Suscan/Messages/InspectorMessage.cpp:90:25: error: ‘struct suscan_analyzer_inspector_msg’ has no member named ‘equiv_fs’
return this->message->equiv_fs;
^~~~~~~~
Suscan/Messages/InspectorMessage.cpp: In member function ‘float Suscan::InspectorMessage::getBandwidth() const’:
Suscan/Messages/InspectorMessage.cpp:96:25: error: ‘struct suscan_analyzer_inspector_msg’ has no member named ‘bandwidth’
return this->message->bandwidth;
^~~~~~~~~
Suscan/Messages/InspectorMessage.cpp: In member function ‘float Suscan::InspectorMessage::getLo() const’:
Suscan/Messages/InspectorMessage.cpp:102:25: error: ‘struct suscan_analyzer_inspector_msg’ has no member named ‘lo’
return this->message->lo;
^~
Makefile:1660: recipe for target 'InspectorMessage.o' failed
make: *** [InspectorMessage.o] Error 1

Add the ability to improve and extend the GUI through a plugin system. Write a test plugin to show the Smith Chart using NanoVNA.

When a new device (SDR) is started, the name or label is not shown in the window title. It only shows Unlabeled source
Look at the screenshot

When i set bladerf bandwidth more, than 2MHz (more 2000000 samples per second), bandwidth all time limited to 2 MHz.

In many cases, SigDigger acts as a mere relay between the receiver and a Matlab/Octave script which does the actual signal processing. However, processing raw I/Q files directly from these scripts is usually slow and/or cumbersome. We can speed up things if SigDigger is able to load and save I/Q data directly in binary .mat format.

Based on the identified device (e.g. LimeSDR vs RTL-SDR dongle), default settings like:

• Antenna
• Bandwidth
• Frequency (e.g. inside FM Broadcast range)
• Sample Rate

Should be pre-defined so end user simply can click "play" button.

When I start a capture, I get a popup with just the text "Failed to start capture due to errors:". I've tried with both a HackRF source and a file source (complex f32 samples) and get the same result.

I'm running Ubuntu 18.04 and I am running a slightly older Qt version than suggested (5.9.5) but I think it's unrelated?

I'm happy to dig in and do some more debugging but I don't really know where to start, so I'd need some advice on things to try.

https://github.com/BatchDrake/SigDigger/wiki/MacOS-Port-Milestone#implement-audio-preview

AM signals sound slightly distorted due to an extremely fast AGC. Sometimes this makes sense, sometimes it does not. Add controls in the baseband audio preview in order to adjust that.

Also, audio buffers are extremely big and this is not necessarily a good idea, especially for low sample rates. Adjust this from the configuration window.

Raw I/Q files generated by SigDigger and other applications like Gqrx follow the same pattern, from which the sample rate can be guessed. Leverage this pattern in order to guess the sample rate automatically in the GUI.

Many signals are better understood in time domain (like ASK). Implement a time domain tab to visualize the complex envelope of the demodulated signal.

If I attach a device after I've run SigDigger, I won't see it in the Device drop-down list. I have to close and run the app again to see and select the device. Maybe adding a Refresh button like CubicSDR would be good (to populate the drop-down with any connected devices)

As the number of systems where SigDigger is being tested is increasing (as well as the device detection issues), debug options should be added to the AppImage.

For less powerful users it is easier to introduce values like Bandwidth, Frequency, Sample Rate in the Hz, KHz, MHz, Ghz.

It could be achieved by simple drop down menu with Hz->GHz value or support for input values like "1.6MHz"

Support for GnuRadio like inputs "1e7" / "1e+7" is also useful.

When working with LEO satellites, TLE data could be used to reduce the Doppler shift to the point that you don't need to readjust the central frequency of the inspector every minute anymore.

This feature could be implemented as a new set of controls in the demodulator pane of the inspector tab (and maybe the inspector panel too) , which could accept a TLE file and a clock reference in order to smoothly correct the Doppler shift at every sample. This would also require some kind of location setting and should work both with captures and live sources.

There is a menu bar that is yet to be populated. Some interesting entries could be:

• File
  • Start
  • Stop
  • Start... (select recent sources)
  • Load profile
  • Export profile
  • Quit
• View
  • Devices
  • Panoramic spectrum
  • Options
• Help
  • About

The frequency of many SDR devices out there lack accuracy. A frequency correction feature (i.e. ppm field) is necessary,

Many SDR on the market have a large instantaneous bandwidth. It will be useful if you can view the full spectrum of the SDR is capable, or maybe more using fast sweeps, to see a very wide bandwidth. Of course, the display will be limited but is not important if you can zoom in at while. At least, the recording should be arbitrary wide bandwidth, in the maximum range of the SDR. For example, there are >100MHz bandwidth SDR like RedPitaya. I would use this for radio astronomy.

rtl-sdr installed, but in source list of sdr devices not present.
Log of rtl_test:
$ rtl_test
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN:

Using device 0: Generic RTL2832U OEM
Found Fitipower FC0013 tuner
Supported gain values (23): -9.9 -7.3 -6.5 -6.3 -6.0 -5.8 -5.4 5.8 6.1 6.3 6.5 6.7 6.8 7.0 7.1 17.9 18.1 18.2 18.4 18.6 18.8 19.1 19.7
Sampling at 2048000 S/s.

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode...

When demodulating graphical channels like NTSC, PAL, WeFax or SSTV, it could be interesting to save the SymView capture as a graphics file (p ej, PNG). This feature should allow saving a portion or the whole capture in different layouts (single column, multiple columns...), rotations, mirroring and slants. A preview dialog may be required.

Implement feature to save demodulated audio to WAV file.

It seems right now the list of devices is initialised in the startup.
It would be a nice feature if we can refresh the list, so if a new device is connected while the app is running, we can detect and start it (without closing and re-opening the app)
For example CubicSDR has a similar button

See https://github.com/BatchDrake/SigDigger/wiki/MacOS-Port-Milestone#c-api-benchmarking

https://github.com/BatchDrake/SigDigger/wiki/MacOS-Port-Milestone#fix-installation-directories

I thought you might be interested in knowing this warning line which is shown when running the app via command line:

qt.qpa.fonts: Populating font family aliases took 149 ms. Replace uses of missing font family "Monospace" with one that exists to avoid this cost.

Review and/or refactor workflow based on user feedback. Use the attached document by @BSAsecure as starting point.
First Steps with SigDigger.pdf

In some scenarios, a digital signal has been modulated twice. This is the case for RDS: it consists of two mirrored BPSK signals modulated at 57 kHz with respect to the FM baseband signal.

Chaining two inspectors together should be straightforward: between every two adjacent inspectors, a spectral tuner selects the desired subchannel. The configuration part is perhaps the most critical one, as the user may want to adjust the parameters for all demodulators from the GUI.

I open this issue as a reference for future, as this happened in all the repos including SigDigger.
I think it's because of volk.
Removing the empty -l from Makefile resolves the issue.
The linker error log is something like this:

ld: library not found for -l-lfftw3
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [SigDigger.app/Contents/MacOS/SigDigger] Error 1

Hi BatchDrake,

First thank you for the fantastic work you are doing on SigDigger.

Trying the AppImage release on my Ubuntu 18.04.3 LTS returns following error :

./SigDigger-full-x86_64.AppImage 
/tmp/.mount_SigDigKeelMp/usr/bin/SigDigger.app: /tmp/.mount_SigDigKeelMp/usr/bin/../lib/libz.so.1: version `ZLIB_1.2.9' not found (required by /usr/lib/x86_64-linux-gnu/libpng16.so.16)

This workaround worked for me: set LD_LIBRARY_PATH variable:
export LD_LIBRARY_PATH=/lib/x86_64-linux-gnu

Hope this can help others !
BR

Hi,

I installed soapysdr-module-uhd and soapysdr-module-all with apt-get on my Debian Buster system, but I cannot get SigDigger to recognize my Ettus USRP N210 device. uhd_find_devices and gqrx have no issue finding it. I am using the SigDigger 0.0.6 AppImage.
If you don't have access to a USRP for testing, let me know and I will help test things out to help debug.

P.S. I tested it out using an AirSpy, it works great so far!

Thanks!

In file included from include/Suscan/Analyzer.h:26,
from Suscan/Analyzer.cpp:23:
Suscan/Analyzer.cpp: In member function ‘void Suscan::Analyzer::setFrequency(double)’:
Suscan/Analyzer.cpp:120:59: error: too few arguments to function ‘int suscan_analyzer_set_freq(suscan_analyzer_t*, double, double)’
SU_ATTEMPT(suscan_analyzer_set_freq(this->instance, freq));
^
include/Suscan/Compat.h:29:9: note: in definition of macro ‘SU_ATTEMPT’
if (!(expr)) {
^~~~
In file included from /usr/local/include/suscan/analyzer/msg.h:31,
from include/Suscan/Message.h:27,
from include/Suscan/Analyzer.h:29,
from Suscan/Analyzer.cpp:23:
/usr/local/include/suscan/analyzer/analyzer.h:154:8: note: declared here
SUBOOL suscan_analyzer_set_freq(
^~~~~~~~~~~~~~~~~~~~~~~~
make: *** [Makefile:1702: Analyzer.o] Error 1

When the channel offset is set in the inspector tab, the frequency shift is being applied to the channel output and not the input (as it ought to be). Additionally, when the shift is above the resolution bandwidth, the channelizer jumps to the next bin (this is correct), producing a completely different spectrum. This shows up as a characteristic sawtooth pattern in the inspector waterfall:

In some situations, a post-channelization shift may be interesting (especially for skewed signals like SSB). This fix should allow adjusting both pre and post channelization frequency offsets from the inspector tab.

The panoramic spectrum view should measure the PSD across the whole supported frequency range by averaging (the whole or portions of) received PSD messages. Since the range covered by each pixel may be either bigger or smaller than the range covered by each PSD message, different averaging cases may occur.

This feature must include:

• Range selection and per-device automatic range detection
• Continuous / one shot panoramic view
• Progressive / Random walk sweep.
• Real time plot update (refresh on PSD message reception)
• Level and waterfall adjustment.
• Device selection (print warning if the profile is in use)
• Interpolation between missing points during random walk.
• LNB frequency offset

https://github.com/BatchDrake/SigDigger/wiki/MacOS-Port-Milestone#fix-warnings-for-clang

I know that profiles can be saved and loaded, but I think it would be very convenient if the last entered data for frequency and sampling rate are set every-time that app runs. What do you think?

https://github.com/BatchDrake/SigDigger/wiki/MacOS-Port-Milestone#implement-packaging

Hello,

Using an AirSpy R2 on Debian Buster, with the 0.0.6 AppImage, click the Peak Detection button causes an immediate segfault:

/home/kevin/Downloads [kevin@carbon] [11:30]
> ./SigDigger-0.0.6-x86_64.AppImage
[INFO] Using format CF32.
/tmp/.mount_SigDigDAkvFX/AppRun: line 4: 15641 Segmentation fault      $APPDIR/usr/bin/SigDigger.bin

Not sure if this is supposed to work yet - if so, let me know how I can help test or what other info you would like.

Thanks!

Gain sliders allow configuring the device gain up to the nearest integer. This is not enough for devices like USRP.

Hey @BatchDrake
Is SigDigger fully relying on SoapySDR or you also have to add device-specific configurations to the code?
In a comment to issue #12 you said

For AirSpy (and hopefully more radios in the future) there are gain presets that allow you ...

And I wondered what you mean by hopefully more radios in future? Because in another comment you've said

... in the end, SigDigger just wraps around SoapySDR in order to detect SDR devices.

I have access to some other SDRs like different SDRPlays and LimeSDR and I can help in testing, but your comment made me wonder if you have to do some changes in the code.

Can we define a simple test criteria as: if you can open a device in SigDigger and observe the spectrum/waterfall and also open some inspector tabs without any issues, then the test is successful for that SDR?