OK, I've done some more experiments, all with an RSP1 and API version 2.09 running on a Raspberry Pi 3.
With an fs of any of 2.000, 2.400, 3.000; a decimation factor of 4; and an intermediate frequency of zero, the problem does not occur. I ran it for 24 hours each, which should have been plenty of time.
Reverting to my previous setting of fs=2.000, intermediate frequency=450 kHz (with an implied decimation of 4), the problem occurred seven times during the 24 hour run.
So I wrote a small test program to try to generate the issue...
Code: Select all
#include "mirsdrapi-rsp.h"
#include <assert.h>
#include <stdio.h>
#include <limits.h>
#include <unistd.h>
static long cbCount = 0;
static double em100 = 0;
static bool noisy = false;
static double emax (short *xi, short *xq, unsigned int numSamples)
{
double em = 0;
for (int j = 0; j < numSamples; ++j)
{
const double i = xi[j];
const double q = xq[j];
const double e = i*i + q*q;
if (e > em) em = e;
}
return em;
}
static void s_callback (short *xi, short *xq, unsigned int firstSampleNum, int grChanged, int rfChanged, int fsChanged, unsigned int numSamples, unsigned int reset, void *cbContext)
{
if (++cbCount <= 100)
{
// Use first 100 calls to find typical maximum signal level
const double em = emax (xi, xq, numSamples);
if (em > em100) em100 = em;
}
else
{
// Is this packet much noisier than normal?
const double em = emax (xi, xq, numSamples);
if ((cbCount % 10000) == 0)
{
printf ("*** Signal max power %.0f at callback %ld\n", (double) em, (long) cbCount);
fflush (stdout);
}
const bool nn = em > 4 * em100;
// Print message on transitions from normal->noisy and vice versa
if (nn != noisy)
{
printf ("*** Noise state %d at callback %ld\n", (int) nn, (long) cbCount);
fflush (stdout);
noisy = nn;
}
}
}
static void s_callbackGC (unsigned int gRdB, unsigned int lnaGRdB, void *cbContext)
{
mir_sdr_GainValuesT gv;
const mir_sdr_ErrT err = mir_sdr_GetCurrentGain (&gv);
assert (err == mir_sdr_Success);
}
int main (int, char**)
{
mir_sdr_ErrT err;
float ver;
err = mir_sdr_ApiVersion (&ver);
assert (err == mir_sdr_Success);
assert (ver == MIR_SDR_API_VERSION);
err = mir_sdr_DebugEnable (1);
assert (err == mir_sdr_Success);
err = mir_sdr_SetPpm (6.24);
assert (err == mir_sdr_Success);
err = mir_sdr_AgcControl (mir_sdr_AGC_DISABLE, 0, 0, 0, 0, 0, 0);
assert (err == mir_sdr_Success);
int newGr = 50;
int sysGr = 0;
int samplePerPacket;
err = mir_sdr_StreamInit (&newGr, 2.000, 143.050, mir_sdr_BW_0_200, mir_sdr_IF_0_450, 1, &sysGr, mir_sdr_USE_SET_GR_ALT_MODE, &samplePerPacket, s_callback, s_callbackGC, NULL);
assert (err == mir_sdr_Success);
err = mir_sdr_SetDcMode (4, 1);
assert (err == mir_sdr_Success);
err = mir_sdr_SetDcTrackTime (63);
assert (err == mir_sdr_Success);
mir_sdr_GainValuesT gv;
err = mir_sdr_GetCurrentGain (&gv);
assert (err == mir_sdr_Success);
sleep (INT_MAX);
}
which produces some interesting output... in the normal (noise-free) state it writes messages like
*** Signal max power 3501 at callback 120000
*** Signal max power 2320 at callback 130000
*** Signal max power 2069 at callback 140000
*** Signal max power 3977 at callback 150000
*** Signal max power 1514 at callback 160000
but then it switches into the noisy state for a while with messages like
*** Signal max power 111454745 at callback 1760000
*** Signal max power 131692826 at callback 1770000
*** Signal max power 109825885 at callback 1780000
*** Signal max power 103865485 at callback 1790000
*** Signal max power 128117700 at callback 1800000
Perhaps significantly, the switch to a noisy state happens at the some time as the sdr API writes debug messages like
Warning: DriverCallback() transfer error 0x16e3208 0
No offset diff1=0x000001f8 diff2=0x000001f8
No offset samp1=0xc8efd0ba samp2=0xc8efd2b2 samp2=0xc8efd4aa
bufOffset=0
Gap=0x37182d32 e=0xc8eed2c2 a=0x6fff4
Gap=0xfffffe23 e=0x701ec a=0x7000f
Gap=0xfffbfdfc e=0x70207 a=0x30003
Gap=0x2fe0a e=0x301fb a=0x60005
Gap=0xafe07 e=0x601fd a=0x110004
Gap=0xfff9fe0a e=0x1101fc a=0xb0006
Gap=0xfffdfe0a e=0xb01fe a=0x90008
Gap=0xfff8fe09 e=0x90200 a=0x20009
Gap=0x3fe01 e=0x20201 a=0x60002
Gap=0xfe13 e=0x601fa a=0x7000d
Gap=0xfdfb e=0x70205 a=0x80000
Gap=0x2fe17 e=0x801f8 a=0xb000f
:
(and many, many similar lines)
:
Obviously I don't know what these messages mean, but the coincidence in timing seems certain to be significant!
One other oddity, which may or may not be significant: even when working noise-free, the sdr API writes messages like
238096: iDCoffset=1275.313558262 qDCoffset=0.000000000
mir_sdr_SetGrAltMode: in: 0 1 (1) 0 0 0
mir_sdr_SetGrAltMode: GR->50[50,0,0,0] gRset->0x32 DCCALmode=4 DCCALspd=1 GrToggle->1
mir_sdr_GetCurrentGainVal : hwVer=1 freq=143.05 bw=200 if=450, bbGr=50, lnaState=0, minGr=20, amPort1En=0, apiDownConvert=1
mir_sdr_GetCurrentGainVal : hwVer=1 freq=143.05 group=4 gainState=0, corr=-9.50, freq0=120.00 freq1=146.00 gain0=114.03 gain1=114.52: curr_no_b
b=104.96 max=84.96 min=3.28 curr=54.96
mir_sdr_SetGrAltMode: out: 50 1 50 0 0
mir_sdr_ReadPacket: Gain update confirmed: Gr=50dB GrToggle=1 gset=0x32
grChanged @ 238475
DCoffsetCorrection: switched to tracking mode diff=2 curr=830.26 last=832.58
every couple of minutes. These look as if they are something to do with DC correction, which surprised me because the code is running in DcMode=4 (one-shot), and my code does not perform any gain changes which might re-trigger the correction. In addition, I notice that the qDCoffset value printed in the first line of these sequences is always 0.000000000, which also seemed odd.
Hopefully this should be enough to allow you (SDRplay) to reproduce and track down the problem, but if you need any more information from me, please ask!
Cheers,
John
