We have received a number of excellent questions, which we have summarized below:

Is it possible to use KrakenSDR with external TX and use one of the RX channel to sample/couple TX to make a coherent radar?

This is untested but we think it should be possible. There are a few things to think about, though. You could probably use a directional coupler to take an attenuated reading from the TX for the KrakenSDR illuminator RX input. The challenge would be keeping the active TX signal away from the RX antenna by using highly directional antennas so that the RX antenna only receives the reflections. You also need to take into account legal power EIRP limits and what frequencies you are licensed for.

What is the power draw of the Kraken at max usage? Potentially looking to use if off-grid.

Burst power draw with the noise source on is 5 V, 2.2 A, 11 W. The noise source is off most of the time though, and then it’s a little less at 5 V, 2.1 A, 10.5 W.

You also need to take into account the power of the Raspberry Pi or computing system you use too. The Pi4 draws about 5 W - 10 W.

Also, if you’re adding extra bias-tee-powered devices, you’ll want to take those into consideration too.

Do you have any data about phase coherency across tunes and power cycles? Also, what is the timing reference?

Phase coherency is lost across tunes and power cycles, but the DAQ software automatically recalibrates phase offsets to achieve phase coherency again with the noise source when this happens. The KrakenSDR uses the same 28.8 MHz oscillator frequency that standard RTL-SDRs use (but of course all units are connected to the same clock as part of the phase coherence solution). The particular oscillator used is a 1PPM TCXO.

It looks like the Arrow antennas you are using are Yagi’s…which would make them highly directional.

The Arrow antenna arrays have a single dipole on each arm, which is omnidirectional. It’s not a TDOA system, rather it’s correlative interferometry, and so direction finding is based on phase information. Arrow antennas are famous for their Yagi antennas, so maybe this is where the misunderstanding comes from.

Will the app be able to find which wireless SSID is associated with which physical structure…? Also, any chance the app will be generic Linux, too? (Don’t get me wrong - I’d absolutely buy a different phone just to use this!)

For Wi-Fi SSIDs, unfortunately, KrakenSDR cannot reach the frequencies at which Wi-Fi operates because the maximum supported frequency is 1.766 GHz. Wi-Fi would also present other challenges, as you’d need much wider bandwidth and an SDR Wi-Fi software stack to decode the SSID. (Look into the OpenWiFi project). I think for the SSID Wi-Fi application there are already many war-driving solutions designed especially for that, so you’re better off with a specialized Wi-Fi solution.

For the DFing app, in 2022 we will be working on a multiplatform solution too, most likely web based, so it will work on any platform.

How are you managing USB bandwidth? Which hub are you using? Will all receivers run at full sample rate?

On the KrakenSDR PCB there is a USB2517 USB 2.0 Hub controller. USB 2.0 and the hub is sufficient to support all five receivers operating at the max stable bandwidth of 2.56 MHz.

Do you think it would be possible to integrate a heading input from an NMEA 2000 compass?

Yes, this should be possible with some minor code modifications to have the compass data collected by the Pi4, through another interface via the Android app, or using your own custom display solution. To know for sure, we’d need more information about how your compass interfaces and provides data.

In a fixed monitoring situation, can signals within a specific compass range of interest be set in software? For example, could it be possible to monitor signals from only 30-degrees of coverage area, relative to the monitoring station?

This sort of filtering would be best done in the application/mapping layer, so probably will be a feature on the PC/web based mapping solution which is yet to be implemented.

Could specific frequencies of interest and scheduling be set so that monitoring can be focused on bad actors?

Currently the KrakenSDR code can monitor one signal at a time. Simultaneous, multi-frequency support is on the development horizon, and when that is done this will be possible at least for frequencies within the same 2.56 MHz bandwidth. Switching between frequencies outside the live bandwidth could also be possible with some delay in between switches. Scheduling could be done in the application layer too.

At how much distance it can do direction finding (e.g. for a 170 MHz walky talky or base transmitter)?

This is difficult to answer as it depends on too many unknown factors like frequency, terrain, obstructions, transmitter power EIRP, TX+RX antenna location/height, multi-path environment, etc. But basically, if the signal can be received, it can be used for DFing. However, the lower the quality of the signal (weak signal, multi-path, etc), the more locations you may need to take readings from.

How easy it is to modify/tweak the software ?

The software is complex, but it is split into blocks and entirely open source. Also, there is documentation on the architecture in our GitHub repository.

I bought previous version too. It work fine but I need tracking [in the] 1900~2000 MHz range. You said it is possible with [a] hacked driver. Can you provide it?

The librtlsdr branch of RTL-SDR drivers provides this higher-frequency functionality through the use of a high-side mixing hack. Please note this is highly experimental and we are still testing its usability with KrakenSDR. It will most likely require high-pass filtering and an LNA, and you should expect the signal strength to be low.

Initially, to work with the Kraken/Kerberos code, you will need to disable zerocopy buffers within the librtlsdr code (just comment out code relating to zerocopy) and make two minor changes in rtl_daq.c:

1. Change rtlsdr_set_gpio(rtl_rec->dev, 1, 0); to rtlsdr_set_bias_tee_gpio(rtl_rec->dev, 0, 1);
2. Change rtlsdr_set_gpio(rtl_rec->dev, 0, 0); to rtlsdr_set_bias_tee_gpio(rtl_rec->dev, 0, 0);

Don’t forget to recompile librtlsdr and rtl_daq after making the changes. Then, in theory, you should be able to tune to the higher frequencies, but you may want filtering too.

If testing works on favorably, we will make a branch of librtlsdr with zerocopy disabled in the next few weeks. We will update our own code to use this branch as well.

I want to cover a wider frequency band and plan to have several antennas to achieve this. So I’m wondering if it’s possible to add…user-defined offset bands. For example, [to] have five bands [that users] can define. For example, 20-50 MHz, 51-100 MHz. And if key in a frequency within band an offset is added.

Our Kraken software is currently designed entirely for coherent radio experiments/use-cases, such as radio direction finding and passive radar.

We don’t have our own general purpose receiver software, but if you’re using it as five separate RTL-SDR tuners with multiple antennas, then you can easily use existing highly developed software with RTL-SDR support such as SDR#, SDR++, HDSDR, CubicSDR, GQRX, SDRAngel, SDR-Console V3, etc. You can use them exactly like you would with five RTL-SDR dongles. It’s fairly simple to open multiple instances of SDR#, so you could open five instances, one for each of the five tuners.

The magnetically mounted aerials you are offering for use with KrakenSDR - what is the operating frequency/bandwidth?

This is still being finalized as we work on the telescopic antenna, but we’re aiming for 100 MHz - 1 GHz by adjusting the telescopic antenna for the correct 1/4 wavelength.

The good thing about correlative interferometry is that you do not need the antennas to be perfectly tuned to the frequency for DFing to work. But you will get less multipath error and hence better results with tuned antennas. Of course you obviously don’t want five one meter whips on your car roof when driving around though. In many tests we’ve been using the antenna stubs shown in the photos which are designed for the 800 MHz band. Even when using those to DF a 400 MHz signal there is no problem.

Is it possible to make a multi-band array by putting multiple different sized elements on the same arms, or adding more arms and adding different sized elements there? Then having a switch to switch between the arrays?

Most commercial DFing antenna arrays use a stacked system. With the larger elements for lower frequencies on the bottom, and the smaller elements for higher frequencies on the top. The reason is that the extra elements or arms will cause the signal to be reflected and refracted, resulting in high multipath corruption which leads to very poor results. In your array you don’t want anything blocking the ‘sight’ of the elements out to the horizon.

(Example commercial stacked array array https://www.alarisusallc.com/product/df-a0085-dual-polarised-df-antenna-array-20-3600-mhz/)

What would be the error margin in tracking continuous transmitting leo satellites ? Also what would be the the best antennas and antenna arrangement for this ?

We would need a clarification on what you mean by error margin in this case?

I want to clarify that our own beamforming DSP code for an application like this has not yet been created. At the moment we only have code for direction finding, and passive radar. So we have not yet considered things like the optimal antennas and arrangement for beamforming.

Having 4-5 identical antennas arranged in a grid would seem like a good starting point for further investigation. You would need to be quite accurate in terms of antenna positioning, so perhaps a PCB patch antenna based solution would be best, depending on what frequencies you are interested in.

Is the hardware adapted to do antenna diversity, for instance to get better signals indoor? What frequencies will the antennas be optimized for?

KrakenSDR is a software defined radio, so it will only do what the DSP code tells it to do. We don’t yet have our own code demo’s available for starting diversity / beamforming experiments, but if you are willing to delve into writing some DSP code, implementing diversity should be possible. The antennas are still being finalized, but there will be a telescopic antenna included that will roughly cover the ranges from 100 MHz to 1 GHz.

Hi! I found KrakenSDR very interesting. I’ve a question: could it be used to make an weather/precipitation radar? Thanks.

Weather radar typically use S-band and X-band frequencies which are unfortunately well outside the range of the RTL-SDRs on board. In addition, for a weather radar you would need to transmit your own powerful pulses, which you’d need a specific license for.

The frequencies typically used for passive radar are much lower in the UHF bands, and those don’t really reflect on precipitation. So in short, unfortunately a weather radar is not possible with KrakenSDR.

I’m a radio amateur and think of mounting the KrakenSDR on top of the car, next to antennas for 27 MHz and 144/430 MHz. Is there any filtering etc… so I can transmit on these frequencies? But Ithink it will destroy the receiver immediately. I just wanted to ask. In that case would it be enough to turn the KrakenSDR off or do I need to unplug the antennas?

Yes you would need to be careful when transmitting with power close to the KrakenSDR antennas. As with most SDRs, there is no input protection against nearby transmitters. The RTL-SDRs on board use the R820T2 tuner, which has a maximum +10dBm input rating.

Even if the device is powered off, I would still recommend disconnecting the antennas as a powerful transmitter could cause the ESD protection to begin shunting.

Do this still support an external reference clock? Also, for ham EME work, what is the observed noise floor with no rf input?

KrakenSDR won’t support an external clock in this version. We may add support in future versions, but it would need to be an external 28.8 MHz clock which is rare. If there is a really compelling use-case we could look at supporting 10 MHz clocks in the future.

The KrakenSDR consists of 5 RTL-SDRs, so the MDS measurements are similar, sitting at around -130 to -140 dBm depending on frequency.

Is the start/center of the 2.6 MHz specified by the user from a control GUI?

Yes the GUI is used to specify the center of the bandwidth.

Does the KrakenSDR  compute DF on ALL signals found in that bandwidth? Can a smaller BW be specified?

Based on our current direction finding code, we decimate down to the size of the signal of interest, and only that signal is sent on to the direction finding algorithms. In future upgrades to the code, we’re aiming to eventually support multiple channels within the full bandwidth.

Will it work on weak intermittent signals such as CW, SSB and FT8?

With your mention of CW, SSB and FT8, i’m assuming you’d be interested in DFing HF signals? Unless you mean 50 MHz FT8?

The KrakenSDR can only support frequencies above 24 MHz, so it won’t work on HF signals. For HF this method of direction finding is not recommended anyway, due to the size of the arrays required. For HF distributed TDOA methods like what the KiwiSDR use are much more appropriate.

But for intermittent CW beacons in the VHF/UHF range it can work. When they get weaker this becomes more difficult to detect very short bursts, but we are working on ways to improve sensitivity.

What will happen with multiple FT8 signals all within a 4 KHz BW but coming from different directions?

If you have multiple signals appearing simultaneously in the same bandwidth a correct result will not be possible. In this case the idea would be to channelize the 4kHz bandwidth into multiple channels (with more advanced code that you would need to write).

I’m interested in setting up an array of horizontal antennas for DFing on an operator-selected signal in a ham radio band during a contest when multiple signals appear on a waterfall and spectrum. The point is to be able to rotate the separate high-gain antenna in the correct direction to contact the selected signal. So what I had in mind is a way for the operator to view the weak SSB/CW/FT8 signals, select one of them in a very narrow bandwidth (50 to 3000 Hz typically), trigger the DF algorithm, and then point the separate high-gain array in the correct direction.

If it’s all VHF/UHF band work, I think something like what you describe would be possible, but it’s a tough task and there are a few things to consider, and probably maybe some additional coding would be required to make a system like this work well. First thing is you’d want to write code to somehow tie the particular FT8 signal to the bearing produced. If they are coming in fast, this could be difficult as the DSP requires a certain amount of data so be able to compute a solution. So if there happen to be multiple signals within that block of data, there is a problem. You’d need to write code to separate out the particular FT8 signal that you want which is probably not a trivial task. Generally you’d want at least ~10-100ms of data for a good solution.

Also you’d need to really consider the effects of multipath. Getting one reading from a distant station can be quite inaccurate due to multipath, which is why for DFing the recommended method is to take multiple readings from a vehicle, or have multiple fixed stations spread around a city wide area. If the station is LOS, and there are few obstructions, flat terrain, then there are likely to be very few multipath problems. But if it’s over the horizon, or with hills/buildings around, then multipath corruption is certainly going to ruin your day due to refractive and reflective effects, unless you can take multiple readings from many locations to average it out.

I’m still confused about mention of a 2.6 MHz bandwidth. It doesn’t make sense to me for the software to search for a signal within that large bandwidth, and then DF on whatever is found. There are likely multiple signals inside any arbitrary 2.6 MHz slot except in artificial situations where an isolated signal is deliberately setup.

The RTL-SDR provides 2.56 MHz max stable bandwidth. There will be probably be multiple signals within that bandwidth, and the DSP can only work with one signal at a time. So we use decimation and FIR filtering to reduce the bandwidth down to nearly the exact bandwidth and frequency of the signal of interest.

Will there be a way for the operator to specify the spacing of the antennas in the DF array, or do you envision a fixed orientation of the multiple antennas in the array? I sure hope that a fixed array size is not required.

Yes the array size needs to be set in the software. The size of the DF array needs to be appropriate for the wavelength of interest.

Can the KrakenSDR passive radar be used for detecting meteors?

This is something we will be actively looking into in the future, but we have seen prior work (e.g https://nenufar.sciencesconf.org/data/program/Vendredi_S3_3_Azarian.pdf) using passive radar interferoemtry to detect and track meteors. The main question to investigate is if the 2.56 MHz bandwidth provides sufficient resolution.

The goal of the future passive radar DSP code is to be able to detect and determine a distance and bearing towards reflected objects using an antenna array. So in theory, if everything was perfect a single station could determine the location and track of the meteor (at least the RF reflective trail part behind the meteor). In the real world it’s obviously going to be a lot noisier though, so multiple stations would be needed.

"The most important thing about these antennas is that we are specifying very tight tolerances for cable-length variance between the five units. In a phase-coherent system, it is important that antenna coax lengths are identical, as even a few centimeters of difference can cause a phase offset, which will result in skewed bearings."
Would it be possible to use a fixed RF/noise source at some small distance from the array to allow it to self-evaluate the lengths?
Can one of the antennas transmit while the others receive? If the antennas are co-planar I would think the math to self-characterize might not be too hard.

Yes, using an external noise source is a good way to calibrate the full system. And transmitting out of one of the antennas is a solution that could also work.

However, there is a problem as it is not legal to transmit wideband noise out in the open, as that could be classed as a jammer. You would need a powerful noise source to drown out other signals (including your signal of interest) as those signals would cause interference to the phase calibration process, or some calibration software modifications to find an empty patch of spectrum within the bandwidth. Certainly CE/FCC certifications would not pass. So the noise needs to be contained within the PCB/enclosure.

There is the possibility of building a custom antenna array with noise source and switch built in to the array base itself. So it would disconnect the antennas during calibration to ensure no illegal emission and no interfering signals, and transmit noise down the cable. At least then you have the cables and any front end filters/LNAs perfectly calibrated. But I think this level of calibration precision is only really necessary once you start getting into frequencies above UHF, and not necessary if you can ensure cables are identical and ideally phase matched in the first place.

I was wondering how big an antenna array needs to be relative the signal wave length. I was wondering if the roof on my house would be big enough for an antenna array operating at 26.450MHz, truck CB?

We have information about array sizing on our older KerberosSDR quickstart page at www.rtl-sdr.com/KSDR, but please be aware that the extra element means that the array will be slightly larger than with 4-elements.

At the lower frequencies array sizing becomes very difficult to implement practically due to the physical wave-lengths involved. For 26.350 MHz you’d be looking at an array radius of at a minimum 2.5 meters, and ideally closer to 4 meters. Going down to a 3-element array might give you more room with ~1.5 meters probably being the minimum radius then, and ideally around 2.5m.

Just curious if any study was made of how quickly a bearing can be acquired, i.e. what is the shortest kerchunk duration that the KRAKEN system can get a bearing on.

Have had pulses down to 1ms detected by the squelch code. Even shorter is probably ok if the pulse is strong.

With such a short pulse the signal needs to be fairly strong, and you need to make sure to decimate right down to the bandwidth of the pulse, so that the pulse bandwidth dominates the received bandwidth.

The operating frequency range is listed as 24 MHz to 1766 MHz, same as a normal R820T2 sdr. Many single-board RTL-SDRs have issues in the L-band with losing PLL lock, and this is something I am specifically concerned about, as I want to operate around 1620MHz. Do the KrakenSDRs have this same problem? I’ve seen that driver changes and cooling can help or even solve the issue, but I haven’t had a chance to implement those on a board yet.

I’ve tested operation at an ambient 22C temperature at 1760 MHz for several hours without the PLL losing lock. This is without any cooling, just the raw PCB, no the enclosure and cooling fins. So I think this won’t be a problem under normal circumstances as the enclosure is going to help cool it even more. However, if the ambient temp is very warm, or the room very stuffy, running a fan over the cooling fins might be required.

I know for sure that cooling solves this problem, and in most cases the driver changes also help reduce the amount of cooling required.

I am wanting to build a radio based solution that I can put on my property that would tell me the exact location of a drone flying on my property. I then want to correlate this information with the GPS on the drone and use it to correct the error on the GPS. Like DGPS only not having to spend a small fortune on RTK-GPS antennas and radios. Would it be possible to locate a radio array for example at the center of a property, say a large home or estate, and then track any drone flying within that property? I assume yes, but what kind of accuracy would we be talking about, and could it be used to correct and provide accurate navigation to the drone so it can safely fly around the property without collision. Thanks!

The RDF isn’t going to be able to give you a location more accurately than GPS can. The RDF accuracy is only going to be within a few meters, to hundreds of meters, depending on the distance. The accuracy will also depend on the multipath environment, so things like buildings/hills/obstructions etc are going to cause the signal to reflect and refract causing distortion to the bearing.

I also believe that most drones operate on frequencies outside the range of the RTL-SDR.

If you’re talking about passive radar detections, this will also have the same issue with accuracy not being more precise than GPS.

1. What are the maximum cable we can attach from 5 element antenna to KrakenSDR? 2. Can KrakenSDR detect radio communication for example, on channel 16 maritime at 156.800 MHz?

1. The maximum cable length will be up to you to decide, depending on losses and how precisely you can cut each to the same length. Ideally with very long lengths you would probably want to use a VNA to precisely phase match the cables.

2. Yes 156.8 MHz is within the RTL-SDR range. If you are DFing you can set up an appropriately sized array for that frequency.

I’m thinking of getting a NVIDIA Jetson Nano and was wondering if it will work for the Kraken based passive radar you have mentioned? Will both the 2G and 4G work?

At the moment we’re unsure how well the Jetson Nano will work as the new live passive radar code is yet to be implemented (only the older non GPU optimized code is functional right now). But we do have a Jetson Nano which will be used for testing the new code to be developed in 2022. It is likely that the GPU will give a good boost to passive radar processing speed, but unsure if we’ll need something more powerful that the Nano.

By 2G and 4G do you mean that you intend to use 2G and 4G mobile phone towers as the passive radar illuminator? Any digital wideband signal should work well, but generally mobile towers will be a lower power and may only be useful for local reflections. Wider area signals like HDTV, DAB etc are generally more useful for passive radar.