KrakenSDR stuck in the calibration loop

1

Hello. Today the device stuck in the calibration loop. Before that, I had saved a configuration, and it seems that on each reboot the device loads it and stucks in a loop. Also, please notice a 700 mhz center frequency (even though it is set to 163 Mhz) and radius warning (even though it isset to 76 cm and fine for 163 mhz). Is there a way to break this loop without re-installing an image? For instance, reset a configuration (163 mhz, 76 cm radius, 3 db gain) that is set by me and loaded by default. Bacause it may happen again

2

Is it only that frequency that causes sync failure?

If it’s on that exact frequency you can change the frequency, then save a config again, then reboot.

It could also be the cache getting corrupt. If you one the system configuration box, there is a clear cache and restart box. Sometimes that can help.

3

Could you please give more details on “system configuration box” and where to find it?

4

It will be on the main configuration page. If it’s not there you might be on an older image, only the latest image from Nov 10 has it.

5

It happened again, and the checkbox and “clear cache” option is not helping. Is there a config file that I can remove via SSH?

6

What hardware is this on?

Clearing the cahce removes all the numba and pyc files in the krakensdr directories, it doesn’t change any config files.

If it’s a bad configuration setting, you can manually edit the configuration via the settings.json file in the krakensdr_doa folder.

The DAQ configuration is stored in heimdall_daq_fw/Firmware folder under the daq_chain_config.ini fle.

1 Like
8

I was having the problem with a calibration loop, but it was when running the software as a service, but if I go in and start it manually… then it works.

Maybe it is because the service was potentially running under the root user and not under my user account?

I’ll just start it by hand for now until I can figure out why it doesn’t work as a service.

I’ve also noticed that it has more trouble with SS (USB 3+) ports than USB 2.0 ports. The particular laptop I’m using does not have any USB 2.0 slots on it though.

UPDATE: If I let it sit for a short while, it fails again on its own. Back into the “calibration” loop.

If I reboot the Kraken itself and kill and restart the software… it comes back. Any ideas? This is not happening with the RPI 4 I have.

9

Ah so you are running on your own laptop, and not the Pi 4?

Any spec information about your laptop we can have?

If the USB3.0 implementation is buggy on your laptop it should definitely cause issues with calibration. Are the USB ports on your laptop being shared with any other devices, or so they share ethernet bandwidth?

One thing we found with the older Pi 3B+'s, is that there USB and Ethernet shared bandwidth. When Ethernet was used the USB would start throttling, and hence packets would drop. Resulting in lost coherence.

10

It does seem to be a problem with using a USB 3.x port. I have two of the Kraken devices. One is on a RPi 4 in my vehicle. That one is working great using the RPi 4’s USB 2 port!

The second one is for a static location, and I tried to use a newer laptop that does not have any USB 2.0 ports. I never did get it to work properly and gave up. It’s a i7 with 16gb RAM with NVME storage.

Today, I dug out a 4 year old Intel Celeron (N3550) based SBC I have that has both types of USB ports, and it works on that device when using one of the USB 2.0 ports.

As a test, I plugged it into the USB 3 port on the same SBC, and it does the “stuck in calibration” thing again.

Both the laptop and the Celeron SBC are running Ubuntu 22.04 with the latest updates.

I found a online benchmark comparison between the Celeron vs. the RPi 4, and the Celeron benchmarks faster in almost every category, so I am hoping it will be able to keep up under heavy load.

As a side note: I was rather surprised at how long it took to install on the Celeron… over 2 hours, but it seems like it is working fine… no lag/delays, hiccups or otherwise. Nothing else is running on it.

FYI: I used the “premade image” for the RPi 4, other than applying some WiFi changes and overclocking it a bit. No issues there.

11

I suspect some USB3.0 hardware is just buggy when it comes to USB2.0 backwards compatibility. We saw that with RTL-SDR units that were constantly dropping samples with some early USB3.0 hubs. However if the USB3.0 hardware is modern, and from a decent brand I would not expect any issues.

My two test desktops and one laptop are all USB3.0 and the Kraken works fine on them. One desktop is 6 years old, and the other is modern. The laptop is 2 years old.

I have another older ~5 year old laptop with only two USB-C USB3 ports. On that one, one USB-C port on the right side works, and the other on the left doesn’t. But that bad port on the left also doesn’t work with any SDR I own, but it’s fine for things like external mice and USB memory.

The Pi4 also has USB3.0 ports, and the Kraken works fine plugged into those.

What brand and model is your laptop?

12

It’s a newer Dell. Intel chipset. i7 processor. I tried it with all 3 USB 3.x ports… no go.

However, with the one Pi 4 I have, I had trouble with the USB 3 ports on it too.

I wonder if the USB C to USB A (3.x) cable I’m using is the problem?

I have some other cables that are USB C to USB A (2.0)… I’ll give one of them a try.

13

Definitely try changing the cables. Some poor quality cables don’t work with Kraken, but usually USB-C cables are built to a higher quality, so most should be fine.

14

Hate to bump this thread. Having the same issue as the video pictured here. Running PI4 with external SSD image. I’ve swapped all the cables and tried multiple power options thinking is was a power issue. Can’t seem to resolve it. The gain setting in the menu goes to a crazy 49.0 and other numbers when this is occurring also. Occasionally it will run fine then goes into CAL/overdrive flash and identical to the video in this threat. I have to DROK voltage Bucks coming to rule out any power issues. Running fresh image.

15

This sounds like it could be a problem. An external SSD running the OS is going to be hogging the USB bandwidth quite a lot, as that bandwidth needs to be reserved for the KrakenSDR. Using a USB SSD would cause a lot of delay on the USB packets, and we need the USB latency to be low for calibration to work.

16

Thanks Carl. I’ll go back to the on board SD and give that a try.

17

I’m having issues with calibration.

Background: I have a custom system with RTL-SDRv3 modified with CLK/GND jumpers and installed kraken_doa on an RPi5 with 5 port usb hub. 467MHz is DOA test freq. Using telescoping WB ANTs.

The SDRs eeproms were updated with device serial numbers etc per heimdall_daq_fw/util/kerberos_eeprom_init.sh at main · krakenrf/heimdall_daq_fw · GitHub

Passes kraken_test.sh - the nodejs gui, mobile app, heimdall are integrating.

Issue 1: It loops through the DOA calibration and intermittently passes for measurement

  • Tried adjusting DAQ.ini calibration fail and burst limits, changing between bias T on/off, noise generator and cal IQ on/off. None of which produced consistent results.
  • Updated DAQ.ini bypassing calibration from /default/kerberose as follows:

[meta]
ini_version = 7
config_name = kraken_defaultkerberos_dev002

[hw]
name = kraken5
unit_id = 0
ioo_type = 0
num_ch = 5
en_bias_tee = 0,0,0,0,0

[daq]
log_level = 5
daq_buffer_size = 262144
center_freq = 700000000467713000
sample_rate = 2400000
gain = 0
en_noise_source_ctr = 1
ctr_channel_serial_no = 1000

[pre_processing]
cpi_size = 1048576
decimation_ratio = 1
fir_relative_bandwidth = 1.0
fir_tap_size = 1
fir_window = hann
en_filter_reset = 0

[calibration]
corr_size = 65536
std_ch_ind = 0
en_iq_cal = 1
amplitude_cal_mode = channel_power
en_gain_tune_init = 01
gain_lock_interval = 0
unified_gain_control = 01
require_track_lock_intervention = 0
cal_track_mode = 20
cal_frame_interval = 687
cal_frame_burst_size = 10
amplitude_tolerance = 2
phase_tolerance = 1
maximum_sync_fails = 1016
iq_adjust_source = explicit-time-delay
iq_adjust_amplitude = 0,0,0,0
iq_adjust_time_delay_ns = 0, 0, 0, 0

[adpis]
en_adpis = 0
adpis_proc_size = 8192
adpis_gains_init = 0,0,0,0,0

[data_interface]
out_data_iface_type = shmem

Blockquote

It performs a quick calibration burst at start up then starts measuring.

Issue 2: When I test emissions at 468 the DOA directions are randomly showing on the polar plot as if it were not phase calibrated while standing at the same location. The DAQ subsystem status shows LOSS for Sample Delay and IQ Sync.

Not sure as to how the noise injection is being performed on kraken and if I need to emulate it to perform a noise calibration or if there is another solution that I am missing

18

Have you set the correct EEPROM serial strings for your five RTL-SDRs? What does rtl_test show?

If it’s showing LOSS, something went wrong with the initial connection.

19

The eeproms are set as follows and congruent with the DAQ.ini settings.

The kraken-test passes with no drops

I think I might need to emulate the noise injection waveform used in the calibration circuit. It seems unable to perform the IQ calibration until I complete the noise calibration. I have an external wave form generator I can try.

I’m missing this Calibration KerberosSDR - Platform for creating and sharing projects - OSHWLab

20

Ah yes if you have no noise source distribution to each dongle, then calibration will fail and there is no way to correlate the channels then.

21

It looks like the noise is injected into the SDR RFI via biased T using a WB waveform 3GHz.

Is(could) the USB controller be used for the noise calibration?