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.