Currently using the RPi4 image and I am looking to learn more about the Advanced Feature described below:
Advanced Feature: The KrakenSDR app actually does something cleverer than calculating simple intersections of bearing lines. It uses the full 360 degrees of data given by the correlative interferometry algorithm. This 360 degrees of data includes multipath direction data too. It then overlays this data on a grid, activating each cell that the 360 degrees of data lies on by some scaled amount. Over time, the cell with the most activations is deemed to be the one containing the transmitter location.
I have the output from my log files as well as the DOA_value.csv. I would really like to take my current position and be able to confidently retrieve a latitude/longitude coordinate for where the signal is originating (just like the Android App). I have been browsing the code the last few days and experimenting on my own, but I think a lot of the front end functionality for mapping operations is happening in the Android app. Are there any more publications available that describe the ways to reliably get a position for the signal outside of the Android app (which is a great app I must say)?
My current use case was going to be write a service that either hits the DOA_value.csv or the log files (as they are written) and will ultimately return a lat/long point for where the signal is originating. Any guidance would be greatly appreciated.
The Kraken has no knowledge of maps, and simply outputs the bearing information as a 360 length array, with each entry for 1 degree.
In the simplest form, determining a lat/lon from multiple bearings is simply determining the max bearing from the 360 points, and calculating the intersections between all the max bearing lines.
The algorithm we use however is slightly different. It casts a grid over the search area then each of the 360 degree values for a single reading is cast over the grid points. Each grid point is activated by the strength of that particular value. Over time, the most highly activated grid points will reveal the transmitter location.
This algorithm is a lot faster when operating as an online system as we have a fixed computational cost per log entry, rather than ever increasing computational complexity as the log file grows larger. As we don’t need to check intersections against all previous log entries.
That makes sense Carl. Seems like a good approach to finding an area geographically. In my mind there are two difficult portions left:
Determining the ‘size’ of the grid. Maybe its just a static grid that expands outward at a hardcoded amount from your current lat/long?
Distance. Lets say a bearing line leads out from my location, how do all cells along that vector not get the same ‘activation level’? How does the app know a signal is .25 miles away and not 3 miles away on the same bearing?
Appreciate your responses, they have been a big help in understanding.
Yep the grid is just by default set to 10km. As the user approaches the edge of the grid, the grid will recenter around the user.
The app does not know from a single bearing how far away the transmitter is. The only way to know the transmitter location is through triangulation. You need to make multiple readings at different locations. The same cells corresponding to the TX location in the grid will be activated over and over, assuming the bearings always point in their direction.
One last question, when does the Android app ‘settle’ on a transmitter location?
Do you guys wait for a queue to fill up and from there you have the confidence to settle on a lat/long location or is it something else under the hood that you use to decide its time to plot a transmitter location on the map?
The estimated location is always plotted, it just continually updates the position as more data comes in. It turns green when there is enough activations on a specific cell to have it activate navigation to that estimated point, but it does not necessarily mean that it has found the location when it turns green.
The black dot on the map? That is simply a point 10km out from the current location located an average of the max bearings. It’s used initially to provide a travel direction. Once the grid starts getting populated, the grid takes over.
Carl as you mentioned triangulation can be used to estimate the distance of the transmitter. In case there are two kraken sdr devices which have common GPS generated timestamp can you estimate what can be the time offset between the two estimations (for the same transmission)? I am thinking that the ±block_size might be a good search area for matching the angles.
That sounds like you are describing TDOA, which is another DFing method. It can be tricky, because the GPS timestamps have to be matched exactly with the signal, and things like OS jitter and USB timing make that impossible to do on the Pi 4 itself. The GPS timestamp or GPS PPS burst to correlate on needs to be injected in hardware, via a FPGA or perhaps a wideband noise pulse from GPS PPS.
If you Google for RTL-SDR TDOA you’ll see one implementation which used DAB timing signals and RTL-SDRs for TDOA.
Thank you for you response. I am not describing TDoA but two parallel DoA where I want to match the angle estimation from kraken sdr 1 with an angle estimation from kraken sdr 2 so to perform triangulation using these two angles. I was asking what can be the search area. For example for estimation from device1 at time t1 with angle a1 I have to expect an other estimation from device 2 (for the same transmitted signal) in t2 with angle a2. How far can t1 be from t2 given than the hardware is almost identical and have common GPS timestamp? In this way, I will use a1 and a2 to perform triangulation. I believe ±block_size is a good search area. Do you have an opinion on that?
Extending the question I would like to kindly ask you to give more information on what is exactly the Update Rate and the Latency that are calculated under the DAQ Subsystem Status table of the GUI. The note on Update Rate is “How long it takes to compute. Should be faster than the data block length, so that no frames are dropped”. The note on Latency is “Time taken from signal entry to data output”. Thus, by having Update Rate consistently smaller than the block size we are sure that no data are dropped. Correct? Also, as far as the Latency, as I have understood the timestamp of the data is generated during the production of the data and it is forwarded to the DSP app where is used to describe the angles estimation in the csv. So, how Latency affects the system? I mean when should I take it into account?
In that case timing isn’t really critical unless you have a very rapidly moving transmitting object. Our online mapper already does this (map.krakenrf.com), and we don’t worry too much about the exact timing of the signal. The bearings used are just whatever the latest bearing is from the krakensdr.
Yes update rate is the computation time of the DSP, and latency is the total time from signal arrival at the krakensdr to output, so that includes the DAQ acquisition time (data block length), and processing time of the DAQ and DSP.
Latency isn’t used for anything at the moment. In the past we had the idea to use it to help better match the GPS location in the Android app at the time of the signal acquisition, but it made such a negligible difference to the result that we decided to just ignore it. Part of that is because the majority of the latency is the signal acquisition time and compute is negligible.
Thank you! It is not that the target is moving rapidly but that I am trying to detect multiple targets that are transmitting burst signal in near time.
Hello, could I synchronize two Kraken RF receivers (that have common GPS clocks) to receive at the same time? I mean the generation of the signal block to be time aligned?