Danke erstmal für die Antworten. Wovor ich mich am meisten fürchte, ist der Ersatz der alten Kabel durch die USB-Strippe, denn im Cockpit sind die Verhältnisse sehr beengt, und an die Kabelage kommt man nicht sonderlich gut ran.
Posts by Oldsmobile
Registriere dich jetzt, um exklusive Vorteile zu genießen! Als registriertes Mitglied kannst du Inhalte herunterladen und profitierst von einem werbefreien Forum.
Mach mit und werde Teil unserer Community!
Mach mit und werde Teil unserer Community!
-
-
Moin!
Nachdem sich mein Projekt langsam dem Abschluss nähert, habe ich noch ein Problem mit dem Einbau meines Raspi 3B mitsamt USB-2.0-CD-Laufwerk: Der Raspi (+ Tasten-Pad, Bildschirm, Verstärker etc.) kommt in den Autoradio-Schacht im Armaturenbrett, von wo aus zwei (~ 60 cm lange) Kabel zur Mittelkonsole führen:
Die Adern sind recht dick (zwar Litzen, aber viel dicker als die bei USB-3.0-Kabeln üblichen Äderchen), aber weder verdrillt, noch geschirmt.
In die Mittelkonsole kommt das USB-CD-Laufwerk. Nun meine Frage: Kann ich die USB-Buchse des Rapis (via Adapter) an den (weißen) Stecker des vorhandenen Kabels und den Stecker des CD-Laufwerks an den Stecker am anderen Ende des Kabel anschließen und das Laufwerk so über die im Auto schon vorhandene Kabelage anbinden, oder muss ich da wirklich ein USB-Kabel durch den Tunnel zwischen Armaturenbrett und Mittelkonsole durchfrickeln (und die vorhandene Kabelage rausreißen), damit es beim Abspielen nicht zu Aussetzern kommt? Danke!
-
Aaaahhh, Flachbandkabel!
Perfekt wäre es, hätte es eine miniUSB-Buchse am anderen Ende.
-
Moin!
Nachdem ich mittlerweile meinen Pi in das vorgesehene Gehäuse (von einem alten Autoradio) verfrachtet habe, muss ich nun die ganzen USB-Geräte anstöpseln — und habe keinen Platz mehr für gewöhnliche USB-Stecker:
Eines der anzuschließenden Geräte ist die Radio-Platine weiter unten mit miniUSB-Buchse. Die übrigen Geräte befinden sich außerhalb des Gehäuses.
Nun meine Frage: Wie lassen sich hier USB-Geräte anschließen bzw. die USB-Ports des Pi rausführen? Ich habe mich schon ein wenig schlau gemacht und bin auf folgende Lösungen gestoßen:
- Nackten USB-Stecker (der sich komplett in der Buchse versenken lässt) verwenden und passende Adern dranlöten
- Abgewinkelten Stecker anschießen (geht aber nur bei ≤2 Geräten)
- Buchsen vom Pi entfernen und die erforderlichen Adern direkt an die freigelegten Stellen löten (Dieser Vorschlag stammt nicht von mir!)
Da im Betrieb mit Stößen und Vibrationen zu rechnen ist (Pkw…), sollten die Anschlüsse nicht allzu leicht rausrutschen können. Welche Lösung ist nun die praktikabelste?
-
Also, eigentlich war die UART-Konsole schon aus:
Nichtsdestotrotz bin ich nochmal durch raspi-config gegangen, einen Reboot gemacht — und habe urplötzlich einen UART mit der richtigen Gruppe und den richtigen Privilegien:
Warum bloß? War die vorherige Konfig fehlerhaft?
-
Leider stecke ich wieder mal ganz tief in einem Schnittstellen-Problem. Diesmal ist es der UART, an dem ein GPS-Board hängt und das ich per gpsd anspreche. Nach einer Neuinstallation von Raspbian Buster verschluckt sich der gpsd beim Start an falschen User-Rechten für den UART (also /dev/ttyS0). Siehe die Ausgabe von systemctl:
Code
Display Morepi@autoradio:/import/valen/autoradio $ sudo systemctl status gpsd ● gpsd.service - GPS (Global Positioning System) Daemon Loaded: loaded (/lib/systemd/system/gpsd.service; disabled; vendor preset: enabled) Active: active (running) since Sat 2021-09-11 00:05:55 CEST; 17min ago Main PID: 608 (gpsd) Tasks: 1 (limit: 2059) CGroup: /system.slice/gpsd.service └─608 /usr/sbin/gpsd /dev/ttyS0 Sep 11 00:05:55 autoradio systemd[1]: Starting GPS (Global Positioning System) Daemon... Sep 11 00:05:55 autoradio systemd[1]: Started GPS (Global Positioning System) Daemon. Sep 11 00:13:18 autoradio gpsd[608]: gpsd:ERROR: SER: device open of /dev/ttyS0 failed: Permission denied - retrying read-only Sep 11 00:13:18 autoradio gpsd[608]: gpsd:ERROR: SER: read-only device open of /dev/ttyS0 failed: Permission denied Sep 11 00:13:18 autoradio gpsd[608]: gpsd:ERROR: /dev/ttyS0: device activation failed. Sep 11 00:13:18 autoradio gpsd[608]: gpsd:ERROR: /dev/ttyS0: activation failed, freeing device
So sehen die Rechte derzeit aus:
Codepi@autoradio:/import/valen/autoradio $ ls -al /dev/ttyS0 crw--w---- 1 root tty 4, 64 Sep 11 00:06 /dev/ttyS0
Das ist aber nicht, was der gpsd erwartet. So ich mich noch erinnern kann, sah mit der alten Installation die Rechtestruktur so aus:
Passe ich sie von Hand an, läuft das GPS-Board, aber leider nur bis zum nächsten Shutdown! Boote ich den Pi nochmal, habe ich wieder die alte (und falsche) Struktur.
Nun: Was mache ich, damit Raspbian die Rechte an ttyS0 nicht bei jedem Booten zurücksetzt, sondern sie einfach belässt?
-
Welche parallele Schnittstelle ist das? Der alte Centronics-Port, den man früher zum Ansteuern von Druckern nützte? Für den gibt es m.W. USB-auf-Centronics-Adapter fix-fertig.
-
OK, ich habe mir einen Wolf gesucht und gefunden: Es war nicht etwa die ALSA-Konfiguration, sondern ein Dienst namens pigpiod, welcher sämtliche GPIO-Anschlüsse ansteuert und das Taktsignal per PWM oder PCM erzeugt. Standard ist PCM, doch dann trampelt der Dienst der Soundkarte auf die Füße. Das Problem hatte ich schon bei der ersten Einrichtung des Sounds vor einigen Jahren. So geht's richtig:
Mit -t 0 schaltet der Dämon auf PWM um, und der Sound wird nicht mehr gestört.
-
Ich arbeite derzeit mit einem Smartphone-Headset an der Klinkenbuchse des HATs (das am Telefon auch klaglos funzt). Die Stromversorgung geht über eine S.USV, die bisher immer perfekt gearbeitet hat.
-
Weder noch. Das Abspieltempo ist völlig normal, auch die Obertöne sind da, nur klingt alles so, als hätte man Klänge / Stimmen mit einem Harmonizer um eine ganze Oktave nach unten transponiert. Sie klingen auch nicht blechern (vocoder-mäßig).
-
Moin!
Nachdem ich kürzlich das Raspbian von meinem Pi 3B+ komplett neu aufsetzen musste, hapert es mit der Tonausgabe über ALSA und das JustBoomm-DAC-HAT: Alle Klänge haben eine viel zu geringe Tonhöhe (vielleicht ½ der geforderten Frequenz). Dabei ist es egal, welche Sorte von Sound-Daten es ist: Ich habe ein MP3-File mit mpg123 abgespielt und einen kurzen Text mit eSpeak sprechen lassen. Beide tönten viel zu tief. Hier meine Audio-HW-Konfiguration (der Onboard-Sound des Pi ist per Boot-Config ausgeschaltet):
Code
Display More**** Liste der Hardware-Geräte (PLAYBACK) **** Karte 0: sndrpijustboomd [snd_rpi_justboom_dac], Gerät 0: JustBoom DAC HiFi pcm512x-hifi-0 [JustBoom DAC HiFi pcm512x-hifi-0] Sub-Geräte: 1/1 Sub-Gerät #0: subdevice #0 pi@autoradio:/import/valen/autoradio $ aplay -L null Discard all samples (playback) or generate zero samples (capture) jack JACK Audio Connection Kit pulse PulseAudio Sound Server dmixer cdplay dsnooper duplex default sysdefault:CARD=sndrpijustboomd snd_rpi_justboom_dac, JustBoom DAC HiFi pcm512x-hifi-0 Default Audio Device dmix:CARD=sndrpijustboomd,DEV=0 snd_rpi_justboom_dac, JustBoom DAC HiFi pcm512x-hifi-0 Direct sample mixing device dsnoop:CARD=sndrpijustboomd,DEV=0 snd_rpi_justboom_dac, JustBoom DAC HiFi pcm512x-hifi-0 Direct sample snooping device hw:CARD=sndrpijustboomd,DEV=0 snd_rpi_justboom_dac, JustBoom DAC HiFi pcm512x-hifi-0 Direct hardware device without any conversions plughw:CARD=sndrpijustboomd,DEV=0 snd_rpi_justboom_dac, JustBoom DAC HiFi pcm512x-hifi-0 Hardware device with all software conversions usbstream:CARD=sndrpijustboomd snd_rpi_justboom_dac USB Stream Output
Und hier meine /etc/asound.conf:
Code
Display Morepcm.dmixer { type dmix ipc_key 1024 ipc_perm 0666 slave { pcm "hw:0,0" period_time 0 period_size 1024 buffer_size 4096 rate 44100 format S16_LE channels 2 } bindings { 0 0 1 1 } } pcm.cdplay { type dmix ipc_key 1024 ipc_perm 0666 slave { pcm "hw:0,0" period_time 0 period_size 1024 buffer_size 4096 rate 44100 format S16_LE channels 2 } bindings { 0 0 1 1 } } pcm.dsnooper { type dsnoop ipc_key 2048 ipc_perm 0666 slave { pcm "hw:0,0" period_time 0 period_size 1024 buffer_size 4096 rate 192000 format S32_LE channels 2 } bindings { 0 0 1 1 } } pcm.duplex { type asym playback.pcm "dmixer" capture.pcm "dsnooper" } pcm.!default { type plug slave.pcm "duplex" } ctl.!default { type hw card 0 }
Was läuft hier schief?
-
Danke, Bernd666. Ich dachte fast schon kein Mensch benütze noch den TDA. Ich bastle da noch ein wenig rum.
-
Schau mal auf die Tabelle. Das sind 8 Befehls-Bytes à 8 Bit. Meine Frage war ja, ob ich immer, wenn ich dem TDA einen Befehl senden will, alle 8 Befehls-Bytes hintereinander (selbst, wenn sich nur an einem der Bytes etwas ändert) und ganz hinten das Stoppsignal schicken muss. Die Grafik mit der Bit-Sequenz scheint zu suggerieren, eine Nachricht bestünde grundsätzlich aus mehreren Bytes.
-
Moin!
Nachdem der TDA7318-Mixer-Chip immer noch Probleme macht (ignoriert Befehle, doch den I²C-Bus habe ich per Logik-Analysierer geprüft), hätte ich hier folgende Frage: Muss ich immer, wenn ich via I²C einen Befehl an den Mixer schicke, alle acht Befehls-Bytes senden? Die Doku macht da keine eindeutigen Angaben, doch vielleicht kann einer von Euch zwischen den Zeilen lesen:
Register hat der TDA anscheinend nicht. Er versteht lediglich acht verschiedene Befehle, die allesamt (mitsamt Argumenten) 1 Byte lang sind:
In die Variable N (Anzahl Bytes) wird im gesamten Dokument nirgends ein Wert eingesetzt, doch die Tabelle mit den Data Bytes lässt sich dahingehend auslegen, dass immer alle acht Bytes gesendet werden müssen, selbst wenn nur ein einziger Befehl erteilt werden soll, oder sehe ich da etwas falsch? Danke.
-
OK, die Soundkarte war anscheinend tatsächlich in'n Mors! Ich kaufte ein neues Exemplar — und zack! lief es sofort.
-
Nachdem ich von meinem alten Raspi 3B wegen eines Defekts auf einen 3B+ wechseln musste, macht das Sound-HAT (JustBoom DAC HAT) nicht mehr mit: Es wird gar nicht mehr erkannt, obwohl nur der Pi neu ist und das Raspbian ein Update erfahren hat! Selbst wenn ich den I²C-Bus scanne, finde ich es unter seiner Adresse (0x4D) nicht mehr (die anderen Adressen gehören zur USV):
Code
Display Morepi@autoradio:~ $ aplay -l aplay: device_list:272: no sound cards found ... pi@autoradio:~ $ i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- 0f 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --
An der /boot/config.txt habe ich ebenfalls nichts geändert:
Auch werden die Treiber anscheinend geladen:
Code
Display Morepi@autoradio:/proc/device-tree/aliases $ lsmod | grep snd snd_soc_pcm512x_i2c 16384 0 snd_soc_pcm512x 32768 1 snd_soc_pcm512x_i2c snd_soc_justboom_dac 16384 0 snd_soc_bcm2835_i2s 16384 0 snd_soc_core 225280 3 snd_soc_justboom_dac,snd_soc_pcm512x,snd_soc_bcm2835_i2s snd_compress 20480 1 snd_soc_core snd_pcm_dmaengine 16384 1 snd_soc_core snd_pcm 106496 5 snd_compress,snd_soc_pcm512x,snd_pcm_dmaengine,snd_soc_bcm2835_i2s,snd_soc_core snd_timer 32768 1 snd_pcm snd 77824 5 snd_compress,snd_soc_pcm512x,snd_timer,snd_soc_core,snd_pcm regmap_i2c 16384 2 rtc_ds1307,snd_soc_pcm512x_i2c
Zum Schluss noch die aktuelle Systemversion:
Codepi@autoradio:~ $ uname -a Linux autoradio 5.10.17-v7+ #1403 SMP Mon Feb 22 11:29:51 GMT 2021 armv7l GNU/Linux
Heißt das, die Soundkarte ist im Eimer?
-
Hat es der TDA7318 überlebt?
Nein. Ein neuer Chip hat's allerdings gerichtet.
-
mal als 2 Phase, mal als N usw.
In einer Ex-Firma hatten wir mal einen (angestellten) Elektriker, der mal tatsächlich statt N eine zweite L-Ader nahm, um Steckdosen anzubinden. Die Folgen waren etwas unschön und kosteten ihn auch den Job.
Die Draufsicht im Datenblatt ist aber auch etwas fies! Der Halbmond wird zwar dargestellt, die Beschriftung des Chips aber nicht. So setzt man den Chip schon mal verkehrt rum ein:
-
So, ich habe jetzt den Chip mit einem zweiten I²C-Bus und Pegelwandlern ausprobiert und nach mehreren erfolglosen Versuchen den Chip aus dem Steckbrett geholt. Er war schlichtweg verkehrt rum montiert. Richtet man sich nämlich nach der Beschriftung, ist Pin #1 unten links (statt oben links).
-
Nur gut, wenn man's vorher weiß!
Trotzdem danke für den Tipp mit den Wandlern. Ich habe schon mal welche benützt, aber an einem SPI-Bus mit einem 5-Volt-Slave dran. Da steht gar keine Spannung vorher fest, und es gibt zwei Datenleitungen (eine pro Richtung). Der TDA (der ja keine PURs hat) sagt ja übrigens auch: 3 V Mindestspannung auf dem Bus.
Gemäß Norm müssen aber alle I²C-Slaves Open Drain haben.