Ich habe ein ziemlich seltsames Problem, an dem ich schon länger rumteste.
Meine Mulituner-Boxen (egal ob HD51, oder Duo4K) sind in DVB-S
verbunden mit einer Multischalterschussel (Astra 1 und Hotbird)
sowie einer Motorschüssel, die den Bereich von 30 W bis 42 E (außer Astra 1 und Hotbird) abdeckt.
Die Auswahl der Schüssel/LNBs wird per Spaun SUR 211 gesteuert.
Dabei kann ich wählen zwischen DiSEqC 1.0 als Optionsschalter
* Port 1 Astra 1, (Port 1 wird am Multischalter ausgewertet)
* Port 2 Hotbird (Port 2 wird am Multischalter ausgewertet)
* und Port 3 + USALS das Kabel zur Motorschüssel,
oder DiSEqC 1.1 als Uncommited Switch 1
* uncom 1 mit com 1 > Astra 1, (Auswertung siehe oben)
* uncom 1 mit com 2 > Hotbird
* und uncom 2 + USALS das Kabel zur Motorschüssel
Ich habe die Delays im Source verlängert, weil es immer wieder Probleme mit dem Timing gab und das Motor-Commond schon abgesetzt wurde bevor der SUR211 die Leitung geschaltet hatte.
Ergebnis: Motor drehte nicht.
Und wenn der Motor sich drehte, kam anscheinend das Tuning-Command für das LNB nicht (mehr) an.
Mit Wiederholungen der DiSEqC-Befehle und/oder des kompletten Tunings konnte das Problem gemildert werden, aber weg war es nicht.
In solchen Fällen war die Motorschüssel nur mit vielen Tricks zu einer weiteren Zusammenarbeit zu bewegen. Ursache war die Verwaltung der "lastSatellitePosition" in frontend.conf und !! zapit.conf.
Wann diese Werte geschrieben werden, war für beide Datensätze anscheinend unterschiedlich.
Meist hatte einer den Wert der angesteuert werden sollte, aber nicht erreicht hatte, der andere hatte noch den Wert des letzten Mals. (Auf diese Redundanz hatte ich schonmal hingewiesen !!)
Inzwischen hat sich das Problem irgendwie verschärft. Oder meine Tricks zum Wiedereinfangen sind in der falschen Reihenfolge.
Wie auch immer, in der Betriebsart USALS werden ja wohl nur Differenzen zwischen "bestehender" und "neuer" Postion berechnte und dann als Winkel von 'alt' nach 'neu' gedreht.
Da die Schüssel aber nicht auf "bestehend" steht (da sie sich ja vorher real garnicht gedreht hat)
wird der Winkel auf die aktuelle (alte) Position bezogen.
Ergebnis:
Die Schüssel fährt im schlimmsten Fall gegen die Endlagen-Einstellung und ist blockiert.
Oder sie nimmt dort keine Kommandos mehr an, weil der Anwender (ohne Sicht auf die Schüssel) die Referenzposition angefahren hat (die in diesem Fall auch gleich der Endlagen-Stellung ist).
Derzeit mögliche Abhilfe:
+ SAT-Kabel vom SUR lösen und das Motorkabel direkt mit der Zuleitung zur Box verbinden.
+ EIne Satposition am Receiver auswählen. (damit Spannung am Motor anliegt)
+ Sinnvollerweise (wenn man Glück und eine Satposition auf der Referenzstellung hat) einen Sender auf der Referenzposition anwählen.
+ Leiter raus, auf's Dach
+ mit den Tasten am Motor und einem Signalmesser am LNB die Referenzposition manuell anfahren.
(mit leichtem Schieben aus der verklemmten Endlage)
+ die gefundene Referenzposition am Motor (Resetschalter) festhalten (fixieren)
+ im Haus kurz prüfen, ob der eingestellte Sender auf dem Schirm ist.
* Alles wieder zurückbauen, Leiter wegstellen.
Da das in letzter Zeit immer häufiger auftritt, habe ich mir ein paar Ursachen ermittelt:
1. Box per PowerOFF mitten aus dem "Stillstand" abgewürgt und dann rgendwann Neustart.
2. Box per Multiboot auf ein anderes Image (mit anderer lastSatellitePosition) umschalten.
3. Settings im aktuellen Image wechseln.
4. Wenn man vom Multischalter kommt, wird uU der gewünschte Sender nicht getuned, weil das Kommando für's LNB vorher ins Nirwana geschickt wurde. (den schlimmen Fehler macht dann anschließend idR der Anwender durch weotere Motordrehungen)
Ein paar Möglichkeiten zur Problemlösung über die Firmware habe ich mir auch ausgedacht:
1. Die Ermittlung/Nutzung des DiSEqC-Status (weshalb ich einen DiSEqC 2.0 Schalter gekauft habe)
Geht aber wohl nicht, weil schon die 2.x-Unterstützung im Treiber nicht vorhanden sein soll.
2. frontend.conf habe ich auf er Box schon nach /var/tuxbox/config verschoben, um den Wechsel der Settings unabhängiger zu machen. Entweder müsste zapit.conf auch nach /var/tuxbox/config verschoben werden oder die Redundanzen müsste besitigt werden. Noch besser wäre es sicherlich zapit.conf in zapit/ komplett zu entsorgen und die entsprechenden Terme in frontend.conf oder scan.conf zu persistieren. (falls nicht irgendein Plugin aus dem letzten Jahrtausend zapit.conf in zapit/ unbedingt benötigt)
3. Vielleicht sind die aktuellen Treiber in der Lage, die für DiSEqC 1.x gedachten Commands
10 Status
11 Config
14 Read switching state (committed)
15 Read switching state (uncommitted)
zu verwenden, um ein wenig Kontrolle in das DiSEqc-Managment zu intgrieren.
4. EInen DiSEqC-KommandoModus der es dem Anwender gestattet, für seine Empfangsanlage passende Command-Sequenzen Schritt für Schritt einzeln zusammenzusetzen. Das geht erfolgreich im DVB-Viewer per DiSqC.xml. Inzwischen gibt es dafür auch einen Editor im UI wo die Einzelschritte in der gewünschten Reihenfolge - dazu mit den ausreichenden Delays - eingegeben werden können. Die DiSEqC-Papers braucht man dann nicht mehr
Eine Muster-XML (mit Motorsteuerung) könnte ich mal anfertigen.
Hier die aktuelle ohne Motoranschluss des TBS 5520 an den Win-PC:
<?xml version="1.0" encoding="UTF-8"?>
<settings>
<section name="Commands2">
<entry name="0192">[E0 10 39 F0] W200 [E0 10 39 F0] W100 {E0 10 38 F0} W100</entry>
<entry name="0130">[E0 10 39 F0] W200 [E0 10 39 F0] W100 {E0 10 38 F4} W100</entry>
</section>
<section name="DiSEqC">
<entry name="Latitude">xx.y</entry>
<entry name="Longitude">aa.b</entry>
</section>
</settings>
Das halte ich persönlich für die am schnellsten zu realisierende Lösung. Den Commandstring könnte man auch in einer frontend.conf unterbringen, wenn man die richtigerweise LNB-zentrierter macht.
An meiner Motorschüssel ist zum Beispiel nur 1 LNB, aber ich muss die Daten dafür für jede Satposition komplett nochmal eingeben. Anwenderfreundlich ist anders...