[linux-dvb] Re: Problems with Kworld ATSC-110
CityK at rogers.com
Thu Feb 1 07:38:03 CET 2007
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
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
> What kind of inconsistency of information is there with regards to the TUV1236d? Are you referring to
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:
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
- 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).
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
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"
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
.... 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
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
- 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
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
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
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! :)
More information about the linux-dvb