The PCTV nanoStick T2 is the first DVB-T2 (Freeview HD) compatible USB tuner to ship.
I've taken mine apart to aid Linux driver development.
Please visit LinuxTV for information on Linux DVB receiver drivers.
It's simple really. You have three choices:
>= 3.0, orIf you can't do option 1, option 3 is the way to go - all you need is is the relevant kernel headers and some prerequisite libraries in order for the build script to work (it'll tell you if they're not installed). This avoids the full kernel compilation required by option 2. You'll have to re-run the build script every time your OS updates the kernel.
Bugs with using the 290e are, from my experience, down to issues in the driver for the controller chip (and thus the bugs apply to more devices than just the 290e) or video/audio stream decoding issues (which are userland issues and nothing to do with the driver). Then of course there's the question of whether your machine is fast enough to decode HD streams. A decent dual-core CPU will do it, as will anything above a GeForce GT 220 with VDPAU support.
Finally, be sure to thank Antti Palosaari for his work; he's the real driving force behind the linux driver - I'm just the guy that makes occasional small patches and writes about the progress of the driver.
PCTV has announced the 292e, a tri-mode tuner with DVB-T2. Of course, Antti made the 290e work in tri-mode as well, but I don't have DVB-C to test it anyway.
Will the 292e be supported in Linux? It's a bit early to tell. I don't have one, so I can't tell what's in it. As this comment on Antti's blog suggests, the internals of the 292e are likely to be different, if some of the other new PCTV products are anything to go by, with at least a new tuner and more than likely a new demodulator, which is potentially bad news, as the Sony CXD2820 is the only T2 demod with an open driver.
So don't rush out to get a 292e just yet. I'll keep my eye out for news and post anything I see, but at the moment I have neither the resources in time nor hardware to do much else about this.
Kernel 3.2 is in rc2 right now. In it are fixes to em28xx from Chris Rankin that should solve the re-plug & multiple em28xx based device deadlocks. I haven't had a chance to test it, but if you will benefit from it, give it a go!
It was brought to my attention in the last couple of weeks that the FFMPEG issue with mid-stream channel config changes has been fixed. This is good news for viewers of HDTV broadcasts that adopt these techniques, particularly channels that use commercials in a different audio format to the programme.
I haven't had an opportunity to test this yet (nor, funnily enough, have I actually run into this problem much recently, seeing as most of my intake is on commercial-free BBC stations), so if anybody is having success do let me know. If I'm up to speed on the MythTV mailing list, they're aware that a fix exists and it's a case of either patching the existing mythtv copies of the libraries, or waiting for the next big merge from ffmpeg/libav (I wonder which one it'll be!), which will happen before 0.25 is released, apparently.
A couple of weeks ago Robert Schlabbach identified how to do proper i2c gate control with the CXD2820R so I put together a patch for that. It doesn't change anything other than making the driver simpler, which is nice, but not very exciting.
In other news, there's some momentum towards fixing the mutex issues in the em28xx driver collection which should make re-plugging and dual-tuner operation hassle-free. I'm not sure what the status is right now as I'm not involved, but I believe the current focus is on making sure any fixes don't create regressions in em28xx devices that are combo analog/digital devices. Hopefully something will be finalised soon so that I can use my second, home-baked (and still a bit unreliable, unfortunately) 290e.
And finally, I've almost finished replacing my aged Shuttle SN21G5 with a Zotac ZBox ID41; a machine almost a fifth the size, using a fifth the energy, and probably two or three times more powerful with its dual-core Atom. The best bit is the 2nd gen Ion GPU, which does a sterling job of decoding and deinterlacing HD video. The box is also acting as a router, with the 802.11n chipset in master mode. It's got a USB ethernet adapter attached to give me enough ethernet ports. If it turns out there's contention for USB bandwidth I'll do away with it as I have no desperate need for a wired LAN.
I think it's time to share a story. Back in January I killed my 290e. I did so by sending I2C commands intended for the tuner out to the EEPROM instead. This was back when I was trying to get an understanding of what was connected where - I got it wrong!
The result of this was a corrupt firmware for the Empia controller. Not so corrupt that it wouldn't enumerate, but corrupt enough that, funnily enough, the i2c implementation was broken, so I couldn't talk to any chips any more.
Fortunately, following a cry for help, PCTV Systems were kind enough to recognise my efforts and supply me with a production sample to replace the stricken 290e. This got me back on track, and as a result I had a 290e with a good ROM, plus a 290e with a bad ROM. You can probably see where this is going - I investigated reprogramming the ROM in the broken device.
The problem with this, of course, was that I couldn't write to the EEPROM on the broken device, because the i2c commands were erroring. So, although I'd managed to get a dump of the good ROM with relative ease, reprogramming the bad one was more of a problem. So I gave up.
The story doesn't end there, however, because some time later, once Antti had worked his magic on the cxd2820r driver and I'd cut my teeth on submitting patches to the linux-media team, I turned my attention back to the dead tuner.
I am a PhD student at the University of Bristol, currently researching at XMOS, a company that makes chips on which you can implement in software more or less any hardware interface you want without all the hassle that comes with FPGA development. I grabbed an existing I2C library for the XCore and wrote a little program to flash the EEPROM with the good data. I then wired up a lead to carry the i2c signals between my XK-1 board and the 290e. I soldered the leads directly to the 290e board and plugged the other end into some headers on the XK-1.
The program ran, and the ROM was good again. But of course, my soldering skills are weak, and the broken 290e had been quite abused by now, so by the time I de-soldered the leads, the tuner chip was occasionally failing to respond. After examination and re-touching yielded no success, I became impatient. I pre-heated my oven to ~200C, placed the 290e on some grease-proof paper then put it on a tray in the oven for ~2 minutes.
Once the 290e had risen and was springy to the touch, I allowed it to cool, after which... it worked. The moral of the story here is, don't write to i2c devices when you don't know for sure which device they are, and never use your oven to bake PCBs - it's not a healthy thing to do - you have been warned!
Hello The Register readers! See the section above on how to build the drivers if you want the quickest way(s) of getting the 290e working under Linux.
Oh, and the Linux driver has DVB-C support, which the Windows driver doesn't ;)
Thanks to everyone who has reported back with details of their successes and issues with the tuner and Freeview HD issues. If I haven't replied to somebody's question I apologise - feel free to prod me again.
A couple of things worth mentioning. One of the first people to express an interest in the work done on this project was Torbjörn Svangård, who is undertaking a project to evaluate the Pandaboard's media performance when running Android. He is now successfully running a nanoStick T2 290e on the device, but without HW H.264 support in Pandroid yet it's a bit difficult to test T2 transmissions with it. Hopefully that situation will soon be remedied.
Finally, I've been experiencing audio issues in MythTV and VLC. With VLC sometimes the audio on my 2.0 system varies in volume (possibly trouble downmixing 5.1 into stereo, but I'm not sure). However, a problem affecting both VLC and MythTV is when an HD broadcast switches audio formats mid-stream. It looks like libavcodec is unable to cope with the change and ceases to decode audio. This isn't too bad for BBC channels, but on the commercial stations the audio format often changes between the feature and its commercial breaks. Glenn McAllow has filed a bug report against avcodec.
I've been watching BBC HD on my underpowered Mythbuntu 11.04 system - it can become stuttery but I think that's a sync issue in mythtv or the fact that I have about zero headroom when decoding HD. There are various patches being submitted to the linux-media list that are related to DVB-T2 so there's some good momentum around it at the moment.
Although I've been building new kernels from source, the cxd2820r driver and PCTV nanoStick T2 290e support are present via the media build script, so if anyone wants to give it a shot against their existing kernel, give it a go and let me know if it works! There's a few things that might be in flux until some patches of mine and a couple of other people are reviewed, adjusted and applied.
Edit: I've just had somebody ask me what system I run MythTV on. While I haven't finished a complete assessment of whether it is capabable of reliable record/playback of broadcast DVB-T2 1080i50, if you have a better-specced system then it's certainly worth giving it a try. My combined backend/frontend is:
Edit 2: When setting up playback rules, it's useful to remember that Freeview HD is 1440*1080 and not 1920*1080. I was trying to do Yadif deinterlace on the HD feed as a result. All seems well with one-field or linear blend deinterlace. The audio is sometimes strange in VLC, but MythTV seems to output in stereo OK for me (I have a 2.0 analogue setup). CPU usage is around 90% on my system.
Antti has made a pull request to the linux-media guys so hopefully some code will be entering the mainline before too long - it depends on whether it's accepted in its present form. In the meantime, you can grab the latest version of cxd2820r driver from Antti's repository. It now includes automatic DVB-T/T2 detection thanks to a new tuning alogithm implementation from Antti. I also made some minor housekeeping contributions.
If the driver is accepted then we can begin to focus on a proper DVB-T2 implementation for the Linux DVB API, which would be nice :).
Well, I've watched some channels from a T2 mux in VLC on Linux. Fantastic! A big thanks to Antti for his efforts. Now begins the process of figuring out how to integrate DVB-T2 support into the linux-media framework. I'm formulating some ideas and will post them to the mailing list to seek counsel before trying them out.
Another LinuxTV developer enters the fray - Antti Palosaari - bringing with him a CXD2820R module! There are still a lot of details to work out when it comes to T2 support, but this should give us a working device. I cannot test until some time next week, but the keen hackers amongst you might want to head over to Antti's git repository to check it out.
Of course, those of you already on the linux-media mailing list will already know this. For those who don't, here's the message.
In theory the majority of the implementation is complete. I'm now trying to get tzap to lock onto a mux. No joy as of yet but I've not got enough debug statements to know what's going on yet, so that's the next step. Once I actually get the thing working I will publish a patch set and then seek help in refactoring/bugfixing to ensure we have something that has a good chance of being accepted into mainstream kernel.
Still, one thing at a time... :)
Following a conference and a holiday, I'm now back in the country and am hoping to continue work this weekend. I'd love to get a transport stream out of the device this weekend - fingers crossed!
I am working with Robert Schlabbach and Andrew De Quincey on the implementation of the the cxd2820r module for Linux. This has sped up development by at least an order of magnitude, so I am extremely grateful for their input. Progress is going well, we have a growing understanding of how to operate the demod. My work on the driver is governed by how much spare time I have, however, so I wouldn't like to say when a testable version will be available.
On the plus side, however, it turns out the re-plug issue I mentioned previously is not related to the 290e or my driver implementation thus far, but rather an apparent mutex bug between em28xx and em28xx-dvb. Thanks to Devin Heitmuller for confirming the issue, and a few other tips for working my way around the em28xx Linux module.
It looks like I have achieved my goal for this weekend, which was getting the 290e brought online as much as is possible with the CXD2820 unimplemented. I have a stub CXD2820 frontend that doesn't do very much, and what it does do (attach) it does rather badly.
However, there is one thing it does do successfully, and that's pass I2C commands through to the TDA18271 tuner that sits behind it. I've made a patch against media_tree that should allow others to test it. I must make clear however that during development I accidentally overwrote the EEPROM on one of my 290e devices. The code that did this is long since gone from my source or patch, but it must still be said that my code comes with absolutely no warranty whatsoever, especially if it breaks your 290e or some other part of your machine.
If some brave soul could try out my cxd2820-bringup.patch file to see if it applies, and (if you have a nanoStick) if it attaches the demod stub and tuner, it would be appreciated. Some notes follow that may be useful:
drivers/staging/. I have made some updates to em28xx and dvb-usb too (see the patch), and updated KConfigs and Makefiles where necessary to build the new module and allow em28xx to link to it.drivers/staging/{Kconfig,Makefile}. Fixed, rebased and reuploaded the patch. If you grabbed it before I fixed it, it's easy enough to fix by hand.Thank you to those who've given their support so far, and a special thanks to those who have pointed me in the right direction from time to time.
Hopefully the project will build a bit of momentum now...
It looks like another T2 capable USB receiver will be hitting the market soon (if it hasn't already in some countries). Geniatech's T200 is a USB box with antenna passthrough (considerate of them), external power supply and a mini-USB connector. It's guaranteed to have a CXD2820 in it. Question is what tuner and controller will be in there? If anyone gets hold of one and is willing to do a teardown, let me know.
I have put up some of my USB logs and one kindly provided to me by Marcus Andersson. The file, usblogs.tar.gz is about 350MiB, but it unpacks to about 2.5GiB, so beware. I've bundled in a couple of parsers that may be useful, but anyone else looking at the may have better tools at their disposal.
I receive my DVB-T{1,2} muxes from the Mendip transmitter in the England's West Country. Marcus got his from the Karlstad Sörmon transmitter in Sweeden.
I may have a further update for you this weekend. Not likely to be mind blowingly exciting, but you never know.
Oh, and one last thing. Taking a multimeter to the PCB sandwich I can determine that the tuner uses the I2C passthrough of the CXD2820R. This should be apparent from the USB logs. Its address is (c0 >> 1) and a write to the 2820 of i2c_master_send(0xd8>>1, { 09 c1 }, 0x02); will, for example, request a register dump from the NXP tuner, it seems.
I have a free weekend coming up which bodes well for the project. I have create a GitHub project and will be publishing stuff to there once there's something people can add to (as previously stated).
More messages of support/help have come in and are appreciated. As I've said to those who've mailed me, if anyone else is working away on this and find themselves further ahead than me, do let me know and I'll throw my efforts into supporting you wherever possible.
I'm back in business. Thanks to some assistance from PCTV Systems I once again have a working piece of hardware, and for that I am grateful.
Work on this will resume in earnest next week, once I have completed some other paid-for work.
It has struck me that there may be an opportunity for collaboration on development beyond the nanoStick T2, given that there are other DVB-T2 enabled PC devices surfacing. The PCI-Express Blackgold BGT3620 also uses Sony demods and there may be other T2 compatible tuners coming soon.
There's no definitive info on Linux support for any of these additional devices, but sufficient to say once one is supported, the others will follow fairly quickly thereafter, I would hope. Support for PCI-Express receivers on Linux is quite scarce, however.
Nevertheless, if any individuals or companies are working towards support for other T2 devices and can be open about it, please get in touch with me, even if it's just so that I know you're out there.
A little progress was made this weekend, followed by a something of a setback. The situation will be remedied, but how long it will take remains to be seen. In the meantime, SniffUSB snoops of the device during plug and tuning to corroborate the data I have collected would be useful.
Happy New Year everyone. I've had more messages of support and offers of help from various individuals, all of which are appreciated. Progress over the Christmas break was slower than hoped due to another more pressing project that I had to see through to completion.
However, since my last update I've collected plenty of usb data whilst tuning to the Mendip transmitter here in the UK's West Country. I've identified how everything appears to be connected up on the device and thus how the Empia chip is directing the various commands sent to it.
In the next week or so I am hoping to have a skeleton driver for the Sony demod that should provide a transport stream, after which I will make everything I've got available for testing and contributions. I'm not sure what the best approach for introducing a whole new driver into V4L is, given I'm new to kernel & V4L development. Advice is welcomed, otherwise I'll make it available somewhere like github whilst simultaneously working to get it into one of the staging areas of V4L proper.
It's extremely cold here in the UK and there's little point in going outside, but this isn't a blog so let's leave it at that.
I've taken logs of various activities with the receiver in Windows. Unfortunately the virtualised USB on my notebook is really slow and the only bare-metal Windows install I have is my netbook, and that cannot do HD TV, let alone HD TV and USB logging... but still I tried, and it seems to do a good enough job for long enough before it ties itself up in a knot.
I've done some parsing of the logs (for which I needed to tweak the parser script for my log format to deal with isochronous transfers popping up in the middle of other URB exchanges) and run them through the helpful parse_em28xx.pl script. Assuming the register mappings are correct for this chip, then the Empia chip's ID is 0x71 (113), which the driver doesn't have in its supported list.
I've added the device IDs in the appropriate places and begun registering the components in the appopriate modules, but until I do some more reveng on the USB data I can't really get much further than that.
A few people have offered up their assistance, so thank you to them. They will be called upon if I find myself in a position where I can ask for help. In the meantime if anyone more experienced takes a sudden interest in getting this tuner working, please get in touch so that I can impart unto you what I have learned.
Anyone wishing to contact me about this project, feel free to do so. If you can't guess my e-mail address you probably don't deserve to e-mail me ;).