Beiträge von Sundtek

transport_stream_id = bitstream_getbits(bs, 16);

Teil der SDT Tabelle. Es heißt auch transport_stream_id in der Spezifikation.

https://www.etsi.org/deliver/e…_60/en_300468v010301p.pdf

5.2.3 Service Description Table (SDT)

service_description_section(){
table_id 8 uimsbf
section_syntax_indicator 1 bslbf
reserved_future_use 1 bslbf
reserved 2 bslbf
section_length 12 uimsbf
transport_stream_id 16 uimsbf

Zitat von kls

Meine Idee geht mehr in die Richtung, die tatsächlichen Daten zu checken.

Der beliegende Patch prüft, ob die gewünschte SID in der PAT enthalten ist und löst einen Retune aus, wenn sie nicht innerhalb von 2 Sekunden gefunden wird. Eine hunderprozentige Lösung ist das freilich auch nicht, denn unterschiedliche Transponder können die selben SIDs verwenden. Eventuell müssen noch weitere Daten mit einbezogen werden (am liebsten ja die Transponder-ID, aber da habe ich auf die Schnelle keine Stelle gefunden, wo man sicher sein kann, die ID des tatsächlich getunten Transponders zu erhalten - falls da jemand drauf deuten kann, bitte her damit!).

Bitte probiert es mal damit. Aber Achtung: der Patch ist experiementell und hat noch einige Debug-Ausgaben. Das soll nur mal ein erster Ansatz sein...

das ist gut, wie wär's auch die Transport Stream ID zu benutzen? Dann sollte es eindeutig sein.

Uwe meinte (nachdem ich das geschrieben hab) dass die Transport Stream ID in der channels.conf hinterlegt ist.

Zitat von HelmutB

Uwe : versuche es einaml mit einer längeren Verzögerung nach dem setzen von 18V und vor dem zurückschalten auf 13V, z.B 100ms: S19.2E 11700 V 9750 t V W100 S0 [71 00 00 00] W100 v

Helmut

Die längere Verzögerung blockiert die 18V doch nur noch länger auf der Leitung (für den anderen Teilnehmer). Nehmen wir an dass der 2. Teilnehmer gerade EPG scannt... da wird eine Kollision dann schon deutlich wahrscheinlicher.

Wenn VDR 2 nun folgende Dinge einstellt während der VDR 1 die Leitung oben hat

Alter Transponder Symbolrate: 22msym; Modulation QPSK

Neuer Transponder Symbolrate: 22msym; Modulation QPSK

Tuner wird da dann ein OK und Locked zurückgeben, egal ob der LNB nun den Transponder wechseln konnte oder nicht - und genau das passiert hier.

Wenn VDR 2 von 22msym; Modulation QPSK auf 27.5MSYM/8PSK wechseln würde dann würde der Tuner im nachfolgendem Schritt kein Hardware-Lock zurückgeben und der VDR würde versuchen Diseqc erneut abzuschicken.

Zitat von kls

Sundtek Kann man sich darauf verlassen, dass ein ioctl()-Aufruf an den Treiber erst dann zurückkehrt, wenn das Signal-Handling auf der Antennenleitung vollständig erledigt ist? Oder ist es möglich, dass der Treiber da was puffert und asynchron abarbeitet?

Ich frage deshalb, weil innerhalb eines VDR ja durch einen Mutex sichergestellt ist, dass immer nur *ein* Tuner die Leitung benutzt. Was aber nicht funktionieren würde, wenn der Treiber asynchron arbeitet.

Sobald ein weiteres Gerät die gleiche Leitung benutzt (anderer VDR oder Receiver) besteht die Möglichkeit einer Kollision natürlich unabhängig davon und bedarf einer Lösung im VDR.

Ist synchron. Es geht im Fall von Uwe soweit ich weiß auch um 2 oder mehrere Systeme die auf der Unicable Leitung sitzen.

Das schwarze Bild kommt bei folgender Situation (bei Unicable)

1. Ein externer Receiver zieht die Leitung auf 18V und schaltet um (z.B ein anderer VDR während er EPG scannt)

2. Es wird ein Sender eingestellt welcher die gleichen Transpondereinstellungen hat wie der vorige. (Modulation & Symbolrate bleiben gleich). Der Tuner liefert ein Hardware Lock und VDR ist glücklich.

Sofern der neue Transponder eine andere Modulation & Symbolrate hat und VDR kein Lock bekommt versucht VDR den Transponder erneut zu tunen (also die Diseqc Befehle erneut abzusetzen).

3. VDR hängt nun auf dem falschen Transponder rum, der liefert zwar Daten aber nicht die richtigen.

Dies wurde mittels folgendem Befehl überprüft (folgender Befehl analysiert den Transportstream der aktuell übermittelt wird, die Befehle greifen auf die Interne Schnittstelle bei den Sundtek Tunern zu):

/opt/bin/mediaclient --tsscan /dev/dvb/adapter0/dvr0

4. Unser Treiber loggt die Diseqc Befehle, wenn Uwe die Befehle manuell absetzt (also ein Re-Tune wie bei einem fehlendem Lock durchführt) bekommt er ein Bild.

/opt/bin/mediaclient -V H

/opt/bin/mediaclient --diseqc "aa bb cc dd ee"

/opt/bin/mediaclient -V V

("aa bb cc dd ee" nimmt er aus unserer Logfile, was VDR halt geschickt hat)

Die SDT (Service Description Table) sollte überprüft werden ob der eingestellte Sender auch wirklich auf dem Transponder vorhanden ist. Falls nicht sollte der Transponder wie bei Punkt 2 behandelt werden (=re-tune)

https://en.wikipedia.org/wiki/Service_Description_Table

Das Problem tritt wohl sehr selten auf.

--- und hier noch wie Uwe es reproduziert hat ---

Jetzt habe ich wieder nachgestellt:

Apr  1 16:07:42 raspberrypi vdr: [2028] switching to channel 26 S19.2E-1-1039-10378 (SR Fernsehen HD)
    Apr  1 16:07:42 raspberrypi vdr: [2217] device 1 TS buffer thread ended (pid=2028, tid=2217)
    Apr  1 16:07:42 raspberrypi vdr: [2216] buffer stats: 389348 (7%) used
    Apr  1 16:07:42 raspberrypi vdr: [2216] device 1 receiver thread ended (pid=2028, tid=2216)
    Apr  1 16:07:43 raspberrypi vdr: [2031] frontend 0/0 locked on channel 26 (SR Fernsehen HD), tp 111053 after 284 ms
    Apr  1 16:07:43 raspberrypi vdr: [2218] device 1 receiver thread started (pid=2028, tid=2218, prio=high)
    Apr  1 16:07:43 raspberrypi vdr: [2219] device 1 TS buffer thread started (pid=2028, tid=2219, prio=high)

Mit dem mediaclient-Tool geschaut, was empfangen wird:

$ /opt/bin/mediaclient --tsscan /dev/dvb/adapter0/dvr0
media scan tp: 0
** NO GROUP GIVEN **
** NO GROUP GIVEN **
** NO GROUP GIVEN **
** NO GROUP GIVEN **
** NO GROUP GIVEN **
** NO GROUP GIVEN **
PMT PID: 0x14b4
  Program Number: 0x286e
  TransportstreamID: 1061
  Encrypted: No
  Service type: 19
  Service running: Yes
  Provider Name: ARD
  Service Name: rbb Brandenburg HD
    --> 0x14bf (27)
    --> 0x14c0 (ISO/IEC 11172 Audio)
    --> 0x14c1 (ISO/IEC 11172 Audio)
    --> 0x14c2 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x14c4 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x029e (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
    --> 0x087b (ISO/IEC 13818-6 type B)
    --> 0x0880 (ISO/IEC 13818-6 type C)
    --> 0x14c3 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
PMT PID: 0x14be
  Program Number: 0x286f
  TransportstreamID: 1061
  Encrypted: No
  Service type: 19
  Service running: Yes
  Provider Name: ARD
  Service Name: rbb Berlin HD
    --> 0x14bf (27)
    --> 0x14c0 (ISO/IEC 11172 Audio)
    --> 0x14c1 (ISO/IEC 11172 Audio)
    --> 0x14c2 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x14c4 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x029e (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
    --> 0x087b (ISO/IEC 13818-6 type B)
    --> 0x0880 (ISO/IEC 13818-6 type C)
    --> 0x14c3 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
PMT PID: 0x14c8
  Program Number: 0x2870
  TransportstreamID: 1061
  Encrypted: No
  Service type: 19
  Service running: Yes
  Provider Name: ARD
  Service Name: MDR Sachsen HD
    --> 0x14d3 (27)
    --> 0x14d4 (ISO/IEC 11172 Audio)
    --> 0x14d5 (ISO/IEC 11172 Audio)
    --> 0x14d6 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x14d8 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x087b (ISO/IEC 13818-6 type B)
    --> 0x0b36 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
    --> 0x0b3c (ISO/IEC 13818-6 type C)
    --> 0x14d7 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
PMT PID: 0x14d2
  Program Number: 0x2871
  TransportstreamID: 1061
  Encrypted: No
  Service type: 19
  Service running: Yes
  Provider Name: ARD
  Service Name: MDR S-Anhalt HD
    --> 0x14d3 (27)
    --> 0x14d4 (ISO/IEC 11172 Audio)
    --> 0x14d5 (ISO/IEC 11172 Audio)
    --> 0x14d6 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x14d8 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x087b (ISO/IEC 13818-6 type B)
    --> 0x0b36 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
    --> 0x0b3c (ISO/IEC 13818-6 type C)
    --> 0x14d7 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
PMT PID: 0x14dc
  Program Number: 0x2872
  TransportstreamID: 1061
  Encrypted: No
  Service type: 19
  Service running: Yes
  Provider Name: ARD
  Service Name: MDR Thüringen HD
    --> 0x14d3 (27)
    --> 0x14d4 (ISO/IEC 11172 Audio)
    --> 0x14d5 (ISO/IEC 11172 Audio)
    --> 0x14d6 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x14d8 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x087b (ISO/IEC 13818-6 type B)
    --> 0x0b36 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
    --> 0x0b3c (ISO/IEC 13818-6 type C)
    --> 0x14d7 (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
PMT PID: 0x14e6
  Program Number: 0x2873
  TransportstreamID: 1061
  Encrypted: No
  Service type: 19
  Service running: Yes
  Provider Name: ARD
  Service Name: hr-fernsehen HD
    --> 0x14e7 (27)
    --> 0x14e8 (ISO/IEC 11172 Audio)
    --> 0x14e9 (ISO/IEC 11172 Audio)
    --> 0x14ea (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x14ec (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
    --> 0x087b (ISO/IEC 13818-6 type B)
    --> 0x08de (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private_sections)
    --> 0x08e4 (ISO/IEC 13818-6 type C)
    --> 0x14eb (ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data)
Total found: 6 PMTs (incl. unknown 0x0000)
Scan finished after 17 packets (3196 bytes)

hr-fernsehen HD war der Sender, der davor eingestellt war.

Jetzt schaue ich in Logfile, was der Sundtek Treiber für ein Diseqc Kommando für hr-fernsehen HD abgesetzt hat:

...
2020-04-01 16:07:42 [421] Set Voltage 18V
2020-04-01 16:07:42 [421] DISEQC> sending commands:
2020-04-01 16:07:42 [421] DISEQC> 71
2020-04-01 16:07:42 [421] DISEQC> 54
2020-04-01 16:07:42 [421] DISEQC> b3
2020-04-01 16:07:42 [421] DISEQC> 02
2020-04-01 16:07:42 [421] DISEQC> 58
2020-04-01 16:07:42 [421] DISEQC> done
2020-04-01 16:07:43 [421] Disabling High Tone (22khz)
2020-04-01 16:07:43 [421] Diseqc execution time: 95 ms
2020-04-01 16:07:43 [421] Set Voltage 13V
2020-04-01 16:07:43 [421] Set Voltage 13V
2020-04-01 16:07:43 [421] Disabling High Tone (22khz)
2020-04-01 16:07:43 [421] Setting Frequency: 1350000
2020-04-01 16:07:43 [421] Setting DVB-S2
2020-04-01 16:07:43 [421] Frequency: 1350
2020-04-01 16:07:43 [421] Symbolrate: 22000
2020-04-01 16:07:43 [421] Checking status 6275597
2020-04-01 16:07:43 [421] Frontend has locked
2020-04-01 16:07:43 [421] INIT_DTV: 0
2020-04-01 16:07:43 [421] TS Sync byte not aligned, realigning stream (0 // 0 // a5 // FEID: 0)
2020-04-01 16:07:43 [421] There have been 10 ts errors within 1 second
...

(1)
$ /opt/bin/mediaclient -V H
Using device: /dev/dvb/adapter0/frontend0
setting voltage
18 Volt (Horizontal)

(2) > Diseqc-Kommando für hr-fernsehen HD:
/opt/bin/mediaclient --diseqc "71 54 b3 02 58"

(3)
/opt/bin/mediaclient -V V

Sobald ich das Diseqc Kommando abgesetzt hatte (2), war sofort ein Bild auf sr-fernsehen HD zu sehen. Das sieht man auch im syslog: rpihddevice: set...

Apr  1 16:10:53 raspberrypi vdr: [2218] rpihddevice: set video codec to H264
Apr  1 16:10:53 raspberrypi vdr: [2043] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
Apr  1 16:10:54 raspberrypi vdr: [2042] rpihddevice: video stream started 1280x720@50p, PAR=1/1
Apr  1 16:10:54 raspberrypi vdr: [2042] rpihddevice: display PAR=1,000, setting video render PAR=1/1

Zitat von vdr_rossi

Leider ist das nicht eingehalten worden. Im Namatek Store sind die nach wie vor als Lagernd gekennzeichnet.

Das schreibt ein Kunde der immer noch auf Ware wartet...

Wir sind dabei und liefern schnellst möglichst aus. Im Laufe der kommenden Woche wird's soweit sein.

Bei Dual S2 fehlen noch die gelaserten Acrylplatten, Dual C ist nun in der Fertigung.

Das Debugging bei Uwe hat auch ein paar Tage gekostet (aber dort ist soweit auch alles gut).

Da die Geräte neu sind gehen wir da jedem Problem sehr genau nach, auch wenn nicht alle Probleme bei uns liegen. Vor allem um zu vermeiden dass andere Kunden auch die gleichen Probleme bekommen und wir nicht mit der Hardware in merkwürdige Situationen laufen; Sollte es schwerwiegende Probleme geben werden die Tuner aus dem Verkauf genommen/storniert und gar nicht erst verschickt (soweit sind die Tuner aber alle in Ordnung).

Wir haben die Geräte zwar äußerst genau getestet, aber haben auch nur unsere definierten Tests durchgeführt (24/7, bei DVB-S/S2/S2X Quad LNB bzw. Signalgenerator mit Last; bei DVB-C Primacom & Signalgenerator)

Dual C und Dual S2 verwenden die gleiche Firmware und den gleichen FPGA Core.

Der Tuner den Vu+ damals als Zusatztuner angeboten hat war Technik Stand 2009, und die werden alle weiterhin unterstützt. Soweit ich weiß war bei den alten Tunern die Netto Umschaltzeit noch 600-900ms (also eher um's 2-3fache höher als bei den aktuellen Tunern).

https://tinyurl.com/ttufrxs

Soweit wir das überprüft haben ist der Tuner bei niedrigeren Frequenzen im Kabelnetz noch ein Stückchen besser als die MediaTV Digital Home/Pro III, Verfügbarkeit ab 9. April 2020 (wir sitzen zur Zeit in der Fertigung und sind auch dabei weitere Dual S2 zu bauen)

Unsere Dual DVB-C Tuner werden wie es derzeit aussieht ab Donnerstag kommender Woche verfügbar sein. Sie verwenden von der USB Seite her die gleiche Technologie wie die Dual DVB-S/S2/S2X Tuner sprich das gleiche FPGA Design, und auch sehr große Hardware-Puffer.

Zitat von SurfaceCleanerZ

Hi,

Der Raspi 1-3 sind ja USB-technisch lahm, der 4 soll ziemlich schnell sein.

Mfg Stefan

Wir haben 320 Mbit via USB 2.0 (4x DVB-S/S2 via Single USB 2.0 Port) auf einem Raspberry PI 3 getestet, das zum Stichwort lahm.

USB 3.0 eignet sich für 8x USB Tuner, wobei wir auf dem Raspberry PI 3 "nur" 7 Tuner zum Laufen gebracht haben, beim 8. Tuner wurde das USB Keyboard gelockt, nach Beendigung des Streams funktionierte das Keyboard wieder. Hier könnte man natürlich noch Hardware PID Filter einsetzen das würde dann wohl auch mit 8 Streams ohne Probleme funktionieren.

hmm vielleicht hab ich mich da verschaut... werde das mal mit Uwe abklären. Eventuell liegt's an seiner diseqc.conf.

Werde es mir morgen remote anschauen woher die Anfrage kommt.

Na es ist nur aufgefallen dass nach den 18V auf einem Tuner der andere Tuner auch auf 13V zurückgeschalten wird (was ja eigentlich nicht notwendig ist da sie nie auf 18V geschalten wurden). Je nach Treiber kann der Umschaltvorgang einfach ein paar Millisekunden zusätzlich andauern. Wenn sich einige andere Tuner im Standby befinden kann das eventuell zu deutlichen Umschaltverzögerungen führen.

Was mir beim VDR aufgefallen ist (hinsichtlich Unicable):

Ein Tuner wird auf 18V geschalten, danach werden die DISEQC Befehle geschickt, und anschließend werden (im Falle unserer Dual Tuner) beide Tuner auf 13V zurückgeschalten. Das ist ein 13V Request zu viel.

Was ich hier für etwas besser halten würde wäre:

Es wird nur ein Tuner für die Spannung und Diseqc verwendet (gut wir können das im Treiber auch noch umlenken), dennoch würde VDR dann den 2. Tuner auch noch auf 13V schalten, eigentlich könnte die LNB Spannungsversorgung des 2. Tuners komplett ausgeschalten werden.

Das er kein Bild erhalten hat lag eventuell an uns da der Treiber die Spannung inkl. dem Diseqc für mehr als 250 Millisekunden belegt hat, aktuell belegt der Tuner die Leitung für ca. 100 Millisekunden (plus was in der diseqc conf so eingestellt ist)

Zitat von sg75

Ich betreibe meinen Rotor mit einem Sundtek-USB-DVB-S2-Stick an einem Raspberry PI.

Das klappt stabil. Ich denke, dass die externe Stromversorgung vom Sundtek-Stick vorteilhaft für die Stabilität ist.

Das Netzteil wird bei unseren DVB-S/S2/S2X Tunern nur zur Stromversorgung der LNBs verwendet, bei den Single Tunern reicht eventuell auch die Stromversorgung des USB Ports für den LNB aus. Die Dual Tuner benötigen zwingend das 12V Netzteil.

Da würde wohl eine Slotblende mit Mutter für die F-Buchse ausreichend sein, von den Muttern hätten wir aktuell schon genug auf Lager.

Werd's mal aufnehmen und nächste Woche mit den Kollegen besprechen damit wir da was in den Shop geben.

Nur zur Info, die Tuner der ersten Serie haben 2mm Bohrungen, die Tuner aus der 2. Herstellung haben dann 3mm Bohrungen (die 3mm Teile sind einfach gängiger und bei der Fertigung besser zu verarbeiten).

Was für Slotbleche benötigt ihr da? Full oder low profile? Wir können uns da ja mal umschauen und ein paar auf Lager legen.

Zitat von JoeBar

Sundtek Sehr cool wären als Option eine Slotblende und ein 12V Molexadapter für eure Tuner, mit der man die Tuner in ein PC Gehäuse einbauen kann.

warhammer als GPU würde ich eine Gigabyte GTX1650 (GTX 1050 ti ist unwesentlich günstiger) nehmen da kannst du wenn es irgendwann unterstützt wird HDR darstellen, außerem sind die Gigabyte Karten semipassiv. In meinem Testsytem bleibt sie beim TV und Filme schauen immer stumm (leider bisher nur FullHD und noch nicht 4K getestet) !

Viele Grüße

Kannst Du mir das Einsatzgebiet für die Slotblende genauer erläutern (eventuell mit Foto)?

Molexadapter wäre soweit kein Problem, können wir aus dem lokalen Elektronikgeschäft hinzugeben falls benötigt.

Zitat von warhammer

OK,

also dann würde ich erstmal so planen:

ansible@bionic (In der Hoffnung das älter=stabiler)

Nvidia GT1030 als Grafikkarte (Gibts ja gut passiv gekühlt)

i3+B365 Board oder Ryzen 3600+B450 Board

Soweit so übersichtlich.

Immer noch keine Idee habe ich bzgl. der Tuner Karten. Eigentlich wollte ich auf USB gehen, aber mehr wie S2 Dual-Karten habe ich nicht gefunden und da die nur USB2 haben bin ich mir da echt unsicher. Also doch vielleicht wieder Steckkarten.

Ich meinte natürlich nicht Hauppauge Companion, sondern Logitech Companion. Blöder automatischer Tippfehler.

Dabei handelt es sich um eine FB mit Erweiterungsbox, die Signale entweder per Netzwerk übertragen kann (Funktioniert bei meinem Fernseher super), oder eben über IR Signale.

Da ist halt die Frage gibt es für den VDR und Kodi eine Möglichkeit per Netzwerk gesteuert zu werden, oder gibt es inzwischen USB IR Empfänger die problemlos funktionieren. Mein alter VDR hat noch einen guten alten seriellen Empfänger...

Danke!

Alles anzeigen

Unsere Dual Lösung ist ziemlich gut geworden, vor allem da wir diesmal auch einen FPGA einsetzen der hier gewisse Unregelmäßigkeiten bei der USB Übertragung abpuffern kann.

Zitat von Lubber

Sundtek scheint auch einen Vierfach Tuner zu planen.

https://www.easy-vdr.de/thread-18748.html#message

Post Nr. 9

Gruß

Lubber

Alles anzeigen

Wir warten hier noch auf neue Quad Leiterplatten, die alten haben im hörbaren Bereich gesurrt (genauer gesagt haben 2 Spannungsregulatoren Kondensatoren zum Surren gebracht, die wurden durch Bauteile anderer Hersteller ersetzt die uns im Fall des Falles auch vor Ort Support mit ihren Bauteilen bieten).

Der funktionable Teil war davon nicht betroffen die 4x Tuner funktionieren sogar ziemlich gut (sogar außerordentlich gut auf einem Raspberry PI 3), freigeben werden wir diese aber erst wenn alle uns aufgefallenen Probleme behoben sind. Mehr wissen wir dann wenn die nächsten Leiterplatten bei uns eintreffen und wir diese bestückt haben.

Wenn Du einen guten Draht zu SES Astra hast kannst Du die vielleicht wirklich davon überzeugen dass sie nur Deine angeforderten Daten übertragen

Unser 120mbit Limit ist nicht das USB Limit (das läge bei 45Mbyte/Sek bei USB 2.0) sondern das Limit des Transponders, selbst wenn Du PID Filter aktivierst werden die Daten immer noch mit der maximalen Bandbreite empfangen).

Je mehr Luft nach oben desto besser ist es hierbei, wobei unser FPGA auch für einen Korridor festgelegt ist und man nicht beliebig langsam oder beliebig schnell dort einspeisen kann. Insgesamt doch eine recht komplexe Geschichte.

Thor5 in Nordeuropa überträgt Transponder mit 73 MBit, es gibt auch noch diverse andere Satelliten die mehr Bandbreite benötigen können.

Ich denke auf Astra gibt's hin und wieder auch diverse Testsignale mit über 70 Mbit, die übertragen zwar (noch) nichts nützliches dennoch halten wir uns an diese zum Testen.

Zitat von kfb77

vielleicht ist es einfach zu viel für den einen USB 2.0 Controller im RaspPi, was er hier verarbeiten muss. Wenn eine Aufnahme läuft und du gleichzeitig eine Aufnahme abspielst, dann ist das auf dem USB Bus los: ganzer Transponder von dem USB Stick, dann wieder ein Stream daraus zurück auf die USB Platte, dann ein Stream von der USB Platte zum Abspielen und vermutlich hast du markad noch am Laufen, der die Aufnahme gleichzeitig wieder von der USB Platte liest.

Das sind 4 parallele Streams und der RaspPi USB Controller ist nicht gerade für beste Performance bekannt. Versuche mal, ob markad abschalten eine Besserung bringt.

Wir haben auf einem Raspberry PI 3 unseren 4x DVB-S/S2 FBC USB 2.0 Tuner getestet dort kamen 320 Mbit (Netto) über die Leitung.

Da sollte man den CPU dann aber langsam etwas hochtakten und nicht mit 600-700MHz im vollen Betrieb fahren.

Single Tuner haben sowieso keine Probleme bei der USB Bandbreite.

Bei den 2x Dual USB DVB-S/S2/S2X Tunern konnten wir dort auch keine Probleme feststellen (wobei die "nur" bis 240 Mbit getestet wurden).

Wer die Tuner mit Astra verwendet hat aber üblicherweise noch Spielraum da viele Sender deutlich unterhalb von 120mbit liegen, bei den Dual Tunern sind die Hardware-Puffer zudem auch riesig (über 1 Mbit, die Tuner wurden ursprünglich auch für Android konzipiert).

Der Raspberry PI 3 hat also eher keine USB Performance Probleme

Zitat von vdr_rossi

Habe mich auch über die Dinge gewundert... aufgrund der überschaubaren Summe habe ich mich dennoch für einen Kauf entschieden.

Mal abwarten wie Lieferzeit usw. ist.

Hatte vor Jahren mal mehrere Sundtek DVB-S2 Sticks im Einsatz. Aber nicht wirklich über einen langen Zeitraum. Habe sie dann verkauft und bin auf Sat>ip umgestiegen.

Sollte bei uns bzw. Namatek ein Dual C Tuner bestellt worden sein, weitere Tuner werden nächste Woche zusammengebaut und verschickt.

Die Leiterplatten verzögern sich leider ein paar Tage sind aber bereits fast fertig.