Mal wieder etwas Langeweile, deswegen habe ich mich mal daran gemacht,
meine damalige ATtiny85-Lösung
Beitrag "Audio Spektrum Analyzer mit ATtiny85"
für einen PiPico umzusetzen. Natürlich erheblich aufgebohrt, da der Pico
wesentlich mehr Rechenleistung zu bieten hat als der kleine Tiny.
Deswegen brauchte ich auch nicht alle Tricks zu verwenden, die ich
damals beim Tiny angewandt hatte.
Die gesamte Signalverarbeitung läuft jetzt mit 32Bit (in verschiedenen
Festkommaformaten, denn eine FPU hat der PiPico nicht).
Es gibt jetzt statt 10 (bzw. 11) Bins im Oktavabstand 19 im
"Halboktavabstand". Zwischen zwei benachbarten Bins unterscheidet sich
also die Mittenfrequenz nicht mehr um den Faktor 2, sondern um den
Faktor sqrt(2).
Dementsprechend mussten die Halbbandfilter steiler werden und sind jetzt
4.er Ordnung statt 3.er wie beim Original.
Außerdem kann das Teil jetzt Stereo, hat also zwei (identische) Kanäle
zu bieten.
Die Ausgabe erfolgt nicht mehr über ein WS2812-Array, sondern über ein
günstiges ILI9341-SPI-Display (in meinem Fall 3,8") und zwar mit 60Hz
Refresh (statt 16,7Hz im Original). Gleich geblieben ist die
Eigenschaft, dass kein Framebuffer im Controller benötigt wird. Denn
damals wie heute hätte der RAM dafür nicht gereicht.
Die Signalverarbeitung erfordert gut 80% der Rechenleistung eines
PiPico Kerns und läuft deshalb komplett auf Core1.
Die Aufbereitung der Daten für das Display läuft auf Core0 und kann bei
besonders ungünstigen Audiodaten (Extremfall: alle Bins gleichzeitig von
0 auf Max) gelegentlich mal aus der Echtzeit geraten. Macht keinen
Schlimmen, der Code ist darauf vorbereitet. Es wird maximal ein kleiner
Ruckler in den Animationen sichtbar. Die Überlastsituation kann man sich
auf Wunsch mit der LED des Pico anzeigen lassen. Mit realer Musik
angesteuert habe ich sie noch nie aufblitzen sehen.
Das Analog-Frontend ist wieder bewusst primitiv gehalten, Anti-
Aliasfilter gibt's also auch hier wieder nicht. Es ist dafür ausgelegt,
Eingangspegel bis +2dBV brauchbar an die ADC des Pico zu liefern.
Ach so: diesmal gibt's auch Quelltexte. Sind für das offizielle
PiPico-C/C++-SDK geschrieben.
Eine Helper-Anwendung (DotNet4.8.1) zur Herstellung eigener Farbschemata
für die Bins habe ich auch gleich beigelegt. Der Screenshot zeigt das
tatsächlich im Code verwendete Design (presenter.c->barcolors[]). Der
Export-Button legt direkt den C-Quelltext in die Zwischenablage.
Sorry übrigens für die Qualität des Videos und des daraus entnommenen
Screenshot. Die Kamera hatte zwar Makrofunktion, aber erhebliche
Probleme mit der Tiefenschärfe und Farbtreue. Das Displaybild sieht also
in der Realität deutlich besser aus als hier gezeigt.
Habe ich das richtig in Erinnerung, dass der Goertzel nur ein Amplitudenspektrum liefert, keine Phasen wie die Fourier-Analyse?
https://de.wikipedia.org/wiki/Goertzel-Algorithmus
Normalerweise bracht man die ja nicht, ist also kein Problem.
Habe ich das richtig in Erinnerung, dass der Goertzel nur ein
Amplitudenspektrum liefert, keine Phasen wie die Fourier-Analyse?
Nein. Goertzel kann auch Phaseninfos liefern. Wird aber in dieser Anwendung nicht benötigt und deshalb werden etwas vereinfachte Goertzels verwendet, die halt nur die Amplitdude liefern können.
Mir ist gerade aufgefallen, dass ich im Analog-Frontend vergessen habe, die beiden Elkos mit Werten auszustatten. Also: 10µF/6.3V. Dürfen aber auch größer sein, kommt nicht so genau drauf an.
Nettes Projekt. Der PicoAnalyzerDesigner funktioniert unter Win11 noch
nicht richtig (keine Farben) 😉.
Das Programm dient vor allem dazu, dass du die Farben selbst nach deinen Wünschen festlegen kannst. Einfach mal in die Ankerpunkte klicken (kleines Rechteck bzw. kleiner Kreis) rechts in der Vorschau.
Nettes Projekt. Der PicoAnalyzerDesigner funktioniert unter Win11 noch
nicht richtig (keine Farben) 😉.
Das Programm dient vor allem dazu, dass du die Farben selbst nach deinen
Wünschen festlegen kannst. Einfach mal in die Ankerpunkte klicken
(kleines Rechteck bzw. kleiner Kreis) rechts in der Vorschau.
Tut halt nicht... Ich habe die Werte nach deiner Vorlage ausgefüllt...
Nettes Projekt. Der PicoAnalyzerDesigner funktioniert unter Win11 noch
nicht richtig (keine Farben) 😉.
Das Programm dient vor allem dazu, dass du die Farben selbst nach deinen
Wünschen festlegen kannst. Einfach mal in die Ankerpunkte klicken
(kleines Rechteck bzw. kleiner Kreis) rechts in der Vorschau.
Tut halt nicht... Ich habe die Werte nach deiner Vorlage ausgefüllt...
Hmmm, seltsam. Die Skalenstriche erscheinen aber. Und die werden mit denselben Methoden gezeichnet wie die eigentliche Bar.
Export-Button ist ja aktiv, benutz den mal und schau dir das Ergebnis in einem Editor an. Sind dann wenigstens da die Farben zu sehen? Einfach mal nur die erste Zeile posten, das reicht schon, um zu sehen, ob da auch alles grau ist oder bunt.
Hmm, also weiss, sollte aber rot sein. Kann ich nicht erklären.
OS ist ein aktuelles Win11.
Ich hab's getestet auf Win11Pro 25H2 Build 26200.8457. Kein Problem, wird hübsch bunt.
Mein Entwicklungsrechner ist Win10 Pro 22H2 Build 19045.6466. Auch kein Problem.
Und, wie gesagt: funktioniert auch unter Mono. Linux Mint 22 "Wilma" mit Mate-Desktop. Das Mono ist allerdings ein wenig aufgebohrt gegenüber der Distribution. Die haben VB rausgeworfen (warum auch immer), ich hab's manuell wieder reingepflanzt, weil ich halt meistens in VB programmiere.
Woran es liegt weiss ich auch nicht. Ich werde es bei Gelegenheit auf einem anderen Rechner probieren. Ist aber nicht super wichtig.
Danke noch mal für das Projekt.
Solche zunächst unerklärlichen Unterschiede liegen manchmal an den Region- oder Spracheinstellungen des Betriebssystems, wegen "." gegenüber "," bei der Konvertierung von Fließkommazahlen. Keine Ahnung, ob das Programm überhaupt solche verwendet.
Tja, Double.Parse hält leider auch dann "0,5" für einen gültigen Wert, wenn "." als Dezimaltrenner konfiguriert ist. Wäre es anders, hätte es wenigstens eine Fehlermeldung gegeben.
So aber wird das Komma als Tausender-Trennzeichen interpretiert. Letztlich ergibt sich also ein Gamma-Wert von 500.0. Gültig, aber führt offensichtlich leider irgendwie dazu, dass aus jeder Farbe (evtl. ausser schwarz) bei der Berechnung weiss wird.
es braucht ein Return
Ja, an dieser Stelle sollte eigentlich mal eine Plausibilitätsprüfung eingebaut werden. Die hätte z.B. sinnlos niedrige oder höhe Gammawerte bemeckern können. Aber leider war der Programmierer zu faul dazu, diese Parameterprüfungen noch einzubauen...
Screenshot.jpg
(200 KB)
Frequencies.png
(5,2 KB)
AnalogFrontend.png
(13 KB)
Designer.png
(14 KB)
