Johannes Stezenbach wrote:
Andrew de Quincey wrote:
Well, the DVB API as specified by Nokia says that FE_SET_FRONTEND
should start tuning, and the result (failure or success) is relayed
to the application by means of an event with FE_GET_EVENT.
I.e. one FE_SET_FRONTEND -> one FE_GET_EVENT. But it'
Johannes Stezenbach wrote:
Holger Waechtler wrote:
Andrew de Quincey wrote:
If there _isn't_ a problem with breaking the Nokia API, I would be glad to
have a look.
If there is, all I have to do to fix my stuff is ignore the FE_TIMEDOUT
bit.
;) just remove it, it's bogus anyway.
(ough! I already
Holger Waechtler wrote:
> Andrew de Quincey wrote:
> >If there _isn't_ a problem with breaking the Nokia API, I would be glad to
> >have a look.
> >If there is, all I have to do to fix my stuff is ignore the FE_TIMEDOUT
> >bit.
>
> ;) just remove it, it's bogus anyway.
> (ough! I already feel th
Andrew de Quincey wrote:
>
> > Well, the DVB API as specified by Nokia says that FE_SET_FRONTEND
> > should start tuning, and the result (failure or success) is relayed
> > to the application by means of an event with FE_GET_EVENT.
> > I.e. one FE_SET_FRONTEND -> one FE_GET_EVENT. But it's also
>
OK, so to summarise, how does this sound:
* Remove the cruft with TIMEOUT etc
* Have the following states internal to the frontend kthread... keep the
external API the same (except for FE_TIMEDOUT).
UNTUNED. Nothing happening; no parameters have been supplied.
TUNING. This is a fast zigzag sca
> Andrew de Quincey wrote:
> >
> > Actually, the update_delay() is fine; its just that the TIMEOUT doesn't
take
> > into account how long it takes to write to the frontend itself... I put
in
> > some instrumentation, and its taking 25 jiffies to call
FE_SET_FRONTEND...
> > I've checked the fronten
BTW: just checked in my new stv0299 low symbol rate changes.
Theres still a problem tuning sometimes. I think it is caused by putting the
STV0299B to sleep... it mustn't be waking up correctly. If I let the kthread
timeout, it frequently takes two attempts to tune it. If I tune multiple
times i
> Well, the DVB API as specified by Nokia says that FE_SET_FRONTEND
> should start tuning, and the result (failure or success) is relayed
> to the application by means of an event with FE_GET_EVENT.
> I.e. one FE_SET_FRONTEND -> one FE_GET_EVENT. But it's also
> possible for the frontend to genera
Andrew de Quincey wrote:
>
> Actually, the update_delay() is fine; its just that the TIMEOUT doesn't take
> into account how long it takes to write to the frontend itself... I put in
> some instrumentation, and its taking 25 jiffies to call FE_SET_FRONTEND...
> I've checked the frontend code: n
On Monday 23 February 2004 20:29, Johannes Stezenbach wrote:
> Andrew de Quincey wrote:
> > > In the meantime, I've found another problem in dvb_frontend.c:
> > >
> > > Although the code has the ability to scan about on frequencies
> > > surrounding the requested frequency, it isn't actually being
Andrew de Quincey wrote:
>
> > In the meantime, I've found another problem in dvb_frontend.c:
> >
> > Although the code has the ability to scan about on frequencies surrounding
> > the requested frequency, it isn't actually being given the time to do so.
> > The following patch fixes this, and ens
> In the meantime, I've found another problem in dvb_frontend.c:
>
> Although the code has the ability to scan about on frequencies surrounding
> the requested frequency, it isn't actually being given the time to do so.
> The following patch fixes this, and ensures at least one cycle of scanning
>
On Monday 23 February 2004 18:02, Andrew de Quincey wrote:
> On Monday 23 February 2004 17:46, Johannes Stezenbach wrote:
> > Andrew de Quincey wrote:
> > > Hi, I've finally found the problem (after much fiddling)
> > >
> > > The linux core drivers already do the seeking-about mechanism you
> > > s
On Monday 23 February 2004 17:46, Johannes Stezenbach wrote:
> Andrew de Quincey wrote:
> > Hi, I've finally found the problem (after much fiddling)
> >
> > The linux core drivers already do the seeking-about mechanism you suggest
> > if it can't lock on to the supplied base frequency. And that wor
Andrew de Quincey wrote:
>
> Hi, I've finally found the problem (after much fiddling)
>
> The linux core drivers already do the seeking-about mechanism you suggest if
> it can't lock on to the supplied base frequency. And that works fine (seeks
> about in steps of symbolrate/16000).
>
> The pr
On Saturday 21 February 2004 02:44, Robert Schlabbach wrote:
> From: "Andrew de Quincey" <[EMAIL PROTECTED]>
>
> > Now, I'm able to lock on to low symbol rate signals...
> > I've just managed it with a 434 symbol rate...
> > getting a REALLY good signal from it, but it took about 10 seconds
> >
On Saturday 21 February 2004 17:16, Johannes Stezenbach wrote:
> Andrew de Quincey wrote:
> > Just noticed another problem.. I've never been able to lock on to low
> > symbol rate channels before... however, in diagnosing the other STV0299
> > problems, I disabled the FE_TIMEDOUT bit in dvb_fronten
Andrew de Quincey wrote:
> Just noticed another problem.. I've never been able to lock on to low symbol
> rate channels before... however, in diagnosing the other STV0299 problems, I
> disabled the FE_TIMEDOUT bit in dvb_frontend.c.
>
> Now, I'm able to lock on to low symbol rate signals... I've
On Saturday 21 February 2004 02:44, Robert Schlabbach wrote:
> From: "Andrew de Quincey" <[EMAIL PROTECTED]>
>
> > Now, I'm able to lock on to low symbol rate signals...
> > I've just managed it with a 434 symbol rate...
> > getting a REALLY good signal from it, but it took about 10 seconds
> >
On Saturday 21 February 2004 02:44, Robert Schlabbach wrote:
> From: "Andrew de Quincey" <[EMAIL PROTECTED]>
>
> > Now, I'm able to lock on to low symbol rate signals...
> > I've just managed it with a 434 symbol rate...
> > getting a REALLY good signal from it, but it took about 10 seconds
> >
From: "Andrew de Quincey" <[EMAIL PROTECTED]>
> Now, I'm able to lock on to low symbol rate signals...
> I've just managed it with a 434 symbol rate...
> getting a REALLY good signal from it, but it took about 10 seconds
> to tune (the current timeout is hardcoded to 2 seconds). The STV0299B
>
21 matches
Mail list logo
