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

Hi Leute,

wie angekündigt, habe ich meine C1500 vorgestern zurückgeschickt.

Ich kann also leider nicht mehr bei der Lösung des Problemes helfen. Aber ich drücke die Daumen.

Viele Grüße,
Schorschi

Zitat

Original von Hein Blöd

Deine Ausführungen bedeuten, dass jetzt der Treiber gepacht werden muss und neu kompiliert werden muss?

Ja, einmal die PLL-Geschichte und zum anderen die beiden Bytes in der Init-Tabelle. Bitte unabhängig voneinander testen.

Zitat

Kann ich noch andere Tests unter Win machen? z.B. als Vergleich einen Qam64 Sender dumpen?

Bitte auch noch einen QAM64 Sender dumpen. Wenn es unter Windows eine Anzeige zum Pegel bzw. zur Signalqualität gibt, bitte auch noch den scheinbar schlechtesten Sender bei QAM64 und QAM256 dumpen.

Zitat

Reichen die Informationenj hier um femon mit besseren Werten zu versorgen?

An den femon-Werten wird sich ohne Spec vom ST0297 nichts ändern lassen. Eigentlich fehlt ja nur irgendein Umrechnungsfaktor.

Es geht eher darum, die Initialisierung des Demodulators zu verbessern.

Zitat

Nur zum Verständnis: Wie hast du die Daten jetzt gelesen und aufbereitet?

Ich habe die Initialisierung des ST0297 beim TT Treiber für die C2300 mitgeschrieben. Daher weiß ich, daß z.B. die Register 0x4a und 0x4b scheinbar eine besondere Bedeutung haben. Beim Windows-Treiber wird zuerst der ST0297 in fast der gleichen Reihenfolge wie unter Linux mit der Inittabelle initialisiert. Ausnahme sind die beiden Register. Da wird 0x00 und 0xff reingeschrieben. Danach wird die PCI-Id gelesen und anschließend werden diese beiden Register mit 0x00 und 0x7b (Werte wie bei der C2300 in der Init-Tabelle) beschrieben. Es gibt noch weitere Unterschiede, wenn der Demodulator keinen Lock bekommt, werden die Werte für Sweep-Rate und Carrier-Offset (siehe stv0297_set_frontend) schrittweise geändert. Bei QAM256 wird ein anderer Wert für den die initiale Demodulationsfrequenz benutzt (s. hier). Es gibt noch ein paar weiter kleine Unterschiede.

Gruß
e9hack

e9hack
Windows und QAM64 werde ich heute Abend noch einmal testen. Werte vom dump liefere ich dann.
/edit
Komme erst Mo/ Di dazu.
/edit

Nochmals zu femon. Hypothese: Der Win Treiber zeigt korrekt die Pegelwerte an, dann könnte man doch an 10-20 Beispielen die Werte Win/Linux vergleichen und zueinander skalieren. Dann sollte doch femon einen halbwegs "verlässlichen" Wert im VDR anzeigen. Ich mache mir die Arbeit gerne, wenn es im Treiber eingebaut werden kann. Vielliecht ist der Skalierungswert zur C2300 ja gleich. Wäre doch mal ein Quantensprung an der Cable-Front.

@Andreas
Danke für die Tests, auch wenn sie nicht erfolgreich waren. Vielleicht helfen ja die neuen dumps von mir weiter. Habe mir gerade mit VLC auf dem Mac dein Testvideo angeschaut. Das ist natürlich ein wenig heftiger als bei mir.

Aber noch einmla in die Runde: Lohnt es sich die Unterschiede von Andreas Installation und meiner anzuschauen, oder gehen wir einfach davon aus, dass es Unterschiede beim Signal sind?

Zitat

Original von _andreas_
Kannst Du mit den "status=54" etwas anfangen?

Ich wollte aus dem Status ablesen, ob die Charge-Pump Autoumschaltung aktiv ist, ob die PLL einrastet und ob die AGC vom Tuner arbeitet. Die Autoumschaltung ist wie gewünscht nicht aktiv, die PLL rastet ein und die AGC arbeitet. Die Variable count, sagt wie lannge die PLL zum Einrasten benötigt.

Zitat

Im Anhang ist noch ein kurzer Ausschnit einer femon-Ausgabe.

Was mich bei der femon-Ausgabe wunder, daß bei so niedrigen BER Werten bereits UNC hoch geht. Bei mir sieht es so aus:

very-new-darkstar:/home/hb # femon
FE: ST STV0297 DVB-C (DVBC)
status SCVYL | signal 0071 | snr 1bf9 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal 0071 | snr 1dde | ber 00000958 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal 0072 | snr 1cf5 | ber 00000a80 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal 0072 | snr 1c73 | ber 00000a7e | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal 0072 | snr 1bd9 | ber 0000093b | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal 0072 | snr 1d52 | ber 00000a2d | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal 0071 | snr 1cad | ber 00000bde | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal 0072 | snr 1c94 | ber 00000a0b | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal 0072 | snr 1e67 | ber 00000c01 | unc 00000000 | FE_HAS_LOCK

Das ist allerdings mein schlechtester Kanal bei QAM64. Alle anderen haben BER < 100. Bei QAM256 bleibt UNC auf 0, solange BER < 600 ist. Bei QAM64 darf BER bis ca. 1200 gehen. Der Pegel ist nicht vergleichbar, da er invers ist (0 Max, 3ff Min).

Gruß
e9hack

Zitat

Original von Hein Blöd

Nochmals zu femon. Hypothese: Der Win Treiber zeigt korrekt die Pegelwerte an, dann könnte man doch an 10-20 Beispielen die Werte Win/Linux vergleichen und zueinander skalieren. Dann sollte doch femon einen halbwegs "verlässlichen" Wert im VDR anzeigen. Ich mache mir die Arbeit gerne, wenn es im Treiber eingebaut werden kann. Vielliecht ist der Skalierungswert zur C2300 ja gleich. Wäre doch mal ein Quantensprung an der Cable-Front.

Ohne Abgleich mit der Spec landet sowas nie in den Treibern.

Gruß
e9hack

Hier noch der M64 dump.

Bei mir sind alle M64 Sender grundverschlüsselt. Dump lief mit CI, aber ohne CAM (besitze noch keins)!
Alle Tests vorher waren auch so.

Und hier noch eine Excel Vergleichstabelle der PCI-, SAA7146- & i2c Register.

Zitat

Original von Hein Blöd
Und hier noch eine Excel Vergleichstabelle der PCI-, SAA7146- & i2c Register.

So eine ähnliche Liste habe ich mir auch angelegt, um zu sehen, wie bei der TT 2300C der STV0297 unter Windows und unter Linux initialisiert wird. Die unterschiede in Deinem Vergleich (nur I2C) sind im wesentlichen auf QAM64/256 zurückzuführen. Der Linux-Treiber initialisiert ähnlich. Ich habe immer noch die Initialisierung des Tuner oder möglicherweise eines weiteren I2C Bausteins, z.B. der IF-Verstärker, als Ursache des Problems im Verdacht. Wenn Du unter Linux i2cdetect laufen läßt, welche i2c-Adressen werden bei der TT 1500C als verfügbar angezeigt? Mit i2cdump kannst Du Dir auch die Register vom STV0297 unter Linux anschauen. Allerdings benötigt man noch diesen Patch, da der STV0297 einige i2c-Kommandos nicht richtig versteht.

Gruß
e9hack

Wie per PN besprochen: Die Werte kommen in den nächsten Tagen.

Hallo,

i2cdetect
Error: No i2c-bus specified!
Syntax: i2cdetect [-y] [-a] [-q|-r] I2CBUS [FIRST LAST]
        i2cdetect -F I2CBUS
        i2cdetect -l
        i2cdetect -V
  I2CBUS is an integer
  With -a, probe all addresses (NOT RECOMMENDED)
  With -q, uses only quick write commands for probing (NOT RECOMMENDED)
  With -r, uses only read byte commands for probing (NOT RECOMMENDED)
  If provided, FIRST and LAST limit the probing range.
  With -l, lists installed busses only
  Installed I2C busses:
    i2c-2       i2c             TT-Budget-C-CI PCI
    i2c-1       i2c             TT-Budget/WinTV-NOVA-C  PCI
    i2c-0       smbus         SMBus I801 adapter at 1400

und

i2cdetect 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c/2.
I will probe address range 0x03-0x77.
Continue? [Y/n]
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          XX XX XX XX XX XX XX XX XX XX XX XX XX
10: XX XX XX XX XX XX XX XX XX XX XX XX 1c XX XX XX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
50: 50 51 52 53 54 55 56 57 XX XX XX XX XX XX XX XX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
70: XX XX XX XX XX XX XX XX

lspci -vn von der Karte

01:07.0 0480: 1131:7146 (rev 01)
        Subsystem: 13c2:1010
        Flags: bus master, medium devsel, latency 123, IRQ 5
        Memory at fc101000 (32-bit, non-prefetchable) [size=512]

Gruß Ulf

Probierts mal damit:

- In den Einstellungen - DVB - Kanäle aktualisieren nur Pid's
- VDR stoppen
- Leere channel.conf reinkopieren
- VDR starten
- Kanalscann mit reelchannelscann machen
- Dann vieleicht noch die Frequenz um 500 KHz runternehmen wenn das Bild Artefakte haben sollte.

Bei mir hat es überhaupt keine Rolle gespielt ob Qam64 oder Qam256.
Beide gingen nicht richtig wenn man den VDR nicht auf nur Pids aktualisieren liess. Die Signalstärke wird bei mir auch als fast nicht messbar angezeigt obwohl ich ein hervorragends Bild ohne jegliche Störungen habe.

Habe eine TT C2300 FF

Gruss
Joe

Zitat

Original von ULF

Code

i2cdetect 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c/2.
I will probe address range 0x03-0x77.
Continue? [Y/n]
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          XX XX XX XX XX XX XX XX XX XX XX XX XX
10: XX XX XX XX XX XX XX XX XX XX XX XX 1c XX XX XX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
50: 50 51 52 53 54 55 56 57 XX XX XX XX XX XX XX XX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
70: XX XX XX XX XX XX XX XX

Alles anzeigen

Das mit der i2c-Adresse vom Tuner war wohl nicht wirklich durchdacht. Da ist noch der stv0297 als 'Gate' dazwischen, sodaß man mit i2cdetect nichts findet. Die gefundenen Adressen gehören dem stv0297 und dem 8kBit E²PROM.

Gruß
e9hack

Moin e9hack,
danke für deinen unermüdlichen Einsatz!
Der Treiber der C1500 ist ja schon recht vielversprechend.

Würde dich der i2cdump evtl weiterbringen?

Wenn ja, würde ich mich mal ans Patchen meiner DVB-Treiber von gestern machen.

Kann man sonst was tun um dich beim Treiberbau der Karte zu unterstützen?

Gruß Ulf

Macht es generell Sinn die i2c Werte win / Linux zu vergleichen? Dann könnte man den stv0297 als Fehlerquelle ausschliessen.

Zitat

Original von Hein Blöd
Macht es generell Sinn die i2c Werte win / Linux zu vergleichen? Dann könnte man den stv0297 als Fehlerquelle ausschliessen.

Es hilft ein klein wenig. Wichtiger wäre, Windows bei der Initialisierung vom Tuner und stv0297 zu belauschen. Das hat mir bei der TT 2300C am meisten geholfen. Allerdings gings da darum, daß die Karte in meinem VDR (CPU zu schnell) zwischen 30min bis 1h für den Lock bei QAM256 benötigt hat.

Gruß
e9hack

Was kann ich konkret machen? Sorry für die Funkstille, aber wir sind im Urlaub gewesen.

Oliver

Zitat

Original von Hein Blöd
Was kann ich konkret machen?

Der einzige Weg wird das Belauschen der I2C-Kommunikation vom Windows-Treiber sein. Möglicherweise geht das mit lmilk. Man benötigt dann einen 2. PC mit Linux. An den Parallel-Port kommt eine simple Hardware, die auf kürzestem Weg mit Masse, SDA und SDL vom Ziel-PC verbunden wird. Ich werde das mal aufbauen und testen.

Gruß
e9hack

Habe gestern auch mal den neusten V4l Treiber mit den beiden Anpassungen in der budget-ci.c installiert (wobei der Bandeintrag bei mir schon stimmte). Die BER und UNC Werte erscheinen jetzt auch bei mir. Pegelanzeige würde ich sagen ist um 2-3 % nach oben gegangen (von ca 7% auf 10% (RTL)). Es werden ca. 60 Sender mehr gefunden (vorher/ nachher mit Wirbelscan auf Auto). Aber das Bild ist mit deutlich mehr Artefakten durchzogen (seit dem Treiberupdate).
Ich habe mich bei der Installation an die Beschreibung der DVB Wiki von linuxtv.org gehalten und nur die Firmware nicht nachgezogen.

Channelscan:
Die aktuelle Reelchannelscanversion in CT vdr6 ist in meinen Augen unbrauchbar geworden (im Vergleich zu den vorangegangenen Versionen (sarge testing). Wirbelscan findet deutlich mehr Sender, benötigt aber auch sehr lange dafür. Der Scan wird aber auch nicht jeden Tag gemacht, da darf er mal brauchen.

e9hack
Hast du schon etwas testen können?

Zitat

Original von e9hack

Möglicherweise geht das mit lmilk. Man benötigt dann einen 2. PC mit Linux. An den Parallel-Port kommt eine simple Hardware, die auf kürzestem Weg mit Masse, SDA und SDL vom Ziel-PC verbunden wird. Ich werde das mal aufbauen und testen.

Ich habe es mir nur angeschaut, aber nicht aufgebaut. Das Verfahren ist meiner Meinung nach nur dazu geignet, den Transfer von einigen Bytes auf einem sonst unbenutzten I²C-Bus zu beobachten. Bei einer DVB-Karte werden aber permanent Daten übertragen. Bei der Initialisierung der Karte müssen ca. 1K an Daten mitgeschrieben werden.

Gruß
e9hack