Re: SDR FM demodulation
On Sat, Feb 11, 2012 at 07:00:16AM +, Alistair Buxton wrote: The source file appears to be about 2 to 2.2 million samples per second. Any higher than that and the person speaking sounds like a chipmunk. Maybe 22050 * 1000 or 1024? Does any Finnish station broadcast pips like the BBC does? That could be used to determine the actual rate. The stereo carrier is at 19kHz and RDS is centered around 57kHz. I'd say this is 2048kHz sampling rate. Daniel -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SDR FM demodulation
On 11.02.2012 09:00, Alistair Buxton wrote: On 9 February 2012 15:01, Antti Palosaaricr...@iki.fi wrote: Decode it and listen some Finnish speak ;) Done. grc and output.wav here: http://al.robotfuzz.com/~al/rtl2832/ The trick was realising that the UChar to Float converter does not adjust it's output to the range -1.0,1.0 that the wideband FM demodulator block expects as input. Once I figured that out the rest was easy. Just set the quadrature rate to the samples per second in the source file, and the decimation to quadrature rate/output sink rate. The source file appears to be about 2 to 2.2 million samples per second. Any higher than that and the person speaking sounds like a chipmunk. Maybe 22050 * 1000 or 1024? Does any Finnish station broadcast pips like the BBC does? That could be used to determine the actual rate. Cool! I did that whole last night up to 6 am. I also ended up very similar blocks, but failed to convert bytes as UChar. I tried to add constant between Deinterleave and UChar To Float but it wasn't possible. So my first idea was to make Python script to make for the sample when I wake-up. But no need anymore :) It was very good learning session and I am very impressed about GNU Radio capability. Idea tool for learning signal handling in practise. I see that device has big potential for students as it is very cheap SDR, everyone can get own! Now someone should make Linux driver that can tune that device to different frequencies and look what it really can do. What kind of driver architecture should be used? Use device 100% userspace or make it working as Kernel driver? I suspect making it as Kernel driver could be too limited since V4L/DVB API restrictions? regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SDR FM demodulation
On Sat, Feb 11, 2012 at 02:46:34PM +0200, Antti Palosaari wrote: I did that whole last night up to 6 am. I also ended up very similar blocks, but failed to convert bytes as UChar. I tried to add constant between Deinterleave and UChar To Float but it wasn't possible. So my first idea was to make Python script to make for the sample when I wake-up. But no need anymore :) I ended up writing a FM demodulator in C before I found Alistair's mail in my inbox. Using a 65536 element table for arc tangent and integer arithmetics, it is pretty fast. Now someone should make Linux driver that can tune that device to different frequencies and look what it really can do. What kind of driver architecture should be used? Use device 100% userspace or make it working as Kernel driver? I suspect making it as Kernel driver could be too limited since V4L/DVB API restrictions? There is also the CX23880/1/2/3 series with two 10 bit ADCs (usually) sampling at 28.7MHz. The video part can be switched to raw mode, where it provides 8 bit samples at full or 16 bit samples at half the sampling rate from the luma ADC. In non-Y/C mode the chroma ADC is used by the audio part, where the data can be fed through a configurable chain of filters, demodulatos, and sample rate converters. Just grep 0x320 cx88-reg.h to get a glimpse of its capabilities. There is absolutely no documentation to be found about most of these registers. A reconfigurable silicon tuner like the XC3028 again increases the number of possibilities by a large factor. BT87x aka CX2587x is used for SDR as well, but its video raw mode is good just for analog tv signals, as it expects vsyncs and the audio ADC usually just samples the tuner's baseband sound output at 448kHz. Some variants claim to support FM stereo and BTSC decoding capabilities, but AFAIR there is no support in the Linux driver and the public data sheet just tells us there is a DAP between the decimation filter and the DMA FIFO. If only there was completely open documentation... All in all, I don't think there can be one API that fits all devices without limiting their functionality. Maybe a UVC or LabVIEW like interface with blocks for tuners, ADCs, decimators, DMA sinks, etc. is suitable, but then applications will end up being tailored to a small number of topologies or require manual configuration. For most people the only use would probably be to listen to FM radio. Daniel -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SDR FM demodulation
On 11.02.2012 17:15, Daniel Glöckner wrote: All in all, I don't think there can be one API that fits all devices without limiting their functionality. Maybe a UVC or LabVIEW like interface with blocks for tuners, ADCs, decimators, DMA sinks, etc. is suitable, but then applications will end up being tailored to a small number of topologies or require manual configuration. For most people the only use would probably be to listen to FM radio. For me I would like to see that more interesting SDR than FM radio :) I should look how famous USRP/USRP2 are connected to the GNU Radio and maybe try similar approach. I think it is userspace interface but it fits fine. It is always possible load device us normal Kernel driven DVB-T and if user like to use it as SDR then user should blacklist just kernel driver. I opened my device and there is Elonics E4000 [1] silicon tuner. That tuner seems to be a little crazy beast! Supports frequencies from 64 to 1678 MHz and very many modulations. So for my eyes it is almost idea cheap SDR. No idea what is supported max bw ADC can sample... DVB-T (174-240MHz, 470-854MHz) ISDB-T (470-862MHz) DVB-H (470-854MHz, 1672-1678MHz) CMMB (470-862MHz) D-TMB (470-862MHz) T-DMB (174-240MHz, 1452-1492MHz) DAB (174-240MHz, 1452-1492MHz) MediaFLO (470-862, 1452-1492MHz) GPS L1 band (1575MHz) FM radio (64-108MHz) [1] http://www.elonics.com/product.do?id=1 regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SDR FM demodulation
On Sat, Feb 11, 2012 at 05:33:05PM +0200, Antti Palosaari wrote: I opened my device and there is Elonics E4000 [1] silicon tuner. That tuner seems to be a little crazy beast! Supports frequencies from 64 to 1678 MHz and very many modulations. So for my eyes it is almost idea cheap SDR. No idea what is supported max bw ADC can sample... I just tried to find the XC3028 product brief. It seems XCeive has recently been bought by a company called CrestaTech that have a USB/PCIe chipset for a small universal receiver and a PC based SDR suite for TV/radio/GPS decoding. Daniel -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SDR FM demodulation
On Fri, 2012-02-10 at 20:29 -0600, David Hagood wrote:
On Fri, 2012-02-10 at 21:08 -0500, Andy Walls wrote:
Randomly checking some of the data with GNUplot, if 2.5 Msps is the
sampling rate, then the fastest freq I saw was about 50 kHz.
How'd you analyze the data - assume it was baseband I/Q and do an FFT?
If so, and if this was digitized baseband, you should have seen the FM
stereo pilot tone at 19kHz.
Well, I was examining the data in the time-domain using 'od' to decode
the bytes to text and using gnuplot to visualize. I looked for high
frequency contant envelope cycles. Pretty lame, I know.
I did this in octave this morning and noted a carrier/pilot of some
sort:
fid = fopen('rtl2832u_fm_sample_FIXED.bin');
N=2^20;
fseek(fid, N*10, SEEK_SET);
[v, count] = fread(fid,[2,N],'unsigned char');
v = (v-128)/128;
w = v(1,:) + j*v(2,:);
f = fft(v(1,:),N);
fw = fft(v(1,:),N);
Fs = 2.5e6;
freqs = [1:(N/24)-1]*Fs/N;
bins = [2:N/24];
plot(freqs, abs(f(bins))/N, '.');
plot(freqs, abs(fw(bins))/N, '.');
[m,mi] = max(abs(fw)/N);
freqs(mi)
ans = 9534.4
[m,mi] = max(abs(f)/N);
freqs(mi)
ans = 9534.4
ans*2/1000
ans = 19.069
I must have Fs wrong.
Anyway not much happens in the data above 100 kHz, but to see the whol
spectrum:
bins = [2:N/2];
freqs = [1:(N/2)-1]*Fs/N;
semilogy(freqs, abs(f(bins))/N, '.');
semilogy(freqs, abs(fw(bins))/N, '.');
But it appears someone has now already solved the decoding problem.
Regards,
Andy
If it's digitized IF, you should be able to run it through a rectangular
to polar conversion (compute mag = I^2+Q^2 and phase = arctan(I/Q) (use
a proper 4 quadrant arctan), then compute frequency by the delta between
the phase samples. Mag should be constant, frequency would then be your
audio.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 27/31] omap3isp: Configure CSI-2 phy based on platform data
Hi Sakari,
On Fri, Feb 10, 2012 at 2:32 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Sergio,
Thanks for the review!
Aguirre, Sergio wrote:
On Thu, Feb 2, 2012 at 5:54 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
Configure CSI-2 phy based on platform data in the ISP driver. For that, the
new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same
was configured from the board code.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispcsi2.c | 10 +++-
drivers/media/video/omap3isp/ispcsiphy.c | 78
++
drivers/media/video/omap3isp/ispcsiphy.h | 2 +
3 files changed, 78 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispcsi2.c
b/drivers/media/video/omap3isp/ispcsi2.c
index 9313f7c..e2e3d63 100644
--- a/drivers/media/video/omap3isp/ispcsi2.c
+++ b/drivers/media/video/omap3isp/ispcsi2.c
@@ -1068,7 +1068,13 @@ static int csi2_set_stream(struct v4l2_subdev *sd,
int enable)
struct isp_video *video_out = csi2-video_out;
switch (enable) {
- case ISP_PIPELINE_STREAM_CONTINUOUS:
+ case ISP_PIPELINE_STREAM_CONTINUOUS: {
+ int ret;
+
+ ret = omap3isp_csiphy_config(isp, sd);
+ if (ret 0)
+ return ret;
+
if (omap3isp_csiphy_acquire(csi2-phy) 0)
return -ENODEV;
csi2-use_fs_irq = pipe-do_propagation;
@@ -1092,7 +1098,7 @@ static int csi2_set_stream(struct v4l2_subdev *sd,
int enable)
csi2_if_enable(isp, csi2, 1);
isp_video_dmaqueue_flags_clr(video_out);
break;
-
+ }
case ISP_PIPELINE_STREAM_STOPPED:
if (csi2-state == ISP_PIPELINE_STREAM_STOPPED)
return 0;
diff --git a/drivers/media/video/omap3isp/ispcsiphy.c
b/drivers/media/video/omap3isp/ispcsiphy.c
index 5be37ce..5d7a6ab 100644
--- a/drivers/media/video/omap3isp/ispcsiphy.c
+++ b/drivers/media/video/omap3isp/ispcsiphy.c
@@ -28,6 +28,8 @@
#include linux/device.h
#include linux/regulator/consumer.h
+#include ../../../../arch/arm/mach-omap2/control.h
+
#include isp.h
#include ispreg.h
#include ispcsiphy.h
@@ -138,15 +140,73 @@ static void csiphy_dphy_config(struct isp_csiphy *phy)
isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG1);
}
-static int csiphy_config(struct isp_csiphy *phy,
- struct isp_csiphy_dphy_cfg *dphy,
- struct isp_csiphy_lanes_cfg *lanes)
+/*
+ * TCLK values are OK at their reset values
+ */
+#define TCLK_TERM 0
+#define TCLK_MISS 1
+#define TCLK_SETTLE 14
+
+int omap3isp_csiphy_config(struct isp_device *isp,
+ struct v4l2_subdev *csi2_subdev)
{
+ struct isp_csi2_device *csi2 = v4l2_get_subdevdata(csi2_subdev);
+ struct isp_pipeline *pipe = to_isp_pipeline(csi2_subdev-entity);
+ struct isp_v4l2_subdevs_group *subdevs = pipe-external-host_priv;
+ struct isp_csiphy_dphy_cfg csi2phy;
+ int csi2_ddrclk_khz;
+ struct isp_csiphy_lanes_cfg *lanes;
unsigned int used_lanes = 0;
unsigned int i;
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1
+ || subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
+ lanes = subdevs-bus.ccp2.lanecfg;
+ else
+ lanes = subdevs-bus.csi2.lanecfg;
+
+ /* FIXME: Do 34xx / 35xx require something here? */
+ if (cpu_is_omap3630()) {
+ u32 cam_phy_ctrl = omap_readl(
+ OMAP343X_CTRL_BASE +
OMAP3630_CONTROL_CAMERA_PHY_CTRL);
How about:
u32 cam_phy_ctrl =
omap_ctrl_readl(OMAP3630_CONTROL_CAMERA_PHY_CTRL);
?
Fine for me.
+
+ /*
+ * SCM.CONTROL_CAMERA_PHY_CTRL
+ * - bit[4] : CSIPHY1 data sent to CSIB
+ * - bit [3:2] : CSIPHY1 config: 00 d-phy, 01/10 ccp2
+ * - bit [1:0] : CSIPHY2 config: 00 d-phy, 01/10 ccp2
+ */
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1)
+ cam_phy_ctrl |= 1 2;
+ else if (subdevs-interface == ISP_INTERFACE_CSI2C_PHY1)
+ cam_phy_ctrl = 1 2;
Shouldn't this be:
cam_phy_ctrl = ~(1 2);
?
Probably yes. This has come directly as it was in the original board
code and might not be entirely correct. It works on the N9 at least.
+
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
+ cam_phy_ctrl |= 1;
+ else if (subdevs-interface == ISP_INTERFACE_CSI2A_PHY2)
+ cam_phy_ctrl = 1;
... and:
cam_phy_ctrl = ~1;
+
+ omap_writel(cam_phy_ctrl,
+ OMAP343X_CTRL_BASE
+
Re: [PATCH v2 27/31] omap3isp: Configure CSI-2 phy based on platform data
On Sat, Feb 11, 2012 at 11:17 AM, Aguirre, Sergio saagui...@ti.com wrote:
Hi Sakari,
On Fri, Feb 10, 2012 at 2:32 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Sergio,
Thanks for the review!
Aguirre, Sergio wrote:
On Thu, Feb 2, 2012 at 5:54 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
Configure CSI-2 phy based on platform data in the ISP driver. For that, the
new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same
was configured from the board code.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispcsi2.c | 10 +++-
drivers/media/video/omap3isp/ispcsiphy.c | 78
++
drivers/media/video/omap3isp/ispcsiphy.h | 2 +
3 files changed, 78 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispcsi2.c
b/drivers/media/video/omap3isp/ispcsi2.c
index 9313f7c..e2e3d63 100644
--- a/drivers/media/video/omap3isp/ispcsi2.c
+++ b/drivers/media/video/omap3isp/ispcsi2.c
@@ -1068,7 +1068,13 @@ static int csi2_set_stream(struct v4l2_subdev *sd,
int enable)
struct isp_video *video_out = csi2-video_out;
switch (enable) {
- case ISP_PIPELINE_STREAM_CONTINUOUS:
+ case ISP_PIPELINE_STREAM_CONTINUOUS: {
+ int ret;
+
+ ret = omap3isp_csiphy_config(isp, sd);
+ if (ret 0)
+ return ret;
+
if (omap3isp_csiphy_acquire(csi2-phy) 0)
return -ENODEV;
csi2-use_fs_irq = pipe-do_propagation;
@@ -1092,7 +1098,7 @@ static int csi2_set_stream(struct v4l2_subdev *sd,
int enable)
csi2_if_enable(isp, csi2, 1);
isp_video_dmaqueue_flags_clr(video_out);
break;
-
+ }
case ISP_PIPELINE_STREAM_STOPPED:
if (csi2-state == ISP_PIPELINE_STREAM_STOPPED)
return 0;
diff --git a/drivers/media/video/omap3isp/ispcsiphy.c
b/drivers/media/video/omap3isp/ispcsiphy.c
index 5be37ce..5d7a6ab 100644
--- a/drivers/media/video/omap3isp/ispcsiphy.c
+++ b/drivers/media/video/omap3isp/ispcsiphy.c
@@ -28,6 +28,8 @@
#include linux/device.h
#include linux/regulator/consumer.h
+#include ../../../../arch/arm/mach-omap2/control.h
+
#include isp.h
#include ispreg.h
#include ispcsiphy.h
@@ -138,15 +140,73 @@ static void csiphy_dphy_config(struct isp_csiphy
*phy)
isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG1);
}
-static int csiphy_config(struct isp_csiphy *phy,
- struct isp_csiphy_dphy_cfg *dphy,
- struct isp_csiphy_lanes_cfg *lanes)
+/*
+ * TCLK values are OK at their reset values
+ */
+#define TCLK_TERM 0
+#define TCLK_MISS 1
+#define TCLK_SETTLE 14
+
+int omap3isp_csiphy_config(struct isp_device *isp,
+ struct v4l2_subdev *csi2_subdev)
{
+ struct isp_csi2_device *csi2 = v4l2_get_subdevdata(csi2_subdev);
+ struct isp_pipeline *pipe = to_isp_pipeline(csi2_subdev-entity);
+ struct isp_v4l2_subdevs_group *subdevs = pipe-external-host_priv;
+ struct isp_csiphy_dphy_cfg csi2phy;
+ int csi2_ddrclk_khz;
+ struct isp_csiphy_lanes_cfg *lanes;
unsigned int used_lanes = 0;
unsigned int i;
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1
+ || subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
+ lanes = subdevs-bus.ccp2.lanecfg;
+ else
+ lanes = subdevs-bus.csi2.lanecfg;
+
+ /* FIXME: Do 34xx / 35xx require something here? */
+ if (cpu_is_omap3630()) {
+ u32 cam_phy_ctrl = omap_readl(
+ OMAP343X_CTRL_BASE +
OMAP3630_CONTROL_CAMERA_PHY_CTRL);
How about:
u32 cam_phy_ctrl =
omap_ctrl_readl(OMAP3630_CONTROL_CAMERA_PHY_CTRL);
?
Fine for me.
+
+ /*
+ * SCM.CONTROL_CAMERA_PHY_CTRL
+ * - bit[4] : CSIPHY1 data sent to CSIB
+ * - bit [3:2] : CSIPHY1 config: 00 d-phy, 01/10 ccp2
+ * - bit [1:0] : CSIPHY2 config: 00 d-phy, 01/10 ccp2
+ */
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1)
+ cam_phy_ctrl |= 1 2;
+ else if (subdevs-interface == ISP_INTERFACE_CSI2C_PHY1)
+ cam_phy_ctrl = 1 2;
Shouldn't this be:
cam_phy_ctrl = ~(1 2);
?
Probably yes. This has come directly as it was in the original board
code and might not be entirely correct. It works on the N9 at least.
+
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
+ cam_phy_ctrl |= 1;
+ else if (subdevs-interface == ISP_INTERFACE_CSI2A_PHY2)
+ cam_phy_ctrl = 1;
... and:
cam_phy_ctrl = ~1;
+
+
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sat Feb 11 19:00:17 CET 2012 git hash:59b30294e14fa6a370fdd2bc2921cca1f977ef16 gcc version: i686-linux-gcc (GCC) 4.6.2 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: General question about IR remote signals from USB DVB tuner
This little demo C program looks for the IR input device, parses the IR output and can start any application on any remote key press or release. Compile with gcc -o test50 test50.c I have added a start xterm, a start firefox, and a kill firefox as example. add your own as needed. Have fun:-) test50.c Description: Binary data
Problem with V4L2 IOCTLs since 2.6.39
Hello, there must be made some changes to the V4L2 IOCTLs, also the V4L2 API since 2.6.39. Upon starting xawtv, i get following errors: ioctl: VIDIOC_S_CTRL(id=9963785;value=0): Unpassender IOCTL (I/O-Control) für das Gerät ioctl: VIDIOC_S_CTRL(id=9963785;value=1): Unpassender IOCTL (I/O-Control) für das Gerät ioctl: VIDIOC_S_CTRL(id=9963778;value=30801): Unpassender IOCTL (I/O-Control) für das Gerät ioctl: VIDIOC_S_CTRL(id=9963776;value=30801): Unpassender IOCTL (I/O-Control) für das Gerät ioctl: VIDIOC_S_CTRL(id=9963779;value=30801): Unpassender IOCTL (I/O-Control) für das Gerät ioctl: VIDIOC_S_CTRL(id=9963777;value=30801): Unpassender IOCTL (I/O-Control) für das Gerät ioctl: VIDIOC_S_CTRL(id=9963785;value=0): Unpassender IOCTL (I/O-Control) für das Gerät I also have made some application (http://tuxwave.net/index.php?page=2subpage=23) using the radio tuner of a Hauppauge WinTV card, since 2.6.39 i can not request the tuner range anymore. Initializing... Card: BT878 radio (Hauppauge (bt878)) Lowest Frequency: 0 (0 MHz) Highest Frequency: 0 (0 MHz The ioctls used by xawtv are related to audio settings (mute/unmute, volume). I tried to get more information upon this subject, but to no available. What changes where made, so that those ioctls fail? I also was in contact with Verkuil, he mentioned the bug on the tuner ranges should be fixed in the kernel versions starting the 3. branch. I am currently useing the 3.2.5 kernel, with no difference so far. It would be very nice and helpful what changes were made to know how to fix those issues. Regards Sebastian Kricner -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Updated tuning file for Crystal Palace transmitter, UK
Hi, The UK's Crystal Palace transmitter supports DVB-T2, so here's an updated tuning file. Cheers, Chris #-- # file automatically generated by w_scan # (http://wirbel.htpc-forum.de/w_scan/index2.html) #! w_scan 20120112 1 0 TERRESTRIAL GB /w_scan #-- # location and provider: Crystal Palace, UK # date (-mm-dd) : 2012-02-12 # # T[2] [plp_id] [system_id] freq bw fec_hi fec_lo mod tm guard hi [# comment] #-- T 48180 8MHz 2/3 NONE QAM64 2k 1/32 NONE # London. T 53780 8MHz 3/4 NONE QAM16 2k 1/32 NONE # London. T 50580 8MHz 3/4 NONE QAM16 2k 1/32 NONE # London. T 56180 8MHz 2/3 NONE QAM64 2k 1/32 NONE # London. T 52980 8MHz 3/4 NONE QAM16 2k 1/32 NONE # London. T 578166670 8MHz 3/4 NONE QAM16 2k 1/32 NONE # London. T2 0 16435 55400 8MHz AUTO AUTO AUTO AUTO AUTO AUTO # London. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
