Erfahrungen mit dem NF-Kompressor

Hallo Frank,

deine Überlegungen betrachten aber nur den gesteigerten Komfort der netzseitigen Teilnehmer. Allerdings ist es durchaus auch von Vorteil, wenn das Signal des Senders auf UKW auch gleich klingt. Wie bereits hier auch erwähnt, hat es gerade für mobile Stationen einen Vorteil.

Aber ich habe soeben eine unliebsame Entdeckung gemacht. Der Banana Pi zeigt erschreckend hohe Prozessorlast beim Einsatz des Kompressors. Nach wenigen Sekunden steigt die Last auf 100%, die CPU wird sehr warm bis heiß und der BPI steigt aus. Ein Neustart ist erforderlich.

Bin mir nur nicht sicher, ob das immer schon so war, oder ob es einen anderen Zusammenhang gibt. Jedenfalls kann ich das reproduzieren. Immer dann, wenn ich den Kompressor im RX1 aktiviere, geht es los. Und das, obwohl wegen der geschlossenen SQL nicht einmal Audio anliegt.

Im TX Zweig ist es kein Problem. Da ist der Kompressor nach wie vor aktiv und die Last bleibt unter 15%, üblich um etwa 10%. Keine Ahnung, warum mir das bis her nicht auffiel. Sobald ich da neue Erkenntnisse habe, werde ich mich dazu noch einmal melden.

Grüße vom Niederrhein..........

Quote from DG7JG

deine Überlegungen betrachten aber nur den gesteigerten Komfort der netzseitigen Teilnehmer

Hmm, eigentlich nicht. Denn der Kompressor (bzw. die "Normierung") würde ja bereits schon auf die Signale wirken, die über den Empfänger hereinkommen. Damit ist das Signal automatisch intern und somit auch bei allen Sendern und bei den netzseitig verbundenen Stationen (EchoLink, RemoteTRX, SvxServer) ok.

Einzig die Signale, die von entfernten Systemen hereinkommen und bei denen kein Kompressor im RX-Zweig aktiv ist, sind nicht betroffen. Zusammengefasst: Das Problem wird (näher) an der Wurzel angepackt. Nämlich direkt bei den RX. Und nicht erst am Ende der Signalkette bei den TX.

Bisher habe ich das jedoch noch nicht ausprobiert. Daher kann ich auch zur Systemlast nichts sagen ...

Wäre schön, wenn Du eine Rückmeldung geben könntest, was die Last angeht.

Hier mehrten sich die Abstürze. Irgendwie seltsam alles. Seltsam auch deswegen, da es längere Zeit gelaufen hat damit. :roll:

Grüße

Stefan

Bei mir funktioniert es in den RX-Abschnitten überhaupt nicht. Ich bekomme dann immer die Fehlermeldung: "Unknown PCM AMP1". Eingetragen habe ich:

[Rx1] 
AUDIO_DEV=alsa:AMP1

Sobald ich das nicht beim RX sondern beim TX einbaue funktioniert es jedoch ...

Hallo Frank,

bei den Fehlern bin ich raus. Bin schon froh, dass ich das so alles hin bekomme. Aber den Eintrag habe ich genau so drin gehabt. Und alle waren begeistert von der Wirkung. Nur, dass eben die Prozessorlast zu hoch ist.

Vielleicht weiß es ja jemand anderes hier....... :geek:

Grüße

Stefan

Nabend,

Kommando zurück. Die hohe von Svxlink erzeugte Prozessorlast hatte ihre Ursache in der Hardware. Die SSD Karte machte bei bestimmten Spannungen hier Probleme.

Frank: Ich kann dir leider bei deinem Fehler nicht helfen, aber hier funktioniert es.

Grüße vom Niederrhein.....

Stefan

Hallo zusammen,

ich muss ein weiteres Mal zurückrudern. :roll:

Nachdem unser BPI inzwischen stabil läuft, ohne die genaue Ursache zu kennen, haben wir uns mit dem Kompressor auf der RX-Seite weiter befasst. Dabei kam die Anwendung "Top" ins Spiel und diese zeigt etwas interessantes.

Wenn, wie beschrieben in der svxlink.conf im RX-Zweig der Kompressor aktiviert wird, zeigt sich nach dem Start von Svxlink unter Top eine normale Auslastung der Prozessors um die 10% +/- 2%. Beobachtet man weiter stellt sich ohne Änderung des Systemzustands, sprich ohne dass gesendet wurde oder irgendetwas aktiviert wurde nach etwa 20 Sekunden eine steigende Last ein, welche dann bei 100% endet.

Dies bleibt auch so und der Prozessor wir erwartungsgemäß etwa 5-6 Grad wärmer. Es ändert sich jedoch sofort, sobald sich eine Station aus dem Netz connected. Danach geht die Last wieder zurück auf die 10% +/- 2%. Dabei brauch noch nicht mal jemand zu sprechen, der eingehende Connect reicht aus. Im weiteren Betrieb ergibt sich auch keine Erhöhung, dieser läuft auch normal ab bis zum nächsten Neustart.

Nun bin ich da etwas in der Zwickmühle. Das Gate läuft hier und wird über PUTTY gestartet. Ich müsste mich danach zunächst selber connecten, mit dem Handy z. B. damit die Last wieder heruntergeht. Die Gefahr, das das vergessen wird ist mir aber zu hoch und ich habe das zunächst wieder zum Leidwesen der netzseitigen Teilnehmer auskommentiert. Schade eigentlich, denn wenn der Kompressor eingebunden ist, der Effekt ist schon sehr gut und wird bereits vermisst.

Die Ursache dafür ist mir schleierhaft. Es läuft keine andere Anwendung, welche ansonsten auf die Soundkarte oder die ALSA Software zugreift. Bei Betrachtung des ALsa-Mixers ist mir aufgefallen, dass sich ein Regler etwas merkwürdig verhält. Der Regler für "Mic links" stellt sich und auch nicht unbedingt reproduzierbar immer wieder mal auf die Einstellung von 33%. Das Mic ist nicht ausgelötet worden, aus Angst, dass Durchkontaktierungen verletzt werden können.
Der Gedanke dahinter war, dass sich der Kompressor vielleicht ein Signal des eingebauten Mic`s als Quelle aussucht und dort wilde Berechnungen anstellt, die zu der hohen Last führen. Auch ein Aufschaukeln von minimalster NF, welche ev. als Brummen intern an der Soundkarte vorliegen, hatten wir überlegt. Der Line-In Regler steht auf die notwendigen 43% für den Betrieb. Selbst wenn man den Eingang des Line-In von der Signalquelle durch Steckerziehen trennt, ändert sich nichts. Der Effekt bleibt.

Soweit zu unseren Erfahrungen. Bleibt zu hoffen, dass jemand weiß, was man dagegen machen kann. Nehme auch gerne Ideen an, um weitere Test durchzuführen.

Grüße vom Niederrhein

Stefan

Hallo alle,

wir stellten gestern einen ganz anderen Effekt fest.
Nach Systemwechsel wurde kürzlich SVXLink neu installiert, es lief problemlos.

Gestern haben wir uns entschlossen, erstmals den NF-Kompressor zu aktivieren.
Nach der Installation/Konfiguration flugs in der svxlink.conf AUDIO_DEV=alsa:plughw:0 durch AUDIO_DEV=alsa:AMP1 ersetzt und Neustart.
Ergebnis: SvxLink startet fehlerlos aber unsere Hardware-RS232 funktioniert nicht mehr, das Rauschsperrenkriterium (SQL_DET=SERIAL) wird nicht verarbeitet.
Nach dem Zurückschalten auf AUDIO_DEV=alsa:plughw:0 ist alles wieder ok.

Wo soll hier ein Zusammenhang sein?

Hat jemand einen Tip? - Danke!

Hi Uli,

ist schon sehr eigenartig. Konntet Ihr eventuell rausfinden, ob das alle seriellen Schnittstellen betrifft oder nur die eine die Ihr gerade nutzt?
Weiterhin: Wie äußert sich der Fehler genau, erscheint die Info "The squelch is OPEN, ... CLOSED" nicht mehr im Log oder erscheint es im Log und SvxLink wertet dieses Öffnen/Schließen nicht mehr aus?

vy 73s de Adi / DL1HRC

Danke für die Reaktion Adi,

Wir haben 4 serielle Schnittstellen Hardwaremäßig in Betrieb.
Der Rechner arbeitet als Host und hat 2 virtuelle Maschinen.
SVXLink arbeitet auf dem Host, da es nicht zu machen war eine ordentliche Soundausgabe auf den virtuellen Maschinen zu schaffen.
Dem Host ist eine Schnittstelle zugewiesen, den VM die restlichen (für APRS-Digi, Funkrufmaster, PR-Box).
Die Info "The squelch is OPEN, ... CLOSED" erscheint nicht mehr im Log!

Ob die anderen Schnittstellen laufen haben wir nicht getestet, bin unterwegs und kann das erst in zwei Tagen prüfen und melde mich noch einmal.

So, schnell vor dem Weggehen noch getestet:
Die anderen Schnittstellen funktionieren.
Schönes Wocheende wünsche ich.....