[linux-dvb] Re: DVB-S in the US.

[William E. Mrozinski <wem@dcshome.com>]

Chris,

   Some lock is closer than no lock at all!(g)  I monitor the /messages log
when I start the driver and vdr but 'channel not syncd' is all I have ever
received ( the rest of the startup is error msg free ) however I am 'new'
to linux too and that adds to the fun.  I've come a long way though, and
I'm pretty confident that my builds & setup are not the issue so I'll keep
trying ( maybe today even ).

    I've even hardcoded NTSC in the driver code with the same results.  No
video ( no lock, duh ) but I can tell its pal from the 50hz scan lines on
my monitor.  I have a pip a/v mux and when I flip the video out from the
card to the small picture it confuses the analog pip and throws the big
picture into 50hz mode too.  You'll know it when you see it...  I think
you would see a ( corrupted ) picture if there is actual video signal; when
I throw my stb dvb into pal mode I see an extremely poor, short scanned,
but clearly there, video image on the NTSC monitor.  Looks just like the
current video out from the 2.1 version Haup card ( the new card ) sans
video image, of course(g).

    I think that the card does not really make it to NTSC mode right now unless
the TS data can command it through its stream descriptions.  Forcing the settings
seems to have no effect to override the actual output mode prior to this
( my big guess! )

    This is a bit consistent with the spectral inversion issue I'm having too. Early
on
when I started troubleshooting the TT software under win I worked with some
one who has a spectrum analyzer ( thanks Steve! ) and he caught the fact that all
the signals that would lock 'out of the box' were spectral inversion off and all the
others that I could find on my stb and not on the haup 2.1 card were spectral
inversion on.  None of the win or linux software I tried carried through a way to
force this setting via the channel listing or other way which is why I needed the win

API before I could confirm this.  Like the viterbi setting, the frontend/firmware
does
have a spectral inversion auto detect setting and I'm assuming that this is normally
so reliable on other units that it just works and has never been something you
needed to 'force'.  Also, like the lack of NTSC feeds in Europe, I'm guessing
that the broadcaster default over there is mostly SI off and so even if there is a
problem, very few users, including the TT developers, have yet to catch this
( another big guess ).

    Every TS is broadcast ( at the RF level, I think ) as either normal ( off? ) or
inverted.  I'm guessing this is the RF level version of whether a high signal is
meant
to mean 1 or 0 ( or low ).  Inversion 'on' flips the meaning in the data stream at
the
radio frequency level of the receive ( very big guess, but I'll bet I'm close(g) )

    It took me a long time to find anything initially with any of the Win software
solutions as they are shipping now.  Unfortunately, 99% of whats available to us
( US ) that is fta is also coded spectral inversion on and so nothing would lock.
I finally found two tp's on T5 ku amongst the mass of foreign channel feeds that
were using spectral inversion off and I got my first lock.  Until I got the new API
and could code a way to force the spectral inversion setting things were very
bleak... Now I can go to any stream that does not auto lock but clearly shows
a good signal and flip the spectral inversion on and all is well(G).  All of the
current
versions of win software ( TT's, Haup's, Siemens ) all default to spectral inversion
auto and don't provide a way to override so without the TT api you'll be searching
a long time for signals under windows.  Send an e-mail to support at TT and they
will ( with signing an EULA ) send you a copy of the API code now; I don't think
it will be freely available anymore. ( prior versions were freely available for
download ).

    My goal is to build my own pvr app under win ( since thats where I'm forced to
live
by the reality of my client base and where I have many years of experience ) but
dvb/vdr has been the catalyst for me to finally get off my butt and setup a linux box

for the first time and that has been fun.  I've got a pvr development box loaded up
with win98 and linux and dual boot between them during all this testing.  Linux
reminds me of the 'good ole days' of PDP11's, Alpha Micro, CP/M, and my old
mainframe systems programmer days(G).  ( lets see, gen VM, gen a few VSE
partitions for the rest of the company, and then gen another ( virtual machine ) just

for me!... )

    I'll keep the list informed if I learn anything new.

    Good luck on your dev project,
            Bill

Chris Worley wrote:

> "William E. Mrozinski" wrote:
> > 1) I've never got a lock or video yet with dvb/vdr, using mainly T5 since there
> > is plenty of fta there for us (USA).
>
> I am getting a lock on the audio and teletext PIDS.  The video is all ;)
> that's screwed up.
>
> > 2) The video out pre-lock has always been PAL for me too even after changing
> > both code references and the driver startup option.
>
> The two references I've tried are saa7146_core.c:
>
> /* insmod parameter: some programs (e.g. īvicī) do not allow to
>    specify the used video-mode, so you have to tell this to the
>    modules by hand, 0 = PAL, 1 = NTSC  */
> static int mode = 1;
>
> (which is probably what you're changing from insmod) and dvb.c (line
> 5767):
>
>         dvb->vidmode=VIDEO_MODE_NTSC;
>
> Yet, the output is still PAL.
>
> I'm beginning to think that the problem is an NTSC/PAL issue.  I was
> expecting to see a screwed-up NTSC stream, not black... but maybe the
> hardware refuses to decode streams in the wrong mode.
>
> > 3) I haven't even gotten past the 2.1 'channel not sync'd' issue which many are
> > having now with the current driver on both sides of the pond.
>
> By 2.1, I'm guessing you mean a rev of the Hauppauge or Siemans board?
> Sorry to not have done my homework on this issue.  I haven't seen a
> "channel not sync'd" problem.
>
> > 4) Under the TT/Win software there is definitely an issue with the current
> > drivers/firmware and spectral_inversion settings.  The auto setting which
> > all the software ( TT & Haup's ) default to only currently finds SI_OFF
> > bouquets.  This may be isolated to the Win firmware; I think dvb loads
> > its own version of firmware, not sure on this.
>
> Dvb definitely loads its own firmware.
>
> I'm not familiar with "SI_OFF bouquets".  Is this BAT table entries?
>
> >
> > It looks like you are after dish programming;
>
> That's just what we're currently aimed at... we're just looking for test
> streams for software developers to work with... we really don't care
> what we're aimed at.
>
> > see if the transponders you
> > can at least partially decode are all SI_ON per lyngsat and if those that
> > won't lock are SI_OFF... ( I'll try this too on E6 in the next day or so
> > and report back... )
>
> Thanks for making me look again.  I had the polarity wrong on all the
> transponders I wasn't picking up.  Again, what's "SI_OFF"?  I know what
> SI tables are, but I'm not sure what "OFF" is.
>
> >
> > Do you know if a CA board will work with dish and their access card???
>
> My guess is, no.  We have a Siemans card too, with the access card
> adapter.  It takes a PCMCIA card, not a Smart Card.  I think this is
> from some Open?? standard.  I don't know if there's a smart card adapter
> or if there's a PCMCIA version of the smart card or if there's a PCMCIA
> sub-adapter for a smart card.
>
> >   VR_2_3  =  2,    // DVB-S: viterbi rate: 2/3
> >   VR_3_4  =  3,    // DVB-S: viterbi rate: 3/4
>
> Both these values worked for me; I had no clue as to the values for this
> table (I'm guessing this correlates to the FEC value in the .dvbrc
> file), so I just did it by trial and error.  My guess was, "2" was
> correct since I more often got good channel data using a "2".  Now that
> you've clarified this for me, "3" is the correct value.  Go figure.
>
> > Have you compared your results under Linux with the Win software?
> > ( Just curious... )
>
> <RANT>
> My company buys us DELL computers, which we immediately overwrite
> Windows with Linux (there no way to find a VAR that will supply us Linux
> machines; we have to pay the Microsoft tax).  I was told to put Windows
> back on one of these machines to try this out.  It seems these DELL
> machines have special Windows drivers for nearly every device embedded
> on the motherboard (even though they look like standard peripherals).
> Plus, the NT CD's sent with these machines (never opened) wouldn't
> install.  It took me four days to get Windows back on the machine (The 7
> disk SuSE set takes about 4 hours).  My first attempts with the
> Hauppauge software didn't produce any results.  Needing to make
> progress, I put the card in a Linux machine and haven't tried the
> Windows machine since.
> </RANT>
>
> If we choose to use this sort of product (for software developers to
> use), I'll have to evaluate the Windows drivers eventually, but I'm not
> looking forward to that.
>
> Chris




-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.