DiSEqC 2.x

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Ich habe mir mal den DiSEqC - Bereich in den Sourcen angeschaut, um eine Erweiterung auf die 2.x -Features einzupflegen.

      Da taucht gleiche eine Frage auf:
      Warum wird die DiSEqC_Type Enumeration in src/zapit/include/zapit/client/zapittypes.h (weit weg vom Schuss) deklariert und der ganze andere Bereich in Sourcen zu Frontend und Scan (wo sie ja auch hingehören) ?

      Aber zu 2.x:
      Da ja die "Sende"-Grundfunktionen in 1.x und 2.x jewweils identisch, sowie gleich zugewiesen sind und nur die Empfangsmöglichkeiten von 2.x über 1.x hinausgehen, würde ich vorschagen, die Differenzierung in den Routinen über diseqc.major und diseqc.minor zu machen.

      Kein DiSEqC => diseqc.major = -1
      Mini DiSEqC => diseqc.major = 0
      DiSEqC 1.0 => diseqc.major = 1, diseqc.minor = 0
      DiSEqC 1.1 => diseqc.major = 1, diseqc.minor = 1 (01b)
      DiSEqC 1.2 => diseqc.major = 1, diseqc.minor = 2 (02b)
      DiSEqC 2.0 => diseqc.major = 2, diseqc.minor = 0
      DiSEqC 2.1 => diseqc.major = 2, diseqc.minor = 1
      DiSEqC 2.2 => diseqc.major = 2, diseqc.minor = 2


      Das bedeutet, dass fast alle bestehenden Routinen erstmal so bleiben könnten und nur im Bedarfsfall um eine Variation im Framing-Byte - über diseqc.major gesteuert - nachgearbeitet werden müssten.

      Für "Advanced" (worunter ich eine Abfolge mehrerer unterschiedlicher DiSEqC-Elemente auf dem Schaltweg verstehe) könnte man das auch gebrauchen, indem man den 'höchsten' Wert auf dem Weg verwendet. Oder diese 'Eigenschaft' den jeweiligen "gesteuerten" Elementen zuordnet.
      Schon eine reine DiSEqC 1.0 Variante - Ein Optionsschalter vor zwei Postionsschaltern - könnte (bei Fehlfunktionen mit den PortGroupCommands) schon in diesen "Typ" passen, wenn z.B. die Delays zwischen Optionschalte und Positionsschalte und/oder Tuning-Kommando angepasst werden müssten.

      Vielleicht hat einer eine Idee, wie man die UniCable-Sachen, SMATV und für spätere Erweiterungen - z.B. FullBandCapture - in diesem oder einem besseren Schema unterbringen könnte ?!?
    • Karneval steht vor der Tür und das gibt Gelegenheit, interessante Sachen zu machen.

      Da wollte ich mal versuchen, die 2.x- getSlaveReply()-Funktion in frontend.cpp einzubauen. Als Nichtprofi erscheint mir die Funktion getEvent() durchaus zur Vorlage geeignet, obwohl ich keine Ahnung habe, wie so ein "Polling" funktioniert oder ob das überhaupt in diesem Kontext Sinn macht.

      Frage daher an die C-Kundigen:
      Kann/sollte ich getEvent() als Pattern für getSlaveReplay() benutzen ?
    • Also ich habe genau eine Software gefunden, die den DiSEqC-2.x ioctl benutzt (github.com/AdamLaurie/satmap/blob/master/dvb.py) und da steht dabei, daß er es nicht benutzt und getestet hat, weil er kein DiSEqC-2.x Equipment hat.

      Dann gibt es genau 5 (eigentlich 4) Treiber die das überhaupt implementiert haben im upstream Kernel:
      * STB0899 - DVB-S2 demod, kenne ich nur auf PCI Karten
      * STV0900 - DVB-S2 demod, aber keine Ahnung wer den Treiber tatsächlich nutzt
      * STV090x - der ist z.B. in der HD1 drin und in der gm990
      * TDA10071 - DVB-S2 demod
      * S5H1420 - alter DVB-S demod

      Ich vermute also, daß du am besten erst mal Testprogramme schreiben solltest, mit denen du die Funktion des Treibers testen und erkunden kannst, bevor du versuchst, das im Neutrino zu integrieren.

      Dazu wäre es sicher gut, die DiSEqC 2.x Spec mal zu lesen und zu schauen was denn da überhaupt getan werden muss:
      - gibt's auf jedes Kommando eine Antwort?
      z.b. beim Motordrehen:
      * kommt die Antwort erst wenn der Motor fertig ist mit drehen?
      * wie weiß ich wann ich nach einer Antwort fragen muß?
      etc.pp.
    • Das Lesen fällt mir leichter als C-Programme schreiben ;(

      Das Antwortverhalten wird über das Framing-Byte (Reply-Flag: 1111 xxRx) des Commands gesteuert.

      Wenn angefordert, wird zwischen 15 und 115 ms geantwortet.
      a) garnicht, wenn die Slave-Hardware das nicht kann (>timeout)

      b) ansonsten über das Framing-Byte der Antwort 0xE4=Okay. Framing >0xE4 gibt Hinweise auf Fehlerquellenc) wenn 0xE4, dann folgen je nach 'Anfrage' noch entsprechende Daten.

      Für den Motor-Bereich
      a) Die Antwort kommt - wie oben angegeben - 15-115ms nach der Abfrage. Geliefert wird ein Statusbyte mit den aktuellen 'Werten' (z.B. dreht noch, ist fertig, Drehrichtung usw.)
      b) ich würde da mal solange die Antwort anfordern, bis ein Endekriterium im Statusbyte auftaucht (fertig, auf Limit gestoßen, Strom weg o.Ä)