The latest 2.2.0 version of Radwave is now released. It's the second non-alpha release, so it is now available without requiring a subscription to this blog. You can find it here:

https://www.radwave.com/releases

Changelog for Radwave Explorer:

  • Fixed tag creation bug that caused "Accept Tags" button to fail

Changelog for Radwave Engine:

  • Massive improvement in download speed from Breakthrough Listen Open Data Archive
    • I discovered that the Open Data Archive was rate-limiting full-file downloads to just 10 Mbps. However, partial-file downloads were not rate limited at all. After discovering this, I changed the downloader implementation to perform two partial downloads of the file, which allows download speed to saturate the network connection. This has been tested on 100 Mbps and 300 Mbps connections.
  • On Linux laptops, closing the lid will typically cause the operating system to pause processing. Information was added to Usage Info about how to configure Linux laptops to avoid this processing pause. This just made it easier for me to kick off processing on my laptop, and stow it away for a while until it completed.
  • Fixed a low level time tracking bug. The issue here stemmed from the headers in the GUPPI files from the Open Data Archive. The format of these files is provided in this paper: https://arxiv.org/abs/1906.07391. If you look at Appendix B.1 in that paper, you'll see that the TBIN term is ideally equal to 1/abs(CHAN_BW). But if you look at Figure 16, which shows a typical raw header, you'll observe that TBIN=3.41333333333333E-07 and CHAN_BW=-2.9296875 (MHz). If you store those values as 64-bit floats, you'll observe that there's a slight difference of between them. While this difference is slight, it's enough to be observed in the hex readout, e.g. TBIN=0x1.6e80fe033c8c0p-22 and 1/abs(CHAN_BW)=0x1.6e80fe033c8c6p-22. It's clear as a human reader that TBIN has repeating 3s, and if we append a single additional 3 to the string-serialized TBIN value that's in the GUPPI header, then the TBIN=1/abs(CHAN_BW*1e6) would be correct. In the Radwave Engine, I found that I was interchanging these two values for one another, which caused non-trivial time discrepancies to appear when calculating sample times for samples deep in collections, and ultimately could cause processing failures during Stage 1 of the Radwave Engine processing. I fixed this by
    • Avoiding the use of TBIN throughout the code
    • Using integer sample-based time tracking where possible, and calculating UTC sample times only as necessary

Known Existing Bugs/Features

Radwave Engine:

  • The progress percentage and time remaining on Stage 1, 2 and 3 is not accurate, and can appear completely unintelligible.

Radwave Explorer:

  • When viewing a file with I/Q enabled, and you run the natural audio processor, the window that shows the output is very small. You have to click/drag on the lower right corner to expand the window.