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

Die Emfangswerte sind bei mir die gleichen Werte wie bei Andreas. Ich glaube auf diese Werte kann man nichts geben. Ich habe hier bei mir eine neue TV Verkabelung im Haus und die Leitung in der Strasse wurde gerade ausgetauscht (war vorher aber gleich). Da wir über Kabel telefonieren und Internet nutzen, kamen die Jungs vom Provider vorher mit dem Fluke-Tester vorbei. Der Wert war so um die 7x dB. Ich meine 73/74 dB. Damit war der Techniker wohl äusserst zufrieden. Vielleicht leigt es bei euch doch an der Kabelinstallation?
Ansonsten probiert doch einfach mal ein C't VDR 5.x aus. Ist doch einen Versuch wert. Sollte damit die Bildqualität dort auf mein Niveau kommen, dann hätten wir doch einen Hebel für Verbesserungsmöglichkeiten - nämlich was sind dann die Unterschiede zwischen den Distris.
Gibt es keinen Unterschied bei der Bildqualität, dann will die Karte mit dem Linux-Treiber ein sehr starkes Signal. Nur könnte dann unser Problem unter Umständen die gleiche Ursache haben wie bei den FF C-Karten. Hatte e9hack nicht mal im Cinergy Thread eine Nebenbemerkung zu den möglichen Verbesserungsmöglichkeiten bei den FF Karten gemacht? Ich muss noch einmal in Ruhe den Thred durchgehen.
Cinergy 1200 DVB-C wird nicht erkannt
Bei der Terratec war auch nur der Tuner unterschiedlich. Vielleicht sollte Dr. Seltsam mal eine Karte von uns bekommen und damit mal einen Vergleich machen. Ich steuer als Nervennahrung gute Schweizer Schoggi bei

Habe noch einmal den MegaThread Qam 256 durchgeschaut und bin hier hängen geblieben:
DVB-C Qualität - QAM 256
und nächste Seite
DVB-C Qualität - QAM 256

Haben wir vielleicht ein Problem im Treiber, dass der Tuner sich nicht auf die Signalstärke/Dämpfung einpegeln kann? Ich bin kein E-Techniker, verspottet mich also nicht für diese Ausführung

Zitat

Original von Schorschi

Dr. Seltsam: Mich würden aber doch noch die femon-Werte von Deiner C1500 interessieren.

Sind Deine Werte für STR und SNR wirklich auch so mies, wie sie Andreas im ersten Post beschrieben hat? Ist bei mir nämlich genauso. Meine TT FF 2.1 liefert 100% STR und 91%-93% SNR, BER = 0, UNC = 0 im selben System.

Dass man die Werte unter verschiedenen Karten nicht vergleichen kann, leuchtet mir schon ein, aber irgendwas scheint ja auch die C1500 an femon zu melden, sonst würden die Werte sich ja nicht ändern, oder?

Alles anzeigen

STR 1%
SNR 3-4%
BER 0
UNC 0
und astreiner Empfang (habe aber nur QAM64 im Netz). Wenn man das Signal erheblich dämpft, kommen irgendwann Artefakte, und BER und UNC fangen an Werte auszuweisen.

Kontaktet doch mal e9hack. Wenn ihm einer eine Karte zur Verfügung stellen kann, kann er sie ja bei sich vielleicht mal testen. Wenn Euch einer helfen kann, dann er.

Zitat

Original von Hein Blöd
Vielleicht sollte Dr. Seltsam mal eine Karte von uns bekommen und damit mal einen Vergleich machen. Ich steuer als Nervennahrung gute schweizer Schoggi bei

das bringt nichts, weil ich keine QAM256 in meinem ewt-Kabelnetz habe (Genossenschaft mit eigener Kopfstation)

@Dr Seltsam
Ist OK. Aber vielleicht bringt es noch diverse Daten der Karten (I2C, etc.) zuvergleichen. Aber da kann uns wahrscheinlich nur e9hack konkret helfen.

Hi Leute,

mit den Links von Oliver habe ich jetzt mal lspci -v ausprobiert. Folgendes kommt dabei heraus:

0000:01:01.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: Technotrend Systemtechnik GmbH: Unknown device 1010
Flags: bus master, medium devsel, latency 32, IRQ 193
Memory at ff901000 (32-bit, non-prefetchable) [size=512]

0000:01:05.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1
Flags: bus master, medium devsel, latency 32, IRQ 177
Memory at ff901400 (32-bit, non-prefetchable) [size=512]

Erkannt werden ja beide Karten. Der Fall liegt also etwas anders wie bei der Cinergy 1200.

Die hohen IRQs machen mich etwas nervös. Weiß jemand, was es damit auf sich hat?

Viele Grüße,
Schorschi

Die Vendor ID (Technotrend) ist bekannt, aber nicht die Sub ID (unknown device). Der Linux Treiber scheint nicht so tief zu gehen. Auch der Windowstreiber unterscheidet nicht die beiden Revisionen.
Aber es muss Unterschiede bei der Ansteuerung der Tuner geben. Kann einer mal verständlich die ganzen Begrifflichkeiten Frontend und Co erklären und wie die DVB Treiberkomponenten damit zusammenarbeiten?

Zitat

Original von Hein Blöd
Die Vendor ID (Technotrend) ist bekannt, aber nicht die Sub ID (unknown device).

Das hat nichts zu sagen. Die Sub-ID steht nur nicht in der Data-Base von lspci drin.

Zitat

Der Linux Treiber scheint nicht so tief zu gehen. Auch der Windowstreiber unterscheidet nicht die beiden Revisionen.

Der Linux-Treiber muß die Sub-ID kennen. Sonnst kann er die Karte nicht ansprechen.

Da die Karte unter Windows scheinbar funktioniert, muß man den I2C-Transfer unter Windows belauschen. Das geht statisch mit dem Tool von LinuxTV. Damit kommt man aber nicht an die Programmierung vom Tuner ran. Für das Belauschen des Tuners oder der Initialisierung des Demodulator muß man den Windows-Treiber patchen. Für die TT C2300 konnte ich den Treiber patchen, um den I2C-Verkehr über den SAA7146 zu belauschen. Bei der Cinergy 1200C habe ich die entsprechenden Funktionen nicht gefunden. Da war aber die Ausgabe vom LinuxTV-Tool ausreichend. Eine weitere Möglichkeit ist das belauschen des I2C-Buses der Karte mit einem Logic-Analyser. Die Auswertung ist aufwändig, wenn der kein direktes 'Tracen' vom I2C-Protokoll erlaubt. Der, auf den ich Zugriff hätte, kann es nicht oder ich habe die entsprechenden Funktionen nicht gefunden.

Noch eine Bitte: Wenn Ihr hier irgendwelche Signalwerte vergleicht, bitte benutzt die Hex-Werte. Die 'Signalstärke' z.B., hat nur eine Auflösung von 10Bit. Da geht bei dem Prozent-Wert jegliche Information verloren.

Gruß
e9hack

So.

Mein VDR läuft wieder. Tests Win/VDR können jetzt losgehen.

Schorschi
Wo bekomme ich logread her? Dann könnte ich bei mir mal schauen.

e9hack
Fange morgen mit den Tests unter Win an (graphedit und saa7146dump). Schauen wir doch mal nach den Werten.

@all
Kann ich ansonsten irgendwelche Werte mal abfragen? Immerhin wäre es doch mal interessant wieso bei mir das Bild nahezu perfekt ist und bei andreas und schorschi nicht.

Fest steht, dass das PCB bei beiden Revisionen gleich ist und "nur" der Tuner gewechselt hat.

Oliver

Hi Oliver,

logread gibt es glaube ich nur bei Distris, die busybox als shell verwenden (easyVdr, LinVdr, etc.).

logread -f

entspricht

tail /var/log/messages -f

(@all: korrigiert mich bitte, wenn ich falsch liegen sollte. :))

Viele Grüße,
Schorschi

Werde ich heute noch testen.

e9hack
Startadresse für i2c ist mir nicht bekannt. Nehme ich die analog vom Cinergy thread? Oder wie kann ich die Adressen herausfinden? dmesg?

messages bringt bei mir ausser svdrp/localhost connect Fehlern nichts zurück.

Im kalten Zustand (direkt nach Einschalten) habe ich stärkere Artefakte, dann habe ich nach 1-2 Minuten die gewohnte Qualität. Das nur noch zur Info.

Zitat

Original von Hein Blöd
Startadresse für i2c ist mir nicht bekannt. Nehme ich die analog vom Cinergy thread? Oder wie kann ich die Adressen herausfinden? dmesg?

Die I2C-Adresse ist 0x1c. Da muß man im Treiber nachschauen.

Gruß
e9hack

Laut Datenblatt vom Tuner (TD1316AL) soll die Charge-Pump bei einer PLL-Schrittweite von 62.5kHz fest auf 90uA (cp = 2) programmiert werden. Ob das wirklich hilft, kann ich nicht sagen.

--- a/linux/drivers/media/dvb/ttpci/budget-ci.c Wed May 09 08:02:02 2007 -0300
+++ b/linux/drivers/media/dvb/ttpci/budget-ci.c Thu May 10 20:18:33 2007 +0200
@@ -897,37 +897,20 @@ static int dvbc_philips_tdm1316l_tuner_s
                                    .len = sizeof(tuner_buf) };
        int tuner_frequency = 0;
        u8 band, cp, filter;
-
-       // determine charge pump
+       int i;
+
+       // the charge pump is always 2 for 62.5kHz PLL step size
+       cp = 2;
+
+       // determine band
        tuner_frequency = params->frequency + 36125000;
-       if (tuner_frequency < 87000000)
-               return -EINVAL;
-       else if (tuner_frequency < 130000000) {
-               cp = 3;
+       if (tuner_frequency < 87000000) {
+               return -EINVAL;
+       } else if (tuner_frequency < 200000000) {
                band = 1;
-       } else if (tuner_frequency < 160000000) {
-               cp = 5;
-               band = 1;
-       } else if (tuner_frequency < 200000000) {
-               cp = 6;
-               band = 1;
-       } else if (tuner_frequency < 290000000) {
-               cp = 3;
+       } else if (tuner_frequency < 480000000) {
                band = 2;
-       } else if (tuner_frequency < 420000000) {
-               cp = 5;
-               band = 2;
-       } else if (tuner_frequency < 480000000) {
-               cp = 6;
-               band = 2;
-       } else if (tuner_frequency < 620000000) {
-               cp = 3;
-               band = 4;
-       } else if (tuner_frequency < 830000000) {
-               cp = 5;
-               band = 4;
        } else if (tuner_frequency < 895000000) {
-               cp = 7;
                band = 4;
        } else
                return -EINVAL;
@@ -937,7 +920,7 @@ static int dvbc_philips_tdm1316l_tuner_s


        // calculate divisor
        tuner_frequency = (params->frequency + 36125000 + (62500/2)) / 62500;
-
+
        // setup tuner buffer
        tuner_buf[0] = tuner_frequency >> 8;
        tuner_buf[1] = tuner_frequency & 0xff;
@@ -949,16 +932,24 @@ static int dvbc_philips_tdm1316l_tuner_s
                fe->ops.i2c_gate_ctrl(fe, 1);
        if (i2c_transfer(&budget_ci->budget.i2c_adap, &tuner_msg, 1) != 1)
                return -EIO;
-
-       msleep(50);
-
-       if (fe->ops.i2c_gate_ctrl)
-               fe->ops.i2c_gate_ctrl(fe, 1);
-       if (i2c_transfer(&budget_ci->budget.i2c_adap, &tuner_msg, 1) != 1)
-               return -EIO;
-
+
        msleep(1);
-
+
+       // wait for pll lock
+       tuner_msg.len = 1;
+       tuner_msg.flags = I2C_M_RD;
+       for (i = 0; i < 20; i++) {
+               if (fe->ops.i2c_gate_ctrl)
+                       fe->ops.i2c_gate_ctrl(fe, 1);
+               if (i2c_transfer(&budget_ci->budget.i2c_adap, &tuner_msg, 1) != 1)
+                       return -EIO;
+               if (tuner_buf[0] & 0x40)
+                       break;
+               msleep(10);
+       }
+
+       printk("(%s:%d) status=%02x, count=%d\n", __FILE__, __LINE__, tuner_buf[0], i);
+
        return 0;
 }

Am Ende habe ich noch eine Abfrage auf den PLL-Lock eingebaut, da man bei aktuellen PLL-IC's nicht mehr solange warten muß.

Gruß
e9hack

Und hier der Dump von einem Qam256 Sender

C:\saa7146dump>saa7146dump 0x13c2 0x1010 0x1c 1
device found: bus:1 device:0 vendor:1131 device:7146 subsysvendor:13c2 subsysdev
ice: 1010
PCI registers:
00: 71461131
04: 02800006
08: 04800001
0C: 00007B00
10: EC100000
14: 00000000
18: 00000000
1C: 00000000
20: 00000000
24: 00000000
28: 00000000
2C: 101013C2
30: 00000000
34: 00000000
38: 00000000
3C: 260F010B
40: 00000000
44: 00000000
48: 00000000
4C: 00000000
50: 00000000
54: 00000000
58: 00000000
5C: 00000000
60: 00000000
64: 00000000
68: 00000000
6C: 00000000
70: 00000000
74: 00000000
78: 00000000
7C: 00000000
80: 80000000
84: 80000000
88: 80000000
8C: 80000000
90: 80000000
94: 80000000
98: 80000000
9C: 80000000
A0: 80000000
A4: 80000000
A8: 80000000
AC: 80000000
B0: 80000000
B4: 80000000
B8: 80000000
BC: 80000000
C0: 80000000
C4: 80000000
C8: 80000000
CC: 80000000
D0: 80000000
D4: 80000000
D8: 80000000
DC: 80000000
E0: 80000000
E4: 80000000
E8: 80000000
EC: 80000000
F0: 80000000
F4: 80000000
F8: 80000000
FC: 80000000
SAA7146 registers:
0000: 00000000
0004: 00000000
0008: 00000000
000C: 00000000
0010: 00000000
0014: 00000000
0018: 00000000
001C: 00000000
0020: 00000000
0024: 00000000
0028: 00000000
002C: 00000000
0030: 001A2000
0034: 001B9800
0038: 001D1004
003C: 000000BC
0040: 00000000
0044: 020000BC
0048: 071E1E1E
004C: 1D1D1D1D
0050: 06C006C0
0054: 00000000
0058: 60000000
005C: 00016000
0060: 40000000
0064: 00000000
0068: 00000000
006C: 00400000
0070: 80400040
0074: 00000000
0078: 80200000
007C: 00460000
0080: 00030000
0084: 00000000
0088: 01010101
008C: 11088340
0090: 00000600
0094: 00000000
0098: 00000000
009C: 00000000
00A0: 00000000
00A4: 00000000
00A8: 00000000
00AC: 00000000
00B0: 00000000
00B4: 00000000
00B8: 00000000
00BC: 00000000
00C0: 00000000
00C4: 00000000
00C8: 00000000
00CC: 00000000
00D0: 00000000
00D4: 00000000
00D8: 00000000
00DC: 000000C0
00E0: 20505000
00E4: 00000000
00E8: 00000000
00EC: 00000000
00F0: 00000000
00F4: 00000000
00F8: 00000000
00FC: 00000D90
0100: 0000077F
0104: 00000000
0108: 00000000
010C: 00000000
0110: 000400B8
0114: 00800010
0118: 00000000
011C: 00000000
0120: 00000000
0124: 00000000
0128: 001C9908
012C: 00000000
0130: 00000000
0134: 00000000
0138: 00000000
013C: 00000000
0140: 00000000
0144: 00207002
0148: 08000102
014C: 1D1D1D1D
0150: 06C006C0
0154: 00000000
0158: 60000000
015C: 00016000
0160: 40000000
0164: 00000000
0168: 00000000
016C: 00400000
0170: 80400040
0174: 00000000
0178: 80200000
017C: 00460000
0180: 00030000
0184: 00000000
0188: 000000C0
018C: 00000040
0190: 00000600
0194: 00000000
0198: 00000000
019C: 00000000
01A0: 00000000
01A4: 00000000
01A8: 00000000
01AC: 00000000
01B0: 00000000
01B4: 00000000
01B8: 00000000
01BC: 00000000
01C0: 00000000
01C4: 00000000
01C8: 00000000
01CC: 00000000
01D0: 00000000
01D4: 00000000
01D8: 00000000
01DC: 000000C0
01E0: 20505000
01E4: 00000000
01E8: 00000000
01EC: 00000000
01F0: 00000000
01F4: 00000000
01F8: 00000000
01FC: 04100410
i2c registers of device @0x1c:
00: 39
01: 69
02: 00
03: 0F
04: 01
05: 00
06: BF
07: DE
08: 11
09: E3
0A: DD
0B: DD
0C: B9
0D: E0
0E: 81
0F: DE
10: F8
11: F4
12: A7
13: 9E
14: D9
15: 86
16: C2
17: DC
18: DC
19: F8
1A: EB
1B: 88
1C: 98
1D: E3
1E: 9F
1F: BE
20: 00
21: 40
22: 00
23: 00
24: 40
25: 88
26: A1
27: A2
28: D4
29: 83
2A: A1
2B: 81
2C: DE
2D: F9
2E: DA
2F: E3
30: FF
31: 00
32: FF
33: 00
34: 50
35: 7F
36: 00
37: 20
38: 00
39: 9F
3A: D9
3B: B9
3C: FE
3D: F4
3E: 80
3F: BC
40: 1C
41: 0C
42: 2B
43: 38
44: FF
45: F1
46: 03
47: 00
48: 00
49: 04
4A: FF
4B: 7F
4C: 00
4D: 00
4E: 00
4F: 00
50: 56
51: 4F
52: 30
53: 13
54: 26
55: 0C
56: 18
57: 1E
58: 3D
59: 08
5A: 1E
5B: 04
5C: 75
5D: 49
5E: 10
5F: 61
60: ED
61: 38
62: 0A
63: 19
64: 4C
65: 6F
66: 58
67: 14
68: F9
69: FF
6A: 02
6B: 00
6C: 00
6D: 00
6E: 00
6F: 00
70: FF
71: 00
72: EC
73: 0D
74: 86
75: 86
76: 86
77: 86
78: FF
79: 00
7A: A0
7B: 0F
7C: 86
7D: 86
7E: 86
7F: 86
80: 20
81: 00
82: 2F
83: 08
84: 04
85: B3
86: 48
87: 78
88: 10
89: 00
8A: 2F
8B: 08
8C: 04
8D: B3
8E: 2F
8F: BB
90: 01
91: 02
92: 01
93: 02
94: 01
95: 02
96: 01
97: 02
98: 01
99: 02
9A: 01
9B: 02
9C: 01
9D: 02
9E: 01
9F: 02
A0: 03
A1: 00
A2: 00
A3: 00
A4: 00
A5: 00
A6: 00
A7: 00
A8: 00
A9: 00
AA: 00
AB: 00
AC: 00
AD: 00
AE: 00
AF: 00
B0: 91
B1: 0B
B2: 80
B3: 55
B4: 91
B5: 0B
B6: 80
B7: 55
B8: 91
B9: 0B
BA: 80
BB: 55
BC: 91
BD: 0B
BE: 80
BF: 55
C0: 53
C1: 70
C2: 12
C3: 53
C4: 53
C5: 53
C6: 53
C7: 53
C8: 53
C9: 53
CA: 53
CB: 53
CC: 53
CD: 53
CE: 53
CF: 53
D0: 00
D1: 00
D2: 00
D3: 00
D4: 00
D5: 00
D6: 00
D7: 80
D8: 00
D9: 00
DA: 00
DB: 00
DC: 00
DD: 00
DE: 00
DF: 12
E0: 00
E1: 00
E2: 00
E3: 00
E4: 00
E5: 00
E6: 00
E7: 00
E8: 00
E9: 00
EA: 00
EB: 00
EC: 00
ED: 00
EE: 00
EF: 00
F0: 00
F1: 00
F2: 00
F3: 00
F4: 00
F5: 00
F6: 00
F7: 00
F8: 00
F9: 00
FA: 00
FB: 00
FC: 00
FD: 00
FE: 00
FF: 00


C:\saa7146dump>

Zitat

Original von Hein Blöd
Und hier der Dump von einem Qam256 Sender

Code

i2c registers of device @0x1c:
4A: FF
4B: 7F

Diese beiden Register haben irgendwas mit dem Regelbereich der AGC zu tun. Linux initialisiert sie mit 0x00 und 0x7b (Tabelle dvbc_philips_tdm1316l_inittab in budget-ci.c). Man sollte probehalber mal diese beiden Werte ändern.

Zitat

Code

DF: 12

Auch Windows scheint den Lock zu verlieren. Bit7 im Register 0xdf signalisiert, daß der Demodulator synchronisiert hat.

Gruß
e9hack

e9hack
Wobei Win ein absolut störungsfreies Bild liefert.
Deine Ausführungen bedeuten, dass jetzt der Treiber gepacht werden muss und neu kompiliert werden muss?
Kann ich noch andere Tests unter Win machen? z.B. als Vergleich einen Qam64 Sender dumpen?
Reichen die Informationenj hier um femon mit besseren Werten zu versorgen?
Nur zum Verständnis: Wie hast du die Daten jetzt gelesen und aufbereitet?

@Andreas & Schorschi
Ich würde mich an dieser Stelle in die zweite Reihe stellen und gerne zuschauen und keinem im Weg herumstehen. Aber ich möchte gerne lernen und das nachher adaptieren.
Wenn mit diesen Werten die Anzeige bei euch sich wesentlich verbessert, ist sie bei mir eh perfekt

the audience is listening