Re: SDR sampling rate - control or IOCTL?

[Antti Palosaari <crope@iki.fi>]

On 21.11.2013 19:49, Mauro Carvalho Chehab wrote:
> Em Thu, 21 Nov 2013 19:05:05 +0200
> Antti Palosaari <crope@iki.fi> escreveu:
>
>> Hello
>> I am adding new property for sampling rate that is ideally the only
>> obligatory parameter required by SDR. It is value that could be only
>> positive and bigger the better, lets say unsigned 64 bit is quite ideal.
>> That value sets maximum radio frequency possible to receive (ideal SDR).
>>
>> Valid values are not always in some single range from X to Y, there
>> could be some multiple value ranges.
>>
>> For example possible values: 1000-2000, 23459, 900001-2800000
>>
>> Reading possible values from device could be nice, but not necessary.
>> Reading current value is more important.
>>
>> Here is what I though earlier as a requirements:
>>
>> sampling rate
>> *  values: 1 - infinity (unit: Hz, samples per second)
>>        currently 500 MHz is more than enough
>> *  operations
>>        GET, inquire what HW supports
>>        GET, get current value
>>        SET, set desired value
>>
>>
>> I am not sure what is best way to implement that kind of thing.
>> IOCTL like frequency
>> V4L2 Control?
>> put it into stream format request?
>>
>> Sampling rate is actually frequency of ADC. As there devices has almost
>> always tuner too (practical SDR) there is need for tuner frequency too.
>> As tuner is still own entity, is it possible to use same frequency
>> parameter for both ADC and RF tuner in same device?
>
> Well, a SDR capture device will always have ADC and RF tuner.

No, no no! Look for example Ettus USRP. It is fully modular and you 
could select different RF boards. I think you could even feed I/O from 
your DTV modulator to that that, having no tuner at all.


> A SDR output device will always have a DAC and a RF transmitter.

Nope! Usually you could feed baseband too, no "tuner" at all.

>
> On both cases, the sampling rate and the sampling format are mandatory
> arguments.

Yeah, app needs to know sampling rate and of course stream format. 
Application stream format is typically pair of floats, whilst hardware 
offers integer numbers as a ADC sampling levels.

> In any case, the V4L2 API has already support for setting the mandatory
> parameters of the expected stream, at struct v4l2_format.
>
> So, it makes sense do do:
>
>   struct v4l2_format {
>           __u32    type;
>           union {
>                   struct v4l2_pix_format          pix;     /* V4L2_BUF_TYPE_VIDEO_CAPTURE */
>                   struct v4l2_pix_format_mplane   pix_mp;  /* V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE */
>                   struct v4l2_window              win;     /* V4L2_BUF_TYPE_VIDEO_OVERLAY */
>                   struct v4l2_vbi_format          vbi;     /* V4L2_BUF_TYPE_VBI_CAPTURE */
>                   struct v4l2_sliced_vbi_format   sliced;  /* V4L2_BUF_TYPE_SLICED_VBI_CAPTURE */
> +                struct v4l2_sdr_format          sdr;     /* V4L2_BUF_TYPE_SDR_CAPTURE */
>                   __u8    raw_data[200];                   /* user-defined */
>           } fmt;
>   };
>
> And add the mandatory parameters for SDR inside its own structure, e. g.
> struct v4l2_sdr_format. Of course, the meta-data provided by a SDR device
> is different than the one for video or vbi, so you'll need to add a new
> streaming type for SDR anyway.
>
> Btw, that's what I proposed here:
>
> http://git.linuxtv.org/mchehab/experimental.git/blob/refs/heads/sdr:/include/uapi/linux/videodev2.h
>
> With regards to the sampling rate range, my proposal there were to add a min/max
> value for it, to be used by VIDIOC_G_FMT, as proposed on:
> 	http://git.linuxtv.org/mchehab/experimental.git/commitdiff/c3a73f84f038f043aeda5d5bfccc6fea66291451
>
> So, the v4l2_sdr_format should be like:
>
> +struct v4l2_sdr_format {
> +       __u32                           sampleformat;
> +       __u32                           sample_rate;            /* in Hz */
> +       __u32                           min_sample_rate;        /* in Hz */
> +       __u32                           max_sample_rate;        /* in Hz */
> +
> +} __attribute__ ((packed));
>
> Where sampleformat would be something similar to FOURCC, defining the
> size of each sample, its format, and if the sampling is in quadradure,
> if they're plain PCM samples, or something more complex, like DPCM, RLE,
> etc.

Personally I would like to implement that a way driver returns some 
known integer formats. That means, driver does some small conversion, 
reads device specific numbers from device and outputs those to some 
known formats like integers.

But I already moved all that stuff to libv4lconvert.

> In the specific case of enumerating the sampling rate range, if the
> sampling rate can have multiple ranges, then maybe we'll need to do
> something more complex like what was done on VIDIOC_ENUM_FRAMESIZES.
>
> Regards,
> Mauro
>

regards
Antti

-- 
http://palosaari.fi/