Beiträge von HelmutB

    Hallo,

    wenn man sich die Daten der TS-Null Pakete ansehen könnte, hätte man vielleich einen Hinweis auf dei Quelle.

    Hier eine Erweitern der MTD Fehlermeldung in der originalen mtd.c :

    Die ersten 8 Bytes werden dabei nach der Pid als zwei 32-Bit Werte ausgegeben.

    Vielleicht willst du das einmal probieren.


    Helmut

    So, hier nun mein Patch für die Erweiterung von GetSignalQuality() und GetSignalStrength().

    (Ich hab den Titel etwas angepasst).


    Die Abfrage des Frontend für die tatsächlich verwendeten Werte von Modulation und Coderate erfolgt nun direkt in in diesen Funktionen, die channels.conf wird nicht mehr modifiziert.


    Zwei Anmerkung:

    Der für den SignalStrengthIndicator (SSI) erforderliche dBm-Wert wird leider von den wenigsten Treibern geliefert, diese Funktion wird daher fast nie verwendet.


    Beim SignalQualityIndex (SQI) wird bei DVB-T und C auch die Bitfehlerrate berücksichtigt.

    Bei einigen - oder eigentlich den meisten - Treiber die ich angesehen habe werden die Bitfehler aber bei jeder Abfrage aufsummiert - d.h. der Wert geht nie auf 0 zurück und die BER ist damit nicht wirklich brauchbar,

    Ich habe ein #define IGNORE_BER eingefügt, bei setzen auf 1 wird der BER-Wert vom Treiber ignoriert.


    Ich kann kein DVB-C testen, bei Terr. und Sat sind die angezeigten Werte plausibel, eher zu gut - also meistens über 90%.

    Vielleicht will den Patch wer testen und die Ergebnise hier kundtun.


    Helmut

    Well, you were referring to Nordig standard earlier.

    Yes, but only to explain from where i have my "wisdom". In the meantime i understand your generally reminder about Nordig. Thank you.

    such calculations require for terrestrial transmissions a few design choices which are specific to local requirements.

    Sounds more complicated than i thought (and looks so easy at Nordig).


    Anyway, as the current vdr supports DVB API 5 (i upgraded from vdr-2.2.0 only 2 or 3 month ago) i thought it was the right time to implement more general and hardware independent SSI/SQI indicators. But the missing, but required transponder parameters for DVB-T2 leaded to the start of this thread.


    Is it usus to remove improper attachments from the thread or can they still remain?


    Helmut


    BTW: if Rolf does'n mind, we could switch back to german.

    Hallo wirbel,

    Rolf is absolutely correct here,

    yes, my fault - i should have (re-)read the vdr documentation before asking questions.

    But is the SSI/SQI representation really country-specific? And if, is there any DVB complient way to do this?

    Implementing such a behaviour in VDR that may use *wrong* tuning settings may break tuning or cause undefined behaviour.

    You are right. I only checked the T2 drivers in the current kernel sources. That is a too simple sight.

    It is the best i leave channel config untouched and implement the FE_GET_PROPERTY ioctl's at the places where they are needed.


    Thank's for your explanations.

    Helmut

    ...and a reminder that any Nordig specific implementation should be hidden behind a proper standard compliance: Setup.StandardCompliance==STANDARD_NORDIG

    May be a dumb question (i do not have much knowledge of compliance regulations) - what should be the meaning of this setup entry and why should it be implemented ? Is the intension to conditionaly execute some parts of code or is it only informational ?

    As far as i know this is an open Standard and free to use.


    Beside this, only the usage of some code-fragments or algos does not automaticaly make it complient to anything. So this setup entry could be missleading.


    Helmut

    Wenn die tatsächlichen Werte nur für die Berechnung der Signalstärke und -qualität benötigt werden, dann wäre es doch sinnvoller, diese in den Funktionen cDvbTuner::GetSignalStrength() bzw. cDvbTuner::GetSignalQuality() zu holen, oder?


    Ja natürlich, es würde dafür vollkommen genügen.
    Der Vorteil die tatsächlich eingestellten Parameter "permanent" in die Kanalliste zu übernehmen ist für mich der, dass man z.B. über femon-plugin diese Info auch angezeigt bekommt.


    Die aktuellen DVB-T2 Teiber verwenden übrigens nur die Parameter "Bandbreite" und "Stream-ID", alle übrigen Einstellungen werden offenbar vom Demodulator direkt aus dem TS-Signal ermittelt und ev. vorhandene Einträge in der channels.conf haben auf das Tuning keinen Einfluss.


    Helmut
     

    Das ist der Treiber für die schon ältere Cine Dual -S2 PCI Sat-Karte mit unterstützung für ein Digital-Devices CI-Interface (über caX und secX).

    Soweit ich den Treiber verstehe:

    Das schreiben zum CI-Interface erfolgt immer mit genau 4096 TS-Paketen. Wenn im TSout-Buffer nicht genügend Pakete vorhanden sind wird mit TS-Null Paketen aufgefüllt, diese Null-Pakete haben eine beondere Kennung am Datenblock - 0x6F.

    Beim Lesen vom CI werden diese selbst generierten Null-Pakete dann wieder verworfen.

    Warum es genau 4096 Pakete sein müssen ist mir nicht ganz klar, ich sehe nur das die TSin/TSout Ringbuffer auch 4096*188 bytes groß sind.


    LG

    Helmut

    Da hast du natürlich recht - es war dann doch schon zu spät um noch klar zu denken.


    Es hätte das Problem aber eh nicht gelöst, da die selbst erzeugten Null-Pakete ja von tsin_exchange() wieder entfert werden und es keines bis zum VDR schaffen sollte.


    Man müsste sich in mdt.c beim einer PID von 0x1FFF das 5. Byte des Pakets ansehen - bei enem Wert von 0x6F würde kommt es definitiv vom ngene Treiber - aber wie ?


    LG

    Helmut

    Ich habe zwar keine entspechende Hardware, aber wenn ich den ngene-Treiber richtig lese werden die

    TS-Null Pakete in ngene-core.c von der Funktion "FillTSBuffers()" erzeugt.


    Diese Funktion wird einerseits von "clear_buffers(struct ngene_channel *chan)" zum initialisieren der Ringbuffer aufgerufen, zum anderen wird sie in ngene-dvb.c von "tsout_exchange(void *priv, void *buf, u32 len, u32 clock, u32 flags)" zum Auffüllen eines TS Buffers bis zur gewünschten Größe verwendet bevor dieser dann zum CI gesendet wird.


    Die Funktion "tsin_exchange(void *priv, void *buf, u32 len, u32 clock, u32 flags)" versucht dann die TS-Null Pakete die vom CI

    kommen wieder zu entfernen.


    Hier die Funktion FillTSBuffer, die den Buffer zuerst mit dem Wert 0x6F (TS_FILLER) füllt und dann in gewissen Abständen des 4-byte TS-Null Header 0x47, 0x1F, 0xFF, 0x10 einfügt.


    Hier kommt mir allerdings seltsam vor, dass der Pointer für den TS-Null Header um 188/4 - also 47 bytes verschoben wird, der Längenzähler aber um die Länge eines ganze TS-Pakets mit 188 bytes verringert wird..

    Das würde bedeuten, das nur das 1. Viertel der erzeugten TS-Null Paktete eine gültigen Header hat, der Rest besteht nur aus den Werten 0x6F die tsin_exchange() dann nicht als Null-Paket erkennt und durchlässt.


    Falls jemand den Treiber verwendet, ev. könnte ein "ptr += 188;" etwas verbessern.

    LG

    Helmut

    Hallo Klaus,

    Welchen Vorteil bringt denn dieser Patch in der Praxis?

    Ich verwende Modulation und Coderate/FEC für die Ermittlung der Referenzwerte zur Berechnung von SIgnalstärke und Signalqualität nach dem Standard von Nordig an den sich offensichtlich auch viele Hersteller von DVB-Receiver halten.

    Ein Wert von "auto" hilft hier nicht.


    Hier die Dokumentation: https://nordig.org/specifications/

    Die Berechnung für DVB-T/T2 ist ziemlich einfach und ich habe es bei mir mit einem Patch im VDR-2.3.8 eingebaut.

    (Ich verwende aber nur die SSI genau nach Nordig, den SQI habe ich etwas "gespreizt", da er sonst eigentlcih immerl 100% anzeigt).

    Wenn die betreffenden Daten nicht in der NIT drin sind, und man diejenigen, die momentan tatsächlich verwendet werden, in die channels.conf einträgt, läuft man dann nicht Gefahr, den Kanal nicht mehr tunen zu können, wenn der Sender einen Parameter verändert, ihn in der NIT aber weiterhin nicht angibt?


    Hier hast du vielleicht nicht unrecht - und ich hab ehrlich gesagt an diese Möglichkeit gar nicht gedacht.

    Das würde aber umgekehrt bedeuten, das alle Parameter die nich in der NIT sind bei DVB-T2 immer auf "auto" gesetzt sein müssten.

    ---

    Ich zuvor versucht meinem Astrometa DVB-T2/DAB USB-Stick zu verwirren und die Parameter von Modulation, Coderate, Inversion auf verschiedeste unmögliche Werte gesetzt.

    Zu meiner Überraschung hat das aber keine Auswirkung, es gab immer wieder einen Lock auf den Sender. Ich nehme an, das der Demodulator von sich aus versucht die richtigen Parameter zu finden. und daher wären Änderungen durch den Provider auch ohne Folgen. Vielleicht kann das jemand mit anderer Hardware auch bestätigen.
    ---

    Ich habe den Patch übrigens etwas adaptiert - er werden nur Sender mit der gleichen Stream-Id aktualisiert.

    Vielleicht sollte die Aktualisierung auch nur ausgeführt werden, wenn Setup.UpdateChannels > 5 ist.


    Helmut

    Macht es nicht Sinn so etwas bei vdr-developer zu posten zum übernehmen?

    Hallo Stefan,

    was meinst du mit "posten" ? Das femon-plugin habe ich auf https://projects.vdr-developer.org/git/ nicht gefunden.


    Das Repository vom Entwickler Rolf Ahrenberg ist hier: https://github.com/rofafor/vdr-plugin-femon

    Er ist ja als User "rofafor" gelegentlich auch hier im Forum unterwegs, vielleicht findet er den Patch brauchbar und übernimmt Ihn.


    Schönen Abend noch, Helmut

    Hier ein kleiner Patch für das femon-plugin, das bei DVB-T/T2/C die dazugehörige Kanalnummer neben der Frequenz anzeigt.

    Es geht den umgekehrten Weg wie w_scan und ermittelt aus Source, Frequenz und Bandbreite das Frequenzband und dann aus den daraus möglichen Basisfrequenzen die Nummer.

    Es sollte für alle Frequenzen und Regionen funktionieren, die w_scan (mit Stand 2016) verwendet.

    Dieser Patch war für femon-2.2.1 geschrieben, lässt sich aber auch auf femon-2.3.0 (femon-master) anwenden.


    femon-2.2.1_02_TC_ChannelNumbers.patch

    Hier in Österreich werden bei einigen Transponder in der NIT falsche Angaben zur PLP-Id geliefert (0 statt 1).

    Da VDR die Stream-Id anhand dieser Info in der Kanalparameter aktualisiert, kann derSender danach nicht mehr empfangen werden.


    Hier ein Patch mit dem VDR nur eine Meldung ausgibt, die aktuell verwendete Stream-Id aber unverändert lässt.

    Betrifft (natürlich) DVB-T2 - ich habe es im Titel ergänzt.

    Hier nun der aktualisierten Patch nach.

    Funktioniert bei mir nun auch mit Update der channels.conf (wird nach 10 Minuten geschrieben).


    wirbel - bei SETCMD() und dem ioctl FE_GET_PROPERTY genügt 0 als Parameter. Der Treiber überschreibt diesen wert immer mit dem Wert aus seinem dtv_property_cache.

    Auf die Kanalliste greife ich mit GetChannelsWrite() zu - so wie es z.B. auch in nit.c geschieht.


    Auch wird nur die Kopie im aktuellen Device aktualisiert da das erste Device, das den Lock auf einen Tranponder bekommt sofort die Parameter aktualisiert. Eigentlcih kann dann kein ein weiteres Device alte Werte haben (Ok - theoretisch schon, nämllich wenn das als erstes auf den Tranponder zugreifende Device den Lock erst nach einem zweiten bekommt - eher unwahrscheinlich aber auch kein wirkliches Problem).


    Ein zweiter Patch ist für den Kerneltreiber des si2168 damit die Paramerter dort auch wirklich aktualisiert werden.

    Den brauche ich für meinen August T230 Stick.

    Hallo wirbel,

    danke fürs drüberschauen.


    Einen verständlicheren Funktionsnamen kann man sicher wählen.

    Das mit der lokale Kopie habe ich auch vermutet, nur - wie bekommt man das dann in die aktuelle (interne?) Kanalliste?

    Ich habe es gestern Abend nicht mehr durchschaut, wahrscheinlich war es schon zu spät.


    Die Stelle des Aufrufs sollte schon passen - es gibt hier ja den FE_HAS_LOCK. Was ich hier vor dem Aufruf prüfe ist, ob ich vom tunerStatus 'tsTuned' durchgefallen bin oder ob er vorher schon 'tsLocked' war. Nur beim Übergang von Tuned zu Locked werden die Frontend-Parameter abgefragt. Also genau einmal entweder nach einem Kanalwechsel oder wenn ein verlorengengener Lock wieder hergestellt wurde.

    In meiner channels.conf sind bei den DVB-T2 Sendern die Transponderdaten z.B. für Modulation, Inversion und Coderate(FEC) immer noch so eingetragen wie sie von w_scan beim Sendersuchlauf als default verwendet wurden, also QPSK, INVERSION_AUTO oder FEC_AUTO.

    Wenn ich es richtig sehe, werden diese Werte von vdr nicht aktualisiert, weil sie in der NIT für DVB-T2 einfach nicht vorhanden sind.


    Meine Idee ist nun, sich diese fehlenden Angaben nach einem erfolgreichen LOCK direkt vom Frontend zu holen.


    Dazu habe ich in dvbdevice.c eine Funktion GetFrontend erstellt in der diese Daten mit FE_GET_PROPERTIES abgefragt werden und dann mit channel.SetTransponderData übernommen werden sollten.


    Dem ist aber leider nicht so. im Log sehe ich zwar die Aktualisierungsmeldung mit Alt-Neu, aber im Kanal-Editor oder vdr-femon sind die Werte unverändert, in der channels.conf sowieso.

    Meine C++ Kenntnisse sind eher bescheiden, und vielleicht bin ja auch ganz auf dem Holzweg.

    Hier der Code als Patch:

    Falls jemand dazu eine Idee oder bessere Lösung hat wäre ich dankbar!


    Helmut

    So, hier nun der Quellen für den Kerneltreiber.

    Es ist der Stand von Vorgestern, ich habe nur ein paar nicht verwendete Codeblöcke entfernt.

    Ich habe es auch noch einmal kurz getestet - das Umschalten von FTA zu verschlüsselt funktioniert eigentlich zuverlässig, aber genau so zuverlässig kommt es beim Zurückschalten im Control-Interface (ca) zu einem USB Timeout - immer beim Versuch von VDR die entsprechende CA_PMT Nachricht zu senden.

    Der Treiber ist noch sehr unfertig und hat sicher noch mehr Fehler als den oben beschriebenen.

    Er loggt auch relativ viel mit - das kann man derzeit nicht global ausschalten, nur an den entsprechenden Stelen auskommentieren.

    Mir ist eigentlich auch nicht ganz klar wo und wie ich die verschieden „locks“ und „waits“ richtig verwende. Vielleicht liegt es auch daran.

    Auf jeden Fall war aber selbst überrasche als ich plötzlich ein klares Bild bekommen habe.


    Vielleicht hat dazu irgendjemand eine Idee oder Anregungen.

    LG

    Dateien

    • WinTV-CI.tar.gz

      (101,48 kB, 21 Mal heruntergeladen, zuletzt: )

    Nach den Anfängen mit Perl-Scripten habe ich Sommer begonnen daraus einem Kernel Treiber zu basteln.

    Mit Hilfe des vdr-plugin-ddci2 ist es mit heute tatsächlich gelungen die HD-Programme des ORF über DVB-T2 auf meinem alten Notebook unverschlüsselt wiederzugeben.

    Der Treiber ist noch ziemlich instabil, z.B. beim Senderwechsel kommen unkorrigierbare USB-timeouts beim ca-device, aber grundsätzlich scheint es zu funktionieren.


    Ich habe jetzt nur ein paar screenshots, den Code werde ich morgen oder übermorgen hochladen.


    Die verwendete Hardware:

    Sony Vaio-SZ 1,6 Ghz, August T230 DVB-T2 USB-Stick mit Miniantenne, Wintv-USB-CI Adapter und ein SimpliTV CA-Modul.


    Falls jemand den USB-Ci Adapter nicht kennt - hier ein alter Artikel aus 2007

    https://www.pcwelt.de/news/Pay…-von-Hauppauge-80727.html

    oder hier (PDF)

    http://terratec.ultron.info/Re…_USB_TechnicalData_DE.pdf


    Vielleicht wäre dieses Thema nun in VDR-HArdware/Allgemein besser aufgehoben.