I’m nearing the finish line (I hope) of an overdue update to the Wirecutter guide to WiFi hotspots. The research for that had me repeatedly subjecting an array of loaner hotspots from all four nationwide wireless carriers to tests of the two core metrics of bandwidth and battery life.

It hasn’t exactly been my most exciting work.

For bandwidth testing, I’ve continued to rely on Ookla’s Speedtest.net Web, Android and iOS apps to clock the download speeds, upload speeds and ping times each hotspot has served up. This is pretty much an industry-standard benchmark, and these apps are simple enough to run.

But getting data out of them is another thing:

• The iOS app creates a .csv file you can open in any spreadsheet app that includes every relevant bit of data–date and time, GPS-derived location, WiFi network name, download/upload/ping measurements, shareable public link–and attaches it to an e-mail message.
• The Android app also generates a .csv file–except that choosing to have it saved to your Google Drive leaves you with a .eml mail-attachment file. You have to e-mail it to yourself to get a usable .csv, at which point you discover that this export doesn’t include the name of the wireless network.
• The Web app’s “Export” button yields a third type of .csv file, one without a record of the WiFi network name, your location, or a shareable link.
• No, the option to create a Speedtest account won’t help–because you can’t log into that from the mobile apps.

Ookla is owned by PCMag publisher Ziff Davis, but that has yet to result in any corporate pressure to make exporting measurements less janky for the hardworking journalists at that and other Ziff tech media properties.

Testing hotspot battery life only requires recording the times you started and ended each trial. But because these things often run for 12 hours or more, it’s not realistic to tether a laptop to a hotspot and keep working nonstop until the hotspot battery expires and the connection drops.

To ensure my laptop would be keeping each hotspot working full time, I opened a page to NASA’s live YouTube channel. Beyond running up the social-media metrics for one of my favorite four-letter government agencies, keeping the browser on a single live channel avoids the risk of YouTube’s recommendations sending me off to some nutcase conspiracy hub.

Because I’m not always that smart, I didn’t think to check my laptop’s ability to log a wireless connection going offline until after I’d spent an hour and change watching one hotspot linger at 1% of a charge.

As a helpful StackExchange thread pointed out, that logged data awaits inside Windows. Type “Event Viewer” in the taskbar search, open that app, select “Applications and Services Logs” in the left-hand pane, double-click the center pane’s “Microsoft,” “Windows,” “UniversalTelemetryClient,” and “Operational” entries in succession, then select “Filter Current Log…” in the right-hand pane. Type “55” in the resulting dialog’s Event ID field, hit “OK” and you’ll see a series of entries.

Assuming you check this right after seeing that the laptop went offline, opening the most recent should reveal a properties field consisting of “Is the Internet available: false,” with the time corresponding to when the hotspot died.

Since I don’t have a Mac laptop, I’m not sure how you’d do this on one. A different StackExchange thread suggests a Terminal command, but that doesn’t work on my iMac–maybe because this aging desktop isn’t running the latest macOS edition. It would be ironic if you have to hit the command line on a Mac to perform a task that Windows lets you accomplish inside a graphical user interface–but the Windows Event Viewer app is mighty ugly itself, and neither operating system covers itself in glory in this aspect.