Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

0.2.6a AM-mode whistling #796

Closed
ah1102 opened this issue Mar 11, 2020 · 30 comments
Closed

0.2.6a AM-mode whistling #796

ah1102 opened this issue Mar 11, 2020 · 30 comments
Assignees
Labels

Comments

@ah1102
Copy link

ah1102 commented Mar 11, 2020

In the version 0.2.6a collected from the source, as well as downloaded from the site http://sdrplay.com, an error with detection in AM mode is observed. When detuning from an AM signal, a whistle is heard. In 0.2.5, this was not.

Снимок экрана 2020-03-11 в 16 07 07

@LightningStalker
Copy link

I have a similar intermittent problem with AM where it sounds very distorted. It's happening with the precompiled version on Mint 16.04

@ah1102
Copy link
Author

ah1102 commented Apr 4, 2020

It seems that the author of the project stopped working on his program. Very sad.

@vsonnier
Copy link
Collaborator

vsonnier commented Apr 12, 2020

@ah1102 Work has slowed down considerably, but nothing is dead (yet). I suppose @cjcliffe (and I) would welcome other contributors who have interest in this project though.

BTW, thanks @Dantali0n for your support on users all across the board, this is much appreciated.

I run Cubic master on Windows10 x64 using an RSP2, in Zero-IF mode, and I also notice that whistle unless the demod is quite perfectly centered on the source. (as in Zero-IF, take care of shifting the Center Frequency away from the demod frequency itself, though)

Since it worked better on 0.25 and Mint is seeing the same problem, I would say the problem may be about liquid-dsp. For reference, I use the v1.32 tag version, compiled with GCC 9.20.

Unfortunatly I know next to nothing to DSPs, so I'm covardly assign this to Charles.

@vsonnier
Copy link
Collaborator

Probably related to #780.

@vsonnier
Copy link
Collaborator

Problem also encountered on the Pi apparently:

Copied from #780 by @cdbrinker:

I don't have this problem running the sdrplay software on my windows machine, but running cubicsdr on their pi 4 disk image, with AM mode on any frequency I get a loud oscillation, almost like a police siren, that drowns out the transmission. Transmission is there, but obscured. This is the case for any signal strong enough that it could otherwise be heard. This doesn't happen in other modes and I can generally hear more of an AM signal in an FM mode as it doesn't cause the 'siren' to go off.
Has anyone had this problem?

@ah1102
Copy link
Author

ah1102 commented Apr 13, 2020

What about developing a bookmark system and displaying them on the frequency spectrum? It’s not difficult to do! And how convenient it would be!

@SDRplay
Copy link
Contributor

SDRplay commented Apr 14, 2020

Anyone suffering with this using our 0.6 SD card image, here's the fix. It looks like there was a bug in liquid-dsp that has now been fixed. We've just tried it here and it's working...

Make sure all SDR applications are closed.

$ git clone https://github.com/jgaeddert/liquid-dsp
liquid-dsp$ cd liquid-dsp
liquid-dsp$ ./bootstrap.sh
liquid-dsp$ CFLAGS="-march=native -O3" ./configure --enable-fftoverride
liquid-dsp$ make -j4
liquid-dsp$ sudo make install
liquid-dsp$ sudo ldconfig

Then restart CubicSDR

@vsonnier
Copy link
Collaborator

vsonnier commented Apr 17, 2020

Hi @SDRplay @ah1102 and all. Here his a video showing the "whistle" effect. This is using a Win64 liquid-dsp (with latest MSYS2 GCC 9.30) compiled from master as @SDRplay suggested, however for me the issue (if it is an issue at all) is the same as the v1.32 version.
Maybe it is related with some compiling optimizations that are not generating the right code.

https://www.youtube.com/watch?v=7qFz39SRtrM

Note for @SDRplay : running SoapySDRPlay3 :)

@SDRplay
Copy link
Contributor

SDRplay commented Apr 17, 2020

Maybe we're talking about different issues then? We had a report that AM wasn't demodulating at all. So I fired up our 0.6 image on the RPi and sure enough in both CubicSDR and GQRX, AM stations in the MW band were either a loud "whistle" or "police siren" when tuning to the AM station carrier.

So, I just rebuilt liquid-dsp and restarted both CubicSDR and GQRX and now the AM stations are demodulating fine in MW band.

That's the issue we were focusing on - I haven't looked at what happens when tuning off-carrier but as the LO isn't moving, it can't be anything to do with the API, so it must be a DSP processing issue.

The issue we found to be resolved, was fixed for both CubicSDR and GQRX - so it's can't be a specific CubicSDR issue. We tried the fix on a number of devices and gave it to customers, whom have confirmed it to be fixed.

I'm not sure where you built SoapySDRPlay3 from, but that sounds out of date - you need SoapySDRPlay from either https://github.com/pothosware (API 2.13) or https://github.com/SDRplay (API 3.x) - note that the API version on our 0.6 RPi image is API 2.13

Hope that helps?

@vsonnier
Copy link
Collaborator

Hi @SDRplay, of course I'm using the https://github.com/SDRplay v3 one, as you can see with the issue I created there about Windows compilation :)

@SDRplay
Copy link
Contributor

SDRplay commented Apr 17, 2020

Hi @vsonnier thanks for those updates, there was a repo called SoapySDRPlay3 somewhere so that's why I thought you had the wrong one - things feel a bit like spinning plates at the moment! Once SDRuno 1.4 and the API 3.07 are released, things will settle down for 5 mins and I'll get a bit straighter with all the non-Windows stuff!

You can always compare what you are seeing to SDRuno - that uses the same API, so if the behaviour is different it has to be in the DSP processing somewhere.

If you use all the same dependencies with both CubicSDR 0.2.5 and 0.2.6a do you still see a difference? Like I said, rebuilding liquid-dsp fixed the RPi issue for both CubicSDR and GQRX for us so unless there is some platform fix dependency going on, I'm not sure where the issue is.

Have you tried the non-Windows version, even in a VM?

@vsonnier
Copy link
Collaborator

vsonnier commented Apr 17, 2020

If you use all the same dependencies with both CubicSDR 0.2.5 and 0.2.6a do you still see a difference? Like I said, rebuilding liquid-dsp fixed the RPi issue for both CubicSDR and GQRX for us so unless there is some platform fix dependency going on, I'm not sure where the issue is.

Between v0.25 and master, indeed a change in AM demodulation was introduced to accomodate a liquid-dsp API change, in this commit: 58086c1

the only change was:

ampmodem_create(modulation_index= 0.5, carrier_frequency=0.0, LIQUID_AMPMODEM_DSB, 0); ==> ampmodem_create(modulation_index=0.5, LIQUID_AMPMODEM_DSB, 0)

As far as I remember there was a time where the AM seemed to work better : you were not forced to center the demod on the the source so precisely, contrary to what my video shows now.

Have you tried the non-Windows version, even in a VM?

I'm too lazy to do that... I suppose I could try it on WSL on Windows10 but I'll have no sound. I don't think this is necessary though: except more polishing and work on UI fixes, the only AM DSP related change between 0.25 and 0.26a+ is that one.

So it is either related to liquid-dsp bug, or a wrong liquid_dsp API usage. Either way, I'm not competent on that matter.

@vsonnier
Copy link
Collaborator

vsonnier commented Apr 17, 2020

FYI I've pushed liquid-dsp updated binaries for Windows, aligned on the current master. So now portability-wise, we could benefit of the latest liquid-dsp changes if needed on all platforms.

@vsonnier
Copy link
Collaborator

vsonnier commented Apr 17, 2020

I've tried the v0.25 Win64 pre-built binary indeed there is no problem with AM there.

@vsonnier
Copy link
Collaborator

vsonnier commented Apr 17, 2020

@SDRplay Another change from v0.25 to v0.26 on Windows was the setting of more efficient compiler options for liquid-dsp, so just for a test I reverted them on the latest master : the whistle is still there, so the fault is not that compiler options.

Can you confirm if you are or not, observing the whistle effect on either Linux or RasberryPi ?

@vsonnier vsonnier added the bug label May 17, 2020
@SDRplay
Copy link
Contributor

SDRplay commented May 28, 2020

Sorry @vsonnier I've only just seen this was a question for me.

Since rebuilding liquid-dsp as per my post above we haven't seen any further issues and no customers have reported any either. We were focusing on RPi to be honest. Is this still an issue?

Hope that helps.

Andy

@srs4511351
Copy link

srs4511351 commented Aug 6, 2020

I have been experiencing the whistling on my Paspberry Pi 4 installation of SDRplay's v0.7 image.
I have the RSP1A SDR.
It worked at first, but after a few hours of use, the whistling when AM was not perfectly tuned started. I was able to demodulate SSB signals on AM. as the apparent internal heterodyne acts as a shaky BFO.
I re imaged my SD card several times, but the whistling eventually came back each time.
Gqrx did not do this on a system where CubicSDR v0.2.6a was whistling. AM was clear even when tuned slightly off.
On one of the installations, I disabled CubicSDR v0.2.6a and installed 0.2.5 from Add remove programs.
0.2.5 worked normally, but I used the SoapySDR server.

Replacing the config.xml file from the one that works or deleting it did not fix the squealing problem.
The liquid-dsp fix did not help.

So, for me, it is just CubicSDR v0.2.6a that has the problem. I would like to be able to download and re install CubicSDR v0.2.6a, but I haven't found an installer the internet.

There are also some spurs that appear periodically in the spectrum on at least 80 meters. They drift up or down in unison.
I haven't verified that they are related to CubicSDR v0.2.6a yet, but I had not noticed it on other versions.

----Steve

@srs4511351
Copy link

srs4511351 commented Aug 7, 2020

I Installed RtAudio, SdrGult (failed), Quisk.
performed sudo apt-get update, sudo apt-get upgrade
Tried CubicSDR and the AM whistle is gone! (for now?)
I don't know which thing fixed it or if it was luck.
The next time I booted the system, I got strange buzzing noises and no actual signals. I stopped the SDR device in CubicSDR, but it wouldn't start again.
After a reboot, it is working again.

After trying my RSP1 on Windows, I notice that the squealing sounds like a station tuned off frequency with SDRuno in Synchronous AM mode (SAM), but SDRuno will tend to lock on to the frequency.

----Steve

@LightningStalker
Copy link

LightningStalker commented Sep 14, 2020

The whistling is very different from what it does on my system. It sounds more like what happens when you tune slightly out of a SSB transmission. It's sort of like that although it's more of a simplified explanation. Maybe the liquid-dsp update will fix it as well.

@colbyAtCRI
Copy link
Contributor

So, I've looked at this. ModemAM in Cubic uses ampmodem from liquid which uses a phase lock loop in the AM demodulation. Basically ModemAM makes a DSB modem with suppressed carrier. It's a nice modem for sure but very sensitive to slight detuning. At 120MHz as little as 1kHz off the center frequency is enough that the PLL doesn't close. What I've done is ditch ampmodem all together and just modified the demodulation loop in ModemAM.cpp to take the cabs of the input signal. I then pass it through a dc blocker (firfilt_rrrf). Works like one would expect. No whistling. Any interest in this?

@srs4511351
Copy link

If this AM mode has benefits over standard AM detection, if may be a nice alternative.
However, I would also like to see the plain, basic modem that you are suggesting.

@colbyAtCRI
Copy link
Contributor

colbyAtCRI commented Dec 22, 2020

Not clear what is mean by "this", srs11351. The modem I implemented is here,

<inserted code doesn't format>

I liken the above demod to a crystal radio (with a full wave rectifier). PLLs do have advantages but what's provided by ampmodem is much too narrow band to be usable. For example listening to 120.1 kHz air traffic, planes vary enough in center frequency to throw ampmodem off making it unusable.

@ve1jot
Copy link

ve1jot commented Dec 23, 2020 via email

@srs4511351
Copy link

If you are asking me what I an suggesting, I would prefer that CubicSDR offer the Synchronous AM modes as well as a standard mode for those who are listening to stations that cannot keep their frequency accurately.

When you say "The modem I implemented is here,", has it been added to the CubicSDR distribution?

@vsonnier
Copy link
Collaborator

vsonnier commented Dec 25, 2020

So, I've looked at this. ModemAM in Cubic uses ampmodem from liquid which uses a phase lock loop in the AM demodulation. Basically ModemAM makes a DSB modem with suppressed carrier. It's a nice modem for sure but very sensitive to slight detuning. At 120MHz as little as 1kHz off the center frequency is enough that the PLL doesn't close. What I've done is ditch ampmodem all together and just modified the demodulation loop in ModemAM.cpp to take the cabs of the input signal. I then pass it through a dc blocker (firfilt_rrrf). Works like one would expect. No whistling. Any interest in this?

You bet @colbyAtCRI, I would like to get a PR :) I took the liberty to restore your original message, with formatting this time:

void ModemAM::demodulate(ModemKit *kit, ModemIQData input, AudioThreadInput audioOut) {
      ModemKitAnalog *amkit = (ModemKitAnalog *)kit;
      
      initOutputBuffers(amkit,input);
      
      if (!bufSize) {
      
          return;
      }
      // This is it. Pushing sqrt(II+QQ) onto the dc blocker followed
      // by applying the FIR filter is all that's needed.
      for (size_t i = 0; i < bufSize; i++) {
            liquid_float_complex sig = input->data[i];
            float I = sig.real;
            float Q = sig.imag;
            firfilt_rrrf_push (mDCBlock,sqrt(I*I + Q*Q));
            firfilt_rrrf_execute(mDCBlock,&demodOutputData[i]);
      }
...

PLLs do have advantages but what's provided by ampmodem is much too narrow band to be usable. For example listening to 120.1 kHz air traffic, planes vary enough in center frequency to throw ampmodem off making it unusable.

This ^^^ alone would justify the change you propose. the short video I've attached previously indeed demonstrate this on the Air Band: The slightest off center is problematic with the current implementation.

@colbyAtCRI
Copy link
Contributor

Thanks for the reformatting. I've cloned the current master and submitted a pull request.

@colbyAtCRI
Copy link
Contributor

If you are asking me what I an suggesting, I would prefer that CubicSDR offer the Synchronous AM modes as well as a standard mode for those who are listening to stations that cannot keep their frequency accurately.

@srs4511351
For synchronous AM detection, the DSB offers an option. The only difference between DSB (other than default bandwidth) from the current synchronous AM demodulator is a suppress carrier flag passed to the ampmodem_create. I couldn't hear a difference between flag settings.

@vsonnier
Copy link
Collaborator

vsonnier commented Dec 25, 2020

Thanks @colbyAtCRI I'll look into it. I'm on Christmas holidays now, and will be able to merge it if suitable at the begining of 2021.

Thanks for the reformatting. I've cloned the current master and submitted a pull request.

I don't see your pull request, you probably missed something in the procedure.

@vsonnier
Copy link
Collaborator

Here is the PR: #865 , thanks to @colbyAtCRI.
Do not hasitate to give it a try and report the results here.

@vsonnier
Copy link
Collaborator

vsonnier commented Jan 2, 2021

I've merged the PR, it works very well : no matter off-center the AM demod is, the sound is now correct. Good catch @colbyAtCRI !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants