Projekt piTelex - Vorstellung

Vorschläge und Wünsche für zukünftige Features des i-Telex-Systems sowie Fachforum für Entwickler.

Moderator: FredSonnenrein

Antworten
Benutzeravatar

BjoernS
Rank 8
Rank 8
Beiträge: 175
Registriert: Mi 6. Mai 2020, 21:25
Wohnort: Darmstadt
Hauptanschluß: 844767 twtr d

Re: Projekt piTelex - Vorstellung

#191

Beitrag von BjoernS »

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
Folgende Benutzer bedankten sich beim Autor BjoernS für den Beitrag:
Baderbahn
844767 twtr d
Benutzeravatar

FredSonnenrein
Developer
Developer
Beiträge: 1937
Registriert: Fr 3. Jun 2016, 13:49
Wohnort: Braunschweig
Hauptanschluß: 8579924 hawe d

Re: Projekt piTelex - Vorstellung

#192

Beitrag von FredSonnenrein »

...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...
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 531075 (Creed75), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.
Benutzeravatar

BjoernS
Rank 8
Rank 8
Beiträge: 175
Registriert: Mi 6. Mai 2020, 21:25
Wohnort: Darmstadt
Hauptanschluß: 844767 twtr d

Re: Projekt piTelex - Vorstellung

#193

Beitrag von BjoernS »

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 :schwitz: Aber auch mono! :hehe:

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
Folgende Benutzer bedankten sich beim Autor BjoernS für den Beitrag:
Baderbahn
844767 twtr d

Baderbahn
Rank 4
Rank 4
Beiträge: 31
Registriert: Sa 2. Apr 2022, 13:19
Hauptanschluß:

Re: Projekt piTelex - Vorstellung

#194

Beitrag von Baderbahn »

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
Viele Grüße,
Simon / Baderbahn
SEL Lo2001 - 27159 wogro d - noch nicht im i-telex
Benutzeravatar

FredSonnenrein
Developer
Developer
Beiträge: 1937
Registriert: Fr 3. Jun 2016, 13:49
Wohnort: Braunschweig
Hauptanschluß: 8579924 hawe d

Re: Projekt piTelex - Vorstellung

#195

Beitrag von FredSonnenrein »

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
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 531075 (Creed75), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.
Benutzeravatar

BjoernS
Rank 8
Rank 8
Beiträge: 175
Registriert: Mi 6. Mai 2020, 21:25
Wohnort: Darmstadt
Hauptanschluß: 844767 twtr d

Re: Projekt piTelex - Vorstellung

#196

Beitrag von BjoernS »

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 ... :schwitz: 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
844767 twtr d
Benutzeravatar

FredSonnenrein
Developer
Developer
Beiträge: 1937
Registriert: Fr 3. Jun 2016, 13:49
Wohnort: Braunschweig
Hauptanschluß: 8579924 hawe d

Re: Projekt piTelex - Vorstellung

#197

Beitrag von FredSonnenrein »

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
Folgende Benutzer bedankten sich beim Autor FredSonnenrein für den Beitrag:
BjoernS
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 531075 (Creed75), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.
Benutzeravatar

BjoernS
Rank 8
Rank 8
Beiträge: 175
Registriert: Mi 6. Mai 2020, 21:25
Wohnort: Darmstadt
Hauptanschluß: 844767 twtr d

Re: Projekt piTelex - Vorstellung

#198

Beitrag von BjoernS »

Moin Fred,

danke für die ehrliche Info. :lol:
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):
  1. 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.
  2. 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.
  3. 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).
  4. 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. :scratch:

Grüße


Björn
844767 twtr d
Antworten

Zurück zu „Entwickler-Ecke“