As soon as I saw this on Engadget I came to tvheadend forum to check compatibility news :)
Hopefully an xbox owning linux user can plug into their system to find out what chipset etc is used.
It may be that its already working OOB, or with v small patch.
Fingers crossed...
13 days later
Device IDs 

0x045e Vendor ID
0x02d5 Product ID

USB Controller 

DiBcom
0700C-XCXXa-G
USB 2.0
D82AC.4
1423-0100-C

Demodulator 

Panasonic
MN88472
408P303E

Tuner 

NXP
8250B
06 05
ZXD4121

dmesg output 

usb 1-3: new high-speed USB device number 4 using ehci-pci
usb 1-3: New USB device found, idVendor=045e, idProduct=02d5
usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-3: Product: Xbox USB Tuner
usb 1-3: Manufacturer: Microsoft Corp.
usb 1-3: SerialNumber: 002493080162

lsusb verbose output 

Bus 001 Device 005: ID 045e:02d5 Microsoft Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x045e Microsoft Corp.
  idProduct          0x02d5 
  bcdDevice            1.10
  iManufacturer           1 Microsoft Corp.
  iProduct                2 Xbox USB Tuner
  iSerial                 3 002493080162
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           46
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           4
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)
2 months later
what was the consensus on this? Does it look like it's supported in Linux?
2 months later

I've got the device and have been playing around with it a bit.

The situation with the individual components is following:

- Dibcom 0700C USB bridge is well supported, the driver needs just minor tweaking in order to support the Xbox tuner.
- The MN88472 demodulator support is improving rapidly, not sure if this needs any changes.

- The NXP TDA18250B tuner does not have any support at the moment. A driver for this needs to be written. Doesn't look too bad when looking at what exists already (similar drivers for similar NXP devices).

In order to proceed a USB trace between the Xbox One and the tuner is necessary. Basically a hardware USB sniffer should be placed between the Xbox and the tuner and traffic on the USB would need to be captured. I don't have such a sniffer nor the Xbox One, so I cannot proceed much at this point...
2 months later

This has been reduced to £19.85 at Amazon and shopto.net - I wonder if there's any known progress with this tuner and Linux compatibility?

It would be a good device, due to multiple DVB-C/DVB-T/DVB-T2 compatibility, relatively low cost and seemingly wide availability.
<<
14 days later
Yeah, I'm tempted by it as well!

You still need to find someone who has all these three:

1) Xbox One tuner
2) Xbox One console itself

3) Hardware USB sniffer

Then save a sniff of the USB bus between the console and the tuner when the tuner is plugged in.

I bought a tuner and made a hardware sniffer from BeagleBone Black with the help of this project - https://github.com/dominicgs/USBProxy . Then I bought an Xbox One and tried to take the traces. Unfortunately the BBB-turned-into-sniffer did not work too well and I was not able to take proper traces before I had to return the Xbox One to the store.

As soon as the traces have been taken, there are a couple of developers interested in the driver development (myself included).

If someone's willing to borrow me a USB 2.0 capable HW sniffer, I could buy another Xbox One to take the traces of course. :)
Olli Salonen wrote:
> You still need to find someone who has all these three:
>
> 1) Xbox One tuner
> 2) Xbox One console itself
> 3) Hardware USB sniffer
>
> Then save a sniff of the USB bus between the console and the tuner when the tuner is plugged in.
>
> I bought a tuner and made a hardware sniffer from BeagleBone Black with the help of this project - https://github.com/dominicgs/USBProxy . Then I bought an Xbox One and tried to take the traces. Unfortunately the BBB-turned-into-sniffer did not work too well and I was not able to take proper traces before I had to return the Xbox One to the store.
>
> As soon as the traces have been taken, there are a couple of developers interested in the driver development (myself included).
>

> If someone's willing to borrow me a USB 2.0 capable HW sniffer, I could buy another Xbox One to take the traces of course. :)

Bah! I just sent an e-mail to Antti (crope) asking if he knew of the state of support for this tuner too & you've pretty much answered it for me (it's non-existent!)

@Olli Salonen

Yeah, I tried the same.. by getting the BeagleBone Black and using USBProxy with it... sometimes the xbox looked like it'strying to detect the tuner.. but failed in the end...
The Xbox seems to upload the firmware to the tuner but then USBProxy fails to enum the device after firmware-download/modeswitch (?!)

I attached usbproxy.log and pcap capture file.

How did I make those captures?
Using beaglebone Black running 3.8.13-bone71 and patched inode.c / gadgetfs module
> rmmod g_serial
> rmmod libcomposite
> tcpdump -i usbmon1 -w capture.pcap

> usb-mitm -v 045e -p 02d5 -l -dd &> usbproxy.log

Now I am trying to find the I2C Bus on the PCB and hooking some wires to it.. so I can use "BeagleLogic" (Beaglebone Logic Analyzer: https://github.com/abhishek-kakkar/BeagleLogic) to gather the sent commands.

So far I cannot report any good results tho...

UPDATE: Btw, I stumbled upon this: https://github.com/bertwu/Madsion/blob/548861a3fc1c4c6b5bd05ce35024be7dca0cfc03/MBoot_Madison_TVOS/MstarCore/src/drivers/tuner/tmbslTDA18250A/drvTuner_TDA18250A.c

UPDATE_2: Attached usbproxy capture & logfile

UPDATE_3: So, if somebody wants to assist and has the hardware handy (the tuner) please try to replay the pcap file via usbreplay (https://github.com/wcooley/usbrevue).. that way the firmware can get uploaded.. and USBProxy does not need to care about the resetted device and would maybe sniff some good stuff of the init process. With wireshark for example, you can chop the pcap into pieces.

UPDATE_4: Ok guys, it's all yours... I broke my adapter. So dunno if my previous dumps are even valid..
a year later

If someone are still working on this, I would like to assist since I try to achieve the same goal.

edit 1:
I used the sources code here https://github.com/hisilicon/x5hd2-drivers/tree/master/source/msp/drv/frontend/tuner/tda18250b that seems have the same base as the source from Madsion above.

The codes are very useful to understand what going on but my undrestanding in the matter of electronics are limited.

I provided some logs. All useful information are intmbslTDA18250A.c .

"function tmbslTDA18250A_Open line 366", the lines number will not match with the origin source cause I have add some lines. "<0x60[0x0] 0x0000c7", means "<"= result fro read at i2c address 0x60 and registry at 0x0 has return 0xc7 ">0x60[0x25] 0x0000cb", ">"= write at i2c address 0x60 and registry at 0x25 the value 0xcb

The channels scan have been made with dvbv5-scan with fr-all file from dvb-t and fr-noos-numericable for dvb-c.

edit 2:

The issue that I have is I can't get any signal despite of the execution code seems to happen normally.

+edit 3:+
I tried the Madison code, it have some specific code for tda18250b but always no locked signal.

Logs provide and the function to set the frequency are different.

EDIT 4 The sources code have some specifics parameter, as IF, that I have to find but without a possibility to "sniff" the communication between the xbox an the device I tried to "brute force " it.
I have found that 550000 Hz, 50000 Hz can lock dvb-t signal and 495000 Hz a dvb-c signal. Not sure if there are a good one's or noises.
There are some parameter, as AGC and some filters than I can undestand so I am stuck.
a month later

Hi Sky Anakin,

Thanks for the log files on this - it has spurred me on to get around to taking a look at this device. From your first logs (logs.zip) you do appear to have the IF set correctly. The TDA18250 code sets this up as pStandard->IF and I can confirm that the IF for DVB-T (all I have access to) seems correct. I get a tuner lock with this IF on a carrier with a DVB-T multiplex (490MHz carrier, 8MHz bw, UK). The tuner IF is set as 4950000 for DVB-T with 8MHz bandwidth in 'tmbslTDA18250A_Config_DVBT.h' (the macro actually sets it as "5000000-50000" - I'm using the macro 'TDA18250A_CONFIG_STD_DVBT_8MHZ_VCO_PULLING_MINUS' for this). Your logs show that reg 0x26 (IF byte) is set to 0x63 (or 99). I'm guessing this value sets the IF in increments of 50000Hz from playing around with it.

However, your logs also show this message:

mn88472 0-0018: get_if_frequency=474000000

From the way this message changes in the scan log, you appear to be returning the carrier frequency to the demod as the Intermediate frequency. You need to make the tuner method 'get_if_frequency()' return the value of 'pStandard->IF'. Then, if the tuner locks on the carrier, the demod should lock on the IF.

Other changes I made to get the device working:

The mn88472 demod needs to be configured for TS_PARALLEL_MODE and TS_FIXED_CLOCK (this demod is normally configured for SERIAL/VARIABLE CLOCK but that doesn't work for me).

The dib0700 bridge for this device appears to do bulk transfers via endpoint 0x82 - I normally configure this for 8 transfers with 8192 byte buffers and this worked OK for T and T2 multiplexes (the linux dib0700 driver configures 4 transfers with 39480 byte buffers). Oh, and I had to set 'disable_streaming_master_mode' - I'm not really familiar with this bridge device so I don't know what this does, but it doesn't appear stream data without it being set.

As I said, with these changes I got the device to stream both DVB-T and T2. Sorry, I don't have access to DVB-C source so I can't offer any help with this.

Cheers!

Gavin

Hi, It's wonderful that you get it works!! It make me get some hope again.

I made some mistakes cause of my ignorances, I though IF mean Input Frequency and I am a real noobs.

I tried with your configuration and I can't get any good results.

It's of course some parameters that I get wrong but I don't know where to investigate.

On dvb-c scan I can lock some frequency and some time I can get the channels name, see dvb-c scan output.

On dvb-t no luck.

Can you make a diff from your dib0700_device.c and mine, see tda18250b.zip.

thanks

Update 1 Foolish of me, the cable tv connection was no tied enough. DVB-C works, thanks!!!!!!!. I try to have DVB-T, have some trouble to lock any signal for now.

Good to hear that DVB-C is OK! Your changes to dib0700.c certainly look correct.

I think I may have found the issue with DVB-T - it's my mistake - a change that I made and 'forgot' about. At the top of this thread is a submission from 'tux user' (the second reply). He very helpfully posted lots of info on the device including pictures! The middle link shows a picture of the tuner and next to it is a small silver 'can' with "27.000" printed on it (it's upside down in the image). This is the crystal for the tuner - its frequency is 27MHz. There is another crystal some distance away labelled "20.500" for the mn88742 demod at 20.5MHz.

Anyway, seeing this I set the crystal frequency to 'TDA18250A_XtalFreq_27000000' for all configurations. The original source uses 'TDA18250A_XtalFreq_16000000'. I tried again with the 16MHz setting and the tuner PLL will not lock on DVB-T. Changing it to 27MHz does.

Give this a try - it's set in '...Config_Common.h' for the master and slave tuner configs.

Cheers,

Gavin

Hey,

Time to report back. I really like that you guys continued research and get to the state where frequency locking and stuff works.

I will have something cool for you soon.. For the people of you how would like to keep their tuner attached to the console ;)

Greetz and thanks
i get myself one of this today, but i am not so into soure editing, diffs....
maybe someone have a little howto for putting the changes in?
Xtal frequency is already set to 27MHz. Most propably a foolish mistake, I will make some clean up maybe I will sort this out.

@Andreas @Sky Anakin @Gavin Ridgway

What Do You think about setting up a git repo with the appropriate changes? It would surely help alot and its much more transparent than exchanging edited source files or diffs.

No problemo. I will upload the sources here probably this week-end. In the tda18250b.zip archive, what I haven't put are the unmodified sources from the Madison sources. For those who want to try, it should not be to hard.
i think this will be great, but i am afraid i cant help a lot setting up this repo.