dvbsnoop Werte unverständlich.

Beitrag von **BPanther** » Mo 2. Jan 2023, 21:45

Das mit dem Script ist möglich, ändert aber nicht viel an der allgemeinen Last wenn Du weiter 0.005 s eingestellt hast durch -A. Man könnte natürlich mit wenigen Handgriffen auch z.B. Parameter -t hinzufügen für eine Zeitangabe, halte ich aber wie gesagt nicht für sinnvoll. Auch in Deinem Fall reicht alle Sekunde vollkommen aus um Schwankungen zu sehen. Auch mit satfind würde man das sehen können, wird aber wohl auch nicht auf der Box bei Dir funktionieren denke ich mal.

Code: Alles auswählen

vuultimo4k:~# satfind --frontend /dev/dvb/adapter0/frontend16
Network (DVB-C): unknown BER: 0 (0%) SNR: 63568 (97%) SIG: 61552 (93%) - [SL]
Network (DVB-C): unknown BER: 4294966934 (6557201%) SNR: 63568 (97%) SIG: 61552 (93%) - [SL]
Network (DVB-C): unknown BER: 4294966934 (6557201%) SNR: 63568 (97%) SIG: 61552 (93%) - [SL]
Network (DVB-C): unknown BER: 4294966934 (6557201%) SNR: 63568 (97%) SIG: 61552 (93%) - [SL]
Network (DVB-C): unknown BER: 4294966934 (6557201%) SNR: 62258 (95%) SIG: 61552 (93%) - [SL]
Network (DVB-C): unknown BER: 4294966934 (6557201%) SNR: 63568 (97%) SIG: 61552 (93%) - [SL]
Network (DVB-C): unknown BER: 4294966934 (6557201%) SNR: 63568 (97%) SIG: 61552 (93%) - [SL]
Network (DVB-C): unknown BER: 4294966934 (6557201%) SNR: 62258 (95%) SIG: 61552 (93%) - [SL]
Network (DVB-C): unknown BER: 4294966934 (6557201%) SNR: 63568 (97%) SIG: 61552 (93%) - [SL]
Network (DVB-C): unknown BER: 4294966934 (6557201%) SNR: 65535 (100%) SIG: 61552 (93%) - [SL]

Code: Alles auswählen

vuultimo4k:~# femon -H -f 16
FE: Vuplus FE (DVBC)
status SCVYL | signal  93% | snr  96% | ber -362 | unc -1225609216 | FE_HAS_LOCK
status SCVYL | signal  93% | snr 100% | ber -362 | unc -1225609216 | FE_HAS_LOCK
status SCVYL | signal  93% | snr  94% | ber -362 | unc -1225609216 | FE_HAS_LOCK
status SCVYL | signal  93% | snr  96% | ber -362 | unc -1225609216 | FE_HAS_LOCK
status SCVYL | signal  93% | snr  94% | ber -362 | unc -1225609216 | FE_HAS_LOCK
status SCVYL | signal  93% | snr  96% | ber -362 | unc -1225609216 | FE_HAS_LOCK
status SCVYL | signal  93% | snr  96% | ber -362 | unc -1225609216 | FE_HAS_LOCK
status SCVYL | signal  93% | snr  96% | ber -362 | unc -1225609216 | FE_HAS_LOCK
status SCVYL | signal  93% | snr  94% | ber -362 | unc -1225609216 | FE_HAS_LOCK

Code: Alles auswählen

vuultimo4k:~# dvbsnoop -frontend /dev/dvb/adapter0/frontend16 -demux /dev/dvb/adapter0/demux16 -dvr /dev/dvb/adapter0/dvr16 -s signal -pd 9 -timeout 100
dvbsnoop V1.4.5X -- http://dvbsnoop.sourceforge.net/
   DEMUX : /dev/dvb/adapter0/demux16
   DVR   : /dev/dvb/adapter0/dvr16
   FRONTEND: /dev/dvb/adapter0/frontend16

---------------------------------------------------------
Transponder/Frequency signal strength statistics...
Capabilities: BER: 1  SNR: 1  SIG: 1  STAT: 1  UBLK: 1
---------------------------------------------------------
cycle: 1  d_time: 0.001 s  Sig: 61552  SNR: 63568  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 2  d_time: 0.114 s  Sig: 61552  SNR: 63568  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 3  d_time: 0.114 s  Sig: 61552  SNR: 63568  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 4  d_time: 0.121 s  Sig: 61552  SNR: 63568  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 5  d_time: 0.118 s  Sig: 61552  SNR: 63568  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 6  d_time: 0.116 s  Sig: 61552  SNR: 63568  BER: 0  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 7  d_time: 0.114 s  Sig: 61552  SNR: 63568  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 8  d_time: 0.115 s  Sig: 61552  SNR: 63568  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 9  d_time: 0.114 s  Sig: 61552  SNR: 63568  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 10  d_time: 0.114 s  Sig: 61552  SNR: 63568  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 11  d_time: 0.115 s  Sig: 61552  SNR: 63568  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 12  d_time: 0.114 s  Sig: 61552  SNR: 63568  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 13  d_time: 0.126 s  Sig: 61552  SNR: 62258  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 14  d_time: 0.114 s  Sig: 61552  SNR: 62258  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 15  d_time: 0.116 s  Sig: 61552  SNR: 63568  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 16  d_time: 0.115 s  Sig: 61552  SNR: 62258  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 17  d_time: 0.123 s  Sig: 61552  SNR: 63568  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 18  d_time: 0.114 s  Sig: 61552  SNR: 63568  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 19  d_time: 0.114 s  Sig: 61552  SNR: 63568  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 20  d_time: 0.115 s  Sig: 61552  SNR: 63568  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 21  d_time: 0.118 s  Sig: 61552  SNR: 63568  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 22  d_time: 0.116 s  Sig: 61552  SNR: 63568  BER: 0  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]
cycle: 23  d_time: 0.114 s  Sig: 61552  SNR: 63568  BER: 4294966934  UBLK: 0  Stat: 0x1f [SIG CARR VIT SYNC LOCK ]

In Anbetracht der unterschiedlichen Ausgaben der 3 Programme, welchem vertraut man nun mehr?!

Alles in allem wirst Du aber wohl weder mit satfind, dvbsnoop noch femon bei Deinem Provider Erfolg haben. Der muß das ja nicht akzeptieren und schickt wenn dann seine eigenen Leute mit Meßgeräten los.

FranzJoseph · Beitrag von **FranzJoseph** » Mo 2. Jan 2023, 22:54

Ja das ist ja halt das Problem. Der glaubt mir ja nicht das ich die Störungen habe. Immer wenn er mit seinem Meßgerät hier erscheint ist alles i.O.
Ich habe ihm gerade einmal einen Tonaussetzer und Klötzchenbildung live zeigen können. Es gibt aber auch zweistündige Sendungen mit 40 Fehlern.
Deshalb will ich die Störungshäufigkeit in Abhängigkeit von der Urzeit erfassen. Mit meinem Log zu Excel Konverter werden dann nur die Schwankungen mit Zeitstempel
erfasst und gezählt. Vielleicht könnten die dann auf die Ursache stoßen. Die UMTS Antennen 20m gegenüber unseres Hauses vielleicht.
Vielleicht haben wir auch einen Hobbyfunker der Stört. Dann wäre es was für die Bundesnetzagentur. Ich sammle erstmal nur Agrumente die vielleicht Rückschlüsse auf irgendwelche Ereignisse zulassen.

Beitrag von **BPanther** » Mo 2. Jan 2023, 23:17

Naja, wenn der direkt an der Hauptdose gemessen hat, mag es auch keine Störungen geben. Genau deswegen habe ich auch mehrfach erwähnt, daß auch nur das, ohne irgendwelche Verteiler, letztlich zählt. Aber Du hast ja noch mind. 1 Verteiler dazwischen den Du bisher nicht abklemmen wolltest.

Funker hat man früher schon gerne irgendwelche Störungen zugeschrieben, die sind das in den wenigsten Fällen. Habe das auch schon oft selbst erlebt. Dazu müssten zudem dann die Störungen weitaus länger und durchgehend anhalten und die sehen auch komplett anders aus wenn unzulässige Geräte verwendet werden würden die einstrahlen könten, was in den wenigsten Fällen der Fall ist.

Beitrag von **vanhofen** » Mo 2. Jan 2023, 23:20

/var/root # femon -help
femon: invalid option -- h

usage: femon [options]
-H : human readable output
-M : minimalized output
-A : Acoustical mode. A sound indicates the signal quality.
-r : If 'Acoustical mode' is active it tells the application
is called remotely via ssh. The sound is heard on the 'real'
machine but. The user has to be root.
-a number : use given adapter (default 0)
-f number : use given frontend (default 0)
-c number : samples to take (default 0 = infinite)

/var/root # femon -H -f 1
FE: DVB-T/T2/C (DVBC)
status SCVYL | signal 99% | snr 88% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal 99% | snr 88% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal 99% | snr 89% | ber 0 | unc 0 | FE_HAS_LOCK
^C
/var/root # femon -H -M -f 1
FE: DVB-T/T2/C (DVBC)
Mon Jan 2 22:46:52 2023 | sig 99% | snr 88% | ber 0
Mon Jan 2 22:46:53 2023 | sig 99% | snr 89% | ber 0
Mon Jan 2 22:46:54 2023 | sig 99% | snr 89% | ber 0
^C

Das ist ab morgen so mit im Image.

FranzJoseph · Beitrag von **FranzJoseph** » Di 3. Jan 2023, 04:51

@vanhofen
Wow. das freut mich sehr. Hat die Sucherei nach einer lauffähigen Variante ein Ende und die neue Option kann ich sehr gut gebrauchen.

@Bpanther
Nun hab ich, um alle Zweifel auszuschließen und nicht selber als Verursacher da zu stehen, den letzten Abzweiger auch noch getrennt.
Kabel geht jetzt also vom Haus-Stern-Verteiler direkt an meinen TV. Ja sogar den Receiver habe ich mal in die Ecke gestellt.
Ja nichtmal in eine meiner Ecken sondern zum Untermieter. Der hat sein eigenes Kabel vom Verteiler in die Wohnung.
Dann ist sogar meine Zuleitung außen vor. Mal sehen was wir dann da für Ergebnisse erzielen. Morgen will ich auch mal, zu testzwecken,
meine Zuleitung mit 75 Ohm abschließen. Gucke ich halt mal DVB-T2. (würd ich sowieso machen, wenn ich nicht ein S*Y-Abo hätte) und
lass beim Untermieter mal die Signalaufzeichnung weiterlaufen.
Das stört ihn nicht, den er nutzt nur Streamingdienste und hat deshalb noch nichts bemerkt. (...wie die meisten hier im Haus)

MfG FJ

Beitrag von **BPanther** » Di 3. Jan 2023, 11:21

Ist/War ja nicht böse gemeint, sondern um auch wirklich alle möglichen Fehlerquellen komplett auszuschließen. Anders machen die das normalerweise auch nicht vom Anbieter, da Messungen grundsätzlich an der Hauptdose gemacht werden, nicht an eigenen Verteilern.

Beitrag von **BPanther** » Di 3. Jan 2023, 13:08

@vanhofen: Habs mit dem -M mal übernommen, allerdings statt gmtime localtime benutzt, da sonst die Zeit falsch ausgegeben wird. Desweiteren habe ich -t <float> hinzugefügt. So kann man den Zyklus direkt verändern, so gibt -t 0.5 alle halbe Sekunde eine Zeile aus.

Code: Alles auswählen

vuultimo4k:~# femon -H -M -t 0.5 -f 16
FE: Vuplus FE (DVBC)
Tue Jan  3 13:11:52 2023 | sig  93% | snr  96% | ber -362
Tue Jan  3 13:11:53 2023 | sig  93% | snr  94% | ber -362
Tue Jan  3 13:11:53 2023 | sig  93% | snr  96% | ber -362
Tue Jan  3 13:11:54 2023 | sig  93% | snr  94% | ber -362
Tue Jan  3 13:11:54 2023 | sig  93% | snr  94% | ber -362
Tue Jan  3 13:11:55 2023 | sig  93% | snr  96% | ber -362
Tue Jan  3 13:11:55 2023 | sig  93% | snr  96% | ber -362
Tue Jan  3 13:11:56 2023 | sig  93% | snr  96% | ber -362

FranzJoseph · Beitrag von **FranzJoseph** » Di 3. Jan 2023, 20:56

@BPanther
Habe ich auch nicht so aufgefasst. Der wahrgenommene Stimmungswechsel hat mich nur irretiert.
Darf ich die Version mit -M und -t auch mal testen? CST ist doch nicht mehr Nightly - oder?
(Tschuldigung für die späte Reaktion aber mein DSL ist heute down. Mache jetzt USB-Tethering. Morgen kommt der Monteur.)

MfG FJ

Beitrag von **Miky** » Di 3. Jan 2023, 20:59

Was meinst Du? Von CST gibt es schon ewig keine Herstellerimages.
Und von uns gibt es schon noch Nightlys

Beitrag von **BPanther** » Di 3. Jan 2023, 21:11

@FranzJoseph: Der Patch ist öffentlich im DDT-GIT und vanhofen wird den sicherlich noch übernehmen. Ich selbst baue keine Images für die CST-Kisten, könnte daher nur fertiges für SH4 (UFS/Spark etc.), MIPS (VU+Duo/DM8000) und ARM (VU+4K, HD51, Bre, H7, E4HD) liefern.

FranzJoseph · Beitrag von **FranzJoseph** » Di 3. Jan 2023, 21:21

@BPanther
HD51 hab ich auch zum testen. oder Dinobot. Ist doch auch arm.
Für CST warte ich auf vanhofen

@Miky
Ne, hast Recht. Von CST gibt es nicht mehr. Aber von NI für CST, meinte ich.

Beitrag von **Miky** » Di 3. Jan 2023, 21:25

Unsere Nightlys machen nur gerade eine kurze Pause. Sollte ggf. ab morgen wieder laufen.

Beitrag von **BPanther** » Di 3. Jan 2023, 21:26

Nun denn, hier sind die 3 - auspacken, Rechte 755.

FranzJoseph · Beitrag von **FranzJoseph** » Di 3. Jan 2023, 21:34

Der UNTERSCHIED auf meiner CST Trinity v2 (Kronos)
ohne -M. Dafür mit Fehlern:

Code: Alles auswählen

CST-6C9BAB:~# femon -H -A -r
FE: Entropic TAVOR demodulator (internal) (DVBC)
Problem retrieving frontend information: Operation not supported
status SCVYL | signal  81% | snr 100% | ber 0 | unc 0 | FE_HAS_LOCK
Problem retrieving frontend information: Operation not supported
status SCVYL | signal  81% | snr 100% | ber 0 | unc 0 | FE_HAS_LOCK

und nun mit -M. und alles schön, sogar mit timestamp:

Code: Alles auswählen

CST-6C9BAB:~# femon -H -A -M -r
FE: Entropic TAVOR demodulator (internal) (DVBC)
Tue Jan  3 20:25:25 2023 | sig  81% | snr 100% | ber 0
Tue Jan  3 20:25:25 2023 | sig  81% | snr 100% | ber 0

@BPanther
-->DANKE<--

Beitrag von **BPanther** » Di 3. Jan 2023, 21:39

Ist das die femon von mir? Und wenn ja, warum immernoch -A beim Aufruf?

FranzJoseph · Beitrag von **FranzJoseph** » Di 3. Jan 2023, 21:44

@BPanther
Hab ich aus dem aktuellen NI nightly.
-A hatte ich noch drin, weil es ja doch ein paar Werte mehr lieferte und -t noch nicht mit drin ist, im NI-Image für die CST Trinity v2 (Kronos).

MfG FJ

Beitrag von **BPanther** » Di 3. Jan 2023, 21:50

Achso, na dann...

BTW: -A wird nicht bei sh4 unterstützt, da gibt es dann eine Fehlermeldung.

Beitrag von **BPanther** » Do 5. Jan 2023, 00:40

Ich habe mal die Darstellung der Zeit geändert, nun auch incl. Millisekunden.

Code: Alles auswählen

vuultimo4k:~# femon -M -H -f 16
FE: Vuplus FE (DVBC)
Thu Jan 05 2023 - 00:40:22.636 | sig  93% | snr  94% | ber -362
Thu Jan 05 2023 - 00:40:23.652 | sig  93% | snr  96% | ber -362
Thu Jan 05 2023 - 00:40:24.666 | sig  93% | snr  96% | ber -362
Thu Jan 05 2023 - 00:40:25.680 | sig  93% | snr  94% | ber -362
Thu Jan 05 2023 - 00:40:26.695 | sig  93% | snr  94% | ber -362

Gefällt mir so etwas besser.

Beitrag von **BPanther** » Do 5. Jan 2023, 01:27

Sorry, Dateien vergessen anzuhängen...

FranzJoseph · Beitrag von **FranzJoseph** » Do 5. Jan 2023, 17:20

@BPanther
Oh ja, mir auch

. Das ist ja nunmal wirklich " human readable".
Das du die Millisekunden noch mit reingenommen hast finde ich toll. Gerade wenn mann in kleinen Intervallen aufzeichnet.
-DANKE-

Neutrino-Images

dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.

Re: dvbsnoop Werte unverständlich.