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.

I have a similar intermittent problem with AM where it sounds very distorted. It's happening with the precompiled version on Mint 16.04
It seems that the author of the project stopped working on his program. Very sad.
@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.
Probably related to #780.
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?
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!
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
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 :)
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?
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 :)
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?
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: https://github.com/cjcliffe/CubicSDR/commit/58086c17fbbb2fcd7a98024198bed777d23e2aba
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.
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.
I've tried the v0.25 Win64 pre-built binary indeed there is no problem with AM there.
@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 ?
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
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
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
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.
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?
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.
Not clear what is mean by "this", srs11351. The modem I implemented is here,
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.
Perhaps if it implemented AM synchronous detection such as GQRX recently
added, it'd be a better AM detector then...
On 2020-12-22 6:50 p.m., srs4511351 wrote:
>
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.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cjcliffe/CubicSDR/issues/796#issuecomment-749819112,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE6UH6RZOKHJLYGBQD2VEWTSWEPD7ANCNFSM4LFVU2NQ.
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?
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.
Thanks for the reformatting. I've cloned the current master and submitted a pull request.
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.
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.
Here is the PR: https://github.com/cjcliffe/CubicSDR/pull/865 , thanks to @colbyAtCRI.
Do not hasitate to give it a try and report the results here.
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 !