Schlechter Empfang der TT C-1500 im Vergleich zur Satellco EasyWatch PCI DVB-C

  • So, habe mal ein wenig gelauscht..


    Win XP, BDA APP, Aktionen gemäss Work Log
    Mein Kabelprovider ist nicht Cablecom, sondern Renet/Quickline. Darum habe ich die meisten Kanäle unverschlüsselt.


    Work log .txt - was wurde wann gemacht
    log.txt - sniffing mit i2cmon von e9hack

    Dateien

    3 Mal editiert, zuletzt von Hein Blöd ()

  • Zitat

    Original von Hein Blöd
    So, habe mal ein wenig gelauscht..


    Win XP, BDA APP, Aktionen gemäss Work Log
    Mein Kabelprovider ist nicht Cablecom, sondern Renet/Quickline. Darum habe ich die meisten Kanäle unverschlüsselt.


    Work log .txt - was wurde wann gemacht
    log.txt - sniffing mit i2cmon von e9hack


    Ich habe mal einen Blick drauf geworfen. Was sofort auffällt, der Tuner wird anders programmiert. Im Log steht:


    Die Charge-Pump (rot) wird anders initialisiert. Bei 394MHz (VHF high) wird nach ca. 70ms der Wert geändert. Bei 450MHz (UHF) bleibt der Wert gleich. Das Bandwidth-Bit (blau) wird bei jedem Programmieren vom Tuner invertiert. Da es bei DVB-C eigentlich nur 8MHz-Bandbreite gibt, sollte der Wert eigentlich konstant sein.


    Das Auswerten der Initialisierung vom stv0297 wird eine kleine Weile dauern.


    Gruß
    e9hack

  • Zitat

    Original von e9hack


    Nach dem Log hat es nur nach diesem (letzten) Zugriff auf den Tuner einen Lock gegeben. Da ist das Bandwidth-Bit nicht gesetzt. Der Linux-Treiber setzt das Bit immer.


    Gruß
    e9hack

  • Soll/kann ich noch etwas testen?
    Sind die Werte anders als bei dir mit Win 2k?

    Einmal editiert, zuletzt von Hein Blöd ()

  • Hi,


    ich habe das Log-File für Frequenz 450MHz analysiert. Es gibt geringfügige Unterschiede zum Linux-Treiber. In der Init-Tabelle sind zwei Byte anders initialisiert:


    Wenn ich das bei meiner TT C2300 anwende, empfängt die nichts mehr. Der Ablauf bei der Initialisierung des Demodulators ist geringfügig anders:


    Wenn ich das bei der TT C2300 anwende, sehe ich keine Änderung bei den BER-Werten. Ein weiterer Unterschied gibts bei der Programmierung des Tuners. Um bei 450MHz einen Lock zu bekommen, waren zwei Anläufe notwendig. Der 1. war mit Inversion = Off, der zweite mit Inversion = On. Gleichzeitig wurde beim zweiten Versuch das Bandbreiten-Bit für den Tuner geändert. Ich weiß nicht warum das gemacht wird. Mit Inversion On/Off hat das nichts zu tun.

    Diff
    --- a/linux/drivers/media/dvb/ttpci/budget-ci.c Thu Oct 18 16:25:58 2007 -0200
    +++ b/linux/drivers/media/dvb/ttpci/budget-ci.c Sun Oct 21 18:21:49 2007 +0200
    @@ -937,7 +937,7 @@ static int dvbc_philips_tdm1316l_tuner_s
                    return -EINVAL;
    
    
            // assume PLL filter should always be 8MHz for the moment.
    -       filter = 1;
    +       filter = 0; //??????????????????


    Gruß
    e9hack

  • Und jetzt? Kann ich hier noch etwas testen? Parameter im Treiber ändern und testen?


    Mir ist noch eine Sache unter Win aufgefallen. Das Bild ist ohne Artefakte, aber hin und wieder sind Frame dropes. Das Signal scheint auch unter Win grenzwertig zu sein. Da muss das Signal mal angehoben werden ;)


    Ich wollte mir die Tage noch einen Verstärker (0-20 dB) für die Hausverteileranlage besorgen. Soll ich da die Win Tests noch einmal wiederholen?

    Einmal editiert, zuletzt von Hein Blöd ()

  • Habe gerade probiert die neusten Treiber Sources (v4l-dvb) zu laden. Nach dem Laden bekomme ich beim make zwei Fehler, weswegen make install nicht laufen möchte. Hat da einer einen Tipp:
    hg clone http://linuxtv.org/hg/v4l-dvb
    cd /v4l-dvb
    make


    =>
    /v4l-dvb/v4l/saa7134-tvaudio.c:30:27: error: linux/freezer.h: No such file or directory
    make[3]: *** [/v4l-dvb/v4l/saa7134-tvaudio.o] Error 1
    make[2]: *** [_module_/v4l-dvb/v4l] Error 2
    make[2]: Leaving directory `/usr/src/linux-headers-2.6.18-4-486'
    make[1]: *** [default] Fehler 2
    make[1]: Leaving directory `/v4l-dvb/v4l'
    make: *** [all] Fehler 2
    vdr:/v4l-dvb#



    make install
    =>
    strip: supported targets: elf32-i386 a.out-i386-linux efi-app-ia32 elf32-little elf32-big elf64-x86-64 elf64-little elf64-big srec symbolsrec tekhex binary ihex trad-core
    make[1]: *** [media-install] Fehler 1
    make[1]: Leaving directory `/v4l-dvb/v4l'
    make: *** [install] Fehler 2
    vdr:/v4l-dvb#


    Und nun?

    Einmal editiert, zuletzt von Hein Blöd ()

  • hallo e9hack,


    können deine Patchs mein Problem mit der Umschaltzeit lösen?
    Dann würde ich diese auch ausprobieren.


    Könntest du vllt. die geänderten Dateien anhängen?
    Hab so meine Probleme mit dem Patchen ;)


    PS.: Um die Patchs einzubauen, muss man doch immer neuen Kernel bauen, oder geht es irgendwie einfacher/schneller?


    Gruß

  • du brauchst keinen neuen Kernel. Aber würde mich wundern, wenn du bei dem kompilieren weiterkommst als ich - siehe Thread oben.

  • Gratulation.


    Auch du hast die neue Revision und die macht Stress. Darum machen wir hier ja die ganze Arbeit. Ich habe die gleiche Karte

  • Naja, ich habe ja noch das Glück, dass die Bildqualität sehr gut ist. Es sind halt die Umschaltzeiten bei QAM256 Sendern. Die machen das Zappen unmöglich und den VDR nicht Wohnzimmer tauglich :-/

  • Wow!


    Grad neuen Kernel mit dem zweiten Patch fertig gebaut, installiert, und siehe da...
    Umschaltzeiten bei ca. EINER Sekunde! :D


    Also ich bin fürs Erste sprachlos. Das muss erstmal mit einem Bier begossen werden ;)


    Ein riesengroßes Dankeschön an e9hack!!


    Wenn ihr was von mir braucht, logs usw, einfach bescheid sagen.


    PS: Bei dem ersten Patch habe ich keinen Unterschied feststellen können

  • Zitat

    Original von VladOs
    Grad neuen Kernel mit dem zweiten Patch fertig gebaut, installiert, und siehe da...
    Umschaltzeiten bei ca. EINER Sekunde! :D


    Ich glaube nicht, das der gesammte zweite Block in Summe notwendig ist. Kannst Du das nochmal zeilenweise einbauen und testen?


    Gruß
    e9hack

  • Habe alle Änderungen an den Sourcen nachgeführt - ab Seite 5 hier. Beim make läuft er wunderbar durch. Make install ebenso wunderbar. Aber das Bild bleibt schwarz (Video der C-Karte). OSD der FF Karte ist wunderschön. Aber an den stv0299 Settings habe ich nichts verändert.


    e9hack
    Den prinktk... (Debugging Info) kann ich wohl einfach rauslöschen?


    VladOs
    Kannst du mir deine Sources V4l zum kompilieren schicken?

  • Auch nach Entschlackung und neuem make und make install hat sich am schwrzen Bild nichts geändert. Aber SNR ist geringfügig besser geworden 12-15%. STR auf allen Kanälen 0%. Was habe ich jetzt ieder getan? Wo liegt der Fehler?

  • Wie gesagt, ich habe den Kernel neu gebaut mit dem zweiten Patch


    e9hack
    Dürfte sehr aufwendig sein zeilenweise zu testen. Da muss ich mich erst mit der anderen Methode vertaut machen.


    Hein Blöd
    Die Sources von V4l hab ich gar nicht angerührt. Ich habe mir die Linux-Source-2.6.22 gezogen, Patch eingebaut und neuen Kernel gebaut.

  • Ich habe wieder Bild (ungepatchter Treiber). Werde heute Abend mit gepatchtem Treiber weiter testen. Versuche mich mal durchzuarbeiten (Zeile für Zeile).

  • Ich habe nur wieder ein schwarzes Bild. EPG kommt rein. Signalanzeige auch. Video- & Audiodatenstrom teilweise 0. Ich habe wohl nicht den richtigen Kernel um weiter mitzutesten. Man kann nur hoffen, dass der nächste CT Kernel demnächst erscheint.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!