search

BatchDrake / SigDigger

Qt-based digital signal analyzer, using Suscan core and Sigutils DSP library
https://batchdrake.github.io/SigDigger/
GNU General Public License v3.0
925 stars 91 forks source link

Samplerate is set to 1sps when using Triggered Inspector #223

Open studiofuga opened 1 year ago

studiofuga commented 1 year ago

When using the signal level triggered inspector, the sample rate is set to 1sps, while when using the pushbutton, it is correctly set to whatever the rate is.

Tested on HackRF One.

studiofuga commented 1 year ago

Confirmed the issue is in main and in 0.3.0 AppImage. Additionally, on my setup compiled from main, While manual Push to Capture works well, Autosqueltch triggers but doesn't capture anything. Not if that is relevant, but there is a DC signal on all frequencies. On AppImage the same DC is waning.

studiofuga commented 1 year ago

Update: capture and DC issues are not present on branch Develop compiled with Qt 5.15.2, Alsa, portaudio and others. Still present the sps issue. See Image.

Schermata del 2023-06-16 19-39-50

BatchDrake commented 1 year ago

Confirmed, working on it.

BatchDrake commented 1 year ago

It should be fixed now, I've just triggered a new development build. Do you mind giving it a try?

studiofuga commented 1 year ago

Yeah, thanks, works like a charm. Tested right now on another linux box.

Out of couriosity, are there any plan to unify the three projects (sigutils, suscan, SuWidgets and SigDigger) in a single project wit submodules, perhaps porting all of them in cmake? I'd be happy to help on that eventually.

BatchDrake commented 1 year ago

Hi, glad to hear that!

Regarding submodules, it's funny you say that because we've been experimenting with them recently. My plan is to add the possibility to rely on submodules to clone everything automatically. However, porting to CMake is precisely what worries me the most.

If you feel like you have the energy to do that, please go ahead! You should start by SuWidgets anyways. You can start by a WIP PR and we can work from there.

studiofuga commented 1 year ago

I'm using cmake in production code for qt projects pretty extensively, so I don't see any obvious difficulty. The only still unsolved issue is the packaging process, that's well solved on debian (dpkg-buildpackage is pretty straightforward) but still a mess in Windows and MacOS environment. But probably it's not an issue actually.

BatchDrake commented 1 year ago

Porting to CMake itself is not the problem, but maintaining compatibility with the existing projects (like SigDigger) could be. And, of course, we still have the complications derived from the lack of sanity of macOS and Windows.

In any case, we can start doing some experiments to evaluate the overall effort.