hello Patrick,
On Sunday 03 April 2011 17:37:00 Patrick Boettcher wrote:
>
>I think this line is not normal in your case:
>
> dibusb: This device has the Thomson Cable onboard. Which is default.
>
Here's the output of dmesg in Lenny (kernel 2.6.26-1) where the tuning was
fine:
usb 2-1: new full speed USB device using ohci_hcd and address 3
usb 2-1: configuration #1 chosen from 1 choice
usb 2-1: New USB device found, idVendor=1822, idProduct=3201
usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T
device' in cold state, will try to load a firmware
firmware: requesting dvb-usb-dibusb-5.0.0.11.fw
dvb-usb: downloading firmware from file 'dvb-usb-dibusb-5.0.0.11.fw'
usbcore: registered new interface driver dvb_usb_dibusb_mb
usb 2-1: USB disconnect, address 3
dvb-usb: generic DVB-USB module successfully deinitialized and disconnected.
usb 2-1: new full speed USB device using ohci_hcd and address 4
usb 2-1: configuration #1 chosen from 1 choice
dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T
device' in warm state.
dvb-usb: will use the device's hardware PID filter (table count: 16).
DVB: registering new adapter (TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA
USB1.1 DVB-T device)
DVB: registering frontend 0 (DiBcom 3000M-B DVB-T)...
dibusb: This device has the Thomson Cable onboard. Which is default.
input: IR-receiver inside an USB DVB receiver as /class/input/input5
dvb-usb: schedule remote query interval to 150 msecs.
dvb-usb: TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device
successfully initialized and connected.
usb 2-1: New USB device found, idVendor=1822, idProduct=3202
usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-1: Product: VP7041
usb 2-1: Manufacturer: TwinHan
The Thomson line was there, nevertheless the locking was fine back then:
1st consecutive test run using tzap:
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 69000 Hz
video pid 0x00a0, audio pid 0x0050
status 00 | signal 1d37 | snr | ber 001f | unc |
status 1a | signal 2161 | snr 0046 | ber 001f | unc | FE_HAS_LOCK
status 1b | signal | snr 0044 | ber 001f | unc | FE_HAS_LOCK
status 1b | signal | snr 0046 | ber 8a18 | unc 0038 | FE_HAS_LOCK
status 1b | signal | snr 004b | ber 4d60 | unc | FE_HAS_LOCK
status 1b | signal f4dd | snr 003a | ber 3ee4 | unc | FE_HAS_LOCK
2nd consecutive test run using tzap:
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 69000 Hz
video pid 0x00a0, audio pid 0x0050
status 02 | signal | snr | ber 001f | unc |
status 1a | signal 9bd0 | snr 0043 | ber 001f | unc | FE_HAS_LOCK
status 1b | signal | snr 0040 | ber 001f | unc | FE_HAS_LOCK
status 1b | signal f4dd | snr 0044 | ber 8754 | unc 002e | FE_HAS_LOCK
status 1b | signal | snr 0042 | ber 94a4 | unc | FE_HAS_LOCK
status 1b | signal | snr 003a | ber 000187e8 | unc | FE_HAS_LOCK
3rd consecutive test run using tzap:
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 69000 Hz
video pid 0x00a0, audio pid 0x0050
status 1e | signal 858e | snr 0058 | ber 001f | unc | FE_HAS_LOCK
status 1b | signal | snr 004c | ber 001f | unc | FE_HAS_LOCK
status 1b | signal | snr 0042 | ber 5b18 | unc 000c | FE_HAS_LOCK
status 1b | signal | snr 0044 | ber 697c | unc | FE_HAS_LOCK
status 1b | signal f4dd | snr 004e | ber 5f20 | unc | FE_HAS_LOCK
status 1b | signal | snr 0055 | ber 5f20 | unc | FE_HAS_LOCK
status 1b | signal | snr 0037 | ber 5400 | unc | FE_HAS_LOCK
So even with a poorly aligned antenna I get some BER, but I always have the
instant lock as expected.
This changed with with the eeprom protection you introduced in 2.6.31, and the
patch for Mario Bachmann never fixed it for my dib3000mb device.
--
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
