Posts by SHF

don-baba wrote:

Hier wird es schon gemacht:

https://hackaday.com/2019/07/10/giving-the-pi-4-pci-express/

http://mloduchowski.com/en/blo…berry-pi-4-b-pci-express/

Da hatte also noch einer die Idee.

Hatte ich aber auch schon vermutet, dass es jemand versuchen wird. Der MOD ist einfach zu verlockend .

Das grosse Pad an der Unterseite von dem IC scheint aber nicht ganz ohne zu sein. Der hat ganz schön rum gebraten um den USB-Controller runter zu kriegen.

Ich bin jedenfalls mal gespannt, was sich da noch entwickelt und wie viel Interesse an dem Umbau besteht.

Vielleicht gibt es, bei genug Nachfrage, ja irgendwann mal so eine Version direkt zu kaufen.

M-Reimer wrote:

Was mein LAN-Problem angeht: Ich habe einen zweiten Raspberry 4 bestellt und der hat die Probleme nicht.

Komischer Fehler.

Unterschiede an den Boards sind aber keine zu erkennen?

habichthugo wrote:

Bzgl. fertiger Leuchtmittel (primäer GU5.3 bzw. 12V) bin ich extra mal durch die Nachbarschaft gespeikt, habe aber keine Type gefunden, die halbwegs homogen und konzentiert abstrahlt

Wenn man wirklich einen sauberen Spot sucht, kommt das, was ich an GU5.3 und GU10 Spots bislang gesehen habe, nicht annähernd an die Ikea-Dinger ran.

Die GU5.3 und GU10 Spots scheinen eher das Abstrahlbild der Halogenbirnen zu imitieren. Viele machen das inzwischen auch recht gut.

habichthugo wrote:

Ok, dass wird dann auch heftiges gebastel.

Die Elektronik sitzt im Netzteil, im Kopf ist nur die LED. Elektrisch also Überschaubar.

Was die Montage angeht, muss man sich schon was überlegen.

Ein kompletter Eigenau ist aber auch nicht ohne.

habichthugo wrote:

USB-Variante

Ok, mit USB gibt es die inzwischen also auch .

habichthugo wrote:

Wird wohl auf einen Eigenbau mit LEDs + Lise(n) hinauslaufen, wobei mir das ein bisserl voodoo scheint, welche Linsen zu welchen LED-Bauformen passen

Oh, ich habe das zufällig vor Jahren mal gemacht. Viel try and error (meist letzteres), bis das Ergebis zufriedenstellend war.

Wenn du einen sauber fokussierten Spot haben willst, solltest du eine LED mit nur einen Chip verwenden. Mit den Grossflächigen habe ich das nicht hinbekommen.

Ob die Optik, die es zur LED zu kaufen gibt, machen nicht unbedingt einen klaren Spot. Die meisten gehen eher Richtung der GU-Birnen.

Den besten Lichtkegel hatte ich bei meiner Luxeon-LED damals mit ein Linse von Conrad hinbekommen, die eigentlich nicht für den Zweck gedacht war. Es müsste eigentlich die Nummer 146455 gewesen sein.

holymoly wrote:

den folgenden Hinweis gibt's beim Raspberry Pi Store

Ich könnte schwören, der war, als ich geschaut habe, noch nicht da.

M-Reimer wrote:

Der war eigentlich spätestens seit dem Raspi 3 eh unnötig. Ich habe nie so einen Key gekauft. MPEG2 geht gut auf der CPU.

H.264 und MPEG2 gehen auf meinem Desktop auch locker auf der CPU, doch läuft es mit Beschleunigung irgendwie viel runder, finde ich.

Besonders bei so Dingen wie Sprüngen und schnellem Vor- und Rücklauf.

Die Projektionsspots Jansjö und Tived von IKEA machen sehr saubere Lichtkegel.

Gleichmässig hell zu komplett dunkel, Übergang an einer scharfen Linie. Wie bei einer fokussierbaren LED-Taschenlampe.

Abstrahlwinkel dürften etwa die gesuchten 20° sein.

Das sind allerdings Komplettlampen.

Die Vorschaltgeräte sind AFAIK Konstantstrom-Typen, da könnte man aber was anderes verwenden und dann mehrere Leuchten in Reihe schalten.

Argus wrote:

hier gibt es auch ein (leider wieder) abgespecktes Schaltbild vom 4er

Man sieht wie die Spannungsregler aufgebaut sind, aber sonst ist leider nicht viel damit anzufangen.

Wenigstens so ein grobes Schema, welche Buchse an welchem IC hängt, hätten die doch machen können.

M-Reimer wrote:

Was leicht erreichbar wäre, ist USB-OTG. Das haben die auf die USB-C Buchse gelegt. Reicht aber nicht für Festplatten.

Die Versorgungsbuchse scheint laut Schaltplan endlich zumindest mit USB2 belegt zu sein.

Wenn es als einfacher USB2 nutzbar wäre, würde mir das an USB reichen.

Gibt es für den Raspberry PI 4 eigentlich auch noch den MPEG2 Codec zu kaufen?

Ich habe schon mal gesucht, aber nur alte Seiten gefunden.

M-Reimer wrote:

Ich habe zwar schon etwas überlegt aber so recht fällt mir kein Anwendungsfall ein bei dem ich ohne USB auskomme.

Ganz ohne USB ist natürlich nicht so toll.

Man müsste mal schauen, wo die USB2-Buchsen dran hängen.

M-Reimer wrote:

Irgendwo müsste man für einen VDR-Server halt auch noch Festplatten ranhängen.

An einen SATA-Controller.

Deshalb will ich ja den PCIe frei kriegen .

M-Reimer wrote:

Würde so eine Digital Devices DVB-Karte an einer einzigen PCI-E Lane laufen?

Ja, die sind nur PCIe x1.

Und die Karten laufen auch an PCIe-Splittern. (siehe I2C Timeouts mit ddbridge)

wirbel wrote:

Jede Antenne mit einem Gewinn von mehr als 0dB hat eine Richtwirkung.

Da hast du natürlich Recht. Das war von mir ungünstig formuliert.

Mich würde interessieren, ob die Antenne etwa wie eine (liegende) Stabantenne reagiert, oder ob sich eine Keule von der Platine weg entwickelt.

Funktionsmässig hatte ich mir auch was in der Art vermutet.

Nur wie kommen die das bei der Grösse hin? Wenn ich mich nicht grob verschätzt oder verrechnet habe, liegt die grösste Abmessung deutlich unter Lambda/4.

wirbel wrote:

Sehr wahrscheinlich auch ein sehr schmalbandiges Design.

Schätze ich auch.

Die zweite, kurze Leitung, neben der eigentlichen Speiseleitung, wird dazu dienen, das die Antenne bei 2,4 und 5GHz funktioniert, vermute ich.

koepcke wrote:

Es gibt PCIe Adapter mit denen man PCIe Karten an einem USB Port kann. Dann könnte man SAT Karten weiter benutzen. Ob die Dinger was taugen?

Diese Buchsen sind kein USB!

Das ist "echter" PCIe x1 auf einer USB3 Buchse.

Die USB3 Kabel und Buchsen passen elektrisch, zufällig nahezu perfekt auch für PCIex1 und werden darum dafür missbraucht.

Wenn man es mit der Kabellänge nicht übertreibt, läuft das wohl auch einwandfrei (siehe Link oben).

M-Reimer wrote:

So wie ich das verstanden habe ist man aktuell noch dabei die Raspberry-Bibliotheken überhaupt auf einen Stand zu bekommen, dass die GPU sinnvoll funktioniert.

Schade, damit ist das Teil für mich momentan genauso interessant, wie all die anderen Boards, wo die GPU nicht gescheit unterstützt wird.

Da muss man wohl mal abwarten, ist momentan eh nicht das Wetter für sowas.

Raspberry-Leuten traue ich es zumindest zu, es zu schaffen, es bis zum Winter grob zum laufen zu bringen.

M-Reimer wrote:

Das irgendwann jemand den PCIe rausleitet um andere Karten daran zu betreiben ist abzusehen.

Das ist ja auch eine Steilvorlage.

USB-Chip raus und die PCIe-Pins auf die USB3 überbrücken. Dann kann man so einen 10€ Mining-Riser verwenden.

Nur das Gehäuse von dem USB-Controller könnte zum Problem werden.Das ist auf der Rückseite vollflächig verlötet, keine Ahnung wie und ob man das gescheit runter bekommt.

M-Reimer wrote:

Da fragt man sich doch warum die dann nur zwei USB3-Buchsen bestückt haben?

Ist mir auch schon aufgefallen.

Die nächste Frage ist, ob die USB2-Buchsen überhaupt an dem Chip hängen oder direkt am SOC.

Ich hatte schon überlegt, ob die noch mit USB3 angebundene Komponenten auf dem Board haben, aber ich sehe nichts.

Hat von euch jemand eine sinnvolle Erklärung zur Funktionsweise dieser "Proant resonant cavity antenna" gefunden? Interessantes Design, aber mehr als "da schwingt was im Spalt" hab ich bislang nicht gefunden.

Mich als Anwender würde unter anderem interessieren, ob die Antennne eine Richtwirkung hat.

Wie sieht es denn mit dem HW-Decoder für h.264 aus?

Ist das Teil abwärtskompatibel, so das aktuelle Software (Xine) läuft?

An sich sieht das Teil aber echt interessant aus und endlich ist die Peripherie auch gescheit angebunden. Nur wenn wenn es dann wieder Jahre dauert, bis Xine die Decoder Unterstützt, kann ich den als Client erstmal vergessen.

Das einzige, was mir auf dem Papier nicht so gefällt, ist der USB-Chip von VIA.

Die USB-Controller von denen waren früher nicht so der Binger. Mal sehen, vielleicht haben die ja inzwischen dazugelernt ...
Da der USB-Controller per PCIe angebunden ist und ich eigentlich kein USB3 brauche, könnte man da auch was anderes mit der USB3-Buchse anstellen . Das Board könnte echt interessant werden!

Argus wrote:

[...] Ganz so trivial ist die Geschichte nicht.

Klar, falsch machen kann man immer was.

Generell ist PCIe aber wohl deutlich unempfindlicher als PCI.

So ein 1m "USB3"-Rieserkanel wäre PCI undenkbar.

Ausserdem gibt es bei PCIe x1 nur ein Aderpaar je Richtung.

Wenn da irgendwas falsch läuft muss es eigentlich alle Übertragungen betreffen.

Argus wrote:

wer sagt denn, das dem nicht so ist? Wer hat das in der Tiefe genau analysiert?

kls wrote:

Wir nutzen mit der gleiche CPU ein Board von Faytech ( FAY003 gefertigt von ASUS) das ein solches Verhalten nicht aufzeigt.

Argus wrote:

Selbst hier bei den beiden Asrock PCI-Brigdes sind (laut lspci) nicht identische Controller im Einsatz.

Laut meinen Informationen (man korrigiere mich, wenn ich falsch liege), ist die PCIe-Hostbridge Teil des J3455 SOC.

D.h. alle Boards mit dem Celeron J3455 haben die gleiche.

Argus wrote:

die CorrErr+ werden ein Indiz aber nicht das Problem sein

Die "CorrErr+"-Flags setzt der Empfänger, wenn er defekte Datenpakete empfängt, die er aber noch korrigieren konnte. (Durch Anforderung einer erneuten Übertragung oder wie auch immer.)

Erst wenn Korrektur scheitert, wird auch "UnCorr+"-Flag gesetzt.

Solange also nur "CorrErr+" gesetzt ist, sind die Daten die man bekommt (noch) in Ordnung.

Trotzdem sind dauernd gesetzte "CorrErr+" ein eindeutiges Indiz, dass die Übertragung nicht "sauber" läuft.

Und da die "CorrErr+" immer nur in einem Link auftauchen, an dem eine DD-Karte beteiligt ist, kann das eigentlich nur bedeuten, dass die die Ursache ist.

Argus wrote:

es wird schon, so wie von DD vermutet, ein HW Design Fehler vorliegen. Entweder was im Chipsatz und/oder im PCB Layout.

Meine Vermutung geht in Richtung BIOS.

Am Chipsatz kann es nicht liegen, sonst wären andere Boards mit dem SOC auch betroffen.

Und was kann man bei 6 Daten-Leitungen gross falsch machen?

Argus wrote:

Dann wird es wohl auch so sein, das mehrere Parameter sich hier addieren und nicht einer allein ganz "Schuld" trägt.

Für mich sieht es so aus:

Die Karte arbeitet nicht "sauber" und produziert bei der Übertragung Fehler.

Bei J3455M funktioniert die PCIe-Fehlerkorrektur nicht richtig.

Trifft beides zusammen knallt's.

kls wrote:

Aber nur auf der "Gegenseite":

Das "CorrErr+" wird immer vom Empfänger der Daten gesetzt. (Geht ja auch nicht anders, wie sollte der Sender wissen, ob die Übertragung fehlerfrei war.) Über den Verursacher des Fehler sag das überhaupt nichts aus.

In dem Fall bedeutet das also nur, dass die Fehler in den Daten Richtung Mainboard waren.

Bei einer DVB-Karte gehen typischer Weise viel mehr Daten von der Karte zum Mainboard, als umgekehrt. Daher ist es auch eigentlich zu erwarten, dass die Fehler häufiger in der Richtung auftreten.

HelmutB wrote:

Hat DD auch diese Karte mit dem PCie Analyzer getestet? Es wäre interessant zu wissen, ob es damit auch diese unerwarteten "Nak"s gibt.

Das wäre wirklich mal interessant.

Meine Vermutung ist, die kommen nicht.

Je öfter ich mir die Bilder ansehe, um so weniger sicher bin ich, ob die "Nak" falsch sind.

Logischer finde ich inzwischen, dass das "Ack" direkt nach der Übertragung falsch ist. Angenommen in diesem Paket ist ein Fehler oder es ist unvollständig, müsste nach einem Timeout ein "Nak" folgen (und dann einer erneute Übertragung). Wenn in der Zwischenzeit aber schon ein "Ack" gesendet wurde, weiss die Gegenstelle was sie tun soll, weil das nicht dem Standard entspricht.

Je schneller der Empfänger das "Ack" nach einem Datenpaket zurück schickt, desto eher kann der Sender das nächste Paket schicken. Das Steigert natürlich den Durchsatz.

Für mich riecht das nach einem experimentellen Feature zur Beschleunigung des PCIe-Durchsatzes, das versehentlich noch aktiviert ist. (VIA lässt grüssen .)

Interessante Einblicke, danke fürs Teilen.

- gleichfalls an DD für die Erlaubnis dazu.

kls wrote:

Die aktuelle Aussage von DD ist, dass es sicher am HW-Design des ASRock J3455M Motherboards liegt, wie die angehängten Screenshots ihres PCIe-Analyzers zeigen sollen.

Für eine Sequenz erst ein "Ack" zu senden und dann später ein "Nak", finde ich auch irgendwie unüblich.

(Zur genaueren Bewertung müsste ich mich damit aber näher beschäftigen.)

Nach dem "Nak" hätte ich auch eigentlich eine erneute Übertragung der betroffenen Pakete erwartet. Die findet anscheinend nicht statt.

Wobei die vor dem "Nak" schon akzeptiert wurden ("Ack"), eventuell liegt es daran.

Da scheint also irgendwas mit der PCIe-Fehlerbehandlung auf dem Board falsch zu laufen.

Damit alles auf das Board schieben, macht es sich DD IMHO aber etwas zu einfach.

Die Datenfehler "CorrErr+" wandern immer mit der DD-Karte, ans andere Mainboard, an den PCIe-Riser, ....

Da muss also irgendwas nicht 100% sauber laufen (die anderen Karten machen die ja nicht).
Solange das Fehlerbehandlung klappt, geht die DD-Karte wohl. Erst in Verbindung mit der defekten Fehlerbehandlung wird es dann irgendwann knallen.

Aber da die anderen PCIe-Karten (Riser, Lan, DVBSky und auch alle meine), es schaffen keine "CorrErr+"-Fehler zu produzieren, sollte man sich überlegen, da auch mal anzusetzen.

Ohne die"CorrErr+"-Fehler würde DD auch im J3455M laufen, da würde ich drauf wetten. Das ist da wohl einfach ein ungünstiges Zusammentreffen.

kls wrote:

Man ist wohl mit ASRock in Kontakt, aber ob sich von deren Seite was tut, ist ungewiss.

Vielleicht ist es schon etwas spät, der Nachfolger ist schon raus und das Board ist praktisch im Abverkauf.

Mal sehen, ich drücke die Daumen.

kls wrote:

Mit dem J4105M läuft die DD-Hardware dagegen soweit stabil.

Naja, die CorrErr+ hatte die DD-Karte auf dem Board doch auch?

Das Problem, dass diverse Libs unnötigerweise an dem Auslieferungskernel hingen, hatte ich in Debian auch schon mal.

Ursache war ein fehlendes Metapaket aus dem Bereich.

linux-image-amd64, wenn ich nicht irre, ist aber schon 'ne Weile her.

Einige Debug-Infos zu den Aufnahmen hätte ich mir, bei der Fehlersuche, auch schon ab und an mal gewünscht.

Wäre echt toll, wenn das direkt in den VDR rein kommen würde . Dann hätten alle den gleichen Stand.

Aktuell fallen mir da zwei Sachen ein, die mich interessieren würden:

- Das verwendete DVB-Device ein.

Während der Aufnahme kommt man problemlos dran, später aber nur noch über die Logfiles (falls überhaupt noch vorhanden).

- Fehlende Pakete der Aufnahme.

Da der TS der Aufnahme ja eh neu gepackt werden muss, würde es anbieten an der Stelle die ankommenden Pakete auf Vollständigkeit zu überprüfen. Prinzipiell muss das sogar schon irgendwie gemacht werden, sonst würde ein Fehler ja alles ausser tritt bringen. Ob man da aber einfach einen Fehlercounter dran bekommt, aber ich mir noch nicht angesehen.

ludi wrote:

Ich habe die erste Variante versucht und danach war das Webinterface nicht mehr erreichbar.

Das ist soweit normal. Dass Fritz.box nicht mehr geht, war zu erwarten. Der DNS der Box wird ja deaktiviert.

Die IP ändert sich natürlich auch, die bestimmt jetzt der DHCP-Server auf dem anderen Router (FB ist nur noch Client!).

Die IP für die FB musst du auf dem anderen Router raus finden (und am besten fest zuweisen).
Dann geht auch das Webinterface wieder.

henfri wrote:

irrecord: fatal error in configfile line 50:
irrecord: "begin remote" isn't valid at this position

Immer der Fehler?

Wie sieht denn die konkrete Zeile aus? Das angehängte Beispiel hat keine Zeile 50!

henfri wrote:

Kann man in kleineren Häppchen lernen, so dass der Verlust nicht so groß ist, wenn es schief geht?

Man kann mit einer lircd.conf mit Header, also mit "remote" aber ohne "codes" starten.

Dann fällt die Erkennung der FB weg und man kann gleich anlernen.

henfri wrote:

Die Muster / Gaps sonstwas werden unterschiedlich erkannt,

Bei deutlichen Unterschieden, läuft schon bei der Erkennung der FB was schief.

Weitere Versuche ohne korrekten Header sind nach meiner Erfahrung zwecklos.

Leider senden die Universal-FBs oft mit einem ziemlichen Jitter, so dass die Erkennung schwierig ist.

Ich hatte den Fall selber mal, dass eine funktionierende RC5-FB nicht als solche erkannt wurde. Erst als ich den Header von einer anderen RC-5-lircd.conf "geborgt" habe ging es dann.

Dein Codeschnipsel (SPACE_ENC|CONST_LENGTH und 32Bit) sieht nach NEC oder Samsung-Protokoll aus (Die_IR-Protokolle_im_Detail). Die Werte sind etwas daneben.

Entweder mal anpassen versuchen oder bei Lirc eine entsprechende lircd.conf suchen und nur deren Kopfteil verwenden.

kls wrote:

Ich stehe dem Vorschlag, in der info-Datei ein Zeichen für Plugins zu definieren, offen gegenüber und halte das mal für die 2.5.x fest.

Bitte dabei nur auch an die Skripte-Bastler denken, die nur einfach eine Zeile anhängen wollen.

Fourty2 wrote:

Recording hooks Script, prüft auf TS-Fehler nach Schnitt und sorgt dafür, daß "alles" bei der Aufnahme bleibt:

Mit der extra Datei im Aufnahmeverzeichnis gab es bei mir irgendwie Probleme.

Wenn ich das noch recht erinnere blieb die beim Löschen der Aufnahme stehen. Kann aber sein, dass das inzwischen nicht mehr auftritt.

ludi wrote:

Leider hat sich dank Seahawk1986s Link herausgestellt, dass die 6490 zu den Boxen gehört, die sich nicht als IP-Client einrichten lassen.

Da gibt es zwei Möglichkeiten das einzustellen:

"vorhandener Zugang über LAN"

"weitere Internetanbieter -> andere Internetanbieter -> Anschluss an externes Modem oder Router -> Vorhandene Internetverbindung mitbenutzen"

Beides versucht?

jrie wrote:

Die Anzahl der continuity Fehler der Aufnahme. Sehr hilfreich, wenn man Aufnahmen manchmal erst viel später anschaut, um gleich zu wissen, ob sie OK sind.

Das hatte ich vor einer Weile vor per Script machen zu wollen und leider kein Feld für den allgemeinen Gebrauch in der info-Datei gefunden.

mini73 wrote:

Evtl. könnte man sich ja ein Zeichen für Plugins überlegen?

+1 (s.O.)

Alternativ die könnte man auch die Kommentar-Zeilen (#) beim Schnitt mitnehmen. Damit könnte man auch was anfangen.

Wenn man sich schon die Mühe macht, ein Kommentar in der info einzufügen, dann will man es normalerweise auch drin behalten.

jrie wrote:

Es wäre schöner, wenn der @ Tag mehrfach vorkommen darf.

IMHO keine gute Idee.

Die @-Zeile wird derzeit aus dem Aux.Feld vom Timer erzeugt. Wenn sich ein Programm drauf verlässt, gibt's Chaos.

Ich hab jedenfalls von der Zeile lieber die Finger gelassen, nicht dass es mit EPG-Search Probleme gibt.

ludi wrote:

Sorry, dass ich mich erst relativ spät zurückmelde.

Dito sorry, ich hab die Antwort übersehen.

ludi wrote:

Positionen 5W und 23.5E sind schon mal gestrichen, da Unicable I nach SHF sowieso nur 2 Positionen unterstützt und

um die Gefahr böser Überraschungen zu vermindern. Da Unicable I älter als Unicable II ist, hoffe ich dass es ausgereifter ist.

Problem ist IMHO eher, dass derzeit nicht viele nicht viele Endgeräte Unicable II unterstützen.

ludi wrote:

Wenn ich richtig gegoogelt habe, kosten sie ungefähr 150 Euro :-/ . Diese Summe wäre wahrscheinlich besser in einen professionellen Satinstallateur investiert.

Den du dann aber auch im Fehlerfall erneut beauftragen müsstest.

ludi wrote:

Beim Monoblock reichte die Stromspeisung des Receivers. Anhand der vorausgehenden Erläuterungen verstehe ich es so: beim Quad Monoblock braucht der Receiver immer nur das gerade benutzte LNB des Monoblocks mit Strom zu versorgen; bei zwei Unicable LNBs jedoch, müssen beide ständig aktiv auf Signale horschen, ob ein Receiver ihre Dienste benötigt und gegebenfalls die Daten des gewünschten Transponders liefern.

Das Problem ist, dass einfach nicht zu sagen ist, welcher LNB wann wie viel Strom zieht. Daher muss man vom schlimmsten Fall ausgehen.

Der Quard Monoblock braucht meist etwas mehr als ein einfacher LNB. Er ist aber so ausgelegt, das er an einem Receiver läuft. Das ist ja der normale Anwendungsfall.

Ich glaube mich aber Fälle zu erinnern, wo diese Monoblocks an den alte FF-Karten auch mal Probleme machten.

ludi wrote:

Eine Idee wäre vielleicht Splitter und Combiner in eine Wasserdichte Dose zu stecken; somit blieben nur die F-Stecker am LNB im Regen.

Das ist mehr oder weniger zwingend, falls man nicht spezielle Outdoor-Versionen verwendet.

Aber ausser Regen gibt es auch noch Kondenswasser und UV-Strahlung, die der Installation zusetzen können.

Die "Dose" sollte also schon was taugen ...

ludi wrote:

Mein erster Gedanke war auch, die Stromeinspeiseweiche müsste zwischen Combiner und Splitter, damit die Receiver an den 4 Koaxkabel davon profitieren.

Das ist richtig.

ludi wrote:

Ich bin mir nicht sicher, was du mit den zwei Splittern meinst; ich nehmen an du wolltest folgendes sagen: von den 4 Koaxkabeln, die mir zur Verfügung stehen, werden 3 benutzt, um Receiver zu versorgen und der vierte, um den Strom einzuspeisen. Die 3 Receiverkabel gehen an einen Splitter draußen der sie verbindet; dieser Splitter und der 4. Koaxkabel mit dem Strom gehen an einen zweiten Splitter, der sie verbindet; dieser zweite Splitter geht an den Combiner...

In der Zwischenzeit frage ich mich dann, warum ich den 4. Koaxkabel mit dem Strom nicht einfach an den ersten (vom Zimmer aus gesehen) Splitter mit den anderen 3 Koaxkabeln verbinden kann. Außerdem, muss ich überhaupt ein Koaxkabel für die Stromeinspeisung reservieren? Vor dem Combiner kommt sowieso alles zusammen; warum also nicht einfach die Stromeinspeiseweiche zwischen einem Receiver und einer Satsteckdose anbringen. Übersehe ich vielleicht etwas?

Das eine Kabel nur zur Fernspeisung zu verwenden ist wohl geschickter.

Wenn es Platzmässig aussen machbar ist, würde ich einen fernspeisbaren Multischalter bevorzugen.

Das sollte aber unbedingt ein Modell für den Ausseneinsatz sein und ich würde es auch nur Wetter geschützt montieren.

Argus wrote:

warum nimmst Du nicht einen Einkabelmultischalter bsw. den hier --> http://jultec.de/JPS1701-16.html

Guter Fund.

Der sieht ja fast so aus, als ob das Gehäuse einigermassen wetterfest ist. Leider steht nichts in der Anleitung

Das hat jetzt zwar etwas länger gedauert, da ich ich das Plugin doch noch nicht drauf hatte.

Aktuell geht mit der "jw9" aber folgendes:

Angezeigt werden können die folgenden Ereignisse:

Die Liste ist IMHO nicht ganz ideal. Sachen wie "MUTE" und generell laufende Aufnahmen fehlen leider.

Zuordnung zu den LEDs, in deinem Fall Icons, geschieht im Menü unter OutputNumber.

Die Zuordnung LED -> Icon aus dem LCDproc-Manual:

Viel Spass beim testen.