Note - I cc'ed the dvb list in on this, as this is where this element of the discussion really belongs, and also would like to open it up to that wider audience. Michael Krufky wrote: > TUV1236D is a NIM with a NXT2004 inside. > Precisely. And the key letter in that last sentence is 'M' -- Module. These are drop in boards. The whole point of being a module is that their placement in either a set top box or on the pcb of a computer card or embedded inside a TV is irrelevant. They are designed to provide a given operational functionality, regardsless on the target product application. > What kind of inconsistency of information is there with regards to the TUV1236d? Are you referring to > input-switching? > I refer to the inconsistency of info about cards based around this module. Lets take the HDTV Wonder, which can be used to perfectly illustrate this fact: - http://www.linuxtv.org/pipermail/linux-dvb/2006-February/008455.html in this thread (and I note others) Michael mentions that he has heard that QAM works with the board. (and, indeed, I seem to recall reading an account too ... alas nowhere to be found now -- neither in google or my memory) - But in this very thread Michael states: from what I hear, QAM256 does not work on the ATi HDTV Wonder (cx88-based, using TUV1236D as well). - http://www.gossamer-threads.com/lists/mythtv/users/200130?search_string=HDTV%20wonder;#200130 in this Apr 24 '06 mythtv thread, the last two users discuss that they can't get QAM to work. The last poster mentions needing to update the (linuxtv) wiki. - http://www.linuxtv.org/wiki/index.php/ATSC_cards The linuxtv wiki table had originally listed the card as QAM capable. But on Apr 25 '06 the wiki is indeed 'updated' by the last poster from the above mythtv thread. The QAM status entry has remained the same ever since that modification. The card now reads "No" to QAM support with a footnote that reads: "Some may have had success. Recent attempts using currently shipping boards have failed" - http://www.mythtv.org/wiki/index.php/ATI_HDTV_Wonder Interestingly, the mythtv wiki doesn't mention QAM until Oct 8th 2006 when someone 'updates' the entry and stresses that the "This tuner IS capable of tuning clear (unencrypted) QAM 256 channels. Most cable providers have the local channels in HD in this QAM 256 format" - Then in Dec '06 we have a user on AVS trying to get it working but is unsuccessful. Further, they are at first given a inaccurate reply (one that I have seen on several occasions) that the hardware has changed. I replied here: http://www.avsforum.com/avs-vb/showthread.php?p=9139129&&#post9139129 .... the point here is that people are extrapolating from the note from the current linuxtv entry that there was a hardware change and repeating that as gospel...Bullocks I say. If you continue to read my AVS response -- I offered up a half baked theory of what may account for the discrepancies that are being observed. Also, if you return to that earlier linuxtv discussion thread, (http://www.linuxtv.org/pipermail/linux-dvb/2006-February/008455.html) you'll see that Curt and I were kicking around the idea of a specific firmware being needed, although Michael disagreed. Michael Krufky wrote: > CityK wrote: >> -- the pressing issue of why some can get it (256-QAM) working with >> their cable provider and others can't >> > > Is it really the cable provider? ...or is it something to do with the other > hardware on the board? As I outlined in my AVS post, I believe its a little bit of both. Here are some quick facts. - there are a number of boards using this frontend. - in Windows, the only one which has driver side support for QAM is the MDP-130 - in Linux, only the Kworld 110 has proof beyond doubt of QAM functionality - in Linux, the Nxt2004 firmware is supplied curtosey of the Aver180, which also supports QAM - the Aver180 has a Alps frontend (TDHU2), whose tuner IC I am ignorant of (does anyone know for sure?). The Aver180 also is based around the saa713x A/V decoder and bridge...something that is in common with the Kworld 110 card .... coincidence that these two somewhat similar cards work with QAM but others don't (I think not). - In the US, there is no unified system in place or being used by the cable networks. Rather you have a bunch of providers using systems that will conform to the SCTE 07 standard. So how do we tie all of this together? I say firmware, cable network and possibly a difference is tuner ICs (between the Alps and the Philips NIM) I don't have any further time to fully spell out my thoughts -- and again, I'm just theorizing at a conceptual level, so nothing concrete -- so I hope people can follow my train of thought and ideas. But briefly: - why couldn't Curt get QAM to work with his Kworld but others can ? Perhaps different type of cable network then what succesful users are on and difference in the tuner IC in the Philips NIM as opposed to the Alps NIM ...i.e. its not switching over correctly or something. - why do saa713x based cards see the Nxt2004 work work with QAM but others don't (ATI conexant, Twinhan and friends DST & BT878 based) Perhaps the firmware is specific to the bridge? Lets look at this from another perspective -- DVD burners -- do those sharing the same chipset work identically without modification of the firmware? I don't think this is the general case. So despite these (TUV1236D) being drop in modules, it may very well be that the firmware still has to be coded correctly to its environment in order to offer up what the module hardware can provide (QAM). Secondly, I get back to the point about the tuner IC in the ALPS NIM ... knowing what this is would certainly help to figure out where the bottleneck really lies. I know I'm not explaining myself well with this point -- but it should be obvious that there is an interaction between the tuner and the Nxt2004. In the base case, the A180, we would expect the firmware to be coded to reflect this environment. We might also expect that the card would work regardless of which cable network it was employed upon. But switch things up -- use a Kworld card. Perhaps in some cable networks, the existing code in the A180 firmware will work reliably with the Philip NIM's TUA6034 tuner IC (say, a "good enough" condition is meet). Perhaps in other cable network envirnoments this "good enough" substitution just doesn't cut it and the card just isn't able to lock on or switch to that network's QAM signals. Make sense? We've taken a firmware coded for a specific hardware environment and expected it to work similarly when supplanted in a different environment. And I think that's where the problem lies. > I know for sure that QAM256 does not work in the Twinhan VP-3250 (and clones) > ... These also have TUV1236D, using the DST ASIC and BT878 bridge. > - have a look at the Twinhan specs page -- http://www.twinhan.com/product_D%2BA_2.asp QAM support listed in the flesh. My point from the above rambling, if it wasn't clear is that I fully believe that all these cards based on the TUV1236D are capable of providing 256QAM support. The problem, it appears to me, is that an appropriate firmware is required to correctly match the hardware environment. What really is needed is an analysis of the various relevant firmwares: - the Micronas based (MDP-130) - the Conexant cx88 based (ATI HDTV Wonder) - the DST/BT878 based (Twinhan & clones) - the Philips saa713x based (Kworld, ADS) All in relation to the current Linux support base method (i.e. using the Alps & saa713x based Aver A180's firmware) > Had I known that the ATSC110 worked with QAM256, I might have tried > to pick one of those up... In fact, I probably would have recommended it to more > users. > Dwaine has definitely been giving it his endorsement for a while :P > I find this confusing. Oh well. > If YOU (the defacto ATSC maintainer) find this confusing -- just think how the causal user finds it! :) _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
