Tvheadend

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...

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)


what was the consensus on this? Does it look like it's supported in Linux?

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...

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.

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's trying 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..

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 in tmbslTDA18250A.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.

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 öman @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.

Tux Winter User

I'm not sure my source will be of use - it's not for a kernel driver so it's quite different to the normal linux kernel code. I will, of course, pass on all the info I can to get the kernel sources working.

@Sky Anakin

Are you still having issues with DVB-T locking? I plan to do a pass through my source code to check for any other differences I might have missed. I used the 'hisilicon' sources as my starting point - I diff'ed them with 'madison' last week and the differences appeared minimal, but 'madison' seemed to have more DVB-C modes. I'll let you know if I find anything else that might be different.

Plus, big thanks to everyone who's posted on this thread and provided information. It's been a great help in us getting this far.

@Garvin
Always nothing. Tried hisilicon sources, DVB-C OK but not DVB-T. I have checked with a TV that I can really get a signal, to be sure.

As there will maybe have some concern with copyright I am doubtfully that there will be an GPL drivers from this.

As said the driver are surelly not kernel-friendly but for those want to try the sources are attached

@sky anakin, how can i compile that?!

Have you already succeeded to compile the linuxtv sources, otherwise it could be lot harder.

I am not the best one to make a tuto how to compile this because I have done it the hard way. Haven't search enough how to do it.

1- Try to compile the latest sources from git

2- copy the modified files.
Clean v4l folder with "make clean".
Add "obj-$(CONFIG_MEDIA_TUNER_TDA18250B) += tda18250b_i2c.o" to linux/drivers/tuners/Makefile
Add "CONFIG_MEDIA_TUNER_TDA18250B=m" to v4l/.config
Add "CONFIG_MEDIA_TUNER_TDA18250B := m" to v4l/.myconfig

3- recompile.
Install with "sudo make install"
cp v4l/tda18250b_i2c.ko to the module kernel folder "/lib/modules/4.4.0-/kernel/drivers/media/tuners/"
reload modules dependencies with "sudo depmod -a"

Good luck

I made a git repo with Sky Anakin's changes. If someone wants to try out the driver, here's how:

git clone git://linuxtv.org/media_build.git
git clone -b xbox --depth=1 https://github.com/trsqr/media_tree.git
cd media_build/linux/
make tar DIR=../../media_tree
make untar
cd ..
make
sudo make install

And now reboot.

However, for me it fails.

[ 1608.143943] dvb-usb: found a 'Microsoft Xbox Tuner' in cold state, will try to load a firmware
[ 1608.145072] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw'
[ 1608.346393] dib0700: firmware started successfully.
[ 1608.848538] dvb-usb: found a 'Microsoft Xbox Tuner' in warm state.
[ 1608.848743] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[ 1608.848901] DVB: registering new adapter (Microsoft Xbox Tuner)
[ 1608.848909] usb 2-1: media controller created
[ 1608.849253] dvb_create_media_entity: media entity 'dvb-demux' registered.
[ 1609.040836] mn88472 0-0018: Panasonic MN88472 successfully attached
[ 1609.040851] BUG: unable to handle kernel NULL pointer dereference at           (null)
[ 1609.186758] IP: [<          (null)>]           (null)
[ 1609.261101] PGD 0 
[ 1609.332558] Oops: 0010 [#1] SMP 
...
[ 1612.135768] Call Trace:
[ 1612.205463]  [<ffffffffc05d8713>] ? mn88472_frontend_attach+0x193/0x1e0 [dvb_usb_dib0700]
[ 1612.345500]  [<ffffffffc0593c72>] dvb_usb_adapter_frontend_init+0xe2/0x1e0 [dvb_usb]
[ 1612.485204]  [<ffffffffc0593a19>] ? dvb_usb_adapter_dvb_init+0x1d9/0x2c0 [dvb_usb]
[ 1612.625498]  [<ffffffffc0592b03>] dvb_usb_device_init+0x503/0x750 [dvb_usb]

Here's the patch on top of current media_tree:
https://github.com/trsqr/media_tree/commit/d36d89ad26998ec1557f572ffa4ee1c4026ba1b1

@Olli
Tried your patch and no errors.
CONFIG_DVB_USB_DIB0700 is not set, have to edit.
What I done is to delete all staging modules from kernel cause sometimes there are two same module and one the staging have some bugs.

On my htpc, where there is another card, I have to remove the frame_vector module cause it cause some errors.

regards

Edit: Try to get ride of the module crash when the device is remove but don't know how. Need to restart the pc when I removed it for some reason.

 [<ffffffff81829a25>] schedule+0x35/0x80
[ 3960.085230]  [<ffffffffc085d4d1>] dvb_unregister_frontend+0xd1/0x130 [dvb_core]
[ 3960.085233]  [<ffffffff810c3ca0>] ? wake_atomic_t_function+0x60/0x60
[ 3960.085236]  [<ffffffffc08a1d9c>] dvb_usb_adapter_frontend_exit+0x3c/0x70 [dvb_usb]
[ 3960.085237]  [<ffffffffc08a0469>] dvb_usb_exit+0x49/0xf0 [dvb_usb]
[ 3960.085239]  [<ffffffffc08a054f>] dvb_usb_device_exit+0x3f/0x60 [dvb_usb]
[ 3960.085241]  [<ffffffff8161ced6>] usb_unbind_interface+0x86/0x280
[ 3960.085244]  [<ffffffff81553811>] __device_release_driver+0xa1/0x150
[ 3960.085245]  [<ffffffff815538e3>] device_release_driver+0x23/0x30
[ 3960.085246]  [<ffffffff81552f31>] bus_remove_device+0x101/0x170
[ 3960.085248]  [<ffffffff8154f089>] device_del+0x139/0x260
[ 3960.085249]  [<ffffffff816217ff>] ? usb_remove_ep_devs+0x1f/0x30
[ 3960.085251]  [<ffffffff8161a699>] usb_disable_device+0x89/0x270
[ 3960.085253]  [<ffffffff8160ffd2>] usb_disconnect+0x92/0x280
[ 3960.085254]  [<ffffffff81611ba2>] hub_port_connect+0x82/0x9c0
[ 3960.085256]  [<ffffffff81612bb1>] hub_event+0x6d1/0xb10
[ 3960.085258]  [<ffffffff810b9415>] ? put_prev_entity+0x35/0x7d0
[ 3960.085260]  [<ffffffff8109a2c5>] process_one_work+0x165/0x480
[ 3960.085262]  [<ffffffff8109a62b>] worker_thread+0x4b/0x4c0
[ 3960.085263]  [<ffffffff8109a5e0>] ? process_one_work+0x480/0x480
[ 3960.085265]  [<ffffffff810a0808>] kthread+0xd8/0xf0
[ 3960.085266]  [<ffffffff810a0730>] ? kthread_create_on_node+0x1e0/0x1e0
[ 3960.085268]  [<ffffffff8182decf>] ret_from_fork+0x3f/0x70
[ 3960.085269]  [<ffffffff810a0730>] ? kthread_create_on_node+0x1e0/0x1e0