Hauppauge WinTV-NOVA-T-500

WinTV-Nova-T-500

This is a dual tuner DVB-T PCI card from Hauppauge.

Native support under Linux started at kernel 2.6.19. As development and refinements never stopped since then, it is strongly suggested to compile an up-to-date v4l-dvb drivers tree and get the latest firmware.

Overview/Features

In actuality, the device's receivers are USB based, but there aren't any USB plugs or sockets involved -- the single PCI card itself sports on board dual USB based receivers that interface with a host USB 2.0 controller (USB to PCI). This unique design is also known as "Bristol".

Components Used

• 2x Microtune MT2060 tuner
• 2x DiB3000P DiBcom DVB-T demodulator & USB controller
• 1x VIA VT6212L host USB 2.0 controller (USB-to-PCI)
• A single Low Noise Amplifier (LNA) is present for both channels, but needs to be manually activated (see below).

Some further technical details may be found in DiBcom DiB0700 USB2.0 DVB-T based devices.

Identification

You will find the model name and number on the box, under the bar code. Cards known to work have the following:

• WinTV-NOVA-T-500 model 289 SL-289-V2.0-UK (in the UK there is also a model 287 - according to Hauppauge UK support this is identical to the model 289 - it is just a PC World/Dixons specific box)
• WinTV-NOVA-T-500 model 289 SL-289-V2.1-UK ... Note: It would appear that having V2.1 on the box could be either the Nova-T or the unsupported Nova-TD (see below). Most confusing!
• List incomplete, please add

Cards not working have the following model name:

• WinTV-NOVA-T-500 model 283 SL-283-V2.0-GER (ships in Germany in a regular box but has a card with two aerial connectors on the inside. A single silver cage on the card carrying the two tuners has a sticker saying "WinTV-NOVA-TD-500 84109 LF". Therefore, the card might have a similar chipsets as the Diversity card shipping in UK.)

Update 21/09/10: WinTV-NOVA-T-500 model 283 SL-283-V2.0-GER with "WinTV-NOVA-T-500, 99101 LF, Rev D8B5" written on the label of the tuner is actually supported.

WinTV-NOVA-TD-500

if my understanding is correct then this board is supported. see the message:

Re: [linux-dvb] Looks like there's a new unsupported WinTV Nova T 500 out there

by Michael Krufky on the 28th August 2008

Update| 14/01/2009: TD500 as specified in note below (but without any diversity stickers, and model 84109 LF Rev D1F4 on card) works well with MythTV v0.21 on AMD 4000+ Mythbuntu 8.10 64-bit. Rob Sworder 14/01/2009

Update| 20/02/2011: Just received two cards TD500 cards with model number SL-289-V3.0-UK. They appear to use the VIA USB chips and worked straight away with MythTV / Fedora. Martin Smith 20/02/2011

Update| 17/07/2011: My new TD500 card is working brilliantly with MythTV 0.24.1-2.fc14.x86_64 and Fedora 14 2.6.35.13-92.fc14.x86_64. I can make four simultaneous recordings with it whilst using a single aerial cable. USB details: Bus 002 Device 002: ID 2040:8400 Hauppauge. Internal label says: WinTV-NOVA-TD-500 DVB-T 84109 LF REV E1F4 Product of Indonesia. Circuit board says 840000-05 LF. It says SL-289-V3.0-UK on the box, the same as Martin's did.

Note: This may be an unsupported 'Diversity' revision !!

Warning! WinTV-Nova-TD-500

This card appears to have been released, in low volumes, only in the UK, but unfortunately it seems that Hauppauge was shipping the Diversity* card in regular NOVA-T-500 boxes!

[* 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]. ]

This newer revision can be distinguished by:
On the box:

• You will find the model name and number under the bar code:
  • WinTV-NOVA-T-500
  • model 289
  • SL-289-V2.1-UK.
• The box also has a sticker stating it is the diversity option and only suitable for intel cards.
  • To quote one user running the device under Windows: "When i put it in my athlon based XP box it blue screened as soon as i tried to load the drivers. I brought mine from Amazon.co.uk and there was no mention that this card was any different or wouldn't work with non-intel processors."

On the card:

• it is labeled with the 'Diversity' feature stickers and the actual model number on the printed circuit board is NOVA-TD-500 (WinTV-NOVA-TD-500 DVB-T 68109 LF rev C1B5)
• the card has two aerial connectors.
• it uses a DiB0710 host USB controller (USB-to-PCI controller) instead of a VIA controller

The DiBcom DiB0710 controller used by this newer revision was apparently never sold for mass-production and DiBcom has end-of-life'd the chip. Furthermore, DiBcom currently do not plan on providing support for this controller. Consequently, given the low shipping volume and the limited support options, development of a Linux driver for this revision would likely be a waste of effort. [2][3]

Fortunately, for Linux users who have mistakingly received a Diversity variant, Hauppauge are apparently willing to exchange this product to a genuine T-500. Call the UK support line 0207 378 0202 and say you have read this article and bought your product from ebuyer, dabs or wherever.

I have been in contact with Hauppauge Technical Support in the UK and only 200 copies of the NOVA-T-500 board was made and there are none left. So they will not do a swap. The NOVA-TD-500 is all they make now. Simon Kenyon 2009-01-07

2009-01-13. A new T-500 arrived today. The box has the identification above - model 289, SL-289-V2.1-UK. It is a NOVA-TD-500. However:

• It has no 'diversity' sticker.
• It uses a VIA USB controller, not DiBcom.

It does have two aerial connectors. The USB id is 2040:8400. It was not recognised by a Debian 2.6.26 kernel, but works with current Mercurial sources. It looks like it will work with stock 2.6.27 kernels. In summary, if you buy a new T-500, it will almost certainly be a new TD-500, not one of the Diversity troublemakers, and it is supported.

Making it Work (generic for all dib0700)

Firmware

August 21, 2008 - New firmware file fixing the last cause for i2c errors and disconnects and providing a new, more modular i2c request formatting.

You will need the dvb-usb-dib0700-1.20.fw firmware file in /lib/firmware or the relevant place for your distribution.

You may need to change the name of the file to dvb-usb-dib0700-1.10.fw or create a link until the driver code reflects that change.

For archival purposes: dvb-usb-dib0700-1.10.fw firmware file

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.

Drivers

It requires the dib0700 driver. Just use Mercurial by following the How to Obtain, Build and Install V4L-DVB Device Drivers instructions.

Forcing the activation of LNAs (Low Noise Amplifier)

You may have to force LNA to get this card working:

In /etc/modprobe.d/options add:

options dvb_usb_dib0700 force_lna_activation=1

Disabling the remote control sensor

You may want to disable the remote control sensor if you are using another one and want to avoid error messages in the logs:

In /etc/modprobe.d/options add:

options dvb_usb disable_rc_polling=1

All relevant kernel modules options

In /etc/modprobe.d/options add:

options [module name] [option name]=[setting]

Get the parameters list using

modinfo [name of kernel module]

The debug values are bit fields, with each bit representing a different category. Add values to turn on multiple debugging categories.

dib3000mc

debug

Turn on debugging

Values: integer

Default: 0 (off)

buggy_sfn_workaround

Enable work-around for buggy SFNs

Values: integer

Default: 0 (disabled)

mt2060

debug

Turn on debugging

Values: integer

Default: 0 (off)

dvb_usb_dib0700

force_lna_activation

Force the activation of LNAs (Low Noise Amplifier), if applicable for the device

Values: integer

Default: 0 (automatic/off)

dvb_usb_dib0700_ir_proto

Set IR protocol

Values: integer 0=NEC, 1=RC5, 2=RC6

Default: 1

debug

Set debugging level

Values: integer (bitmap) 1=info, 2=fw, 4=fwdata, 8=data

Default: 0 (none)

dvb_usb

debug

Set debugging level

Values: integer (bitmap) 1=info, 2=xfer, 4=pll, 8=ts, 16=err, 32=rc, 64=fw, 128=mem, 256=uxfer

Default: 0 (none)

disable_rc_polling

Disable remote control polling

Values: integer

Default: 0 (enabled)

force_pid_filter_usage

Force all DVB USB devices to use a PID filter, if any

Values: integer

Default: 0 (disabled)

dvb_core

dvb_net_debug

Enable debug messages

Values: integer

Default: 0 (disabled)

frontend_debug

Turn on frontend core debugging

Values: integer

Default: 0 (off)

dvb_shutdown_timeout

Wait n seconds after close() before suspending hardware

Values: integer

Default: 0

dvb_force_auto_inversion

Set whether INVERSION_AUTO is forced on

Values: integer

Default: 0 (off)

dvb_override_tune_delay

Wait n milliseconds for lock after a tuning attempt

Values: integer

Default: 0

dvb_powerdown_on_sleep

Turn LNB power off on sleep

Values: integer

Default: 1 (enabled)

cam_debug

Enable verbose debug messages

Values: integer

Default: 0 (off)

debug

Turn on debugging

Values: integer

Default: 0

dvbdev_debug

Turn on device debugging

Values: integer

Default: 0 (off)

dibx000_common

debug

Turn on debugging

Values: integer

Default: 0 (off)

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
  • How to handle the input? aka. the DRIVER. E.g. devinput
• Settings for mapping driver output generated by your remote (a bunch of hex numbers) to key names (something like 0..9, Volume+, Next, Record)
• Settings for mapping key presses to actions (usually located in your .lircrc)

Mythubuntu case

On mythubuntu 10.10, you just have to add this line in /etc/udev/rules.d/65-persistent-hauppauge.rules

SUBSYSTEM=="input", KERNEL=="event*", ATTRS{idVendor}=="2040", ATTRS{idProduct}=="8400", SYMLINK+="lirc0"

Device/driver settings

Find the IR receiver's device by looking in the dmesg output for a line similar to:

input: IR-receiver inside an USB DVB receiver as /class/input/input4

Additionally, the IR receiver will be listed if you execute the command:

cat /proc/bus/input/devices

For example:

I: Bus=0003 Vendor=2040 Product=9950 Version=0100
N: Name="IR-receiver inside an USB DVB receiver"
P: Phys=usb-0000:07:01.2-1/ir0
S: Sysfs=/class/input/input4
U: Uniq=
H: Handlers=kbd event4 
B: EV=3
B: KEY=14afc336 284284d00000000 0 480058000 219040000801 9e96c000000000 90020000000ffd

In this example, the remote control gives output into /dev/input/event4.

The event number depends on your particular system and can vary.

Eventually this event number can even vary at every reboot.

You could create a new udev rule in /etc/udev/rules.d/65-persistent-hauppauge.rules.

KERNEL=="event*", ATTRS{name}=="IR-receiver inside an USB DVB receiver", SYMLINK+="input/dvb-ir"

This would make IR receivers handled by the usb_dvb framework always always be linked to /dev/input/dvb-ir.

But Linux systems running recent udev will automatically create non-varying names, a nicer and automatic way of providing a stable input event name:

$ ls -la /dev/input/by-path/
total 0
drwxr-xr-x 2 root root 140 2008-02-07 20:31 .
drwxr-xr-x 4 root root 280 2008-02-07 20:31 ..
lrwxrwxrwx 1 root root   9 2008-02-07 20:31 pci-0000:00:1a.1-usb-0:2:1.0-event-kbd -> ../event1
lrwxrwxrwx 1 root root   9 2008-02-07 20:31 pci-0000:00:1a.1-usb-0:2:1.1-event-mouse -> ../event2
lrwxrwxrwx 1 root root   9 2008-02-07 20:31 pci-0000:00:1a.1-usb-0:2:1.1-mouse -> ../mouse1
lrwxrwxrwx 1 root root   9 2008-02-07 20:31 pci-4-1--event-ir -> ../event4
lrwxrwxrwx 1 root root   9 2008-02-07 20:31 platform-pcspkr-event-spkr -> ../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:

#Chosen Remote Control
REMOTE="Terratec Cinergy DT USB XS Diversity"
REMOTE_MODULES=""
REMOTE_DRIVER="devinput"
REMOTE_DEVICE="/dev/input/by-path/pci-1-5-event-ir"
REMOTE_LIRCD_CONF="/etc/lirc/lircd.conf"
REMOTE_LIRCD_ARGS=""

#Chosen IR Transmitter
TRANSMITTER="None"
TRANSMITTER_MODULES=""
TRANSMITTER_DRIVER=""
TRANSMITTER_DEVICE=""
TRANSMITTER_LIRCD_CONF=""
TRANSMITTER_LIRCD_ARGS=""

Remote key setup

See device specific section below or try [4].

Sample .lircrc

A sample .lircrc can be found LircrcExample here.

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

 begin
  prog = mythtv
  button = Mute
  config = echo " > /dev/null
  config = |
  ...
 end

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

Remote control key codes

Snowboard remote control

Grey top, black bottom, 45 buttons, snowboard shape.

Here is a proper lircd.conf:

#
# brand:                       Hauppauge
# model no. of remote control: 45 buttons Snowboard Shape Silver over Black
#

begin remote

 name  hauppauge-45-snowboard
 bits           16
 eps            30
 aeps          100

 one             0     0
 zero            0     0
 pre_data_bits   16
 pre_data       0x1
 gap          199999
 toggle_bit      0


     begin codes
         Go                       0x0162
         Power                    0x0074
         TV                       0x0179
         Videos                   0x0189
         Music                    0x0188
         Pictures                 0x00E2
         Guide                    0x016D
         Radio                    0x0181
         ArrowUp                  0x0067
         ArrowLeft                0x0069
         OK                       0x0160
         ArrowRight               0x006A
         ArrowDown                0x006C
         BackExit                 0x009E
         Menu                     0x008B
         VolumeUp                 0x0073
         VolumeDown               0x0072
         PrevCh                   0x016B
         Mute                     0x0071
         ChannelUp                0x0192
         ChannelDown              0x0193
         Record                   0x00A7
         Rewind                   0x00A8
         SkipBack                 0x0195
         Play                     0x00CF
         Pause                    0x0077
         Stop                     0x0080
         Fwdwind                  0x00D0
         SkipFwd                  0x0197
         1                        0x0002
         2                        0x0003
         3                        0x0004
         4                        0x0005
         5                        0x0006
         6                        0x0007
         7                        0x0008
         8                        0x0009
         9                        0x000A
         *                        0x0037
         0                        0x000B
         #                        0x0029
         Red                      0x018E
         Green                    0x018F
         Yellow                   0x0190
         Blue                     0x0191
     end codes

end remote

Silver remote

Assuming, you have a silver remote, named A415-HPG-WE-A. The following keycodes should work with it, specify them in /etc/lirc/lircd.conf:

 begin remote
  name  Hauppauge A415-HPG-WE-A
  bits           16
  eps            30
  aeps          100
  one             0     0
  zero            0     0
  pre_data_bits   16
  pre_data       0x1
  gap          403983
  toggle_bit_mask 0x80000000
     begin codes
         TV                       0x0179
         Videos                   0x0189
         Music                    0x0188
         Pictures                 0x00E2
         Radio                    0x0181
         Guide                    0x016D
         Off                      0x0074
         Go                       0x0162
         Up                       0x0067
         Down                     0x006C
         Left                     0x0069
         Right                    0x006A
         Ok                       0x0160
         Menu                     0x008B
         Back/Exit                0x009E
         Vol+                     0x0073
         Vol-                     0x0072
         PrevCh                   0x016B
         Mute                     0x0071
         Ch+                      0x0192
         Ch-                      0x0193
         Stop                     0x0080
         Record                   0x00A7
         Rew                      0x00A8
         Play                     0x00CF
         FFW                      0x00D0
         Pause                    0x0077
         Replay                   0x0195
         Skip                     0x0197
         1                        0x0002
         2                        0x0003
         3                        0x0004
         4                        0x0005
         5                        0x0006
         6                        0x0007
         7                        0x0008
         8                        0x0009
         9                        0x000A
         Star                     0x0037
         0                        0x000B
         Char                     0x0029
         Red                      0x018E
         Green                    0x018F
         Yellow                   0x0190
         Blue                     0x0191
     end codes
 end remote

On-board LNA

You may want/need to turn on the on-board amplifier:

sudo gedit /etc/modprobe.d/options

Add:

options dvb-usb-dib0700 force_lna_activation=1

Or if you are using Ubuntu 9.04 onwards

sudo gedit /etc/modprobe.d/options.conf

Add:

options dvb-usb-dib0700 force_lna_activation=1

Jittery reception?

This card has an issue (which particularly manifests itself in Australia where a bandwidth of 7MHz is used) with jittery reception - artifacts and choppy sound throughout recordings despite having full signal strength. Australian users will typically see this behaviour on SBS and ABC channels.

The fix is to enable the 'buggy sfn workaround':

sudo gedit /etc/modprobe.d/options

Add:

options dib3000mc buggy_sfn_workaround=1

or if you are using Ubuntu 9.04 onwards

sudo gedit /etc/modprobe.d/options.conf

Add:

options dib3000mc buggy_sfn_workaround=1

See also: Talk:Hauppauge_WinTV-NOVA-T-500

Losing one tuner?

There are reports of the system losing one of the 2 tuners. This behaviour could be caused by the USB sub-system going to sleep/suspend.

A work-around is to pass a parameter to the usbcore kernel module, asking it to disable its suspend capability.

Edit the /etc/modprobe.d/options file and add:

options usbcore autosuspend=-1

or if you are using Ubuntu 9.04 onwards

Edit the /etc/modprobe.d/options.conf file and add:

options usbcore autosuspend=-1

If you are using a Debian-based distribution, you may need to rebuild your initrd and reboot for this to take effect as per this post.

If your kernel has usbcore built-in (e.g. Fedora Core 8, Ubuntu 12.04) and not as a module, you will have to modify your boot loader config to pass the parameter to the kernel at boot time by adding the following to your kernel boot line in your GRUB or LILO config:

usbcore.autosuspend=-1

More information about this is available on this mailing list post.

Another solution has been given for MythTV users and is worth trying:

MythTV has a parameter to delay the tuning of channels in the same configuration screen where you select active/passive EIT scanning. More precisely, it's at the right of the Active EIT scanning checkbox. I have adapter0 with passive EIT scanning, and 0 delay, and adapter1 with Active EIT scanning and 150ms of tuning delay. That solved the tuner-losing stuff and also I have my EIT fully populated.

More information about this is available on this mailing list post.

There is a step-by-step guide on how to setup MythTV and achieve tuner stability here.

About the stabilty of this driver

The current drivers are close to stable at the moment (2008-01-25). Occasional USB disconnects may still be experienced. The disconnects were caused by disabling the pull-down resistors or unintentional writes from the dib0700 bridge to the usb bus when accidentally hitting the end of a SOF packet. Why and when this happens can only be debugged by the dibcom firmware guys [5] . Other possible reasons for bad behavior could be bad reception (check your aerial, cabling, splitters and low-cost amplifiers) and EIT scanning. Search the linux-dvb mailing list for more information and current problems being experienced.

2008-06-16 - Today, using an up-to-date Ubuntu 8.04 x64, a recent V4L-DVB tree, the MythTV tuning and EIT settings and the provided remote receiver, this card is absolutely rock solid with no USB disconnects, no tuner lost or any other trouble. The few MythTV tweaks are an slight annoyance, but they are worth it. This card is a great DVB-T solution!

When used with VDR the driver will randomly start logging i2c read/write errors and the second tuner becomes unresponsive. After a couple of weeks of testing I've found that disabling the EPG scan (EPGScanTimeout = 0) works around the issue reliably.

Rare power issue

When this DVB-T card was plugged into a system based on an Asus Z8NA-D6 motherboard, a significant and unexpected increase in power consumption was noticed. The increase was about 20 W for an idle system, and would occur even when not watching TV. In fact it would happen even with the relevant kernel drivers blacklisted, which rules out a possible driver issue. This is believed to be a subtle hardware incompatibility, where the Hauppauge WinTV-NOVA-T-500 card prevents the motherboard's north bridge from using low power states. The exact details aren't known. The same card used in a different system did not cause the problem, and other cards used in the Asus Z8NA-D6 system did not either.

Sample kernel output

[   34.053116] dib0700: loaded with support for 7 different device-types
[   34.054165] dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in cold state, will try to load a firmware
[   34.268559] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.10.fw'
[   34.479133] dib0700: firmware started successfully.
[   34.980174] dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in warm state.
[   34.980218] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[   34.980411] DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T)
[   35.093975] DVB: registering frontend 0 (DiBcom 3000MC/P)...
[   35.124572] MT2060: successfully identified (IF1 = 1245)
[   35.602656] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[   35.602833] DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T)
[   35.608527] DVB: registering frontend 1 (DiBcom 3000MC/P)...
[   35.613271] MT2060: successfully identified (IF1 = 1251)
[   36.172233] input: IR-receiver inside an USB DVB receiver as /devices/pci0000:00/0000:00:1e.0/0000:07:01.2/usb10/10-1/input/input4
[   36.198807] dvb-usb: schedule remote query interval to 150 msecs.
[   36.198811] dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully initialized and connected.
[   36.199046] usbcore: registered new interface driver dvb_usb_dib0700

Rebooting warning

The T500 has a characteristic which is apt to confuse. Changes to drivers, configuration parameters (eg turning on LNA) etc will not be implemented by a simple 'warm' reboot. It needs a power down, complete removal of power from the system (unplug at wall socket or turn PSU off) then power up - a cold boot. Oddly, this same procedure has also been necessary after changing X11 parameters to switch between HDMI and VGA.

External Links

• Hauppauge UK product page (no longer listed)
• The new model currently being sold
• Hauppauge UK product support page
• A slightly dated user page, but it may still be useful for some
• MythTV wiki page on this card (updated)