Frequencies in I/Q recording are ~5.128 kHz low

[Frank O]

Recently I did field recordings over three nights with an Airspy HF+ Discovery and SDR Console v3.0.24 to capture non-directional beacons in the <500 kHz spectrum.

The first two nights, the bandwidth for the radio and recording were both set to 384 kHz, centered on 365 kHz. Everything appeared normal with the I/Q recordings.

On the third night, the only configuration change is that I changed the radio bandwidth to 768 kHz and modified the recording bandwidth. I intended for this to be 540 kHz wide centered at 270 kHz (so as to capture 0 to 540 kHz), but I see in the recording data that it was centered at 270 kHz with a bandwidth of 550.260 kHz.

When I play back the recording in SDR Console, all signals are about 5.127 kHz below their published frequencies. As a result, NDB and DGPS decoders are not recognizing signals.

The first obvious thing that occurs to me is that the low end of the recording bandwidth overshot the 0 kHz mark by 5.130 kHz -- within 2 to 3 Hz of the frequency error that I'm seeing across the recording.

Is there a way to fix the I/Q file so that frequencies are correct, enabling signals to be decoded? Or is this one of those "Oops, don't do this again next time" experiences?

[Simon G4ELI]

This is obviously a bug, will fix next week after 3.0.26 is released.

[Frank O]

Thanks, Simon. I don't know much of anything about how I/Q .wav files are structured. My overnight recording for the date with the frequency error is divided into 88 .wav files, each just under 1 GB in size. If I wanted to try to repair them, is there something like a starting frequency appearing in one place in each .wav file that could be modified with the right kind of editing software? Or is the error scattered across each .wav file in such as way as to make a fix unfeasible?

[Simon G4ELI]

Off the top of my head this can't be fixed. I'll test this myself, what I must do is ensure that your files can be played back correctly so don't delete them.

[Frank O]

Thanks, they're not going anywhere.

I see that when I open one of the .wav files in PskovNDB (NDB decoder software), it displays a file header which shows a center frequency of 270000 Hz and a sample rate of 550260 -- the latter being the same as what SDR Console identifies as the recording bandwidth. Not clear to me that playing with either or both of those values would fix anything.

[Simon G4ELI]

The problem is the bandwidth - it's wrong. Any chance you could upload the first file to the cloud for me?

[Frank O]

Actually I have a fix, thanks to great help from DR53.

On his suggestion, I downloaded the binary editor HxD and used it to locate the string "R.a.d.i.o.C.e.n.t.e.r.F.r.e.q.=.2.7.0.0.0." in one .wav file, then changed the value to "2.7.5.1.3.0.". The file now shows correct frequencies when replayed in SDR Console v3.0.24, and PskovNDB and Amalgamated DGPS are identifying signals correctly.

Now I just have to automate fixing the other 87 .wav files. My DOS skills are pretty rusty, so I'll probably take them to a Linux machine and use something like sed.

Thanks again (particularly to DR53) for the help!

[DR53]

Hi Simon,

Is this a good time to bring up another display / recording quirk?

When you set a center frequency for a recording and press the >l< button when an offset mode such as CW-U, LSB or Wide-U is in use, the display is centred on the middle of the bandwith filter, not the selected frequency. This offset error, of half the filter width, is carried through into recordings, so that the CF you thought you'd set is not what you actually get. The easy workaround is always to make sure that you are in AM mode before setting up a recording, but we are all getting more forgetful as we get older!

Is this something you might also look at in a future release?

Regards,
Dave

[Simon G4ELI]

Hi Simon,

Is this a good time to bring up another display / recording quirk?

When you set a center frequency for a recording and press the >l< button when an offset mode such as CW-U, LSB or Wide-U is in use, the display is centred on the middle of the bandwith filter, not the selected frequency. This offset error, of half the filter width, is carried through into recordings, so that the CF you thought you'd set is not what you actually get. The easy workaround is always to make sure that you are in AM mode before setting up a recording, but we are all getting more forgetful as we get older!

Is this something you might also look at in a future release?

Regards,
Dave

Dave,

Please add this as a new posting, don't hijack a thread, thanks.

[Simon G4ELI]

Hi Simon,

Is this a good time to bring up another display / recording quirk?

When you set a center frequency for a recording and press the >l< button when an offset mode such as CW-U, LSB or Wide-U is in use, the display is centred on the middle of the bandwith filter, not the selected frequency. This offset error, of half the filter width, is carried through into recordings, so that the CF you thought you'd set is not what you actually get. The easy workaround is always to make sure that you are in AM mode before setting up a recording, but we are all getting more forgetful as we get older!

Is this something you might also look at in a future release?

Regards,
Dave

Check frequencies, then use the Lock option when making a recording. I'm not going to change the >|< logic at this late stage before I release 3.0.26 - may affect other areas of the code.