Real data input to Linrad

[afedri-sdr Alex]

Hello All,

I am working now on the new SDR hardware, that allows direct sampling data transfer over USB3 interface, playing now with Linrad using custom ExtIO plugin (so can change required parameter in plugin). Real ADC samples are sample with relatively high sample rate , meanwhile up to 76800000 Hz (i.e. 76.8Mhz), during debugging I can set lower sample rate (but target - to get maximum). 

SDR sends data as 16-bit real data (i.e. no imaginary part here)

Wandering how it is possible to define in Linrad hardware in such manner that it will accept real (non complex) samples?

Meanwhile Linrad treats samples as complex data stream (emulated in ExtIO), but I want to use real sample - this will lower load on data transfer interface and on Linrad that makes unneeded extra signal processing processing, and works hard.

P.S. Small bug report , during Linrad source code compilation, I met MinGW compiler error

that complains on "#define __USE_MINGW_ANSI_STDIO 1" in afedri.c file, to solve the problem I replaced this definition by the next:

#define _GNU_SOURCE

73!

Alex

[afedri-sdr Alex]

In my previous request I am looking for temporary solution ,  or possibility to define the real data format in par_userint file and/or other par_* files

Also when choosing high sample rate I met Out of memory message, how during configuration  I can solve this Out of memory problem?

73!

Alex

[Franco Venturi]

Alex,

to go from real samples to I/Q, you can mix your input signal f(t) with a local oscillator running at a frequency f_LO; for the I component you take the LO waveform with phase=0, i.e. f(t) * cos(2pi * f_LO * t), while for the Q component you take the the LO waveform shifted by 90 degrees, i.e. f(t) * sin(2pi * f_LO * t).

Using the complex exponential notation, which is in my opinion much more convenient, this becomes:

    I(t) + jQ(t) = f(t) * exp(j * 2pi * f_LO * t)

Using the standard notation f_s for the sample rate, your input sample sequence can therefore be described as follows:

  x[0] = f(0)

  x[1] = f(1 / f_s)

  x[2] = f(2 / f_s)

...

  x[k] = f(k / f_s)

If we select f_LO = f_s / 2,  then for the k-th sample at time t_k = k / f_s, we can see that:

   I(t_k) + jQ(t_k) = x[k] * exp(j * 2pi * f_s/2 * t_k) = x[k] * exp(j * 2pi * f_s/2 * k / f_s) = x[k] * exp(j * 2pi * k / 2)

and given the periodic nature of the complex exponential (i.e. of cos and sin), we have the following:

  for f_LO=f_s/2   ->    I + jQ:  x[0] + j0, -x[1] + j0, x[2] + j0, -x[3] + j0, x[4] + j0, ...

It is also easy to see what happens if we instead take f_LO = f_s / 4:

  for f_LO=f_s/4   ->    I + jQ:  x[0] + j0, 0 + j*x[1], -x[2] + j0, 0 - j * x[3], x[4] + j0, ...

So in summary in the first case (f_LO = f_s / 2), your I and Q sequences would be:

  I: x[0], -x[1], x[2], -x[3], x[4], ....

  Q: 0, 0, 0, 0, 0, ...

In the second case (f_LO = f_s / 4), the I and Q sequences would be:

  I: x[0], 0, -x[2], 0, x[4], ...

  Q: 0, x[1], 0, -x[3], 0, ...

73,

Franco K4VZ

[afedri-sdr Alex]

Franco,

Thanks for your answer, but it is not related to my question.

I did not ask about DSP theory, I am asking about specific software and it's embedded ability to accept specific type of data.

I very well know how to transfer real number to complex and opposite complex to real, every transformation requires extra processing time.

I am looking for the way that possible already implemented in Linrad, do not want to insert any additional non needed procedures, I try to keep thing simple.

73!

Alex

[afedri-sdr Alex]

Franco,

Small offtopic, related to your answer:

Your method , in reality only part of solution, it will not work well without additional Low Pass (antialias) Filter  ... And this filter - it is exactly where most processing time will be spent...

When I suppose Linrad already has it's own embedded procedures...

73!

Alex

[Leif Asbrink]

Hello Alex,

Linrad can do real ADC samples at high speed, but only for the
PCIe9842 card. 14 bit integers at up to 200 MHz:
https://www.youtube.com/watch?v=kxkd8e_ijw8

http://www.youtube.com/watch?v=4Hm9dUvImGg

Linrad sets ui-extio_type this way:
errcod=InitHW(extio_name, extio_model, &ui.extio_type);
Known extio_types are:
1) 16 bit dll callback

2) Soundcard input

3) 16 bit dll callback

4) Soundcard input

5) 24 bit dll callback

6) int 32bit dll callback

7) float 32bit dll callback

8) 24 bit dll callback

These modes all send complex data pairs, IQ data.

I guess you write your own dll so I suggest you discuss with Alberto
how to properly tell the application program what data the dll
will deliver.

Modes up to 11 seem to be defined now:
https://github.com/myriadrf/ExtIO_LimeSDR/blob/master/src/LC_ExtIO_Types.h

73

Leif

> --
> There is an excellent Linrad User Guide by Gaetan, ON4KHG, at:
> http://w3sz.com/Linrad%20Installation%20&%20Configuration%20User%20Guide%20-%20V1-0.pdf
> ---
> You received this message because you are subscribed to the Google Groups "Linrad" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linrad+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/linrad/48e4db10-8475-480b-99a1-99134a1d8482n%40googlegroups.com.

[afedri-sdr Alex]

Hello Leif,

Thanks for the advice.

Please take in account that meanwhile I am deeply in process of new hardware evaluation and studying different possibilities of integration with existing SDR applications.

Suppose, there is no need to make any changes to ExtIO protocol, 

ExtIO - is dedicated for use with Winrad, or HDSDR etc. - and those programs can accept and process real data stream (not in efficient manner, but can do that)). 

Due to fact that ExtIO interface supports only complex (pairs) samples, this require some extra data preparation, sending Real data as I and zero (or same data) as Q  per one complex sample. 

But software it self know how to process real data, i.e. software can ignore image (or real per user choice) part of complex pair. 

So I can process real data stream with high sample rate with HDSDR (maximal sample rate value) depends on the PC ability (for example my notebook - allows maximum 50MHz, when my Son's PC - have no problem with 76.8Mhz and higher).

It is not the case with Linrad when I am using ExtIO.

In the case of Linrad the  ExtIO support - is not must for current experiments, I only want to apply minimum changes to Linrad's native code, with hope it has some hidden (from me) possibility.

I put attention that Linrad has support of direct sampling card PCIe9842, I tried to produce "fake" configuration for this card,  but during configuration Linrad requires PCIe9842 drivers to continue configuration process.

So I have no success producing par_userint config file - I target to get this config -  to try to use it as reference for further experiments with Linrad and hacking :-)

Wandering, can it be solution : applying  some changes to PCIe9842 source, rebuilding  it as user hardware?

Meanwhile experiments shows that on my notebook ,  Linrad has serious problems to process even 9.6MHz real data stream using ExtIO interface and complex samples "emulation".

Yes, I get twice wider spectrum - because Linrad treats samples as complex and suppose it spends at least twice more CPU resources for unneeded signal processing.

"Emulation" I mean real part carry data, Image part always ZERO (or same real data).

May be you can recommend what setting could be applied to allow Linrad to process bigger sample rates? Meanwhile my expected sample rate is 76.8Mhz (higher  also possible, but meanwhile not important)

73!

Alex

[Leif Asbrink]

Hello Alex,

How do you send real data to the ExtIO dll?

Surely you could send your data to the Extio and let it believe
that it is complex data. Then give specific hardware name that
Linrad can check for.

Set mode exthwUSBdata16 = 3
Then use this:
typedef bool (__stdcall * pfnInitHW) (char *name, char *model, int& hwtype);
// name: descriptive name of the hardware.
Set name to realUSB-whatever "Preferably not longer than about 16 characters"

Then change Linrad to check whether name begins with realUSB
and change in start_extio
217:
case 1:
case 3:
if(strncmp(name, "realUSB" 7) != 0)
{
lir_text(7,8,"int 16bit I/Q dll callback");
ui.rx_input_mode=IQ_DATA;
}
else
{
lir_text(7,8,"int 16bit real dll callback");
ui.rx_input_mode=0;
}
goto prt_callb;


306:
switch(ui.extio_type)
{
case 1:
case 3:
case 6:
ix=(int*)IQdata;
j=extio_read_bytes/4;
for(i=0; i<j; i++)
{
iz=(int*)&timf1_char[timf1p_sdr];
iz[0]=ix[i];
timf1p_sdr=(timf1p_sdr+4)&timf1_bytemask;
}
if(strncmp(name, "realUSB" 7) == 0)
{
ui.rx_ad_speed*=2;


I guess the USB3 callback would deliver data directly to Linrad
so it would not matter what the dll thinks about the data.
Maybe I have forgotten something, but with some luck you would
be able to find ut fairly easily.

When it runs youmight find that the different fft1 versions give
significantly different CPU loads.

73

Leif

> *May be you can recommend what setting could be applied to allow Linrad to

> process bigger sample rates? Meanwhile my expected sample rate is 76.8Mhz

> (higher also possible, but meanwhile not important)*
>
> 73!
> Alex

[afedri-sdr Alex]

Leif,

My ExtIO dll variant for this new hardware is working correctly as plugin with software that ExtIO dedicated to be used - i.e. with Winrad and HDSDR, so let suppose the data format and declaration is correct inside ExtIO.

...

Real data is send very simply - I channel (or  "Left channel") contains value of real data sample, Q channel (or "Right channel" ) can be set to zero or alternatively I can set is same as I channel, both variants has been tested - no difference in result.

There is special definition related to data format (complex or real), so Winrad and HDSDR knows to use data from only one ("Left" or "Right") channel (second unused , only spends extra data transfer bandwidth).

So the main drawback of this approach - twice higher processor load cased by extra (unused) data transfer.

In connection to Linrad, as I understand , Linrad cannot use only channel  with Real data and treats data stream as complex when using ExtIO , so I see on the waterfall doubled spectrum (positive freq. and negative) each half contains correct spectrum.

But in the case with Real data - negative part - is unused extra.

By the way I am not looking for solution based on ExtIO plugin interface, probably in this case user_hardware.c - can be better solution, but here I need more understanding in Linrad's internal procedures.

73!

Alex

[Leif Asbrink]

Alex,

You missunderstood my message.

Linrad can easily use real data. I think the small modifications to
the Linrad code will work fine with a stream of real data to the
ExtIO dll if you inform the dll that the data is 16 bit I and Q.
By telling Linrad through the name that the stream of 16 bit values
should not be interpreted as I and Q but as a stream of real data at twice
the specified sampling rate.

In case you want to add a module to Linrad to control the settings
of your hardware it should be easiest to make a copy of one of the USB3
modules. Airspy, BladeRF, RTL2832, Mirics or AirspyHF+.
They all use complex data but the BladeRF can also use real data:

if(sampling == BLADERF_SAMPLING_INTERNAL)
{
ui.rx_input_mode=IQ_DATA;
ui.rx_rf_channels=1;
}
else
{
ui.rx_input_mode=0;
ui.rx_rf_channels=2;
}

This is the same as you see in the modifications I suggested for extio.c

73

Leif

> --
> There is an excellent Linrad User Guide by Gaetan, ON4KHG, at:
> http://w3sz.com/Linrad%20Installation%20&%20Configuration%20User%20Guide%20-%20V1-0.pdf
> ---
> You received this message because you are subscribed to the Google Groups "Linrad" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linrad+un...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/linrad/74d424ae-e150-4eff-90f1-6cbf1771b8d4n%40googlegroups.com.

[afedri-sdr Alex]

Hi Leif,

Thanks for the advice, apologies for long delay with my reaction.

Will return to Linrad later, now working on other issues.

73!

Alex