Overview/Features

This device features two tuners and is supplied with two antennas. You'll have adapter0 and adapter1 in /dev/dvb, which you can use separately. Adapter0 seems to be the connector on the side of the stick? Note that you need to have 2 antenna leads plugged into the stick, one in the end, and the other into the side in order to get both tuners to work! Owner's manual is here.

The "Diversity" option is a hardware based feature that allows for the device's two receivers to be configured in a combined use mode to achieve better reception on a single channel. The diversity feature of the DiBcom demodulators is currently not implemented in the Linux-DVB drivers, so only the dual tuner configuration is presently supported on such devices [1].

Note: The dual tuner may not work on amd690g chipset (SB600 southbridge).

August 29,2008 - Issues with Firmware 1.20. Some issues have been found with the latest version of the firmware. Users may wish to continue to use 1.10 unless they have patched their v4l-dvb code with dib0700_new_i2c_api.patch.

November 15,2008 - Issues with Firmware 1.20.

The above mentioned dib0700_new_12c_api.patch is not available discretely but is now rolled into the mercurial drivers

dvb-usb-dib0700-1.20.fw firmware file is now stable for reception, but remote control functionality is broken; any key press is repeated until the next key is pressed. The only way to get remote control functionality presently is to roll back to 1.10 firmware and suffer the occasional disconnect.

The mercurial drivers have been changed so they now load 1.20 firmware. To revert to 1.10 firmware you need to rename your firmware file to dvb-usb-dib0700-1.20.fw or provide a link of that name.

To avoid spurious remote control signals with 1.20 firmware, you need to edit /etc/modprobe.d/options or from Ubuntu onwards /etc/modprobe.d/options.confand add:

options dvb_usb disable-rc-polling=1

November 28,2008 - i2c errors.
Changes were made to the remote control drivers on November 16,2008 to correct the repeat key problem. The card is generally stable for dual tuner reception and remote control function with Firmware 1.20.

November 10,2009 - mt2060 I2C write failed.
Possible regression of a driver bug raised against Ubuntu running 2.6.27-14 and 2.6.31-2.17 causing mt2060 I2C errors in MythTV useage with firmware 1.20.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/397696
Recommend check the kernel extensions listed here for Low Noise Activation and rc_polling are loaded with correct config file name for your distribution, EIT listings information is turned off until a suitable delay (500ms-1000ms)is added to a single card (not both) and the card has correctly been added to the database as two tuners (no additional NULL entries) in the mythtv recordcard table.

dibx000_common

Remote control support

Using evdev

As long as the evdev module is loaded, a remote that is recogniced as hid device will be treated as a usb keyboard and this means that you can avoid using lirc.

However, many of the keys on your remote may generate keycodes which are not mapped to anything, by default.

In X you can use xev to find the keycodes and xmodmap to map them to useful symbols.
Unfortunately, some keys may generate keycodes that X doesn't recognize at all and the device does not support keymaps, or this would be easy to fix.

Using LIRC

Usually remote controls in linux are managed by the lirc software collection.

To get lirc up and running you need to configure some things.

Settings for the hardware

Where does lirc get its input from? aka. the DEVICE. E.g. /dev/input/event3

LIRC will use it without needing a special kernel module. use the dev/input (or devinput. Check this with the command "lircd --device=help".) driver and specify the input event device in /etc/lirc/hardware.conf

# /etc/lirc/hardware.conf
#
# Arguments which will be used when launching lircd
LIRCD_ARGS=""
#Don't start lircmd even if there seems to be a good config file
#START_LIRCMD=false
#Try to load appropriate kernel modules
LOAD_MODULES=true
# Run "lircd --driver=help" for a list of supported drivers.
DRIVER="dev/input"
# If DEVICE is set to /dev/lirc and devfs is in use /dev/lirc/0 will be
# automatically used instead
REMOTE_DEVICE="/dev/input/by-path/pci-4-1--event-ir"
MODULES=""
# Default configuration files for your hardware if any
LIRCD_CONF="/etc/lirc/lircd.conf"
LIRCMD_CONF=""

If you have REMOTE and TRANSMITTER sections in your hardware.conf file, they should look like this:

Remote key setup

Sample .lircrc

Keys repeated twice

But there is still the problem of the key repeats for it, so that each keypress will be repeated twice. The patches, as mentioned above, may not work, but a workaround is possilbe. It is described in http://ubuntuforums.org/showthread.php?p=4253678

Simply add config = echo " > /dev/null before the main config in .mythtv/lircrc or .lircrc

So each 2nd keypress will be suppressed. This works in some application but not others (e.g. vlc).

Alternatively there is a patch for the kernel driver that solves it, it can be found here.

Finally if that doesn't work and you have the silver remote (A415-HPG-WE-A
) then changing the lircd.conf line as follows can prevent the duplicate key presses. This has the side-effect of disabling key repeats for the remote entirely. Change
toggle_bit_mask 0x80000000
to
toggle_bit_mask 0x00000000

Note: do not try to comment out (using #) any line in this file, or lirc won't work anymore.

Do NOT do this:

#toggle_bit_mask 0x80000000
toggle_bit_mask 0x00000000

Replace the original line instead.

Specific to the model

Specific Remote control support

There is no need to compile and load any lirc modules; the remote is detected along with the tuner and is registered as a USB input device. If you are using udev or devfs then this means that the device should be linked to one of the /dev/input/event* device nodes and a simple rule will create a named symlink.

If you do want to use lirc set it up to use the that device as DEVICE and devinput as DRIVER. Then try one of the config files below.
If it doesn't work then you will need to use irrecord to generate a config file.

While key repeats are still buggy irrecord will fail if you obey its instructions and hold down an arbitrary key; instead, when you are told to hold an arbitrary key, press an arbitrary key repeatedly (the same one, not different ones each time) until irrecord reports that it has found the gap length.

As long as the evdev module is loaded, the remote will be treated as a usb keyboard and this means that you can avoid using lirc. Many of the keys generate keycodes which are not mapped to anything, by default, in X; you can use xev to find the keycodes and xmodmap to map them to useful symbols. Unfortunately, some keys generate keycodes that X doesn't seem to recognise at all (on my set-up, at least) and the device does not support keymaps, or this would be easy to fix.

Troubleshooting

It seems, that there exist USB-problems with mainboards using an AMD690g chipset concerning USB-disconnects. This problem is described here and on the linux-dvb Mailing list. (Disable the remote sensor?) --Doc murke 09:40, 13 March 2008 (CET)

Low power muxes

At least two people have indicated on the mailing list (8 April 2008 and 12 April 2008) that trouble picking up reception on low power muxes can be helped by adding an attenuator. It is thought that this may be caused by the internal amplifier taking in to account the strongest muxes only. Weakening the overall signal appears to increase the amplification of all muxes, so improving reception.

These devices appear to be susceptible to EM interference. This is in UK on DVB-T reception, 50Hz, 240VAC. Having two of these fed from coax Splitter into the back of a decent case (Silverstone LC04) it was found :-

- Leave the device and Co-ax feeding the device anywhere near the case power leads etc and experience screen freezes, pixelation and sound stutter.

- Plugging directly into the case on the USB port directly below the ethernet port picked up noise (Presumably from the ethernet Unshielded Twisted Pair 100M). Coaxes on this test were well routed so strongly believe this is the device.

To solve, use the USB extension leads from the box to get the actual device away from the case and run the coaxial cable well away from the rest of your cables.

Once this was done a 100% perfect picture 100% of the time.

If Hauppauge read this, please retest these devices in a controlled environment under the CE EMC directive and delete this if you can not simulate.