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
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.
Could you please give more details on “system configuration box” and where to find it?
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.
It happened again, and the checkbox and “clear cache” option is not helping. Is there a config file that I can remove via SSH?
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.
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.
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.
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.
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?
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.
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.
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.
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.
Thanks Carl. I’ll go back to the on board SD and give that a try.