Problem mit Unicable und Drehmotor in DVBviewer

[Crania1]

Hallo,

 

wie bereits berichtet funktioniert das Zusammspiel von Unicable und Drehmotor mit DVBViewer NICHT.

(Oder besser formuliert, in meiner Konfiguration).

 

http://www.DVBViewer.tv/forum/topic/53091-problem-with-32bit-to-64bit-wrapper-and-diseqc/

http://www.DVBViewer.tv/forum/topic/9117-unterstutzte-hardware/page-3

 

Nach weiteren Analysen und Messungen habe ich festgestellt, dass auf der Antennenleitung

beim Umschalten auf einen anderen Transponder IMMER zwei identische

Tuningbefehle vom DVBViewer gesendet werden.

Dies wäre ja erstmal nicht besonders tragisch (Nur Zeitverschwendung).

 

Das Problem tritt erst beim Wechsel auf einen anderen Satelliten auf.

Hier erwarte ich zwei unterschiedliche DiseqC-Befehle auf der Antennenleitung:

 

a) Positionsbefehl(GoTo xx) "E0 31 6B xx) auf eine zuvor im Drehmotor gespeicherte Position xx.

Tuningbefehl für den Unicable LNB "E0 10 5A xx xx" (xx xx ist Pol,Band,Freq)

 

Es werden aber auch hier zwei identische Tuningbefehle ausgegeben.

Dies ist doch ein klarer BUG in der DVBViewer Software.

Hiermit kann sich der Motor nicht bewegen!

In der Debug.log sind die beiden Satelitenpositionen 30 und 29 wiederzufinden.

Weiterhin gibt es noch in beiden Fällen den Wert 7.

 

SetTuner TType: 1, Freq: 11534, Symrate: 30000, LOF: 9750, Tone: 0, Pol: 0, DiseqC: 7, FEC: 3, APID: 512, VPID: 511, PMT: 97, SID: 4601, SatMod: 1, DiseqCVal: 30, NID: 1, Flags: 24

 

SetTuner TType: 1, Freq: 11244, Symrate: 22000, LOF: 9750, Tone: 0, Pol: 0, DiseqC: 7, FEC: 4, APID: 2251, VPID: 2250, PMT: 225, SID: 13225, SatMod: 1, DiseqCVal: 29, NID: 1, Flags: 24

 

Gibt es noch weitere Stellschrauben an denen man drehen kann oder Analysetools?

 

Gruß Crania1

support.zip

Edited August 28, 2013 by Crania1

[Griga]

Du hast also tatsächlich einen Unicable-LNB an deine Drehschüssel geschraubt? Und zu welchem Zweck? Der eigentliche Sinn von Unicable - nämlich die konfliktfreie Steuerung einer Satellitenanlage durch mehrere Receiver über ein Antennenkabel - wird durch eine Motorsteuerung konterkariert.

Hier erwarte ich zwei unterschiedliche DiseqC-Befehle auf der Antennenleitung:

 

Kannst du mit dem DVBViewer vergessen. Unicable plus Motorsteuerung ist schlicht nicht vorgesehen, ebenso wenig wie im Standard EN 50494. Wenn es mit ProgDVB wie gewünscht funktioniert, musst du ProgDVB verwenden.

 

In der Debug.log sind die beiden Satelitenpositionen 30 und 29 wiederzufinden.

Weiterhin gibt es noch in beiden Fällen den Wert 7.

 

 

DiSEqC = 7 ist die interne Kodierung für das Goto Position nn Kommando, und DiSEqCValue enthält nn. Soweit ok. Was das Log nicht zeigt: Die Aktivitäten eines nachfolgenden Programmteils, das die Daten für Unicable umbaut. Da bleibt von den Motor-Kommandos nichts mehr übrig.

 

Bei Tests mit der Positionier-Console von TransEdit wurden auch keine

Motor-Diseqc-Befehle ausgesendet!

 

Das sollte allerdings funktionieren. Die Konsole hat mit Uncable nichts am Hut, weil sie kein Tuning ausführt, sondern nur die den Buttons zugeordneten DiSEqC-Kommandos sendet. Diesem Punkt nachzugehen ist das einzige, was sich lohnt.

[Crania1]

Hallo,

 

im Prinzip hast Du ja recht mit Deinem Unicable/Drehschüssel Einwand.

Aber es gibt doch einige Gründe es so zu machen:

 

a) Der LNB befindet sich immer genau im Fokus der Schüssel (Gewinn, kein schielen).

Es ist nur ein Kabel von der Antenne zu den Receivern erforderlich.

c) Eine vorhandene Antennenverkabelung kann weiter benutzt werden (Bus statt Stern).

Hier sind nur die Antennendosen in den einzelnen Räumen auszutauschen (Gleichspannungsentkopplung, usw.)

d) Bei mehreren weiter auseinanderliegenden Satelliten ist nur eine Schüssel und ein LNB erforderlich.

e) Hierbei können alle Receiver natürlich immer nur GLEICHZEITIG die Programme einer Satellitenposition empfangen (Im Mehrfamilienhaus natürlich sinnlos).

f) Wenn Ihr nicht die Positionskommandos unterdrücken würdet, währe doch alles GUT. Er werden doch schon zwei DiseqC (Zwei gleiche!) ausgegeben obwohl der Wiederholungszähler auf 1 steht.

 

Aber nun zurück zum eigentlichen Problem:

Wenn es nur an der UniCable-Konfiguration liegen sollte, dann müsste sich der Motor

ja ansprechen lassen wenn ich alles umkonfiguriere und die Antennenleitung auf den Legacy-Output meines LNB lege.

Aber hierbei werden auch keine DiseqC-GoTo's gesendet.

Dies deckt sich auch mit dem Verhalten bei TransEdit.

 

Gruß Crania1

[Derrick]

..das wäre lustig, wenn jeder in einer mehrteilnehmeranordung die schüssel verdrehen könnte. Totschlag im mehrfamilienhaus weil der nachbar DSDS weggedreht hat

[Griga]

Wenn Ihr nicht die Positionskommandos unterdrücken würdet

 

Die werden nicht unterdrückt. Das ist so "by design". Um Unicable mit Drehmotor zu kombinieren, wären erhebliche Änderungen im Programmablauf erforderlich. Niemand hat hier damit gerechnet, dass jemand sowas machen würde.

 

Jede Umschaltung, die mehr als ein Kommando erfordert, muss ohnehin im DiSEqC Editor als Sequenz definiert werden (DiSEqC = Extended), und in dem System ist Unicable schlicht nicht vorgesehen.

 

Wenn jetzt noch sagen wir mal 9 Leute dazukommen, die das brauchen, würde ich anfangen, über eine Lösung nachzudenken. Oder es müsste sich eine programmtechnisch sehr einfache Lösung finden. Aber die sehe ich im Moment nicht.

 

Aber hierbei werden auch keine DiseqC-GoTo's gesendet.

Dies deckt sich auch mit dem Verhalten bei TransEdit.

 

Das wundert mich, weil ja offenbar Unicable-Kommandos und damit DiSEqC Raw Commands generell mit der TeVii funktionieren.

[Crania1]

Hallo,

ok. ich gebe es auf...

Vielen Dank für die Antworten.

Gruß Crania1

 

PS: Es gibt da noch mindestens zwei weitere Gründe, auch an einer Einzelplatzanlage

ein UniCable-System zu verwenden:

 

1. Der UniCable-LNB hat ca. 8-10dB mehr Gewinn gegenüber einem standard LNB durch einen schmalbandigen ZF-Verstärker. Es kann dann zB. ein kleinerer Spiegel verwendet werden.

 

2. Es kann der untere User-Frequenzbereich gewählt werden. Dies verringert die Verluste bei langen Antennenleitungen.

 

3. Es ist nicht gut, wenn man die Möglichkeitem die in der Hardware stecken durch Software blockiert.

[Derrick]

Hallo,

ok. ich gebe es auf...

Vielen Dank für die Antworten.

Gruß Crania1

 

PS: Es gibt da noch mindestens zwei weitere Gründe, auch an einer Einzelplatzanlage

ein UniCable-System zu verwenden:

 

1. Der UniCable-LNB hat ca. 8-10dB mehr Gewinn gegenüber einem standard LNB durch einen schmalbandigen ZF-Verstärker. Es kann dann zB. ein kleinerer Spiegel verwendet werden.

 

2. Es kann der untere User-Frequenzbereich gewählt werden. Dies verringert die Verluste bei langen Antennenleitungen.

 

3. Es ist nicht gut, wenn man die Möglichkeitem die in der Hardware stecken durch Software blockiert.

1. ist ja wohl ein märchen. Definiere mal den vermeintlichen gewinn. Dann wirst du feststellen, dass der gewinn einer schüssel fast nur von der grösse abhängt. Beim lnb wird als gewinn manchmal die verstärkung bezeichnet. Der conversion gain normaler lnbs reicht in der regel immer aus.

2. könnte bei einem sehr dünnem und minderwertigen kabel ev. eine rolle spielen.

3. da hast du recht. Allerdings ist es ja nicht absichtlich gemacht, um dich zu ärgern

[Griga]

Ich habe mal bei Digital Devices nachgefragt, wie deren Treiber, wenn er für Unicable konfiguriert ist, DiSEqC-Kommandos für Motoren, Uncommitted Switches und ähnliches behandelt.

 

Sie werden gesendet, aber ich wurde darauf hingewiesen, dass es ein weiteres Problem gibt, an das ich bislang nicht gedacht habe und das auch der DD-Treiber nicht berücksichtigt. Wenn mehrere Tuner an einer Antennenleitung hängen, kommen DiSEqC-Kommandos generell nur sauber durch, wenn der Spannungspegel des sendenden Tuners deutlich über dem der anderen Teilnehmer liegt Man müsste also für Motor-Kommandos ebenso wie für Unicable-Kommandos die LNB-Versorgungsspannung kurzzeitig auf 18 V hochziehen. Oder alle anderen Tuner derweilen abschalten.

[Crania1]

Hallo,

 

vielen Dank dass Ihr euch noch mal gekümmert habt.

 

Also, aufgrund der UniCable-Problematik habe ich mein System zurück konfiguriert

und bin an den Legacy-Ausgang des LNB gegangen. Also

LNB ---> Motor ----> Tevii S464

sonst sind keine weiteren Tuner angeschlossen.

 

Folgendes habe ich durch Messungen ermittelt:

1. Beim Wechsel des Satelliten sendet der DVBViewer das DiseqC GoTo-Kommando korrekt aus. (Ohne Spannungserhöhung auf 18V) Der Motor dreht korrekt. Dies könnte möglicherweise bei mehreren Tunern ein Problem werden.

 

2. In TransEdit funktioniert die Positionierung nicht. Hier gibt es möglicherweise ein Timingproblem. Die Spannung auf der Antennenleitung wird erst beim Aufruf von , zB. ScanSelected eingeschaltet. Bei meiner Tevii S464 erreicht die Spannung aber erst nach ca. 30ms die 18V. Nach weiteren 25ms wird bereits das DiseqC-Kommando ausgesendet. Zu diesem Zeitpunkt ist möglicherweise die Power-Up-Sequenz im Motor noch nicht abgeschlossen, denn das Kommando läuft ins Leere. Der Motor dreht nicht.

Hier wird zwar die Spannung auf 18V erhöht, im Gegensatz zum DVBViewer, da sie aber von 0V kommt muss hier mehr Zeit verstreichen, damit alle Initialisierungen abgeschlossen werden können.

 

3. Wenn ich TransEdit aufrufe und dann die Positionier-Console, wird überhaupt keine Spannung auf die Antennenleitung gelegt...

 

4. Vom Design her; welchen Ansatz soll denn die Positionier-Console verfolgen, ausser der Positionierung des Spiegels? Es währe sehr hilfreich, wenn man beim Justieren gleichzeitig die Veränderungen im Signalpegel sehen kann um hier auf Maximum abzustimmen. Oder soll man immer gleichzeitig einen Scan laufen lassen?

 

5. Soll oder soll nicht, TransEdit konzeptionell mit der gleichen Datenbasis arbeiten wie DVBview? Und wer soll hier die Einstellungen vom jeweils anderen übernehmen?

Hier sind zB. zu nennen: Transponderlisten und DiseqC-Einstellungen.

 

Gruß Crania1

[Griga]

Danke erst mal für das qualifizierte Feedback. Damit lässt sich was anfangen.

 

Was wir von Herstellern als API erhalten, ist meist äußerst kümmerlich. Etwas undokumentierten Beispielcode, damit hat es sich. Auf Timing-Feinheiten und sonstige Bedingungen wird nicht eingegangen. Dementsprechend gibt es gerne Probleme, sobald jemand mehr will als nur Astra 19° Ost empfangen Man kann solche Geräte als Entwickler eigentlich nur sauber zum Funktionieren bringen, indem man sie selbst austestet. Oder ein versierter Anwender Hinweise gibt.

 

Und TeVii-Geräte gehören ehrlich gesagt bei den hiesigen Entwicklern und Testern nicht zur favorisierten Hardware....

 

Wie auch immer:

 

Zu (1): TransEdit initialisiert das Gerät für jeden Scan neu und gibt es danach sofort wieder frei, um es möglichst wenig besetzt zu halten. Deshalb muss bei jedem Scan die LNB-Spannung erneut hochgefahren werden (siehe 2). Wenn du im DVBViewer den Sender / die Sat-Position wechselst, ist das natürlich nicht der Fall. Beim Scannen mit dem DVBViewer dürfte es aber ähnliche Probleme geben.

 

Zu (2): Der TeVii-Treiber schaltet die LNB-Spannung vermutlich erst ein, wenn die Anwendung beim ersten Tunen die Polarisation setzt, so wie ich unsere ostasiatischen Freunde kenne. Beim ersten Tunen müsste es also zwischen dem Setzen der Polarisation und dem Senden des DiSEqC-Kommandos eine Verzögerung geben. Welchen Wert schägst du vor?

 

Du kannst im DiSEqC-Editor (DiSEqC = Extended) selbst dem Motor-Kommando eine Verzögerung voranstellen und verschiedene Werte probieren. Allerdings wird sie so bei jedem Anfahren einer Sat-Position wirksam, was eigentlich unnötig ist. Letztendlich sollte es also besser wie oben beschrieben in der Anwendung geregelt werden.

 

Zu (3): Das Öffnen der Positioner Console allein intitialisiert das gewählte Gerät nicht. Dies geschieht erst, wenn man einen der Buttons anklickt und damit ein DiSEqC-Kommando sendet. Ansonsten ist die Positioner Console Optimist. Sie führt kein Tunen aus, sondern sendet nur DiSEqC-Kommandos. Was sollte sie auch tunen? Sie geht davon aus, dass ein Treiber schon bei der Initialisierung die LNB-Spannung hochfährt, oder zumindest, bevor er das erste DiSEqC-Kommando ausgibt. Ohne LNB-Spannung macht es ja keinen Sinn. Das sollte der Treiber eigentlich wissen. Und eigentlich auch, welche Verzögerung dabei angebracht ist, anstatt die Anwendung oder den Anwender über die Eigenarten der Spannungsversorgung rätseln zu lassen.

 

Bei einigen Geräten machen sich die Treiber-Programmierer um sowas Gedanken. Bei anderen nicht... eine Positioner Console haben viele nicht auf dem Schirm. Sofern der Treiber überhaupt bei der Firma selbst geschrieben und nicht irgendwo abgekupfert wird.

 

Kurz gesagt, wenn bei der TeVii die Initialisierung des Geräts und das Senden eines DiSEqC-Kommandos nicht ausreicht, um die LNB-Spannung einzuschalten, müsste die Positioner Console wohl bei TeVii initial ein Art Dummy-Tuning ausführen oder zumindest die Polarisation setzen, um stand alone zu funktionieren.

 

Zu (4) Oder man startet vor Verwendung der Positioner Console den Analyzer. Das ist besser als Scannen, da man dort die Signalqualität und auch eventuelle Paketverluste durch schlechten Empfang sieht.

 

Verbleiben wir so: Du schaust, was sich aus den hier vorgeschlagenen Ansätzen ergibt, und ich schaue, ob und wie sich beim Handling von TeVii-Geräten Verbesserungen durchführen lassen. Gegebenenfalls werde ich danach eine Testversion in den Mitgliederbereich hochladen, die du überprüfen kannst.

[Crania1]

Hallo,

habe die Info mit Interesse gelesen und erstmal versucht die

Zeitspanne für die Initialisierung des Motors zu ermitteln.

 

1. In TransEdit -> DiseqC -> Extended -> Delay 200ms und Preset Position 29 eingestellt -> Apply und Save nicht vergessen. Es zeigte sich keine Veränderung im Zeitverhalten. Egal was ich als Delay eingestellt habe (50, 100, 200, 400, 600ms).

Hierbei ist mir aufgefallen, dass bei ScanSelected nach ca. 2,7 Sek. also kurz bevor die Spannung wieder abgeschaltet wird, nochmal ein DiseqC-Positionskommando gesendet wird.

Hier funktionieren anscheinend mehrere Sachen noch nicht im Zusammenspiel mit dem Tevii Treiber.

 

2. Bei mir zeigt der Analyser keine Daten von DVB-S2 Transpondern an. Auch teilweise von anderen Transpondern. Konnte hier keine Systematik erkennen. Ist dies auch auf den Tevii-Treiber zurückzuführen? Im DVBViewer gibt es hierzu keine Einschränkungen.

 

3. Also, bevor wir hier die Zeit für Workarounds zum Tevii-Treiber verwenden(mit ungewissem Ausgang wegen trail and error), tendiere ich dazu, die Tevii-Karte in die Ablage-Rund zu entsorgen und mir eine neue, mehr kompatible Karte zu beschaffen.

Ein Tipp hierzu Eurerseits wäre hilfreich. Aus der Hardware-Kompatibilitätsliste kann man nicht eindeutig entnehmen welche Karte gut mit Drehmotoren kann.

(Hinweis: Die Tevii-S464 funktioniert soweit. Sie hat nur Probleme im Zusammenspiel mit einem Drehmotor und DVBViewer).

 

4. Wenn Ihr hier bereit seid Entwicklerzeit zu investieren, würde mir mehr helfen, wenn Ihr nochmal über die UniCable-Drehmotor Problematik nachdenkt... Könnte man ja vielleicht über DiseqC -> Extended realisieren.

 

5. Die Positionier-Console funktioniert, wenn man vorher den Analyser aktiviert. Hierbei wird dann die erforderliche Spannung auf die Antennenleitung geschaltet. Jetzt kann man mithilfe des Parameters Missing die Grenzen bestimmen und die Antenne auf Mitte einstellen. Diese Vorgehensweise ist praktikabel und führt zu guten Ergebnissen.

 

Gruß Crania1

[Griga]

Zu 1. und 2.: Ich habe die zuständigen Mechanismen in TransEdit überprüft und kann mir nicht erklären, wie es zu dem von dir geschilderten Verhalten kommt - es sei denn, du hast unter Settings -> Hardware "Use standard interface" eingeschaltet, was man nicht ohne zwingenden Grund tun sollte. Das zweite DiSEqC-Kommando könnte dadurch entstehen, dass du Settings -> Hardware -> LNB power off aktiviert hast (was durch ein Dummy-Tuning mit BDA_POLARISATION_NOT_DEFINED erledigt wird) und der Treiber das letzte DiSEqC-Kommando automatisch wiederholt, wenn man kein neues setzt. Für eine genauere Beurteilung fehlen mir deine aktuellen Einstellungen. Sehen kann ich sie, wenn du hier deine TransEdit.ini (aus dem Konfigurationsordner) anhängst.

 

Wenn deine TeVii S464 die LNB-Spannung bei Freigabe des Gerätes automatisch abschaltet, ist dies übrigens nicht korrekt in unserer HW-Datenbank vermerkt. Die "LNB power off" Checkbox sollte gar nicht erscheinen, wenn ein Gerät / Treiber es automatisch erledigt.

 

Insgesamt scheint es bei TeVii-Geräten einigen Klärungsbedarf zu geben. Das können wir weiter verfolgen, aber es kann sich hinziehen...

 

Zu 3: Empfehlenswert sind i.a. die Doppeltuner von Digital Devices (Cine S2) wegen der Treiber-Qualität und der optimalen Unicable-Unterstützung. Aber es hängt natürlich aiuch davon ab, was du machen willst. Zum DXen mit Einsatz von Tools wie CrazyScan sind vermutlich TBS-Geräte besser geeignet. In dem Fall sollte dich jemand wie Derrick beraten, der damit Erfahrung hat.

 

Zu 4.: Der Fall hat ehrlich gesagt geringe Relevanz (außer für dich natürlich). Ich werde nur etwas unternehmen, wenn sich eine einfach zu realisierende Lösung anbietet. Bislang weiß ich keine. Mit einer Digital Devices-Karte stehen die Chancen besser, dass sich in der Hinsicht etwas tun wird, weil der Treiber-Programmierer hier mitliest, deinen Fall zur Kenntnis genommen und mit mir darüber per Mail kommuniziert hat. Mit Fernost-Firmen ist das nicht so einfach.

 

Zu 5.: Immerhin etwas

[CiNcH]

 

Insgesamt scheint es bei TeVii-Geräten einigen Klärungsbedarf zu geben. Das können wir weiter verfolgen, aber es kann sich hinziehen...

 

Bei TeVii ist das nicht so einfach. Von einigen Geräten weiß ich, dass LNB-Off hardwaretechnisch erst in späteren HW-Revisionen realisiert wurde. Deshalb haben wir uns glaub entschieden, das "Auto-Off" im Zweifelsfall in der HW-Datenbank als "nicht unterstützt" zu deklarieren.

[Crania1]

Hallo,

 

guter Tipp mit dem Standard Interface. Habe es wohl beim herumprobieren eingeschaltet und dann vergessen.

 

1. Das DiseqC verhalten hat sich (Bei ScanSelected) dahingehend verändert, dass jetzt nach ca. 2.6 Sek. kein zweites DiseqC Kommando mehr gesendet wird und die Spannung nicht abgeschaltet wird sondern auf 12 V reduziert wird. Dann nach ca. 9 Sek. wird die Spannung nochmal auf 18V angehoben und ein weiteres DiseqC-Kommando gesendet. Welches konnte ich nicht ermitteln, aber der Motor dreht nicht. Nach ca. 17 Sek. wird die Spannung dann ganz abgeschaltet.

Am eigentlichen Timing-Problem, wie in Post #9 Punkt 2 berichtet, hat sich aber nichts geändert. Der Treiber ignoriert einfach die eingestellten DiseqC Delays. Ich habe den Eindruck und gemessen, dass überhaupt alle unter DiseqC->Extended eingestellen Kommandos ignoriert werden.

Wenn ich hier Testweise:

Delay 200, Position 29, Delay 200, Position 29 eintrage, würde ich erwarten, dass zwei Positions-Kommandos gesendet werden. TransEdit soll diese Liste doch nur abarbeiten, das kann der Treiber doch nicht wissen? Oder wird die Liste im Block übergeben?

 

2. Die LNB power off Checkbox ist vorhanden und nicht aktiviert.

 

3. Falls Ihr aus der TransEdit.ini keinen entscheidenden Hinweis bekommt, werde ich wohl zur Cine2 wechseln.

 

4. Das der Analyser bei manchen Transpondern keine Daten anzeigt hat sich nicht geändert.

Kann das an der Transponderliste von KingOfSat liegen? Obwohl, ich benutze die selbe Liste auch im DVBViewer, da funktionieren die Transponder.

Es funktioniert zB. mit Astra19.2° 10743MHz, H, 22000, 5/6,

und Astra19.2° 12266MHz, H, 29500, 3/4,

aber nicht mit Astra19.2° 11362MHz, H, 22000, 2/3, (HD)

Das gleiche Verhalten zeigt auch ScanSelected, bei 11362MHz erscheinen die drei Kanäle nur unter Dead Channels und sind bei der Freq-Spalte mit X markiert.

 

Gruß Crania1

 

TransEdit.ini

[Griga]

Dann nach ca. 9 Sek. wird die Spannung nochmal auf 18V angehoben und ein weiteres DiseqC-Kommando gesendet.

 

Die Wiederholung resultiert daraus, dass du Settings -> Hardware -> Retune Attempts auf 1 gesetzt hast. Und die Anhebung auf 18 V daraus, dass das Gerät in TransEdit nach wie vor für Unicable konfiguriert ist (SlotFrequency.0=1210). Es werden also Unicable-Kommandos, keine Motor-Kommandos gesendet. Wenn das folgende zutrifft

 

Also, aufgrund der UniCable-Problematik habe ich mein System zurück konfiguriert und bin an den Legacy-Ausgang des LNB gegangen.

 

passt das überhaupt nicht und erklärt einiges, insbesondere

 

Der Treiber ignoriert einfach die eingestellten DiseqC Delays. Ich habe den Eindruck und gemessen, dass überhaupt alle unter DiseqC->Extended eingestellen Kommandos ignoriert werden.

 

Womöglich hast du nach der Konfiguration für Nicht-Unicable vergessen, den Save-Button im Settings-Fenster anzuklicken. Nur so behält TransEdit geänderte Einstellungen über das Programmende hinaus.

[Crania1]

Hallo,

 

kaum macht man es richtig schon funktioniert es...

 

Das war der entscheidende Hinweis.

Habe vergessen die Rückkonfiguration von UniCable auch in TransEdit zu machen oder Save vergessen. Entschuldigung.

 

1. Jetzt konnte ich die erforderliche Verzögerung für den Drehmotor nach Power-On ermitteln. Sie beträgt ca. 200ms. Also frühestens 200ms nach Power-On nimmt der Motor Kommandos an.

Habe jetzt überall 250ms bei DiseqC->Extended eingestellt, so ist man auf der sicheren Seite. Diese Zeitspanne ist leider in den Technischen Daten des Motors nicht enthalten.

(Motor von GTSAT Typ: GT-DM14MG)

 

2. Jetzt zeigt der Analyser auch bei allen Transpondern Daten an.

 

Vielen Dank nochmal für Eure Hilfe.

 

Gruß Crania1

[DaMickVanHalen]

 

Zu 4.: Der Fall hat ehrlich gesagt geringe Relevanz (außer für dich natürlich). Ich werde nur etwas unternehmen, wenn sich eine einfach zu realisierende Lösung anbietet. Bislang weiß ich keine. Mit einer Digital Devices-Karte stehen die Chancen besser, dass sich in der Hinsicht etwas tun wird, weil der Treiber-Programmierer hier mitliest, deinen Fall zur Kenntnis genommen und mit mir darüber per Mail kommuniziert hat. Mit Fernost-Firmen ist das nicht so einfach.

 

 

Nur mal so als Feedback: Die Kombination Unicable-LNB für 4-Teilnehmer, Drehmotor und 4 Digital Devices Tuner funktioniert bei mir absolut problemlos (mit Recording Services). Die Unicable-Konfiguration habe ich in der Treiber-Konfiguration vorgenommen. DVBViewer "weiß" nichts vom Unicable und spricht die 4 Tuner als normalen Sat-Tuner an. Den Fall, dass ich auf zwei Tuner mit unterschiedlichen Positionen zur gleichen Zeit verwenden wollte, hatte ich noch nicht wirklich. Als ich das Mal getestet hatte, war glaube ich der erste Tuner, der aktiv war, der "Master". Da der Fall für mich nicht wirklich relevant ist, habe ich da aber nicht großartig getestet.

Edited September 12, 2013 by DaMickVanHalen

[Griga]

Also frühestens 200ms nach Power-On nimmt der Motor Kommandos an.

 

Also sollte TransEdit vor dem Senden des ersten DiSEqC-Kommandos (einmalig) 250 ms warten. Da die Zeit von der Außenanlage bzw. vom Motor abhängen kann, wäre eine konfigurierbare Lösung gut. Zu beachten ist in diesem Zusammenhang, dass eine 14 <--> 18 V-Spannungsumschaltung ebenfalls ein zu knapp danach folgendes DiSEqC-Kommando sabotieren könnte. Also vielleicht lieber doch vor jedes Kommando eine Verzögerung setzen?

 

Besitzer vonTBS-Geräten an einer Drehschüssel haben ebenfalls von solchen Timing-Problemen berichtet. Hinsichtlich der Spannungsversorgung sind die Treiber ähnlich wie die von TeVii gestrickt. Eine hier getestete TBS USB-Box schaltete jedoch einen DiSEqC-Switch in einer TechniSat Multytenne zuverlässig, ohne dass eine Verzögerung nach dem Einschalten der Spannung notwendig war.

 

Der DVBViewer und TransEdit fügen standardmäßig eine Verzögerung von 100 ms zwischen dem Senden eines DiSEqC-Kommandos und dem Tunen ein (außer bei Unicable, da gelten spezielle Timing-Bedingungen). Wenn ich mich recht erinnere, vermeidet dies ein zu schnelles nachfolgendes Einschalten des 22 kHz-Signals, das früher mitunter Probleme machte. Wer jedoch im DiSEqC Editor eine Sequenz zusammenstellt (DiSEqC = Extended), muss sich selbst um erforderliche Verzögerungen kümmern. In diesem Fall halten sich DVBViewer und TransEdit heraus.

 

Eine ähnliche Vorgehensweise wäre für die Verzögerung zwischen dem Einschalten der LNB-Versorgungsspannung und dem ersten DiSEqC-Kommando denkbar, d.h. ein konfigurierbarer Wert "Start Delay" im DiSEqC Editor, und ansonsten eine Standard-Verzögerung von z.B. 250 ms. Der Nachteil solcher "zur Sicherheit und für alle Fälle"-Defaults ist allerdings, dass sie zwar manchmal berechtigt sind, aber ansonsten die Senderumschaltung unnötig verlangsamen - insbesondere natürlich, wenn der Treiber auch noch verzögert. Deshalb wäre es vielleicht gut, wenn man die Defaults per Tweak ändern könnte.

 

Das grundsätzliche Problem ist hierbei, dass Anwendung und Treiber nicht wissen, was der jeweils andere macht, und beide nur raten können, wie lange die Außenanlage braucht, um nach dem Einschalten der Spannung aus dem Quark zu kommen. Entwickler, die sich darum Gedanken machen, müssen von Annahmen ausgehen, die zutreffen können oder auch nicht