KrakenSDR API endpoints and documentation

Why is that? Can you give me more details? In theory MUSIC algorithm can detect multiple signals in the same time window.

The algorithm can measure the angle of arrival for multiple signals in the same time window, as in it can output multiple peaks on the same DOA graph.

Just select the expected number of RF sources in the GUI to what you know to be the number of transmitters. But at best it will result in three peaks on the same graph, and there is no way to know which signal each peak corresponds to.

But if the angle of arrivals happen to be close to one another, within the resolution limits of the 5-element array, then the peaks will be blended together.

1 Like

Thanks, I am trying to understand better the code for this reason I am asking so much question. The work is very very good and I am trying to get the best from it and make the necessary changes in order to fit best in my use case.

One more question, can you explain to me the difference between the channel and the VFO? What is the variable channel_number and why is useful?

channel_number is the number of hardware channels. It’s modifiable to be backwards compatible with the KerberosSDR.

VFOs are software defined slices of the spectrum that should cover a single signal.

1 Like

Hello again, I would like do ask if kraken sdr have some utilities for mitigating reflections?

Utilities like algorithms? Only what we have in the software. You can try the decorrelation algorithms in the web GUI, but they are still quite experimental and may not work correctly.

1 Like

I can verify that the confidence level is not really useful. If it is not used by Android app too then it may be removed. I upload a scatter-plot for reference. The plot depicts the error (the absolute difference between the real and the estimated angle) vs the confidence of the estimated angle

error_conf

I want to log at about 150 ms. I have an odroid n2+ (yes, I know about the USB issues) and i understand the block time adjustments that need to be made, but I am using the android app and I can’t get the log time to be under a second. Is this possible? why the limitation? I’m also interested in much larger logfile limitations, but can’t find those settings.

The Android app is just soft limited at 1s, to prevent someone accidentally creating a log file that grows huge too quickly. We can look at reducing that period.

Is this

2. Max DOA Angle in Degrees in Compass Convention : (3 Digit 000 - 359, 90deg East),

still applies to version 1.8.0? Or has something changed in taking into account the heading. Because I use the android app to plot the data and the direction is off. It is like the android app does not take into account the heading (from the data.csv file) to correct it while plotting.

Nothing should have changed. Check what your heading sensor is selected as in the app. When you plot your data file it will use the data from whatever heading sensor is selected.

1 Like

I can see this behavior when using root music algorithm. Can this be due to too many wrong estimation compared to MUSIC?

Root music is a different type of algorithm, it won’t work well with the app. It only produces a single bearing angle output.

Nice. I understood. On the other hand, for MUSIC the app plots the amplitude in each angle (not only in a single bearing angle like the angle with the max amplitude). Correct?

Yep, that is correct.

1 Like
18-377. Full 360 degrees DOA output. First element specifies DOA power output at 0 degrees, second element power at 1 degrees etc. NOTE: Uses unit circle convention, so due EAST is classed as 0 degrees, NORTH 90 degrees and so on. Needs to be rotated into compass convention.

I think this is wrong, at least at the latest versions. I conclude that the doa_result_log is already in compass convention. When I get the index of max, I get the same value as the value in

2. Max DOA Angle in Degrees in Compass Convention : (3 Digit 000 - 359, 90deg East),

Are you sure that you’re running the latest code with the fix for the max DOA angle? I just had a look, but I can confirm the full 360 output is in unit circle convention.

I am using the version 1.7 and when I take the doa_result_log.index(max(doa_result_log)) I get the same index with the theta_0_list for each j. The theta_0_list is passed as the second attribute in the csv and the doa_result_log as the last one

Is that the V1.7 with the latest code pulled from the GitHub?

The image files haven’t been updated yet with the latest fixes, to get them you have to do a git pull.

I can not understand exactly what you mean. If I git log I get

Merge: ed7c56f e8d8e28
Author: krakenrf <[email protected]>
Date:   Fri Jan 19 13:58:35 2024 +1300