Introduction

To see how well a WSJT-X based DoTDoA system could actually perform, I built the following system out of web-based SDRs, ft8modem controlled JT9 instances, and some custom analysis software written in Julia.

This architecture isn't optimal because all of the complicated signal processing ends up running on one computer, but I'll have more to say about that later in this post. This particular distribution of components has the virtue of being simple to set up on one's own. While the figure shows 3 simultaneous SDRs, I have run this setup with up to 5.

Analysis

In the previous post, I described how the "spots" from a two WSJT-X instances can be transformed into a list of "cospots" and then "double-cospots". In the figure, above, the "spots" are the log files and the final analysis program does the spots ➔ cospots ➔ double-cospots transformation according to which "unknown" sending station it wants to focus on.

Recall that the previous post concluded that for any pair of receivers $(R_x, R_y)$ we would end up with a value of $^{xy}M_U$ for each double-cospot between the two receivers. That means that the example in this post will end up with three sets of values:

• A set of $^{AB}M_U$ values for $(R_A, R_B)$
• A set of $^{BC}M_U$ values for $(R_B, R_C)$
• A set of $^{CA}M_U$ values for $(R_C, R_A)$

There are many different ways that these three sets can be statistically analyzed. For instance, one of the simplest would be to calculate the mean of each set of values, resulting in one $^{xy}M_U$ value for each $(R_x, R_y)$ pair. Then we could draw the three branches correxponding to these values and we'd get something that looks like this:

The yellow paths are branches of spherical hyperbolas that should intersect at the location of the sending station, and the sending station is located in the small cyan Maidenhead grid.

This very simple approach already shows promise but for a "mean" to be truly representative of the samples (our observations) the distribution of samples should be unimodal and symmetric. For various reasons including long vs short path propagation, ground vs skywave propagation, etc, the distributions of our samples are often not unimodal and/or not symmetrical. The following are some typical samples collected for five pairs:

So the analysis program I've written works with these distributions instead of working with simple "mean" values.

The plots above probably require further description:

• The black dots are $^{xy}M_U$ sample values
• The black line is the estimated distribution of the sample values
• The central greenish region is the "baseline" between $R_x$ and $R_y$
• The center vertical line, dashed red, is the midpoint on the that baseline
• The x-axis ranges from about -135 to +135 (recall that Earth has a circumference of about 135 light-milliseconds)

In the following figure, I've superimposed hyperbola branches onto one of the plots:

Remember that our goal is to find the branch for the $(R_x, R_y)$ pair corresponding to this plot. The black line is an estimated probability density (EPDF) and it shows us the likelyhood of any particular branch being the right choice. In the example, we see that the right choice is mostly likely in the negative range, but there is also a smaller possibility that it's slightly into the positive range. The width of these spikes can be thought of as the uncertainty around their respective peaks.

At this point, we might be tempted to choose the position of the tallest peak as the best $^{xy}M_U$ value, but doing so would be similar to the "mean" approach we previously discussed: it would throw away all the uncertainty information.

To preserve the uncertainty information, the analysis program can be thought of as sweeping the entire EPDF across the globe to create one "fuzzy branch". In the following figure, a few copies of the EPDF have been superimposed to help you see how the "fuzzy branch" relates to the EPDF.

In the next figure, we see what all three of those EPDFs look like, all at once.

At first glance, all that fuzziness might make it seem like this is a step backward in our attempt to figure out exactly where the transmitter is, but there's one more step we can apply to this analysis: we can either multiply or add the fuzzy branches together to emphasize the points where all three are present. When we do that we end up with the next figure.

The three fuzzy branches have now been transformed into a heatmap and the red dot highlights the point of maximum "heat". It appears to be very close to the Maidenhead grid square (cyan) that the sender reported. Let's zoom in for a closer look:

The red contour in this figure shows the portion of Earth's surface where the heatmap is "hotter" than the "coolest" point in the grid square reported and covers about 0.06% of Earth's surface. Said another way, about 99.94% of the Earth's surface is more-or-less ruled out by this analysis.

The figure also includes a black outline which shows the theoretical best that any analysis could do if we're resolving to 1 light-millisecond on each pair's baseline. The size and orientation of the theoretical black line is quite similar to the size and orientation of the red contour line, suggesting that the method of analysis is valid and effective.

Conclusion

I believe that this proof-of-concept demonstrates that it's reasonably easy to validate the locations reported in FT8 messages, using nothing more than data already calculated by WSJT-X's JT9 executable.

Why bother verifying? Well, several aspects of the hobby depend on reliable location information, awards and contests being two obvious examples. Systems like the ARRL's "Logbook of the World" and WSJT-X's "SuperFox Mode" use cryptographic methods to establish some degree of identity verification from which locations can be reasonably inferred, but these approaches require manual steps be carried out by people. Verifying reported locations based on (Do)TDoA can be completely automated and I wonder if there's anything interesting we can do with that within the FT8 community.

In the next post I'll be describing a different system that I'm currently working on, one that will actually take advantage of distributed signal processing.

73s