[gelöst] Unicable2 - LNB1/2/3/4 ohne Probleme, aber Tuning Timeout bei LNB5/6/7/8

  • Meine Anlage besteht aus einer WF T90 mit 8 Breitband LNBs, die an einem Jultec Unicable Multischalter JPS1701-16 angeschlossen sind. Von dort geht eine Ableitung an eine DM920 mit FBC Tuner BCM45308X (A1, A2) und Triple Tuner Si2169D (B1, B2). Mit den 8 LNBs werden folgende Satelliten empfangen: 5.0W(Sat.A), 0.8W(Sat.B), 4.9O(Sat.C), 9.0O(Sat.D), 13.0O(Sat.E), 19.2O(Sat.F), 23.5O(Sat.G), 28.2O(Sat.H). Die DM920 läuft mit dem aktuellen Newnigma2 unstable image.


    An Tuner A2 ist eine Technisat Multytenne angeschlossen. Das funktioniert problemlos. Sie wird abgeschaltet, sobald das System mit der T90 fertig eingerichtet ist und stabil läuft.


    Die T90 ist momentan an B1 aktiv angeschlossen. Im Userband SCR1 entspricht LNB1 Sat.A, LNB2 Sat.B, usw. bis LNB8 Sat.H. Die ersten vier machen keine Probleme. Aber ab LNB5 kommt keine Verbindung zustande (Tuning Timeout bei Manueller Kanalsuche).


    Das Userband SCR5 habe ich im Multischalter so umdefiniert, dass LNB1 Sat.E, LNB2 Sat.F, LNB3 Sat.G, LNB4 Sat.H, LNB5 Sat.A usw. bis LNB8 Sat.D entspricht. Mit diesem Userband funktioniert die Manuelle Kanalsuche z.B. für Sat.E und Sat.G.


    Das angehängte Logfile enthält die Ausgabe der Manuelle Kanalsuche für Sat.G(23.5O) einmal mit der Tunereinstellung SCR1/LNB7, die zu Timeout führt, und dann mit der Tunereinstellung SCR5/LNB3, die funktioniert.


    Meine Frage ist nun, ob jemand a) Erfahrung mit Unicable und mehr als 4 LNBs pro Benutzerband hat und b) eine Idee, wie man das Setup zum Funktionieren bringen kann.


    Die Alternative ist natürlich, dass ich mich auf 4 LNBs pro Userband beschränke und einige weitere der Userbänder wie SCR5 im Multischalter umkonfiguriere.

    • Offizieller Beitrag

    Aktuell werden nur 4 Unterstützt. Sprich in der Software sind nur 4 eingebaut... es gibt im Unicable 2 Protokoll aber noch 4 bits für einen Uncommitted Switch.


    Die Frage ist ob es reichen würde das untere Bit zu setzen damit man die nächsten 4 nutzen kann. Wenn ich es mit normalem DiSEqC Vergleiche würde das ausreichen. Aber sicher bin ich nicht. Wäre auch kein großes Ding das einzubauen. Ich weiss nur nicht ob es ausreicht.


    cu

  • Ghost: Vielen Dank für deine Antwort.
    Ich habe versucht, übers Internet dazu noch etwas herauszufinden. Bit 0 des dritten Datenbytes des 70er-Kommandos selektiert das Band (High/Low), Bit 1 die Polarität. Das deckt sich mit den Logfileausgaben. Die verbleiben 6 Bits dienen offenbar der Adressierung der bis zu 64 bei Unicode2 möglichen Satelliten. Das Beispiel auf der Jultec Seite (http://www.jultec.de/gloss_JESS.html) legt das jedenfalls nahe, auch wenn es nirgends explizit steht. "70 06 6C 02" adressiert den ersten Satelliten. Wenn ARD auf dem fünften zu finden wäre, denke ich, dass das entsprechende Kommando "70 06 6C 12" lauten müsste, und "70 06 6C 22" entsprechend für den neunten Satelliten. Ich werde bei Jultec nachfragen, mit der Hoffnung eine Bestätigung zu erhalten.


    • Offizieller Beitrag

    Hi,


    ich verstehe es etwas anders als Du :winking_face:


    Ich vermute eher, dass es wie bei DiSEqC ist... sobald man das uncommitted bit setzt hat man ja schon wieder 4 neue mögliche satelliten durch die 2 bits darunter.. also option und position vom committed byte.. sprich man beginnt beim 5. Satellit dann mit option/position im committed byte wieder wie bei sat 1... nur dass halt das unterste uncommitted bit gesetzt ist.... bei sat 9..12 wäre es dann das zweite uncommitted bit... 13..16 dann das erste und zweite... usw.. so wäre es bei DiSEqC. Eigentlich einfach die 6 bits nur verwenden wie es beim normalen dezimalen zählen auch ist... jedes weitere bit verdoppelt ja die Möglichkeiten.


    000000 = 0
    000001 = 1
    000010 = 2
    000011 = 3
    000100 = 4 (das wäre dann das neue bit)
    000101 = 5
    000110 = 6
    000111 = 7
    001000 = 8
    001001 = 9
    001010 = 10
    001011 = 11
    001100 = 12
    001101 = 13
    001110 = 14
    001111 = 15


    usw....


    Aber frag mal bei Jultec :winking_face: Ich werde das wenn du die Antwort hast entsprechend einbauen.


    cu

  • Ghost: Mittlerweile habe ich eine Antwort von Jultec erhalten. Ich denke, es läuft auf das hinaus, was du vermutest hast. Einen Auszug der E-Mail füge ich ein:


    "... Ihre Beispiele mit der ARD sind richtig, die Bits werden einfach "weiter hoch gezählt". Ich habe Ihnen einen Auszug aus der EN 50607 (JESS wurde 1:1 in diese Europanorm überführt) angehängt. Daraus ist zu erkennen, dass sich das letzte Byte des Befehls 0x70 aus den "Uncommitted Switches" und den "Committed Switches" zusammensetzt. Diese Switches sind aus der "normalen" DiSEqC-Welt bekannt, wobei die "Committed Switches" für die ersten 4 Satelliten verwendet werden und mit den "Uncommitted Switches" zwischen diesen 4er-Blöcken umgeschaltet wird. Ich habe genau dieses Datenformat für JESS gewählt, weil die Receiverprogrammierer dann einfach nur die vorhandene Satelliten-/Ebenenauswahl in den Einkabelbefehl zu mappen brauchen. ..."


    Wie Jultec weiter schreibt, bieten sie Receiveranbietern Support bei der Implementierung von JESS an und stehen für weitere Fragen zur Verfügung.

  • die stellen den Anbietern auch Testequippment zur Verfügung :thumbs_up:

  • Ghost: Ich möchte nochmal nachfragen, ob die Antwort von Jultec die erforderliche Klärung gebracht hat und, wenn ja, ob geplant ist, eine entsprechende Änderung demnächst zu implementieren?

  • @Ghost: Mittlerweile steht ja das unstable Image ...dm920-20180811... zum Download zur Verfügung. Ist die Änderung darin enthalten? Mit der heute aktualisierten NN2 Version funktioniert es auf meiner DM920 jedenfalls noch nicht.

  • Mit der neuen Version (4.3.2r1) funktionieren nun auch LNB5/6/7/8 einwandfrei mit FBC und Triple Tuner. Vielen Dank an alle, die mitgeholfen haben, dies zu ermöglichen.