[vdr] Re: Some questions about plugin-features of vdr-developer...

[Christian Schuld <chris@sonnengesicht.de>]

Hi,

On Tuesday 03 September 2002 20:12, you wrote:
> Christian Schuld wrote:
> > Hi,
> >
> > On Tuesday 03 September 2002 14:04, you wrote:
> > [..]
> >
> > > > The EPG handling needs to be adjusted, too, when using multiple
> > > > satellites, because then you don't have unique ServiceId any more.
> > >
> > > Yes, I'm aware of that. This will be taken into account when the DiSEqC
> > > (or rather "source" handling) mechanisms will be rewritten.
> > >
> > > As for the rotor handling: I guess we could have some notation that
> > > let's you specify a string like the good old AT modem codes, where you
> > > can specify any sequence of voltage, tone, DiSEqC commands, timeouts
> > > etc. However, I'm not sure how the cDvbDevice could "know" when the
> > > rotor has reached its target position. Is there some feedback for this?
> >
> > Unfortunatly not, the DiSEqC 1.2 protocol is one-way only. The only way
> > to know whether the rotor reached the target position is to retune after
> > a delay and check the frontend status. Repeat this, until (fe_status &
> > FE_HAS_SYNC) is true.
>
> But that might hold the risk of inadvertently stopping at the wrong
> position, in case there's a suitable channel on some satellite on the way
> from the current to the target position. Chances for this to happen are
> small, but theoretically it might happen.

The rotor moves and stops at the right position by itself (when configured 
correctly). But the chances for locking on a channel on a wrong satellite is 
not so small. One way solve this, is to parse PAT/PMT tables so see if 
combination of ServiceID/V-Pid/A-Pid matches with the wanted channel. Should 
be possible with a few lines of code, cause is all in "libvdr" allready :-)

> > Btw, want do you think, is a DiSEqC 1.2 Rotor control (like move east, go
> > the sat no, store sat no, etc.) something to be implementated in the VDR
> > core or better in a plugin. For a plugin, cDvbDevice would need a public
> > SendRawDiSEqC() member function or something in that way.
>
> I guess this should go into the core code.
>
> How *exactly* would a sequence of actions look like in order to make a
> rotor move to a given position?

The Move-Cmd is a single DiSEqC statement like this: (old DVB api)

<snip>
int send_diseqc(int fd_front, int fd_sec, int addr, int cmd, int no, unsigned 
char *buf)
{
  struct secCommand scmd[2];
  struct secCmdSequence scmds;
  struct secStatus sstatus;
  FrontendParameters fep;

  scmd[0].type                 = 0;
  scmd[0].u.diseqc.addr        = addr;
  scmd[0].u.diseqc.cmd         = cmd;
  scmd[0].u.diseqc.numParams   = no;
  memcpy( scmd[0].u.diseqc.params, buf, no );

  [..]

  scmds.voltage         = sstatus.selVolt;      //SEC_VOLTAGE_18;
  scmds.continuousTone  = sstatus.contTone;     //SEC_TONE_ON;
  scmds.miniCommand     = SEC_MINI_NONE;
  scmds.numCommands     = 2;
  scmds.commands        = scmd;

  if (ioctl(fd_sec,SEC_SEND_SEQUENCE, &scmds) < 0) {
     perror("ioctl(fd, SEC_SEND_SEQUENCE,..)");
     return -1;
  }
  return 0;
}

send_diseqc(front_fd, sec_fd, 0x31, 0x6b, 1, &satellite);
<snap>

But that only let the rotor move. Tuning looks something like this:

<snip>
do {
   tune_it(front_fd, sec_fd, freq, sr, pol, dqno );

   sync=0;
   for(i=0;i<4;i++) // this loop prevents us from locking to a wrong satellite                 
                    // on the movement
   {
       char eye[4]=";:.:";
       usleep(500*1000);
       front2_fd = open(front_dev, O_RDONLY );
       ioctl(front2_fd, FE_READ_STATUS, &status);
       close(front2_fd);

       synced = (status & FE_HAS_SYNC);
       if(synced) sync++; else sync=0;

       printf("\b\b\b\b\b\b\b\b\b\b\b\b"
           "%02i(%01i/%01i) %c%s",
           timeout, sync, i, eye[i],
           synced?"-)":"-("
       );
       fflush(stdout);
   }
   if(sync<3) { timeout++; }
} while(sync<3 && timeout<25);
<snap>

> Klaus

Christian