[linux-dvb] Re: The correct way to tune a channel

[Johannes Stezenbach <js@convergence.de>]

Dave Chapman wrote:
> 
> Hello Driver Developers,

I'm a driver user, but maybe you still want to know how
how I handle tuning (which is essentially what Ralph told me to do).

> My tuning sequence is as follows:
> 
> 1) SEC_SEND_SEQUENCE:(set tone, voltage and Diseqc):
> 2) QPSK_TUNE (set frequency and Srate):
> 3) call QPSK_GET_EVENT and wait for event.
> 4) If event.type is QPSK_COMPLETION_EV, then call DMX_SET_PES_FILTER to set
> the Video, Audio and Teletext PIDs.

That's exactly what I do.

QPSK demodulator hardware does some more or less complicated
stuff to achieve carrier locking (including AFC) and sync recovery.
These algorithms are restarted explicitly by QPSK_TUNE. If you would
do the SEC_SEND_SEQUENCE as the second step, you'd change the signal
while the demodulator algorithms are running, which makes the
demodulator's job much harder, i.e. slower and more likely to fail.
Also, after a SEC_SEND_SEQUENCE it may be a good idea to wait for some
msecs for the signal to stabilize, before starting the QPSK_TUNE.
The necessary wait duration is probably very dependent of the type
and connection of diseqc switches used.

The QPSK_GET_EVENT stuff is meant to work asynchronously, i.e. the
driver should test the frontend sync byte repeatedly, and if necessary
perform a zig-zag scan or other stuff, and post the QPSK event when
it either has a lock or gives up.
The current implementation does not do this, but posts the QPSK event
immediately after setting the frontend paramteres. Quite often this
results in a failure event, because the demodulator is still busy
trying to achieve a lock at this time. To compensate for that, wait
some msecs and try FE_READ_STATUS. The driver's libdvb tries that
up to 10 times (search DVB.cc for QPSK_GET_EVENT).

Also, you don't have to block in the QPSK_GET_EVENT ioctl, but
can use select (use exceptfds) or poll (with flag POLLPRI) on
the frontend file descriptor. Thus users can zap to the next channel
w/o waiting for the driver to finish tuning to the current channel.

> What checks can I perform to check that the tuning process is working happily?

The FE_READ_STATUS ioctl gives you two flags:
- FE_HAS_SIGNAL (frontend is completly locked)
- FE_HAS_LOCK (frontend sees a carrier, but symbolrate/fec
  is wrong or SNR is to bad or whatever)

FE_HAS_LOCK is more experimental and meant for transponder
scanning.
The full sync byte as available in the old API is not in the
new API, because it is too dependent on the VES1893 chip. If you
know that you have a VES1893, you can use the following to read it:

/* NOT RECOMMENDED */
uint8_t
get_sync (int fefd)
{
  struct qpskRegister reg;

  reg.chipId = 0x20; /* decoder */
  reg.address = 0x0e; /* sync */
  if (ioctl (fefd, QPSK_READ_REGISTER, &reg) == -1)
    {
      perror ("QPSK_READ_REGISTER");
      return 0;
    }

  return reg.value;
}


Regarding PES filters:
During tuning, there is some possibility that the demodulator
outputs bogus data, which the demuxer and/or MPEG decoder takes
as an invitation to crash ("ARM RESET").

Ralph told me, that I must stop (DMX_STOP) all filters before
tuning to avoid that. OTOH, the signal could get weak at any
time, so ultimately the only way to avoid ARM RESETs is
that the demuxer/MPEG decoder firmware gains stability.


Regards,
Johannes


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