2 Fehler im Treiber des Tuners CU1216Mk3

  • Hallo Leute!


    Mir ist aufgefallen, dass der Kabeltuner cu1216mk3 auf einigen Kanälen falsche Frequenzen zurückliefert. Meistens beträgt der Fehler über 8,3 MHz.
    In der Logdatei "messages" finden sich auch dazu passende Zeilen:

    Code
    Jun 11 17:02:59 dm7020hd user.info kernel: [ 9569.877000] tda: afc=5 (8321225 Hz)


    Um das weiter zu erforschen, habe ich ein kleines C-Programm geschrieben, das den Tuner auf Frequenzen von 329 bis 331 MHz mit einer Schrittweite von 62,5 kHz einstellt und dabei jeweils das AFC-Register des Tuners ausliest. Hier ist das Ergebnis:


    Das Programm zeigt in den ersten Zeilen die Eigenschaften des Tuners an und dann alle Frequenzen in kHz, bei denen er synchronisiert hat. Die erste Zahl ist die zum Tuner gesendete Frequenz, die Zahl dahinter die vom Tuner zurück gelieferte. Diese zweite Zahl müsste immer 330000 sein, wenn im Treiber die Berechnung des Frequenzversatzes richtig funktionieren würde. Die Formel ist: Frequenz Offset = (AFC * Symbolrate) / 512.
    Schlimmer ist aber, dass der Tuner im Bereich zwischen 329 und 330 MHz überhaupt nicht synchron wird. Das könnte das Problem des Users amir_333 hier erkären, wenn die Oszillatorfrequenz in seinem Tuner geringfügig niedriger wäre als bei mir. Ein solcher Tuner würde nicht synchronisieren, wenn er auf genau 330 MHz eingestellt wird, denn durch die Toleranzen des Quarzes wäre er dann ja tatsächlich etwas darunter!
    In der Logdatei findet sich dieses:


    Dann habe ich in mein kleines Programm diese Zeile eingefügt.

    Code
    ioctl(fd, FE_SET_FRONTEND_TUNE_MODE, FE_TUNE_MODE_ONESHOT);


    Jetzt synchronisiert der Tuner fehlerfrei auf allen Frequenzen.
    Der Tuner ist also völlig in Ordnung. Dies ist aber nicht der normale Betriebsfall in Enigma2.
    In diesem ONESHOT-Modus werden keine Tuner-Parameter zurück geliefert. In der Logdatei wird auch nichts gespeichert.

  • Hi,


    Die neuen Treiber vom 12.6.2015 haben leider nichts geändert, die Fehler sind noch da.
    Um die Ursache für die erfolglose Synchronisierung unterhalb der Mittenfrequenz zu ergründen, habe ich in mein kleines ONESHOT-Testprogramm noch die Zeit eingebaut, die es zur Synchronisierung braucht. Der Status wird alle 10 ms abgefragt. Die Zeitangabe ist in Millisekunden. Wie man sieht, braucht der Tuner unterhalb der Mittenfrequenz etwas länger, warum auch immer.


    Offensichtlich wird der Tuner im Normal-Modus durch den Kernel gestört, bevor er die Synchronisation erreichen kann. Ich würde an Eurer Stelle versuchen, im Treiber in der Funktion "get_tune_settings" die Variable "min_delay_ms" auf einen ausreichenden Wert zu setzen.
    Den AFC-Fehler habe ich in cu1216mk3.ko gefunden. Ihr habt da (x / 512) durch (x >> 9) ersetzt. Leider ist x bei Euch wohl unsigned. Aus einer kleinen negativen Zahl wird so eine sehr große positive. Nachdem ich den Maschinenbefehl "srl $s1,$s1,9" durch "sra $s1,$s1,9" ersetzt habe, wird jetzt immer die richtige Frequenz von 330000 kHz zurückgeliefert.
    In Enigma2 wird jetzt aber aus 331 MHz immer 329 Mhz, keine Ahnung warum. In den original Linux-Quellcodes gibt es auch einen Treiber für tda10023. Dort wird 10 Bit geschoben. Das habe ich in cu1216mk3.ko dann auch so eingebaut. Jezt stimmt die Anzeige in Enigma2. Scheinbar darf man den Frequenzfehler nur halb korrigieren.


    PS: In allen Treibern ist jetzt zu lesen "license=GPL". Ist das Absicht oder ein Versehen?
    MfG,
    Hein

    • Offizieller Beitrag

    Hi,


    wir hatten da bisher nichts gemacht an dem Treiber. Deshalb kann sich da auch nichts geändert haben.


    Also nach meinen Recherchen handelt es sich aber eh momentan nur um einen reinen Anzeige Fehler. Also das ganze wird nur beim benutzen von get_property oder get_frontend falsch berechnet. Beim reinen tunen spielt das keine Rolle.
    Und da wir die zurückgelesenen Daten auch nicht abspeichern sollte es eigentlich egal sein. Außer ich hab was übersehen.
    Da das ganze nun aber auch schon mehrere Jahre kaputt ist kommts auf nen paar Tage/Wochen dann auch nicht mehr an. Abgesehen davon betrifft es einen Tuner den wir schon länger nicht mehr verkaufen.


    Wir schauen uns das bei Gelegenheit aber mal an danke.


    Das mit dem GPL... danke fürs melden. Das ist in der Tat nicht gewollt. War ein Bug. Ist in den nächsten Treibern dann wieder okay.


    cu

  • Hi,
    Es sind zwei Fehler. Der Anzeigefehler ist das Eine. Ein weiterer Fehler sorgt dafür, dass der Tuner nicht synchronisiert wenn seine Quarzfrequenz geringfügig unter der Sollfrequenz liegt. Dieser Fehler ist gravierend. Bei mir tritt das zufallsbedingt hin und wieder auf, dann muss ich einmal einen Kanal vor- und zurückschalten.
    Der Tuner wird zwar nicht mehr hergestellt. Ich habe ihn mir aber gebraucht gekauft, weil der in meiner dm7020hd ursprünglich verbaute Tuner CXD1981 noch mehr Empfangsprobleme macht (SNR auf einigen Kanälen unter 30 dB). Weil der alte Tuner noch so begehrt ist, verlangen die Händler stolze Preise dafür, mehr als für den Neuen.
    Wenn Du jetzt sowieso wegen der GPL alle Treiber neu compilierst, kannst Du das ja gleich mit in Ordnung bringen. Bei dem Anzeigefehler weißt Du ja schon, wo er ist. Bei dem Synchronisierfehler habe ich angedeutet, wo er zu suchen sein könnte. Damit Du nicht lange probieren musst: In den original Linux-Treibern wird die Varaible "min_delay_ms" meistens auf einen Wert zwischen 100 und 1000 gesetzt.


    MfG
    Hein

  • Vielen Dank, Ghost!


    Beide Fehler sind behoben. :smiling_face:
    Unten ist das Ergebnis mit meinem normalen Testprogramm zu sehen (das ohne ONESHOT).
    Der Tuner synchronisiert jetzt auch in Enigma2 sehr schnell bis +- 1 Mhz.


    MfG,
    Hein