Beiträge von rjkm

Wenn das plugin richtig msys=dvbt wählt, sollte es gehen.

Ja, es geht auch alles gemischt. Die Tuner/Demods sind alle einzeln auf der Karte.

Debian unstable mit Standard Debian kernel 4.19.0-1 + mein dddvb git (letzteres hat keine Änderungen, die bzgl. des Problems relevant wären).

Da aber wirklich der PCIe-Link "wackelt", glaube ich nicht, daß es am Kernel liegt, eher an Einstellungen an den PCIe-PHYs. Und die werden im Kernel soweit ich weiß normalerweise nicht angefaßt, nur im BIOS.

Da ich die Probleme, als sie noch auftraten, bei weiterer Belastung der CPU hatte (ich habe immer zum Test ein Kernel gleichzeitig gebaut), kann natürlich noch ein Unterschied ziwschen dem J3355M und dem J3455M bestehen, da letzterer 2 Kerne mehr hat.

Zitat von kls

Ich habe noch ein solches Board, welches noch BIOS 1.20 hat.

Aber leider gibt es auf der ASRock Download-Seite die Version 1.60 nicht (mehr).

Hast du die vielleicht noch und könntest sie mit zum Testen zur Verfügung stellen?

Ich habe nur die vom J3355M (identisches Board nur mit 2-Core statt 4-Core Apollo-Lake).

Man kann aber anscheinend die alten runterladen, wenn man den Download-Link per Hand anpasst.

Soweit ich mich erinnere, mußte man auch erst 1.50 als "Bridge-BIOS" nehmen.

Zitat von kls

Ohne Netzwerklast leuchten die ersten beiden LEDs (von der Hinterkante mit dem TAB2-Stecker her gezählt) permanent, die anderen 3 sind aus.

Mit Netzwerklast blinkt die 5. LED. Sobald der Fehler auftritt leuchtet auch diese permanent, und ich meine, dass die dritte dann ganz schwach leuchtet.

Den Downgrade auf BIOS 1.80 hat das Board angenommen, am Verhalten hat sich aber dadurch nichts geändert.

Die LEDs zeigen, daß der PCIe-Link instabil wird.

Das gleiche hatte ich mit BIOS <1.60 auch. Mit dem 1.60 konnte ich es nicht mehr provozieren.

Ich nehme also an, daß die in >=1.70 wieder etwas geändert haben.

Leider kann man wohl auf das 1.60 nicht zurück.

Flackern die LEDs auf dem Cine-Board, z.B. wenn gleichzeitig das Netzwerk belastet ist?

Nimmt das Board denn z.B einen Downgrade auf das 1.80 BIOS an?

Am I2C hat sich ewig nichts geändert. Da gibt es ja auch kein Problem.

Das Problem ist immer entweder, daß der IRQ verloren geht, oder, daß der PCIe-Link ganz abbricht.

Und dadurch gibt es halt dann Overflows im DMA und Timeouts im I2C.

Bevor ich das 1.9er BIOS probiere, werde ich auch erst mal sehen, ob man zurück auf das 1.6er kann ...

Seit wann hast Du welches BIOS drauf?

Ich habe die Erfahrung gemacht, das es vor 1.6 große Probleme mit z.B. der Cine gab. Mit der 1.6er ist es bei mir aber ganz stabil, auch mit extra Streßtest-Firmware. Neuere BIOSe habe ich nicht probiert.

Die PCIe-Link-Probleme mit DigitalDevices-Karten scheinen mit dem neuem BIOS auch nicht mehr aufzutreten.

Vorher konnte ich diese Probleme mit spezieller Firmware, die den Link komplett auslastet, direkt provozieren.

Mit dem neuem BIOS scheint es bisher keine Probleme zu geben.

Zitat von kls

USB-Adapter und Stick kommen zusammen auf unter 20 Euro. Eine SSD dürfte da wohl etwas höher liegen. Und die PCIe-Slots sind alle schon belegt (entweder direkt durch eingesteckte Empfangskarten oder indirekt durch dort montierte, über Kabel mit der DD-Bridge verbundene Karten.

Ich probiers einfach mal :-).

Klaus

Was für ein J3455M-Board ist das genau?

Ich frage, da es aus eigener Erfahrung und Berichten hier im Board mit DDBridge und Apollo-Lake Probleme geben kann.

Gruß,

Ralph

minisatip geht mit der Hardware nicht. Man kommt z.B. nicht direkt von der CPU aus an den Transportstream.

Das Netzwerkinterface der CPU ist 100MBit und die schafft davon nur so 50Mbit.

Das Streaming macht der FPGA, direkt vom TS-Ausgang der Demods (ggf. über ein CAM) in ein GBit-Port des Switches.

Daher kommt man nicht direkt an den TS. Dafür ist eben die Latenz sehr klein und man kann ohne Probleme alle Transportstreams

komplett streamen.

Bzgl. Hardware und Bootvorgang hatte ich hier auch schon vor ein paar Jahren einiges geschrieben:

https://github.com/DigitalDevi…ob/master/docs/octopusnet

Eine serielle Console gibt es auch auf der Platine. Bei Interesse kann ich dazu noch was schreiben.

Verschiedene input streams kann man über das Property DTV_STREAM_ID auswählen. Das wird soweit ich sehen kann im VDR schon länger unterstützt.
Die Demod der Karte muß es aber auch unterstützen (z.B. der stv0910, eingeschränkt auch der stv0900).

Unabhängig kann man in DVB-S2 für das Physical Layer Scrambling über einen Parameter verschiedene Gold Codes auswählen.
Das hat nichts mit Scrambling für DRM zu tun. Man kann damit aber z.B. die Signale benachbarter Kanäle besser trennen, wenn man geeignet
orthogonale Gold Codes verwendet. Siehe EN302307 Kapitel 5.5.4.

Normalerweise wird immer Gold Code 0 benutzt. Viele der Sender, die MIS benutzen, verwenden aber gleichzeitig auch andere Gold Codes.
Der manchmal angegebene Root Code kann leicht in den Gold Code umgerechnet werden.
Er ist einer der Zwischenwerte in dem oben angegebenen Kapitel 5.5.4.

Die oberen 24 Bits von DTV_STREAM_ID werden in manchen Treibern für die PLS und die Selektion von Root oder Gold mißbraucht.
ddbridge unterstützt das auch, aber zusätzlich auch DTV_PLS nur für den Gold code. Der Root Code ist ja wie gesagt redundant.

Gruß,
Ralph

Das subvendor ffff subdevice ffff deutet auf einen Fehler im Flash hin. Da stehen die Sub-IDs drin.
Das sollte nicht vorkommen.Welche Karte hast Du genau?

Man könnte versuchen, das mit ddtest (in dddvb/apps) zu fixen.
z.B.:

ddtest flashprog -SubVendorID dd010031

für eine CT V7 bzw. dd010022 für eine S2 V7.

Vorsicht! Dabei wird auf das Flash geschrieben, von dem auch der FPGA bootet.

Wenn mehrere ddbridge Karten im Rechner sind, mit "-d X" die richtige auswählen. Besser aber nur mit einer ddbridge Karte im Rechner durchführen.

Alternativ im Treiber vor der Zeile mit

/* in case sub-ids got deleted in flash */

einen Eintrag mit ffff bzw. PCI_ANY_ID einfügen:

DDB_ID(DDVID, 0x0006, PCI_ANY_ID, PCI_ANY_ID, ddb_ctv7),

Wenn das nicht hilft, auf jeden Fall zum Support.

Gruß,
Ralph

Zitat von wolfi.m

Hi,

...die "Digital Devices Cine S2 V7" wohl schon!

Nein.

Zitat von wolfi.m

Gruss
Wolfgang

Und wo steht da DVB-S2X?

Gruss,
Ralph

Zitat von 9000H

Hi,

wie schaut es eigentlich aus mit der Unterstützung von DVB-S2X für die Cine S2 v7 bzw. Max S8?

CU
9000h

Das können beide Karten bzw. die Demods darauf nicht.
Es kann also keine Unterstützung dafür geben.

Gibt es überhaupt schon Karten mit Demods, die S2X können?

iperf sagt auf der OctopusNet bzgl. Streaming nichts aus, da der SoC nichts streamt. Der SAM9G45 kann soweit ich weiß nur ca. 50-60Mbit/s.

Der FPGA streamt direkt mit vollen 1Gbit/s von den Demods in den eingebauten Switch. Mit so wenig Latency wie der FPGA schafft das auch keine reine Software-basierte Lösung (egal ob SoC oder PC). Die OctopusNet ist da bestimmt kein Flaschenhals. Selbst 12 komplette Transport-Streams (wenn man ein paar doppelt streamt) sind kein Problem.

Was ist denn das Teil am Kabel zwischen Technisat-Switch und OcotpusNet? Also das, was in dem Switch-Ausgang steckt?
Dämpfungsglied, Verstärker?

https://github.com/DigitalDevi…ob/master/docs/octopusnet

Zitat von fnu

Nein, in die ProLiant Micro Server lassen sich nur LowProfil Karten einbauen, im Gen8 gar nur eine Karte. Der Slot ist eigentlich für SmartArray Contoller vorgesehen. Wäre aber eine Marktlücke für eine DD MaxS4, 4 Tuner, 2 Anschlüsse ...

Also 1 Eingang/Tuner geht vielleicht. Bei 2 braucht man nochmal LNBH plus Kleinkram. Demods könnte man immer noch 8 haben. Macht aber wirklich nur für Unicable Sinn.

Mehrere Eingänge bei Unicable machen aber auch Sinn, wenn man keinen Multiswitch hat, sondern z.B. zwei Unicable LNBs (z.B. der 24fach von GT-SAT) und diese über 2 Stränge verteilt.

Eine komplette (nicht willkürlich zusammengegrepte) Ausgabe der Kernel-Messages ab Laden des ddbridge Treibers würde mal weiterhelfen.

Ist das jetzt auch immer noch in einem virtuellen System?

Die Bemerkung bzgl. DiSEqC verstehe ich nicht.

Wenn man Unicast anfordert, sollte der SAT>IP-Server auch nur Unicast senden.

Bei der OctopusNet sende ich auch bei Multicast aber auch nur auf den Ports, wo ein Client ist.
(Sie macht aber kein allgemeines IGMP Snooping.)