Squelch Mode not working? Or DOA estimate not working?

Hi all, I am working with kraken installations on linux laptops. I just updated from a May version of the krakensdr software to version 1.6.1, and the squelch mode does not appear to be working. The auto configuration works great – the DOA estimate only outputs when there is a signal.

However, I want to collect all the data, even when there is no strong signal. There is no longer an option to disable Squelch mode in the config, so I tried making squelch manual and setting it to -80 dB, so that it should just record outputs for everything. When I restart the kraken with this setting it appears to work at the start. The software is giving a DOA estimate when the incoming VFO power is -60 dB. However, after I turn on a 900 MHz source, the DOA estimates stop. The power on the configuration page is reading around -2 dB and overdrive, but there is still no DOA estimate even though squelch is set to -80 dB. Furthermore, after I turn off the source the DOA estimates never return. From my observations I think that once overdrive mode is hit (when antennas are hit with enough power), the DOA estimates stop and never turn back on until the kraken restarts.

I tried this test with auto-squelch mode on, and overdrive had no effect on whether it showed DOA estimates or not. It would be great if I could use this manual squelch mode, or if I could just disable squelch all together. Any help would be great, thanks!

Hi Evan,
I am seeing similar results as you. I spent about five hours out and about, attempting to learn the behavior of the KrakenRF, the SDR server (hosted on a Pi400), and the Kraken SDR app on an old Samsung A6 tablet running something like Android 7. I have been seeing similar behavior. the front display lights on my kraken are white (power) and green (what I interpret as the Kraken in CALIBRATE mode). If the green light is on, and I check the second gear symbol on the right, I will see the calibrate indication flashing, the next two indicators as OK, but the calibrate, sync IQ, and third indicators in red. If I totally reset the krakenRF, the Pi400, and power cycle the tablet, I can get the system to come up and process DOA for a few minutes (the green light on the right under the certification sticker on the front of the kraken is on for a bit, then turns OFF- at this point, the kraken app on the tablet shows all green, and going to the main display and selecting doalogfilename and hitting SAVE, then selecting the arrow in the lower right corner brings up the map, and kraken starts to determine bearing to the target, At some point, sometimes only a few minutes into tracking, the beeps stop, and no further tracking occurs. switching back the the server display settings, one sees the IQ Snc has gone red. It appears that the IQ stream from the Kraken hardware has stopped sending the stream to the Pi. Like you, I have found the only reliable way to regain DOA function is to power cycle the tablet, the Pi, and the Kraken receiver. I bring up the Kraken receiver first, then the Pi, and then start up the Tablet, verify it has the Kraken WiFI before starting the app on the tablet.

Im trying to understand if this behavior indicates a problem with the kraken receiver itself, the Pi4, or the application. The documentation doesn’t seem to provide sufficient detail to understand the system.

Perhaps the developers could contribute to the forum, or a blog, or perhaps a YouTube session where we users could lodge queries and the experts actually tell us the theory of operation, so we can troubleshoot our hardware and software and understand the order of configuration, and what each “switch” and parameter does, as well as what the various status indications mean (start processing, stop processing Save configuration, etc), Is Start Processing in GREEN a good thing, or does this need to be pressed. When pressed, it turns orange (is this good or bad?), and then sometime later it turns green again. Did anything happen? If the system processing??? Lots and lots of questions here.

Are you referencing the app in this paragraph?

Green means that the app is actively receiving data. Orange means that you are not moving, and so data collection is paused. Once you start moving again data collection will resume and the icon will turn green again.

Most of the theory of operation and info about the app is available on the Wiki 06. Android App Guide · krakenrf/krakensdr_docs Wiki · GitHub

If this is happening then the issue is that the Kraken is disconnecting from the Pi or struggling with power. Check that the cables are not loose. Sometimes bumping the cables can cause USB or power to drop which will cause a disconnection. Make sure that the power supply is high quality and is not cutting out.

Can you see what the spectrum looks like when you are transmitting? Please post a screenshot if you can.

Are you sure that the 900 MHz source is transmitting directly in the center of your tuned bandwidth in the KrakenSDR?

I suspect that the 900 MHz transmitter might not be within the VFO bandwidth (which by default is centered), and it could be overdriving the ADC, causing the noise floor to drop out or the actual signal you are monitoring to be desensitized that it cannot be received anymore.

The squelch is essentially off when it’s set very low but -80 might not be low enough, try -160.

The spectrum has a spike right at 900.1 MHz where I expect to see my signal. The transmitter is definitely within the bandwidth because the algorithms get correct DOA estimates for a short time before the DOA algorithms stop.

From what I am observing it is definitely an app problem. Somewhere in the software the boolean for enabling DOA estimation gets turned off, or the DOA estimation loop gets stuck somewhere. I have now found that disabling the checkmark for DOA estimation and re-enabling the checkmark restarts DOA estimation and it works again for a short time. What you said about overdriving the ADC could maybe do this, if that disables this boolean somewhere.

If it was a problem with the signal, I would expect that messing with the “enable DOA estimation” boolean would not help since the signal would be the problem. The fact that disabling and then re-enabling fixes the problem should mean that the software permanently stopped estimating DOA somewhere, and without a good reason because when I manually turn it back on the signal is coming through just fine.

This is my understanding of what is going on, I come from a computer science background and not too much of an RF background. So maybe this can be explained from signal perspective but to me it looks like a software issue.

Can you please upload a screenshot of your config screen + what the spectrum screen looks like?

Here is config:

The forum only lets me upload one picture at a time.

More config:

Then spectrum while emitter is ON:

It initially gets a correct heading on the DOA estimation page. Then after 10s-1min it stops running, and I have to disable and then re-enable the checkbox for “Enable DoA Estimation”, and it works fine for another 10s-1min. So I think that boolean in signal_processor.py gets disabled and never re-enabled. Or the DOA processing loop gets stuck somewhere.

Hm oddly even though your squelch is disabled at -120, your VFO bar is red, which means that the VFO is disabled from squelching. Does the VFO bar ever turn green?

When it gets stuck, does the DAQ subsystem status information change? Does the Frame Index keep increasing?

Please try running ./kraken_doa_start.sh -c (with the -c flag). This will clear the caches just in case it was a cache corruption issue.

The VFO is green for the time that the DOA estimations are coming through, and then it turns red along with when the DOA estimates stop.

And the DAQ system status also keeps updating while the DOA estimates are stopped, and the frame index keeps increasing. All it takes to get everything working again (for 20s) is to uncheck and check the DOA estimation checkbox.

I just tried the -c flag you gave, and the DOA estimations are still stopping.

Do you think it could be a read/write speed issue? I’m using the kraken with a Lenovo laptop running ubuntu. It seems like the kraken software is mainly optimized for running on a raspberry pi, so maybe it could be a speed issue?

I have now been running what I think is the same version of kraken software on a different laptop, and I don’t see this behavior. I might try a fresh install on a new laptop and see if I get the same problem.

A laptop should be more powerful that a Pi4 so I don’t think it’s a speed issue as you’re getting a good update rate and latency showing on your config screen.

Do you get this same problem on another signal at a different frequency?

Yes, I was getting that bug for all frequencies and I realized it was doing it with auto-squelch enabled too.
I am now using a different laptop, and it does not have the same behavior going on. I’m not going to be using the other laptop anymore, thank you for trying to help. Seems like it was a machine-specific bug or something wrong with the installation. I’ll post again if I see this happen on other machines. Thanks!