Telexforum.de

Moin Simon!

Baderbahn hat geschrieben: ↑Di 21. Jun 2022, 19:01 FS will anlaufen, stoppt aber sofort, im Terminal X-Fach folgende Meldung:
Code: Alles auswählen
ALSA lib pcm.c:8545:(snd_pcm_recover) underrun occurred

Hatte ich noch nicht ... vermutlich ein Lastproblem. Scheinbar liefert das Programm nicht schnell genug neue Daten zum Schreiben auf den Audioadapter.

Wie ist die CPU-Last währenddessen? Prüf doch mal, was an Audio rauskommt aus dem Pi, ist das abgehackt? Welches Pi-Modell benutzt du? Gehst du an ein direktes Audio-Gerät (hw:...) oder ist ein Soundserver dazwischen (z.B. Pulseaudio)? Direkt ist besser.

Du könntest auch experimentieren mit den Einstellungen des Ausgabestreams. In der Experimental ist es Zeile 200 in txDevED1000SC.py:

stream = audio.open(format=pyaudio.paInt16, channels=1, rate=sample_f, output=True, input=False, output_device_index=devindex, input_device_index=devindex, frames_per_buffer = 1024)

Normalerweise berechnet PortAudio (die unterliegende Bibliothek) die Größe der ans Device zu sendenden "Häppchen" selbst. Mit frames_per_buffer kann man diese manuell festlegen. Probier mal mit 1024, oder mehr/weniger.

Grüße

Björn

...ihr solltet mal überlegen, ob eine niedrigere Sampling Rate sinnvoll wären. 44,1 kHz mit 16 Bit ist jedenfalls "Kanonen auf Spatzen"...

Das i-Telex macht eine Abtastrate von 12,8 kHz mit 8 Bit... Mono natürlich...

Moin Fred!

FredSonnenrein hat geschrieben: ↑Mi 22. Jun 2022, 10:31 ...ihr solltet mal überlegen, ob eine niedrigere Sampling Rate sinnvoll wären. 44,1 kHz mit 16 Bit ist jedenfalls "Kanonen auf Spatzen"...
Das i-Telex macht eine Abtastrate von 12,8 kHz mit 8 Bit... Mono natürlich...

48 kHz

Aber auch mono!

Aber ja, sehe ich auch so. Ich hatte auch mit Jochen darüber gesprochen (Reim nicht beabsichtigt), hat aber niedrigere Prio bekommen, weil es bei uns soweit gut funktionierte.

Bin mal gespannt, was Simon sagt. Wenn das Thema CPU-Last ist ... eine geringere Abtastrate könnte piTelex mit ED1000 vielleicht auch auf kleineren Pis lauffähig machen.

Könnten wir ggf. für piTelex deine Filterparameter übernehmen?

Grüße

Björn

Hallo Ihr,

das Lustige ist, daß es ja direkt über den Pi geklappt hat...
Der Pi ist ein Pi zero 2W (also der "große" zero, der das ja ansich können sollte)

Was mir heute eingefallen ist: Ich habe piTelex so wie im WIKI beschrieben im Autostart drin. Mal sehen, ob das auch korrekt startet - nicht, daß sich da zwei Instanzen in die Quere kommen oder so.

Vielleicht finde ich heute Abend noch Zeit, mir das anzusehen, ich halte Euch auf dem Laufenden!

Viele Grüße,
Simon

Moin Björn

BjoernS hat geschrieben: ↑Mi 22. Jun 2022, 12:13 Könnten wir ggf. für piTelex deine Filterparameter übernehmen?

Klar, die sind aber auf die Abtastrate abgestimmt.
Für andere Abtastraten also ganz andere Koeffizienten der digitalen Filter erforderlich.
Ich hatte die Parameter damals mit WinFilter errechnet.

Viele Grüße,

Fred

Moin zusammen!

Baderbahn hat geschrieben: ↑Mi 22. Jun 2022, 12:37 Der Pi ist ein Pi zero 2W (also der "große" zero, der das ja ansich können sollte)

Das war Jochens und meine Vermutung ...

Guck doch mal bitte nach der CPU-Last, wenn du die AT drückst (z.B. mit top). Beim 4B sind es 30...40%.

FredSonnenrein hat geschrieben: ↑Mi 22. Jun 2022, 15:44 Klar, die sind aber auf die Abtastrate abgestimmt.
Für andere Abtastraten also ganz andere Koeffizienten der digitalen Filter erforderlich.
Ich hatte die Parameter damals mit WinFilter errechnet.

Habe im SF deine Tabelle und die Winfilter-Daten gefunden, hilfreich. Mit scipy.signal.butter wollte ich dein Mark-Filter nachkonstruieren. Dabei kommt ein Filter mit denselben Nullstellen, aber den Polen -0,176±0.870j raus. Hmm, seltsam, dachte ich mir, Winfilter heruntergeladen und gleiche Daten eingegeben. Was kommt raus? -0,172±0.867j, passt ganz gut zu SciPy, aber beides recht weit entfernt von deinen -0,074±0,890j aus SF.

Sehr verdächtig, beides Winfilter v0.8. Die Mittenfrequenz liegt bei deinen SF-Daten korrekterweise bei 3,15 kHz, bei mir bei 3,375 kHz. Wenn ich als F1 und F2 2,96 und 3,34 kHz einstelle (Bandbreite 190 Hz), komme ich ungefähr auf deine Werte (-0,070±0,899j), ähnlich mit dem Space-Filter. Hast du eine Idee Fred, was ich hier falsch mache, bzw. was F1=3,15 und F2=3,6 kHz genau bedeuten bei deiner Version von Winfilter?

Scheinbar gab es bei v0.8 nochmal eine inkompatible Änderung, oder es ist ein Problem mit neueren Windowsversionen (Kompatibilitätsmodus hilft auch nicht). Habe nämlich deine .wfd-Dateien mal geöffnet, da kommt nur Müll raus: Ein FIR-Bessel-Tiefpass im GHz-Bereich ... interessanterweise ist die Abtastrate gleich F2.

Grüße

Björn

Hallo Björn,

BjoernS hat geschrieben: ↑Do 23. Jun 2022, 12:14 Habe im SF deine Tabelle und die Winfilter-Daten gefunden, hilfreich. Mit scipy.signal.butter wollte ich dein Mark-Filter nachkonstruieren. Dabei kommt ein Filter mit denselben Nullstellen, aber den Polen -0,176±0.870j raus. Hmm, seltsam, dachte ich mir, Winfilter heruntergeladen und gleiche Daten eingegeben. Was kommt raus? -0,172±0.867j, passt ganz gut zu SciPy, aber beides recht weit entfernt von deinen -0,074±0,890j aus SF.

Offen gesagt kann ich mit den komplexen Werten aus der Berechnung nicht viel anfangen.
Bei der Filter-Dimensionierung war mir wichtig, dass die jeweils andere Frequenz brauchbar unterdrückt wird.

BjoernS hat geschrieben: ↑Do 23. Jun 2022, 12:14 Sehr verdächtig, beides Winfilter v0.8. Die Mittenfrequenz liegt bei deinen SF-Daten korrekterweise bei 3,15 kHz, bei mir bei 3,375 kHz. Wenn ich als F1 und F2 2,96 und 3,34 kHz einstelle (Bandbreite 190 Hz), komme ich ungefähr auf deine Werte (-0,070±0,899j), ähnlich mit dem Space-Filter. Hast du eine Idee Fred, was ich hier falsch mache, bzw. was F1=3,15 und F2=3,6 kHz genau bedeuten bei deiner Version von Winfilter?

Nein, überhaupt nicht.
Und weil ich so wenig Ahnung davon habe, habe ich die Berechnung einfach mal in Excel simuliert. Das Ergebnis war brauchbar --> Ende der Untersuchung.

BjoernS hat geschrieben: ↑Do 23. Jun 2022, 12:14 Scheinbar gab es bei v0.8 nochmal eine inkompatible Änderung, oder es ist ein Problem mit neueren Windowsversionen (Kompatibilitätsmodus hilft auch nicht). Habe nämlich deine .wfd-Dateien mal geöffnet, da kommt nur Müll raus: Ein FIR-Bessel-Tiefpass im GHz-Bereich ... interessanterweise ist die Abtastrate gleich F2.

Das kann ich bestätigen, offenbar ein Bug in Winfilter. Mit manueller Eingabe der Parameter kann ich eine binär-identische .wfd erzeugen, aber ich kann diese Datei nicht neu laden.
Warum wieso... Keine Ahnung... Ist ja schon ein paar Jahre her...

VIele Grüße,

Fred

Moin Fred,

danke für die ehrliche Info.

FredSonnenrein hat geschrieben: ↑Fr 24. Jun 2022, 10:04 Bei der Filter-Dimensionierung war mir wichtig, dass die jeweils andere Frequenz brauchbar unterdrückt wird.

Interessehalber, hast du das mit Hardware getestet oder hattest du ein konkretes Ziel wie "<-30 dB" o.ä.?

Habe mal geforscht, zur FSK-Demodulation gibt es noch andere Alternativen, ist aber wohl für unsere Anwendung nur wesentlich komplizierter (z.B. mit Diskriminator oder über den Goertz-Algorithmus).

Habe mal den Profiler angeworfen (allerdings nur am PC):

Ein Herabsetzen der Filterordnung von 4 auf 1 bringt praktisch nichts. Mit 1. Ordnung kommt am Ende praktisch dasselbe Filter heraus, wie i-Telex es benutzt.
Eine andere SciPy-Funktion zum Berechnen zu benutzen, bringt eine merkliche Beschleunigung (lfilter statt sosfilt). Letztere möchte das Filter in einem anderen Format haben und ruft erstere mehrfach auf.
Die Samplerate zu vierteln (48 kHz => 12 kHz) bringt praktisch nichts. So richtig geht es auch nicht, denn viele Audioadapter unterstützen so niedrigere Raten überhaupt nicht. Numpy kann aber recht effizient unterabtasten (d.h. nur jeden x. Wert aus einem Array liefern).
Die Daten vor der Filterung von nativem Format auf 8 Bit herunterzurechnen bringt ein wenig.

Ansonsten verteilt sich die größte Last ungefähr hälftig auf die Filterung und die anschließende Mittelwertbildung.

Simon, habe mal einen kleinen Patch mit 2. und 4. vorbereitet -- probier doch mal aus, ob das reicht für den Zero 2W. Ansonsten könnte man mal mit Cython experimentieren.

Grüße

Björn

Hallo Björn,

bezüglich PiTelex und Zero 2W gibt's gute Neuigkeiten!

Asche auf mein Haupt - der Fehler lag bei mir! Ich hatte die telex.py per rc.local im Autostart.
Via SSH habe ich dann ebenfalls die telex.py gestartet - dadurch läuft PiTelex auf zwei Instanzen und obiger Fehler wird geworfen.

Jetzt habe ich testweise die Autostartzeile in rc.local auskommentiert und siehe da: Ich kann via SSH die telex.py starten, ohne in Konflikt mit der anderen Instanz zu kommen. Das Schreiben via SSH auf dem FS ist "problemlos" möglich.

Ich stehe gerade auf dem Schlauch, wie ich via SSH in die laufende Instanz komme

Also mach' Dir erstmal keinen Kopf, entschuldige bitte, falls ich Dir schon allzuviel Mühe bereitet habe.

P.S. "problemlos" steht in Anführungszeichen, da mein "FS schreibt von selbst Zeichen - Problem" weiterhin besteht. Ich Hoffe, daß die bestellten Federsteckleisten bald kommen, dann kann ich einen sauberen SEU-Prüfstand aufbauen.

Baderbahn hat geschrieben: ↑Sa 25. Jun 2022, 12:08 Ich stehe gerade auf dem Schlauch, wie ich via SSH in die laufende Instanz komme

Die laufende Instanz wurde mit einem Terminal-Multiplexer gestartet?
Probiere doch einfach mal:

Code: Alles auswählen

screen -R

Telexforum.de

Projekt piTelex - Vorstellung

Re: Projekt piTelex - Vorstellung

Re: Projekt piTelex - Vorstellung

Re: Projekt piTelex - Vorstellung

Re: Projekt piTelex - Vorstellung

Re: Projekt piTelex - Vorstellung

Re: Projekt piTelex - Vorstellung

Re: Projekt piTelex - Vorstellung

Re: Projekt piTelex - Vorstellung

Re: Projekt piTelex - Vorstellung

Re: Projekt piTelex - Vorstellung