Andy Clark wrote: >Patrick Boettcher wrote: > > >>>>>I'm experiencing a problem with a newly-bought Nebula uDigiTV USB2 box. >>>>> >>>>> >>>>> >>>>>Oct 19 23:48:52 vim kernel: >>> 02 7f 01 00 00 00 00 >>>>>Oct 19 23:48:52 vim kernel: <<< 02 7f 01 8a 00 00 00 >>>>>Oct 19 23:48:52 vim kernel: >>> 02 73 01 00 00 00 00 >>>>>Oct 19 23:48:52 vim kernel: <<< 02 73 01 8a 00 00 00 >>>>> >>>>> >>> >>>Here we have it: When trying to identify the mt352 (0x7f) it gets 0x8a >>>(whereas 0x13 is expected). Same for nxt6000: 0x0b expected, 0x8a >>>delivered. >>> >>>So either you have a new very new device with an unkown demod inside, >>>or your box is broken :) . Does it work in windows? >>> >>> >>> >> >> >> >> > >I've not yet tested it in Windows, but I will do so this evening. The >box is actually a uDigiTV, rather than a master, and it occurs to me >that this might be the cause of the problem. However, from what I read >about the two types of decoder, it was my understanding that the main >difference was that the master device comes with an IR interface and >with Windows software for recording, whereas the slave doesn't. > > > I have now tested the box in Windows, and it works. It's a uDigiTV slave unit (<http://www.nebula-electronics.com/information/info.asp?Code=0007>) which means that it needs a uDigiTV master USB box or a PCI version for the Windows software to function correctly. I have a DigiTV PCI card, so I was able to get the USB slave device to work in Windows. In addition, I've also confirmed that the box will work in Linux, provided that I first boot to Windows. After doing so, I can switch back to Linux, and I receive the following messages :- Oct 22 19:50:18 vim kernel: check for cold 547 201 Oct 22 19:50:18 vim kernel: dvb-usb: found a 'Nebula Electronics uDigiTV DVB-T USB2.0)' in warm state. Oct 22 19:50:18 vim kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Oct 22 19:50:18 vim kernel: DVB: registering new adapter (Nebula Electronics uDigiTV DVB-T USB2.0)). Oct 22 19:50:19 vim kernel: >>> 02 7f 01 00 00 00 00 Oct 22 19:50:19 vim kernel: <<< 02 7f 01 13 00 00 00 Oct 22 19:50:19 vim kernel: DVB: registering frontend 0 (Zarlink MT352 DVB-T)... Oct 22 19:50:19 vim kernel: dvb-usb: Nebula Electronics uDigiTV DVB-T USB2.0) successfully initialized and connected. Oct 22 19:50:19 vim kernel: >>> 08 00 04 01 00 00 00 Oct 22 19:50:19 vim kernel: >>> 07 00 04 00 00 00 00 Oct 22 19:50:19 vim kernel: usbcore: registered new driver dvb_usb_digitv After doing so, I can obtain a lock with tzap, and MythTV is able to access and record correctly. If I then power-cycle the USB box, I'm back to the original behaviour. The firmware loads in Linux, and the box responds :- Oct 19 23:48:52 vim kernel: >>> 02 7f 01 00 00 00 00 Oct 19 23:48:52 vim kernel: <<< 02 7f 01 8a 00 00 00 Oct 19 23:48:52 vim kernel: >>> 02 73 01 00 00 00 00 Oct 19 23:48:52 vim kernel: <<< 02 73 01 8a 00 00 00 Considering the above, my first guess would be that the uDigiTV slave device uses firmware different to that provided by dvb-linux, and that Windows is providing the correct firmware. Can anyone advise how I can identify and extract the firmware supplied to the box when running Windows? As it stands, I'm using the box on my PVR. However, my dual-boot workstation is in a different room to the PVR, so getting the DVB decoder working involves a long power extention cable and a powered USB hub. :) I'm happy to perform further testing to improve native Linux support for the decoder. Let me know. Many thanks, Andy Clark.
