You just jumped over all my previous hard work and introduced
implementation, as I tried still to study and finalize all requirements....
http://palosaari.fi/linux/kernel_sdr_api_requirement_specification.txt
I don't like that. I want just study all requirements and implement
those as a once and correctly. That one does not meet very many of those
listed requirements.
Antti
On 04/21/2013 02:10 PM, Mauro Carvalho Chehab wrote:
Em 21-04-2013 07:34, Hans Verkuil escreveu:
On Sun April 21 2013 12:09:51 Mauro Carvalho Chehab wrote:
Em 21-04-2013 06:34, Hans Verkuil escreveu:
Hi Mauro,
On Sat April 20 2013 19:51:11 Mauro Carvalho Chehab wrote:
This is a version 2 of the V4L2 API bits to support Software Digital
Radio (SDR).
It looks pretty good to me. Just one question though: what is your
rationale
for choosing a new device name (/dev/sdrX) instead of using the
existing
/dev/radioX?
I'm not saying I'm opposed to it, in fact I agree with it, but I
think the
reasons for it should be stated explicitly.
Because a SDR radio is different than a normal radio device:
A normal radio device is actually radio and hardware demod. As the demod
is in hardware, several things that are required for the demodulate the
signal (IF, bandwidth, sample rate, RF/IF filters, etc) are internal to
the device and aren't part of the API.
SDR radio, on the other hand, requires that every control needed by the
tuner to be exposed on userspace, as userspace needs to adjust the
software decoder to match them.
So, they're different.
Btw, it is also possible that the same device to offer analog TV,
digital TV, hardware-decoded radio and SDR. One example of such devices
are cx88. The existing drivers supports already hardware demodulers,
but the device also allows to export the collected samples to userspace.
It is just a matter of programming the cx88 RISC code to do that.
Internally, cx2388x has 2 10 bits ADC, one for baseband (composite
inputs)
and another one for IF signal capable of working up to 35.44 MHz
sampling
rate (on "8x FSC PAL" supported mode). It would be easy to export its
output to userspace.
Btw, while seeking for more data about SDR this weekend, I discovered
one project doing exactly that:
http://www.geocities.ws/how_chee/cx23881fc6.htm
I did a very quick look at its source code. It is limited, as it works
only at a fixed sample rate of 27 MHz provides only 8 bits
samples[1], and
I'm not sure if it allows using both ADCs.
Yet, It shows that it is possible that a driver/subdrivers to offer
the 4 different types of devices:
- analog TV;
- digital TV;
- radio;
- SDR.
So, IMO we should not abuse of /dev/radio for SDR.
I agree. I just wanted to have it explicit :-)
Sure. I'll summarize the above at the commit patch on a next version.
I also think we should provide and maintain a library doing the
decoding for
SDR that is part of v4l-utils. Otherwise you'll end up with a big
userspace
mess.
I partially agree. I've seen some SDR usages that are experimental
app-specific stuff like GSM and ADSB receivers.
You can see a sample of such projects that use one of the existing
userspace libraries at:
http://sdr.osmocom.org/trac/wiki/rtl-sdr#KnownApps
In principle, I don't think it is worth to invest our time handling
all sorts of possible decoders at v4l-apps[1].
It makes more sense to offer instead low level library there to allow
applications to abstract from hardware differences, like doing
fourcc conversions.
There are at least two ways of outputting data on the known devices:
- simple ADC samples in time domain;
- IF using in-phase/quadrature (I/Q) samples.
Also, the number of bits can vary from device to device, being 8 bits
and 10 bits the most common ones. I think I saw some analog TV devices
using a 12 bits sampler somewhere, but I can't remember if it is
flexible enough to output sampled data to the DMA engine, or if they're
just simple I2C devices that output only decoded data via I2S.
Anyway, the low-level library should take care of those differences,
just like it is done at libv4l for image standards.
With time, the library may also provide a basic set of decoders for
more common analog radio standards: FM, AM DSB-FC, AM DSB-SC, AM SSB.
It may also provide analog TV decoders and even digital TV ones,
but writing them may take a lot of time. It could be good projects
for Google's Summer of Code and similar events.
I would love to have a set of those decodes there, as they can
offer a nice set of instrumentation tools to test what is being
received on some place and calibrate device drivers.
I would love even more to have SDR TX devices. With both TX and RX
working, one could send us a sample of what they're receiving on
some place, and this signal could be used by the developer to test
their devices, improving the driver to better receive such signals.
I suspect that low-cost SDR TX devices will come with time.
[1] Ok, if someone wants to add support for those app-specific decoders,
maintain it there and it doesn't offer any legal issues that would
restrict v4l-utils distribution, I'm not against to add it there.
And we want this checked by v4l2-compliance, and qv4l2 should be able
to use
the library so we have at least one application that can handle it.
Regards,
Hans
Regards,
Mauro
[1] The trick is to program the cx88 RISC to output data from the
samplers, instead of from the demods. We do that already for the
audio standard detection.
I've no idea if cx88 has any upper DMA maximum bandwidth. If it has,
that might be the reason to limit to 27MHz, 8 bits, but I suspect
that it was done that way just because it was easier.
Btw, I'm almost sure that other Conexant designs can also offer
similar interfaces.
Regards,
Hans
The changes from version 1 are:
- fix compilation;
- add a new capture type for SDR (V4L2_BUF_TYPE_SDR_CAPTURE),
with the corresponding documentation;
- remove legacy V4L1 buffer types from videobuf2.h.
With regards to VIDIOC_S_TUNER, what's currently defined there is
that, in contrary to what a radio device does, this ioctl would
set the input.
This patch adds the very basic stuff for SDR:
- a separate devnode;
- an VIDIOC_QUERYCAP caps for SDR;
- a fourcc group for SDR;
- a few DocBook bits.
What's missing:
- SDR specific controls;
- Sample rate config;
...
As discussing DocBook changes inside the patch is hard, I'm adding
here
the DocBook formatted changes.
The DocBook changes add the following bits:
At Chapter 1. Common API Elements, it adds:
<text>
Software Digital Radio (SDR) Tuners and Modulators
==================================================
Those devices are special types of Radio devices that don't have any
analog demodulator. Instead, it samples the radio IF or baseband and
sends the samples for userspace to demodulate.
Tuners
======
SDR receivers can have one or more tuners sampling RF signals. Each
tuner is associated with one or more inputs, depending on the
number of
RF connectors on the tuner. The type field of the respective struct
v4l2_input returned by the VIDIOC_ENUMINPUT ioctl is set to
V4L2_INPUT_TYPE_TUNER and its tuner field contains the index number of
the tuner input.
To query and change tuner properties applications use the
VIDIOC_G_TUNER
and VIDIOC_S_TUNER ioctl, respectively. The struct v4l2_tuner returned
by VIDIOC_G_TUNER also contains signal status information applicable
when the tuner of the current SDR input is queried. In order to change
the SDR input, VIDIOC_S_TUNER with a new SDR index should be called.
Drivers must support both ioctls and set the V4L2_CAP_SDR and
V4L2_CAP_TUNER flags in the struct v4l2_capability returned by the
VIDIOC_QUERYCAP ioctl.
Modulators
==========
To be defined.
</text>
At the end of Chapter 2. Image Formats, it adds:
<text>
SDR format struture
===================
Table 2.4. struct v4l2_sdr_format
=================================
__u32 sampleformat The format of the samples used by the SDR
device.
This is a little endian four character code.
Table 2.5. SDR formats
======================
V4L2_SDR_FMT_I8Q8 Samples are given by a sequence of 8 bits
in-phase(I)
and 8 bits quadrature (Q) samples taken from a
signal(t) represented by the following expression:
signal(t) = I * cos(2Ï€ fc t) - Q * sin(2Ï€ fc t)
</text>
Of course, other formats will be needed at Table 2.5, as SDR could
also
be taken baseband samples, being, for example, a simple sequence of
equally time-spaced digitalized samples of the signal in time.
SDR samples could also use other resolutions, use a non-linear
(A-law, u-law) ADC, or even compress the samples (with ADPCM, for
example). So, this table will grow as newer devices get added, and an
userspace library may be required to convert them into some common
format.
At "Chapter 4. Interfaces", it adds the following text:
<text>
Software Digital Radio(SDR) Interface
=====================================
This interface is intended for Software Digital Radio (SDR) receivers
and transmitters.
Conventionally V4L2 SDR devices are accessed through character device
special files named /dev/sdr0 to/dev/radio255 and uses a dynamically
allocated major/minor number.
Querying Capabilities
=====================
Devices supporting the radio interface set the V4L2_CAP_SDR and
V4L2_CAP_TUNER or V4L2_CAP_MODULATOR flag in the capabilities field of
struct v4l2_capability returned by the VIDIOC_QUERYCAP ioctl. Other
combinations of capability flags are reserved for future extensions.
Supplemental Functions
======================
SDR receivers should support tuner ioctls.
SDR transmitter ioctl's will be defined in the future.
SDR devices should also support one or more of the following I/O
ioctls:
read or write, memory mapped IO, user memory IO and/or DMA buffers.
SDR devices can also support controls ioctls.
The SDR Input/Output are A/D or D/A samples taken from a modulated
signal, and can eventually be packed by the hardware. They are
generally
encoded using cartesian in-phase/quadrature (I/Q) samples, to make
demodulation easier. The format of the samples should be according
with
SDR format.
</text>
Note: "SDR format" on the last paragraph is an hyperlink to
Chapter 2. Image Formats.
At "Appendix A. Function Reference - ioctl VIDIOC_QUERYCAP", it adds:
<text>
Table A.93. Device Capabilities Flags
...
V4L2_CAP_SDR 0x00100000 The device is a Software Digital Radio.
For more information about SDR programming
see the section called “Software Digital
Radio (SDR) Tuners and Modulators�.
</text>
Mauro Carvalho Chehab (3):
[media] Add SDR at V4L2 API
videodev2.h: Remove the unused old V4L1 buffer types
[media] V4L2 api: Add a buffer capture type for SDR
Documentation/DocBook/media/v4l/common.xml | 35
++++++++++++++++++
Documentation/DocBook/media/v4l/dev-capture.xml | 26
++++++++------
Documentation/DocBook/media/v4l/io.xml | 6 ++++
Documentation/DocBook/media/v4l/pixfmt.xml | 41
++++++++++++++++++++++
Documentation/DocBook/media/v4l/v4l2.xml | 1 +
.../DocBook/media/v4l/vidioc-querycap.xml | 7 ++++
drivers/media/v4l2-core/v4l2-dev.c | 3 ++
drivers/media/v4l2-core/v4l2-ioctl.c | 32
+++++++++++++++++
include/media/v4l2-dev.h | 3 +-
include/media/v4l2-ioctl.h | 8 +++++
include/uapi/linux/videodev2.h | 33
+++++++----------
11 files changed, 163 insertions(+), 32 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe
linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
