SDR Play syncUpdate

Add useful snippets of code or links to entire SDR projects.
Post Reply
LoserSM
Posts: 2
Joined: Mon Sep 24, 2018 4:00 pm

SDR Play syncUpdate

Post by LoserSM » Mon Sep 24, 2018 4:14 pm

Hey guys!
At the moment I try to implement a function that switches between two rf-Frequencies using syncUpdates using a SDRPlay2pro.

I try to switch between 868 and 867 MHz in a synchronized way. The real goal is be @ one frequency for like 99% of the time, switch
to the other frequency for like 10.000 samples and switch back.

I'm currently trying to to it easier with two big time intervals: sampling frequency is 2 MHz and the intervall given to mir_sdr_SetSyncUpdatePeriod is 1.000.000 -> 2 frequency changes per second. The sample number given to mir_sdr_SetSyncUpdateSampleNum is just an arbitrary number.

From the inital value given to mir_sdr_SetSyncUpdateSampleNum I can calculate the exact samplenumbers, where the frequency is switched.

In the callback function I use the rfChanged flag to detect wether a frequency change took place.

Now to my problem: The sample where the frequency changed (calculated by the sync period) is not always located in the buffer where the flag is set.

In my eyes the syncUpdates are useless if they do not work like that?!

Thanks for your help!
Last edited by LoserSM on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason

LoserSM
Posts: 2
Joined: Mon Sep 24, 2018 4:00 pm

Re: SDR Play syncUpdate

Post by LoserSM » Thu Dec 06, 2018 5:14 pm

Little update:
I found out that the periods have to be a multiple of the samples per buffer. Also the minimum time I can switch to another frequency is like 57ms at any frequency. -> ~120.000 samples at 2MHz, ~480.000 samples at 8.3 MHz.
As long as these conditions are met, the calculated sample where the switch should occur and the first sample number at "rfChanged" is the same and it works as it should, but only for a few hours and I get a:

Code: Select all

Error: USB buffer overflow
with

Code: Select all

mir_sdr_SetSyncUpdateSampleNum: -80510 (at actual sample rate -80510)
mir_sdr_SetSyncUpdateSampleNum: SyncUpdate is deferred near wrap-around: -80510->8307586
a few lines before. Somehow the debug API output is not matched to the "unsigned int" (%u). I guess that's why negative values are displayed here. My counters for this tasks are all unsigned ints, so they wrap at the same time as the "unsigned int firstSampleNum" from the callback.

A GDB backtrace leads to:

Code: Select all

#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007ffff7bc3dbd in __GI___pthread_mutex_lock (mutex=0x8ffa60) at ../nptl/pthread_mutex_lock.c:80
#2  0x00007ffff5dfeb3e in mir_MutexLock () from /usr/local/lib/libmirsdrapi-rsp.so.2.13
#3  0x00007ffff5e03b2e in mir_sdr_Uninit () from /usr/local/lib/libmirsdrapi-rsp.so.2.13
Might this happen because I use way too big values for the

Code: Select all

mir_sdr_ErrT mir_sdr_SetSyncUpdatePeriod(unsigned int period)
function? The API specifies an upper limit of a million samples for the update period and I am using up to eight million (one million seems to be a pretty strange limit to me and it works well). Can somebody tell me if this is a bug in the API, specifically in the sync update handling? Thank you.
Last edited by LoserSM on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason

Post Reply