I2C anstuern

[Artur]

Hallo,

gibt es eine Möglichkeit den I2C Bus über serielle Schnittstelle oder LAN anzusteuern?
Es gibt ja Probleme mit dem Empfang der QAM256 Sender mit der Sagem. Ich habe mir vorgenommen mit dem Tuner ein wenig zu experimentieren. Dazu müßte ich in der Lage sein die Register des Tuners und der PLL zu beschreiben und zu lesen.

Gruß

[PauleFoul]

Da gibt es irgendwo im Forum eine Anleitung wie man die Tunerwerte
auslesen kann.

[DrStoned]

Da gibt es irgendwo im Forum eine Anleitung wie man die Tunerwerte
auslesen kann.

Das war hier.

Greetz von DrStoned

[AudioSlyer]

könnte für dich interessant sein.
http://www.nalanda.nitc.ac.in/industry/ ... oc1293.pdf

Carrier Recovery - Fine Tuning
The carrier recovery block allows the acquisition and tracking
of a frequency offset as high as 12% of the symbol rate,
even for low signal to noise ratios. The phase comparator
algorithm provides a high phase noise tolerance which
reduces the tuner cost. The frequency offset recovered by
the chip can be monitored through the I2C interface. This
information can be used to readjust the tuner frequency in
order to reduce the analog filtering degradation on the signal
and thus improves the Bit Error Rate. This information
is also provided automatically to the DDS in order to
recover the frequency with complete accuracy before
receive filtering.

----

General Monitoring

0x80 R LOCK Lock status of AGC1, AGC2, TIMING, CARRIER, EQUALIZER, FEC
0x81 - 0x83 R BER1 Bit error rate estimate
0x84 R BER2 Bit error rate estimate based on frame synchronization word
0x85 R NPERR Number of uncorrectable frames
0x86 - 0x88 R TIMFREQOFF Symbol rate frequency offset with respect to SYMRATE
0x89 - 0x8A R DDSFREQOFFSET Frequency offset recovered by DDS
0x8B - 0x8C R CARFREQOFFSET Residual frequency offset (normalized to symbol rate)
0x8D - 0x8E R PHASENOISE Phase noise estimation
0x8F - 0x90 R ADDITIVENOISE Additive noise estimation
0x91 R AGC1LEVEL AGC1 current value (external)
0x92 - 0x93 R AGC2LEVEL AGC2 current value (internal)

[AudioSlyer]

Code: Alles auswählen

	/*
	 * Performance optimizations, should be done after autoconfig
	 */
	at76c651_writereg(i2c, 0x10, 0x06);
	at76c651_writereg(i2c, 0x11, ((at76c651_qam == 5) || (at76c651_qam == 7)) ? 0x12 : 0x10);
	at76c651_writereg(i2c, 0x15, 0x28);
	at76c651_writereg(i2c, 0x20, 0x09);
	at76c651_writereg(i2c, 0x24, ((at76c651_qam == 5) || (at76c651_qam == 7)) ? 0xC0 : 0x90);
	at76c651_writereg(i2c, 0x30, 0x90);
	if (at76c651_qam == 5)
		at76c651_writereg(i2c, 0x35, 0x2A);

Hat einer mal ene Doku wo diese Register beschrieben sind?
Die anderen habe ich alle gefunden.
[/code]

[AudioSlyer]

----

[Artur]

Danke für die Anworten.
Das Datenblatt habe ich auch. Ist euch schon mal der Widerspruch aufgefallen:

The internal oscillator of the chip provides a direct, jitterfree
clock...

und ein paar Seiten weiter:

WARNING: Performance in 256-QAM may be affected
by the jitter on the oscillator. It is preferable to use an
external crystal oscillator if 256-QAM is required in the
final application. Atmel does not guarantee the BER
specifications given on page 20 and page 21 if a crystal
is used on its own.

Wie passt das zusammen? OK, der Takt für den Core wird noch über die PLL multipiziert. Vielleicht ist das das Problem. Aber warum dann nur bei QAM256? Bei QAM512 und 1024 müßte es sich umso heftiger auswirken. Das wird aber nicht erwähnt.

Ich habe schon das Forum zu diesem Thema durchforstet. Es wird viel geschrieben, aber niemand hat es analysiert. Ich habe den neusten Treiber. So richtig läuft es nicht. Mir ist auch aufgefallen, daß bei stärkerer Signaldämpfung es besser wird. Das deutet darauf hin, daß der Tuner übersteuert.
Was ich eingentlich vorhabe, ist den Tuner extern anzusteuern (z. B. mit einem Atmel Controller). Dann könnte ich die Tunereinstellungen selbst setzen, und durch Auslesen der Monitoring Register die Auswirkungen beobachten. Hoffe damit das Problem eingrenzen zu können.
Das müßte aber auch irgendwie mit Debugbefehen gehen. Nur wie? Von Linux habe ich leider nicht viel Ahnung.

[Gorcon]

Mir ist auch aufgefallen, daß bei stärkerer Signaldämpfung es besser wird. Das deutet darauf hin, daß der Tuner übersteuert.

Der Tuner selbst nicht, eher der Demodulator (oder irgendwas anderes hinter dem Tuner).

Gruß Gorcon

[MarcM]

It is preferable to use an
external crystal oscillator if 256-QAM is required in the
final application.

Ist das so ? Wird der bei uns extern angesteuert ?

Ansonsten......WAS MUß ICH KAUFEN UND WO EINLÖTEN ?

Ich nehme mal an, einen per I2C steuerbaren Oszi ?!!!! Kann ja nicht die Welt kosten, aber wenn damit die QAM256 Probleme bei Sagem verschwinden...

Marc

[Carjay]

Hat einer mal ene Doku wo diese Register beschrieben sind?
Die anderen habe ich alle gefunden.

Das ist einfach das was die BN macht.

[Artur]

ext. Oszillator ist ein Quarz mit intergriertem Schwingkreis (der befindet sich beim Atmel auf dem Chip). Man braucht allerdings 3,3V Typ. Reichelt hat z.B. nur 5V Typen im Angebot. Damit das Ganze Sinn macht, müßte man die doppelte Frequenz nehmen und die PLL abschalten (wenn es stimmt, daß der interne Oszillator keinen jitter hat). Dann würde aber der AD-Wandler auch mit der doppelten Frequenz laufen. Schaft er das? Oder müßte die Frequenz wieder halbiert werden?
Ich glaube nicht, daß es hilft. Habe das schon auf der Arbeit diskutiert. Die Ausagen zum jitter hat niemand verstanden.

[Carjay]

WARNING: Performance in 256-QAM may be affected
by the jitter on the oscillator. It is preferable to use an
external crystal oscillator if 256-QAM is required in the
final application. Atmel does not guarantee the BER
specifications given on page 20 and page 21 if a crystal
is used on its own.

Hm, das steht in dem Datenblatt was ich hier habe nicht drin. Hast du eine andere Version? Der Atmel im Sagem-Frontend benutzt da ja 28,9 MHz Quartze, also keinen Oszillator (wie du schon schriebst).

Wegen des Nichterwähnens von 512-QAM und 1024-QAM: diese sind in der EN 300429 nicht spezifiziert, sind wohl eher theoretischer Natur (der Demod kann es, aber benutzt wird es bei DVB nicht).

Ich weiß nicht genau warum du den Aufwand treiben willst, den Demod extern anzusteuern statt es einfach in den Treiber einzubauen aber wenn die Mikrocontroller eher deine Welt sind... hm, das geht glaube ich schon irgendwie, aber ich habe das noch nie machen wollen. Schau vielleicht mal bei http://www.lm-sensors.org/ vorbei, ich glaube, die hatten da Tools für.

Es kann aber sein, daß du dann eine Spezialversion vom Kernel auf der Box brauchst.

[Artur]

Wegen des Nichterwähnens von 512-QAM und 1024-QAM: diese sind in der EN 300429 nicht spezifiziert, sind wohl eher theoretischer Natur (der Demod kann es, aber benutzt wird es bei DVB nicht).

in einem anständigen Datenblatt würde es stehen.

Ich weiß nicht genau warum du den Aufwand treiben willst, den Demod extern anzusteuern statt es einfach in den Treiber einzubauen

Tja, wenn das für mich so einfach wäre, würde ich nicht fragen. Ich habe es bis jetzt nicht geschaft ein Image erzeugen. Bei der Gelegenheit kann ich mal fragen, was der Compilerfehler "keine Regel für Erstellung von U-Code.bin. Schluß" bedeutet (an den genauen Wortlaut kann ich mich nicht erinnern). Soweit ich es verstanden habe, stehen die Regel in den Makefiles und die werden durch Aufruf von configure automatisch erstellt. Richtig?
Außerdem wird die U-code.bin doch aus BN image gewonnen und nach dem Flashen wieder eingespielt.

Zurück zum Thema. Ich glaube auch, daß ich eine angepasste Version brauche. Ich denke, man müßte eine zusätzliche Datei erzeugen (z. B. "i2c"), die Daten auf dem I2C ausgeben kann. Sie sollte beim Aufruf Daten von seriellen Schnittstelle empfangen und an den I2C weiterleiten.
Folgende Ablauf wäre denkbar:
1) Dbox mit dem neuen image starten und boot abbrechen
2) die Datei "i2c" über Terminal starten. Diese wartet dann in einer Endlosscheife auf Befehle die über serielle Schnittstelle kommen und gibt sie auf dem I2C aus. Der Befehlt könnte z.B. so aufgebaut sein: device-id,read/write,address,data. Eventuell müßten noch ein paar Bytes dazu (Länge,Checksumm) um es sicher zu machen. Die Anwort müßte auch noch definiert werden.

Vielleicht kann ein Profi es in ein paar Minuten programmieren. Die Module gibt es ja schon. Der Ansatz mit dem ext. Controller ist zwar aufwendig. Für mich aber einfacher als den Kernel anzupassen

[AudioSlyer]

Ich hab mal ein bischl mit dem Treiber "rumgespielt", bezüglich QAM256.
Bin jetzt auch an den Punkt gekommen alles auf die Hardware, beziehungsweise auf die Taktung zu schieben
Nutze doch das /proc/bus/at76c651 um einige Daten während des Betriebes auszulesen. Leider hab ich selber keine Sagem, um einige Dinge zu testen.

[AudioSlyer]

Könnte das mit QAM256 nicht ein i2c-Bus Speed Problem sein?
Wie ist denn der Soll- und "max. Habenwert bezüglich kHz?
Sollte das so sein, könnte man einen Loop oder Delay in dem Kernel einbauen.

[Gorcon]

Könnte das mit QAM256 nicht ein i2c-Bus Speed Problem sein?

Kann ich mir nicht vorstellen, denn dann wäre es ja nicht Pegelabhängig. (nimmt man den Pegel runter ist der Empfang i.O. )

Gruß Gorcon

[jmittelst]

Könnte das mit QAM256 nicht ein i2c-Bus Speed Problem sein?

Kann ich mir nicht vorstellen, denn dann wäre es ja nicht Pegelabhängig. (nimmt man den Pegel runter ist der Empfang i.O. )

Gruß Gorcon

Leider ja nicht bei allen Boxen (Tunern)...

cu
Jens

[AudioSlyer]

Wenn aber der I2C Takt zu hoch für den at76c651 ist, kombiniert mit qam256,
könnte es doch zu diesen Problemen kommen, oder?

[Gorcon]

Könnte das mit QAM256 nicht ein i2c-Bus Speed Problem sein?

Kann ich mir nicht vorstellen, denn dann wäre es ja nicht Pegelabhängig. (nimmt man den Pegel runter ist der Empfang i.O. )

Gruß Gorcon

Leider ja nicht bei allen Boxen (Tunern)...

cu
Jens

Mag sein, aber bei den von mir getesteten Boxen (4 Stück) musste ich den Pegel so weit absenken das die AGC nicht mehr in betrieb war, danach ging die BER bis auf Null runter. (mit diesem Pegel hatte ich mit einer Nokia überhaupt keinen Empfang mehr).

Ich habe momentan hier noch 3 SagemBoxen stehen, jedoch kann ich mit QAM 256 nichts mehr testen da seit einem Monat ausser Premiere HD kein QAM 256 mehr eingesetzt wird.

Gruß Gorcon

[PauleFoul]

Ich habe momentan hier noch 3 SagemBoxen stehen, jedoch kann ich mit QAM 256 nichts mehr testen da seit einem Monat ausser Premiere HD kein QAM 256 mehr eingesetzt wird.

Gruß Gorcon

Warum ist den bei Dir kein QAM 256 mehr?? Du kommst doch aus dem
KDG Raum, oder??

[Gorcon]

[OT]
Ich wurde bis vor kurzem von der KDG versorgt in einem NE4 Kabelnetz der Primacom.
Seit einem Monat hat sich die Primacom aber hier selbständig gemacht und hat der KDG die rote karte gezeigt. (Dadurch sind die Kabelgebühren auch gesenkt worden)
Seit dem gibts hier eben kein QAM 256 mehr da alle Programme jetzt mit QAM 64 eingespeist werden und das mit BER Werten von Null.
Die KDG Programme konnte man zuvor auch nur Illegal nutzen da sie nicht freigeschaltet wurden.
[/OT]

Gruß Gorcon

[Artur]

kennt jemand die Bedeutung von P0-P2 bei der PLL-Konfiguration:

Code: Alles auswählen

static int tua6010_setfreq(struct dvb_i2c_bus *i2c, u32 freq)
{
	u32 div;
	u8 buf[4];
	u8 vu, p2, p1, p0;

	/* 47 MHz ... 862 MHz */
	if ((freq < 47000000) || (freq > 862000000))
		return -EINVAL;

	div = (freq + 36118750 + 31250) / 62500;

	if (freq > 401250000)
		vu = 1;	/* UHF */
	else
		vu = 0; /* VHF */

	if (freq > 401250000)
		p2 = 1, p1 = 0, p0 = 1;
	else if (freq > 117250000)
		p2 = 1, p1 = 1, p0 = 0;
	else
		p2 = 0, p1 = 1, p0 = 1;

	buf[0] = (div >> 8) & 0x7f;
	buf[1] = (div >> 0) & 0xff;
	buf[2] = 0x8e;
	buf[3] = (vu << 7) | (p2 << 2) | (p1 << 1) | p0;

	return at76c651_pll_write(i2c, buf, 4);
} 

Ich habe festgestellt, daß mit den Einstellungen P2=1, P1=1 und P0=0 der Empfang besser wird. Bei 121 MHz liegt BER bei <20 und bei 113 Mhz bei 1000-2500. Es gibt aber keine unkorrigierbaren Fehler mehr. P2=0, P1=1 und P0=1 bringt bessere Ergebnisse beim schwachen Signal (erklärt die Wirkung der Dämpfung). Ich habe es allerdings nicht verstanden. Laut Datenblatt sind das Ports, die keinen Einfluß auf die Funktion der PLL haben dürften.
Ich weiß auch nicht, ob die Werte von der Frequenz abhängen. Ich glaube eher, daß QAM64/256 entscheidend ist.

[nightcrawler252003]

Hi,

ich habe mir mal das Datenblatt vom AT76C651 angeschaut, da steht drin das der AT76C651 selber intern ein Quarz hat, der über P0, P1 und P2 gesteuert wird.

Weitherin steht am ende das für Qam256 ein externen Quarz empfohlen wird, da der interne Quarz bei Qam256 wohl zu viele Schwankungen hat, dieser Quarz ist auch verbaut und wenn ich es Richtig interpretiert habe muss damit der externe Quarz benutzt wird der interne Quarz auf den Tabellen-Wert n=2 eingestellt werden, n=2 ist P0=0 P1=0 P2=1, anscheinend gibt es um den externen Quarz zu benutzen dann noch ein weiteres Kommando.

So wie es aussieht wird aber mit dem derzeitigen Treiber der interne Quarz bei Qam256 benutzt und nicht der externe der für Qam256 gedacht ist.

[MarcM]

So wie es aussieht wird aber mit dem derzeitigen Treiber der interne Quarz bei Qam256 benutzt und nicht der externe der für Qam256 gedacht ist.

hmm,
dann müsste man da mal genauer schauen/forschen...allerdings wirds bei mir mit der BN201 auch nicht besser mit den QAM256 Sendern....

Ist jetzt also auch die Frage ob der ext. Quarz von der BN201 angesteuert wird oder nicht....ich hatte vor Wochen mal hier jede Menge I2C Logs von meinen 2 Sagems gemacht...da war jedenfalls kein Unterschied zwischen den BN201 und dem damaligen Yadi Treibern zu erkennen...

Marc

[nightcrawler252003]

Hi,

das hatte ich mich auch gefragt, aber fakt ist bis dato sendet Premiere mit Qam64, also gab es kein grund für Premiere die unterstützung für den externen Quarz in ihren Treibern einzubauen, nur blöd für uns die mit der Box auch QAM256 KD-Kanäle sehen wollen.