I'm a huge SDR-Console fan. I BCBDX which means listening around the top of the hour. Over time the clock on my recording doesn't track the real recorded time but drifts behind. I have a ten hour recording and it's almost a minute behind after that time.
Originally I thought it might be my fault. I do use your Windows server and listen over WiFi-to-Ethernet. There's bandwidth available.
I have tried both RSP1A and Airspy HF+ Discovery. I've recorded both on an internal SSD and a USB3 SSD. My recordings usually cover ~1.2 mHz, around 10.6 mb/s.
I installed a service to sync my computer's clock every hour, but even before I did the recording didn't track my computer's clock.
This is a problem that doesn't show up unless you're listening for something where the exact time is meaningful.
Running a speedy Windows 11 machine. The server is an older laptop, Windows 10. The server is the only thing running on the laptop. Wifi connection is very good.
Thanks.
Recorded clock doesn't track
Re: Recorded clock doesn't track
This is inevitable. The system follows the front end's clock.
{^_^}
{^_^}
Re: Recorded clock doesn't track
I don't understand. All my clocks remain on-time.
Re: Recorded clock doesn't track
If you believe that statement bringing you up to speed is going to take time. All clocks, even the best thing NIST has, feature error bars on the clock's frequency. All clocks are different from each other for their free running errors. Clocks can be phase locked to other clocks to get a set to temporarily agree long enough to be useful. Even GPS satellites have frequency errors, although the errors are very small. Clocks that once a day refer to WWV one way or another are "close" but not really accurate in the short term even though they are corrected in the long term. (Can you tell clocks are one of my fascinations?)
In a typical SDR system you may run on your computer there are at least three clocks involved. Two of them are typically rated at better than 50 parts per million. That's a 50 Hz error or less on a 1 MHz signal. The SDR clock can be another of these things I call floor sweepings or they can be 1ppm TCXOs, that's one Hz error out of 1 MHz. And some use a GPS disciplined clock, which is nice for some applications but won't make your received signal match your system time. They will slowly drift apart. The error you see is within the error band I expect to happen with typical clock errors.
It's pretty easy to figure time error with say 20 ppm. Ten hours is 36000 seconds. The error you get would be about 0.72 seconds in that period, .00002 * 36000 seconds = 0.72. If both front end and system are typical cheap crystal oscillators I'd expect your error to be anything less than about 7.2 seconds either plus or minus.
{^_^} (At any given time a Phase IIb GPS satellite is within about 2 parts per 10 to the 13th of the correct frequency. Ground control can dither that to some time above ideal frequency followed by some time below ideal frequency and average much better than two parts umptyfratz. Um, I know because I designed the synthesizer that does this. The true radiated signal alternates above and below somewhat worse than the number above. But it's so small an error it takes really fancy equipment to find it. It would have been better if we could have used more modern ICs than the original 7400 series. GPS satellites are radiation hardened. And newer ICs had gold in them. And gold generates REALLY nasty secondary radiation when hit by primary radiation.) Yes, time fascinates me. I cannot estimate it with any usable accuracy. So I am fascinated that it can be measured and generated to these kinds of figures.
Joanne)
In a typical SDR system you may run on your computer there are at least three clocks involved. Two of them are typically rated at better than 50 parts per million. That's a 50 Hz error or less on a 1 MHz signal. The SDR clock can be another of these things I call floor sweepings or they can be 1ppm TCXOs, that's one Hz error out of 1 MHz. And some use a GPS disciplined clock, which is nice for some applications but won't make your received signal match your system time. They will slowly drift apart. The error you see is within the error band I expect to happen with typical clock errors.
It's pretty easy to figure time error with say 20 ppm. Ten hours is 36000 seconds. The error you get would be about 0.72 seconds in that period, .00002 * 36000 seconds = 0.72. If both front end and system are typical cheap crystal oscillators I'd expect your error to be anything less than about 7.2 seconds either plus or minus.
{^_^} (At any given time a Phase IIb GPS satellite is within about 2 parts per 10 to the 13th of the correct frequency. Ground control can dither that to some time above ideal frequency followed by some time below ideal frequency and average much better than two parts umptyfratz. Um, I know because I designed the synthesizer that does this. The true radiated signal alternates above and below somewhat worse than the number above. But it's so small an error it takes really fancy equipment to find it. It would have been better if we could have used more modern ICs than the original 7400 series. GPS satellites are radiation hardened. And newer ICs had gold in them. And gold generates REALLY nasty secondary radiation when hit by primary radiation.) Yes, time fascinates me. I cannot estimate it with any usable accuracy. So I am fascinated that it can be measured and generated to these kinds of figures.
Joanne)
Re: Recorded clock doesn't track
Now to carry it to the next step at the risk of insult.... If so please forgive me.
When you record the recording is made if a stream of data coming in at a sample rate controlled by the A/D's clock. Suppose it is nominally 1 MHz and actually 1.000010 MHz. That is a 10 ppm error. But all the playback can do is presume the sample rate is exactly 1 MHz and plays it back accordingly. So even one clock with an assumption vs reality difference can give you the time error you are seeing. In this specific case you may be able to run the front end off a GPSDO such as Leo Bodnar's tools. Then the assumption about actual sample rate is accurate enough you should not see an error on playback for analysis.
For playback with listening, though, you grow another clock error source, the sound card's clock. So, one must do the best one can recognizing where the errors probably arise in the system. If you are really hardware adept you might be able to lock the sound card to GPS. Or if money is no object there are audio cards with external clock inputs designed for precisely synchronizing a collection of cards all used in one sound related project.
I suspect that now I am getting way out in the weeds. I really hope this filled in a gap or two in your thinking about this problem.
{^_^}
When you record the recording is made if a stream of data coming in at a sample rate controlled by the A/D's clock. Suppose it is nominally 1 MHz and actually 1.000010 MHz. That is a 10 ppm error. But all the playback can do is presume the sample rate is exactly 1 MHz and plays it back accordingly. So even one clock with an assumption vs reality difference can give you the time error you are seeing. In this specific case you may be able to run the front end off a GPSDO such as Leo Bodnar's tools. Then the assumption about actual sample rate is accurate enough you should not see an error on playback for analysis.
For playback with listening, though, you grow another clock error source, the sound card's clock. So, one must do the best one can recognizing where the errors probably arise in the system. If you are really hardware adept you might be able to lock the sound card to GPS. Or if money is no object there are audio cards with external clock inputs designed for precisely synchronizing a collection of cards all used in one sound related project.
I suspect that now I am getting way out in the weeds. I really hope this filled in a gap or two in your thinking about this problem.
{^_^}