BPanther's Neutrino Forum

Ich habe mit dem Multi-USB aus dem Experimentell die Box über Bank 1 komplett "aufgeräumt".
Das untescheidet sich doch vom hier gewohnten Stand. Wird vielleicht noch etwas dauern, bis ich da entsprechend fit bin.

Mein vorab gesichertes NI habe ich mal wieder in Bank 2 geflasht und den 'fehlenden' Inhalt hinter dem /Common-Link komplett als Verzeichnis ins Root kopiert.

So habe ich einen Vergleich mit Gewohntem.

Kurzer oberflächlicher Erfahrungsbericht:

+ Gut gefällt mir das Datum neben der Uhrzeit im Standby

- Die DiSEqC 2.x Optionen funktionieren auf Anhieb nicht. (Ich werde aber noch Logs machen und auswerten)

- Die Unterscheidung von DiSEqC 1.0 (nur A/A .. B/B) zu 1.1 (nur umcommitted/commited) ist nicht sauber differenziert. => 1.1 entspricht auch 1.0
(Das ist in allen mit bekannten Neutrino-Varianten wohl so)

- Erst die Erweiterte Auswahl stellt dann die eigentliche 1.1 Konfiguration zur Verfügung.
Hier wäre im Prinzio der Platz für komplexere Installationen, Schalter + Motor, mehrstufige Schalterkaskaden, Ku-/Ka-/C - Band ...


Ich werde mich jetzt erstmal ein wenig in die etwas andere Menüstruktur und mir unbekannte Features eingewöhnen.

Gibt es evtl. lesenden Zugriff auf Deinen Experimentell-Source ?
Oder geht das DDT-üblich eh nur mit Patches auf den jeweils aktuellen GIT-Stand ?

Na ja, wenn ich beim Testen echt was brauche, kann ich ja nachfragen...

Janus hat geschrieben: Mo 28. Okt 2019, 17:36Gibt es evtl. lesenden Zugriff auf Deinen Experimentell-Source ?
Oder geht das DDT-üblich eh nur mit Patches auf den jeweils aktuellen GIT-Stand ?

Experimentell entspricht als Basis dem GIT Stand plus meiner eigenen Patches (ich mache einige Sachen anders) und der überarbeiteten Patches von Dir, wobei ich bei letzterem im Bezug auf S2X nochmal was gemacht und neu hochgeladen hatte. Habe beide mal angehangen - das Testmenü ist wie gesagt entfernt bzw. nicht berücksichtigt.

Hast Du aus dem Diff nur meine Änderungen an den Frontend-Dateien übernommen und ansonsten keine Änderungen durchgeführt ?

Im Log sehe ich zwischen den Einstellungen DiSEqC 1.0 und DiSEqC 2.0 keine Unterschiede bei den Umschaltoperationen zwischen DiSEqC 1 und 4
Ich hatte damals auch nur versucht das SlaveReply zu verwirklichen und gezielt den Optionsschalter per 2.0 anzusprechen, um danach die Antwort auswerten zu können.

Da nach den ersten Versuchen keine "Antworten" kamen, habe ich das Ganze gedifft und halt wieder verworfen.
Im Diff stehen also keine umfangreicheren Lösungen, sondern nur ein Einzelfall (2.0 Optionsschalter) der in üblichen Konfigurationen gar nicht erst auftaucht und auch irgendwo separat gecodet war.

Der wirkliche Unterschied zwischen 1.x und 2.x besteht im Framing Byte (S.13 der Bus Spezifikation).
1.x schickt 0xE0 und 0xE1
2.x schickt 0xE2 und 0xE3 und wartet dann auf Antworten mit dem Framingbyte
0xE4 = Okay, keine Fehler
sowie
0xE5 bis 0xE7 = entsprechenden Fehler erkannt, evtl. bitte wiederholen.

Diese Logik muss in alle Kommando-Routinen eingearbeitet werden, für die ein Reply erwartet werden kann.
if timeout = entsprechend reagieren
elseif 1.x konfiguriert => nicht auf Antwort warten, weitermachen
elseif reply 0xE4 => auswerten und weitermachen
elseif reply 0xE5..7 => Fehler auswerten und entsprechend reagieren

In der von mir schon erwähnten Command-Byte Liste in der Bus-Spezifikation (S.15-17) gibt es eine Spalte, in der angegeben ist, welches Command überhaupt ein Reply absetzt und welchen Informationsinhalt man erwarten kann.
Darüberhinaus ist die ganze Frontend-Konfiguration nicht wirklich problemorientiert.
Wie schon gesagt, die Bereichseinteilung von x.0 und x.1 und evtl. x.2 ist für den User nur nachvollziehbar, wenn die seit der DigitalResearch-Box existierenden "Sky-Anforderungen" an die Empfangseinrichtung eingehalten werden.
[==> 1 Satposition - mehr braucht's ja nicht! Für fortgeschrittene Sky-User maximal 4 Satpositionen per DiSEqC 1.0, aber ohne Motorsteuerung]

Die "Erweiterten EInstellungen" ergeben für mich aktuell auch keinen Sinn, das sie irgendwie dann doch DISEqC 1.1 inkl. Motorsteuerung ermöglichen. Ich würde da Lösungen für komplexe Anlagen erwarten, im ersten Schuss zumindestens ein SendCommandString mit entsprechend formulierten Kommando-Ketten.

Vielleicht kann man im Zusammenhang mit einer "Weiterentwicklung" auf DVB-S2X und DiSEqC 2.x mal eine korrekte UseCase-Logik über die Konfiguration legen. Ich habe hier noch irgendwo ein paar Überlegungen dazu archiviert. Könnte ich mal zusammensuchen...

DiSEqC 1.0/1.1/1.2, USALS

da steht nicht davon das die 2.0 oder 2.x kann

He, he
da steht auch nicht, dass die Neutrino kann!

Aber die haben recht, ihr Enigma kann das auch nicht!

Aber im Ernst, DiSEqC 2.x ist ein Feature des S2X-Tuners. (zumindestens auf der HD51)
Ich hoffe, ohne dass ich jetzt den dort verbauten FBC-TwinTunertyp kenne, dass das bei der Duo4K auch so ist...

edit Nachtrag:

aktueller S2X FBC-Twintuner soll ein BCM45308x sein. Bisher kein DataSheet gefunden.

Janus hat geschrieben: Di 29. Okt 2019, 14:35Hast Du aus dem Diff nur meine Änderungen an den Frontend-Dateien übernommen und ansonsten keine Änderungen durchgeführt ?

Sicher, ich habe Dir doch gesagt, daß ich das eh nicht selbst einbauen kann da ich mich damit nicht auskenne. Entsprechend habe ich angenommen, der Patch von Dir ist komplett.

Janus hat geschrieben: Di 29. Okt 2019, 14:35Die "Erweiterten EInstellungen" ergeben für mich aktuell auch keinen Sinn, das sie irgendwie dann doch DISEqC 1.1 inkl. Motorsteuerung ermöglichen. Ich würde da Lösungen für komplexe Anlagen erwarten, im ersten Schuss zumindestens ein SendCommandString mit entsprechend formulierten Kommando-Ketten.

Ist halt im Grunde nur eine Art Diseqc 1.2 bei erweitert.

Janus hat geschrieben: Di 29. Okt 2019, 14:35Vielleicht kann man im Zusammenhang mit einer "Weiterentwicklung" auf DVB-S2X und DiSEqC 2.x mal eine korrekte UseCase-Logik über die Konfiguration legen. Ich habe hier noch irgendwo ein paar Überlegungen dazu archiviert. Könnte ich mal zusammensuchen...

Ich würde mich erstmal auf eines konzentrieren, damit das läuft, denn die beiden sind ja nicht von einander abhängig. Funktioniert denn zumindest erstmal S2X?

nur eine Art Diseqc 1.2 bei erweitert

Goto-RotorIndex und Goto-Position (USALS) lassen sich sowohl unter 1.0 als auch unter 1.1 konfigurieren und funktionieren dort auch (oft).

Ein paar S2X-Sachen (16APSK und 32APSk, eigentlich noch S2) habe ich damals ohne jede Vorlage reingeschrieben, in der Hoffnung für die Treiber die richtige Enumeration genommen zu haben. Ich fürchte, das war auch nicht korrekt. Den damals einzigen 16APSK-Sender habe ich damit nicht tunen können.

Und an die vielen FECs habe ich mich dann nicht mehr rangetraut. Aber in dem BlackHole-Git sind die ja anscheinend eingearbeitet. Ob richtig ? Keine Ahnung.

Ich werde mich da wohl erst wieder mit der Duo4K beschäftigen. Vielleicht läuft da ja eine Enigma-Variante mit dem S2X-Tuner auch für S2X - Transponder.

Ich habe bei S2X noch einiges an der Reihenfolge gemacht, damit die zum Kernel passt, denn das kennt S2X bereits durch die Kernel-Patches. Aber keine Ahnung was das BackHole GIT sein soll...

Janus Beiträge sind schwer zu lesen. Viel klimbimm aber um was es geht - keine Antwort dazu

die Frage lautete ob s2X klappt ja nein

am besten mit ukraine auf 4,8 testen, das ging aber mit neutrino gitstand schon -denn ich hatte das von ukrainern und Russen testen lassen mit HD51 und Spark sh4 7111

Auf 9E finden sich auch einige, aber da mein Motor derzeit spinnt, kann ich das nicht testen. Ich habe den aktuellen S2X Stand mal ins GIT mit gepackt, die restlichen FEC kommen dann später. Es machen sich dann so sicherlich nachträgliche Änderungen einfacher. Derzeit wird anscheinend meist PSK_8 benutzt.
BTW: PSK_8 <-> APSK_8. Das Kernel kennt einen Unterschied und hat dafür separate Einträge, daher habe ich die ebenfalls gemacht. Ob das in der Praxis wirklich einen Unterschied macht sei mal dahingestellt. Die höhreren (64/128/256) sind im Kernel allerdings nicht vorhanden.

Hier mal der 4.10er Kernel, (HD51)
https://www.kernel.org/doc/html/v4.10/m ... ntend.html

Linux Kernel: include/uapi/linux/dvb/frontend.h

Dort muss es drinne sein sonst nützt das auch in Neutrino/E2 nix, deswegen hatte ich das auch damals nicht alles eingebaut.

Alternative für ältere Kernel: einen backport patch erstellen (betrifft die includes und die eigentlichen tunertreiber) - wobei selbst in den aktuellen Kerneln nicht alles unterstützt wird.
https://git.kernel.org/pub/scm/linux/ke ... h=v5.4-rc5

Richtig, und bei den VU+ ist das im Kernel 3 und 4 per Patch enthalten:
https://github.com/Duckbox-Developers/b ... bs2x.patch
https://github.com/Duckbox-Developers/b ... bs2x.patch

Kann man sicherlich auch für die HD51 so übernehmen wenn dort noch nicht vorhanden.

EDIT: Habs mal für die HD51 aus dem VU+ Patch angepasst und ins GIT hinzugefügt...
https://github.com/Duckbox-Developers/b ... 7d0328c4a7

Ich baue derzeit MIPS/ARM durch (also HD51 und VU+) und lade das dann normal als Update rev18072 hoch - Experimentell ist dann erstmal wieder leer. Dann können andere das mit dem S2X auch ggf. mal testen. Bei der HD51 kam in diesem Zusammenhang auch noch der Kernelpatch zu S2X hinzu - der fehlte da nämlich noch.

Ich habe mal auf 33 Ost (Eutelsat 33) mit der 18072 das Scannen unter dem Gesichtspunkt MultiStream und S2X kurz angetestet.
(mit der AX HD51)

Generell:
Wenn ich in der "Manueller Frequenzscan" die grüne Taste (== Kanalsuche starten) drücke, springt das Ganze wieder auf die Konfiguration des EInzeltransponders zurück. Sämtliche Änderungen die vor der grünen Taste gemacht wurden, sind verworfen. Da ich vom NI die grüne Taste gewohnt bin und die Farbe (blau) hier auf dem kleinen Icon nicht wirklich von grün zu unterscheiden ist (Rentner, 'gedeckte' Farbeinstellung am TV) liegt der Fehler bei mir.

Btw.:Ich hatte das mit den Farben und Bezeichnern in dem Bereich Sendersuche mal vereinheitlicht.
Falls daran hier ebenfalls Interesse besteht, kann ich den Patch auch mal hochladen.

Wenn ich in dieser Transponderkonfiguration DVB-S2X einstelle, kann ich zwar zusatzlich 8~, 16~ und 32APSK einstellen, die X-FECs oberhalb von 9/10 lassen sich aber nicht auswählen.

Der S2X Transponder 12597 V mit FEC 25/36 lässt sich dann nur über DVB-S2 und FEC=Auto scannen. Mit Erfolg!
Stelle ich statt DVB-S2 aber DVB-S2X und Auto ein, scheitert sowohl der Empfangstest als auch die Kanalsuche.

Der Multistream-Transponder auf 12646 H wurde mit den - auf KingOfSat - korrekten PLS-Werten sauber gescannt.

Beide "speziellen" Scans führen zu darstellbaren, unverschlüsselten Sendern.
Einen Test auf Astra 5 habe ich abgebrochen, weil der Scan der 32APSK-Transponder nur zu "Kanalsuche fehlgeschlagen" führte.
Da ich das 32APSK nur über die EInstellung DVB-S2X erreichen kann und die Transponder dazu noch als "leer" geführt sind, konnte ich nicht entscheiden, ob da ein Fehler vorlag.

Ähmm... Ich habe nicht gesagt, daß ich die "hohen" FEC schon mit eingebaut habe, das kommt erst noch. Da muß noch einiges hinzugefügt werden -und das in der richtigen Reihenfolge wie sie im Kernel auch vorhanden sind.

Aber schon schön zu hören, daß das mit den Streams ansich schonmal funktioniert. Heißt, wir sind auf dem richtigen Weg.

Zu den Farbtasten: Ich finde die so schon ganz OK wie sie sind. Allerdings hast Du natürlich recht, was die Auto-Suchen betrifft, da müsste es dann auch blau sein für die Suche. Das sollte man noch anpassen.

EDIT: Farbe sollte nun mit blau überall beim Scan Start passen (im GIT eingecheckt). Deswegen baue ich aber nicht nochmal neu durch.