DJ3EI

I have a homegrown C++ program that fetches data from the IC-705 built-in USB sound card and pushes it to a raw sound file, mono, nominally 48000 samples / second (it's actually about 47999,67). It turns out the Linux pipewire API hands out the sound samples in batches of 1024 samples at a time. Whenever such a batch comes in, the program fetches the "nanoseconds since the epoch" time stamp from the system and writes the number of bytes received and that time stamp to an auxiliary "marks" text file. The clock is NTP disciplined, or it was until about 16:36 UTC - then I goofed. I use the software chronyd for that. New: Yet another python program calls chronyd's control program chronyc every 10 seconds and writes timestamps of the call and chronyd's opinion of the state and precision of the system clock to yet another auxiliary text (CSV) file chrony.track. I experimented with using that information to fine-tune the timestamps retrieved from the marks files. The rest is a bunch of Jupyter notebooks and a bit of Python code. Running these notebooks is one of the rare occasions where I'm happy my PC has 16 GByte of RAM. As I learned the hard way, it is not wise to open several of them simultaneously. Normally, 80 m is best. Today with evening K=5, 40 m was best and the morning 20 m transmission also useful. The afternoon 20 m was weak, as was 80 m. I threw my whole bunch, raw files and software, into an archive and made it available as https://dj3ei.famsik.de/attic/2026-06-05-FMTLab/DJ3EI_FMTLab_2026-06-05_raw.tar.xz . That archive has a sha256sum of cff7505f7308f0805cc6e4e18354e5c7c7dea4f461e96945aa4a6ddfa5deb440 and a size of 538 MByte. I may eventually document the details a bit via my blog https://dj3ei.famsik.de/blog/ .

The 80 m band transmission was again by far the strongest, so I exclusively used that. But I wasn't able to find the correct frequency until about 2.6 minutes into the transmission, as it deviated considerably from the previously advertised one. So I missed the initial transmission at a well-known frequency. As I had calibrated my rig with the RWM time signal transmitter that day, I hope to be reasonably fine anyway. I recorded audio with well-known USB dial frequency, and record timestamps each time a 1024 audio sample batch comes in from the rig. All error boundaries are just educated guesses. With FFT from scipy, I found the audio frequency 2312.586 Hz ± 0.1 Hz. My trx was set at USB 3563400 Hz, I estimate its true frequency as 3563399.950 ± 0.5 Hz and allow maybe another ± 0.5 Hz for ionosphere instability. So 3565712.536 Hz ± 1.5 Hz. For the pulse length, I used a convolution each to find the rising and falling edge of each pulse. As far as I can tell, FMTLab did not send the full 360 pulses, but sometimes left out some at end of a pulse minute. For each pulse minute, I determine the median of the pulse length and throw out all pulse lengths that deviate from it by more than 2 ms (QSB). A total of 245 samples survived, the average is 43.239 ms pulse length. I notice that the same way to measure the pulse length of the 100 ms and 50 ms pulses produces values about 1.1 ms too short, so my pulse length value is 44.339 ms ± 2 ms. I have measured the total RWM delay to be 31.9 ms ± 0.7 ms, estimate the propagation delay 5.85 ms ± 0.2 ms, so my processing delay comes out at 26.05 ± 1 ms. The propagation delay to FMTLab's QTH is estimated at 2.4 ms ± 0.2 ms, so the total FMTLab delay is 28.5 ± 1.2 ms. Measuring when the 100 ms pulse starts yields an average value of 40.631 ms into the full second (compared with the PC's NTP disciplined clock). Subtracting the FMTLab delay yields 12.159 ms with an error bound of maybe ± 3 ms.

Calibrate IC-705 frequency via RWM time signal transceiver. Homebrew Software to pull audio from rig and write timestamps for audio parcels as they come in. Precision of timestamps relies only on NTP. A lot of Jupyter Notebook magic to do the actual measurment.