[linux-dvb] Re: Full featured card summary

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Johannes Stezenbach wrote:
> 
> Andrew de Quincey wrote:
> > its not the firmware.
> > its not the frontend driver (that was a different issue).
> >
> > well, pretty obvious where it has to be really; must be a card setup problem
> > in the OSS code. I'll have a closer check over the next few days.
> 
> Like I said before, DiSEqC was always unreliable with my ves1893 card,
> but I don't know if it is a general problem or if just my card is
> broken.
> 
> Anyway, today I got a DiSEqC test box from Eutelsat, and it does not
> even recognize a single valid bit of DiSEqC data. It recognizes
> 13(18 volt and tone on/off, so I guess the timings of our DiSEqC stuff
> must be totally off. I didn't have the time to connect an
> oscilloscope to investigate further. Maybe tomorrow.
> 
> The little Spaun DiSEqC test box I use normally recognizes
> the DiSEqC sequences most of the time, but it is probably
> much more tolerant that the Eutelsat test box.

Same with my DiSEqC tester. With the DVB driver it detects the
signals correctly every time, with dvb-kernel only sometimes.

> Does someone know for sure how the DiSEqC signals for a
> ttpci rev1.3 card with ves1893 are generated? Is this
> different from all other cards?

From what I can see in the driver source, on AV7110 based cards
the actual DiSEqC signal is generated fom inside the firmware.
But since the firmware hasn't changed between the latest DVB driver
and dvb-kernel (at least as far as i know) I would assume that
the actual signal the firmware generates should still be the same.
Unless, of course, some other setup stuff interferes with that...

Is there something about the COMTYPE_AUDIODAC stuff that's done
differently in dvb-kernel and could break the generation of the
DiSEqC signal?

Klaus


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