MH-M18, CSR-8645**, Bluetooth-Audio zum nachrüsten

Der chaotische Hauptfaden

Moderatoren: Finger, Sven, TDI, Heaterman, duese

Antworten
Benutzeravatar
Später Gast
Beiträge: 1052
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

MH-M18, CSR-8645**, Bluetooth-Audio zum nachrüsten

Beitrag von Später Gast » Mo 5. Apr 2021, 13:43

Moin zusammen,

ich hab hier so'n Bluetooth-Audio Board (mh-m18), mit dem ich gerne die Beschallung in der Karre vereinfachen würde. Problem ist nur, sobald das an nen Verstärker angeschlossen ist, hört man recht deutliche Pfeifgeräusche. Galvanische Trennung ist (mittels 2 Übertragern) gegeben. Mit Kopfhörern hört man die Geräusche auch, allerdings viel leiser (Musik ist auch leise über KH). Die Störgeräusche kommen erkennbar vom Chip selbst.

-> Gibt es einfache Schaltungen, mit denen ich die Quietscherei abstellen kann? Ich hab hier noch ne Platine namens BT-Audio rumliegen, die hat das Problem nicht. (macht aber dafür bescheuerte Ansagen und andere Störgeräusche, hat außerdem keinen Eingang für Fernbedienungssignale) Bei dem Board sind 100µF Elkos in Reihe vor den Audioausgang geschaltet. Das allein brachte bei MH-M18 noch keinen Erfolg.

Alternativ nehme ich auch dankend Empfehlungen für bekannt gute Bluetooth-Boards entgegen, Featureset wäre anständiger Klang, keine nervigen Ansagen, keine Störgeräusche, nach Möglichkeit mit Tastern/Eingang dafür. Mikrofoneingang/Fernsprechfunktion wäre ebenfalls nice to have. Jemand schon Erfahrungen mit JDY-64 gemacht? Sieht aus wie das, was ich brauche, aber habe keine Lust jetzt zum dritten Mal zu bestellen, lange zu warten und wieder in die Röhre zu kucken. :|
Die bereits vorhandenen mh-m18 Platinchen zum Funktionieren zu bringen wäre auch im Sinne der Nachhaltigkeit zu bevorzugen.

Grüße
Mo
Zuletzt geändert von Später Gast am Di 27. Apr 2021, 19:01, insgesamt 1-mal geändert.

sysconsol
Beiträge: 3117
Registriert: Fr 8. Jul 2016, 17:22

Re: MH-M18, Bluetooth-Audio zum nachrüsten

Beitrag von sysconsol » Mo 5. Apr 2021, 20:09

Passt nicht ganz zum Thema:

Aufgrund einer aktuellen Erfahrung mit einem OVC3860 stelle ich mir die Frage, ob irgendetwas außer CSRirgendwas überhaupt ernsthaft zu benutzen ist.
Hatte vor, zum OVC3860-Problem noch etwas zu schreiben, dann kam aber die Zeit dazwischen...

Die CSR sind in BT-Kopfhörern recht weit verbreitet, man muss nur einen finden, wo das DSP-Modul auf linear steht (oder man hat einen CSR USB-ISP-Adapter).
Beim Beyerdynamic Byrom BT ist das z.B. der Fall.

sysconsol
Beiträge: 3117
Registriert: Fr 8. Jul 2016, 17:22

Re: MH-M18, Bluetooth-Audio zum nachrüsten

Beitrag von sysconsol » Di 6. Apr 2021, 07:24

Wo kommt das Pfeiffgeräusch eigentlich her?

Ich sehe da zwei mögliche Quellen:
- Betriebsspannung unsauber
- IC konstruktionsbedingt

Ersteres könnte man verbessern.

Testweise mit Batterie versorgen. Mit dicken kurzen Leitungen (wegen deren geringen Widerstand).
Die meisten USB-Kabel sind dafür nicht geeignet, die Steckverbinder machen es nicht besser.

Oder mit einem Oszi anschauen.
Oder prüfen nach Gehör mit einem Kondensator als DC-Sperre an einem Audioeingang.
Ein Software-Oszi für die Soundkarte sollte es auch tun.

Benutzeravatar
Später Gast
Beiträge: 1052
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: MH-M18, Bluetooth-Audio zum nachrüsten

Beitrag von Später Gast » Di 6. Apr 2021, 12:02

sysconsol hat geschrieben:
Di 6. Apr 2021, 07:24
Wo kommt das Pfeiffgeräusch eigentlich her?

Ich sehe da zwei mögliche Quellen:
- Betriebsspannung unsauber
- IC konstruktionsbedingt
Von außen kommender "Lärm" auf der Versorgung existiert, ist aber von den Störgeräuschen, die der Chip selbst macht (gleichbleibende Abfolge von verschiedenen Geräuschen nach Powercycle), klar und deutlich zu unterscheiden und erstmal nicht das Problem. Mein Denkansatz geht im Moment in die Richtung, dass die Strompulse, die der Chip in Sendeleistung (oder sonstwohin) pumpt, auf die Versorgung durchschlagen.
Testweise mit Batterie versorgen. Mit dicken kurzen Leitungen (wegen deren geringen Widerstand).
Die meisten USB-Kabel sind dafür nicht geeignet, die Steckverbinder machen es nicht besser.
Betrieb an Powerbank mit ordentlich Stütz-C sollte ähnliche Wirkung zeigen? Ich hab schon Elken und Kerkos in die Versorgung geklemmt, aber halt auf Breadboard. dann wohl mal mit Anlöten versuchen.
Oder mit einem Oszi anschauen.
Oder prüfen nach Gehör mit einem Kondensator als DC-Sperre an einem Audioeingang.
Ein Software-Oszi für die Soundkarte sollte es auch tun.
Durch die Übertrager ist DC am Amp-Eingang ja auszuschließen. RMK hat mir zwar vor ner Weile ein Oszi vermacht, leider hat das nach einigen Minuten Betrieb beschlossen, dass jetzt der Strahl nicht mehr auf dem Schirm landet. Reverse Kausalketten anyone, wie repariert man ein Oszi ohne Oszi? :lol:
Ich mach dann wohl nach Gehör weiter.

Ein CSR-Irgendwas liegt hier auch in einer Verstärkerplatine verbaut rum, macht doofe Ansagen und war auch nicht Störgeräuschfrei, wimre. Meine Recherchen haben zutage gefördert, dass man die auch mit nem nicht CSR-Adapter proggen kann, wenn man ne gepatchte dll oder sowas ins Installationsverzeichnis packt. Hab das dann aber nicht gemacht weil keine Zeit und Nervt. :cry:

sysconsol
Beiträge: 3117
Registriert: Fr 8. Jul 2016, 17:22

Re: MH-M18, Bluetooth-Audio zum nachrüsten

Beitrag von sysconsol » Di 6. Apr 2021, 12:27

Die Sache mit gepatchter DLL habe ich nach einem Tag aufgegeben. Auch schon wieder 2 Jahre her...
Später Gast hat geschrieben:
Di 6. Apr 2021, 12:02
sysconsol hat geschrieben:
Di 6. Apr 2021, 07:24
Oder mit einem Oszi anschauen.
Oder prüfen nach Gehör mit einem Kondensator als DC-Sperre an einem Audioeingang.
Ein Software-Oszi für die Soundkarte sollte es auch tun.
Durch die Übertrager ist DC am Amp-Eingang ja auszuschließen.
Ich meine das anders.
Wenn man kein Oszi hat, kann man sich behelfen, indem man den Audioeingang vom PC (oder einem Verstärker) DC-mäßig entkoppelt auf die zu untersuchende Leitung klemmt (in diesem Fall die Versorgungsleitung).
Der Übertrager lässt DC-mäßig Strom fließen. Deswegen der Kondensator.
Ein Software-Oszi sollte sich im Internet finden lassen.
Später Gast hat geschrieben:
Di 6. Apr 2021, 12:02
Betrieb an Powerbank mit ordentlich Stütz-C sollte ähnliche Wirkung zeigen? Ich hab schon Elken und Kerkos in die Versorgung geklemmt, aber halt auf Breadboard. dann wohl mal mit Anlöten versuchen.
Abblock-Kondensatoren so nah wie möglich am IC und mit so wenig wie möglich Widerstand.
Später Gast hat geschrieben:
Di 6. Apr 2021, 12:02
Mein Denkansatz geht im Moment in die Richtung, dass die Strompulse, die der Chip in Sendeleistung (oder sonstwohin) pumpt, auf die Versorgung durchschlagen.
Kann gut sein. Siehe die Sache mit den Abblock-Kondensatoren.

Beim OVC3860 habe ich die Probleme im fliegenden Aufbau mit viel zu langen Leitungen nicht gehabt,
später, eingebaut :cry: , hatte ich die Probleme.
Möglicherweise stört sich der Chip selbst.
Seitdem gibt es auch nur noch hörbar komprimiertes Audio :?

Benutzeravatar
RMK
Beiträge: 3323
Registriert: Di 20. Jan 2015, 14:59
Wohnort: östlich von Stuttgart

Re: MH-M18, Bluetooth-Audio zum nachrüsten

Beitrag von RMK » Di 6. Apr 2021, 12:44

Hm, ich bin mir relativ sicher dass "Später Gast" ein Oszi hat... :-)

Benutzeravatar
Später Gast
Beiträge: 1052
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: MH-M18, Bluetooth-Audio zum nachrüsten

Beitrag von Später Gast » Di 6. Apr 2021, 13:11

Ja Robert, dein Oszi hab ich oben ja schon erwähnt, das hat nach ner halben Stunde leider beschlossen zu schielen und wird damit seiner Aufgabe nicht mehr gerecht. So, wie der Fehler aufgetreten ist, könnte ich mir vorstellen, dass es "nur" an verschlissenen Bedienelementen liegt, aber das genauer zu untersuchen fehlte mir bisher die Muße.

@Topic: kaum macht mans richtig, funktionierts auch. :o

Hatte verschiedene Problemstellen in meinem Aufbau, die die gleichen Geräusche verstärkt und sich damit gegenseitig maskiert haben.

1. Stromversorgung mit gemeinsamer Masse = Ground Loop. Gelöst durch Versorgung aus Powerbank + C.
2. Enstreuungen über ungeschirmte Steckverbindungen im Audiosignalpfad. Geschirmte Kabel direkt an der Platine angelötet und Ruhe war.

2. War der Knackpunkt, die Verbesserung aus der getrennten Stromquelle ist hinter den Einstreuungen verschwunden.
IMG_20210406_124041.jpg
Werde das Teil wohl aus einem isolierenden DCDC-Wandler versorgen müssen. Dann brauche ich wahrscheinlich auch die Übertrager nicht mehr, was Einstreuungen auf dem Wege auch nochmal deutlich reduzieren sollte.

Merke: Steckbretter sind des Teufels! :evil:

Benutzeravatar
Bastelbruder
Beiträge: 8514
Registriert: Mi 14. Aug 2013, 18:28
Wohnort: drunt' am Neckar - km142,7

Re: MH-M18, Bluetooth-Audio zum nachrüsten

Beitrag von Bastelbruder » Di 6. Apr 2021, 13:13

Glück gehabt!

Und ich bin relativ sicher daß ein Oszi oder der, der davor sitzt, den Fehler nicht findet. Hilfreich wäre ein Spektrumanalyzer mit Line-/Mikrofoneingang, den man AC-gekoppelt anschließt.

Benutzeravatar
Später Gast
Beiträge: 1052
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: MH-M18, Bluetooth-Audio zum nachrüsten

Beitrag von Später Gast » Di 6. Apr 2021, 17:02

Bastelbruder hat geschrieben:
Di 6. Apr 2021, 13:13
Glück gehabt!
Zumindest ein Bisschen. Ganz ohne Störgeräusche ist es immernoch nicht. es macht zb bei ca 400Hz einen charakteristischen An/Aus- bupf-Sound, den ich sehr ähnlich auch schon an anderen Chinesischen DACs gehört habe, dfPlayer mini zB, aber auch anderen Bluetooth-Dongeln.

Der Vollständigkeit halber mal noch andere Produkte angesprochen:

Diese hier habe ich bestellt und wegen lauter störender Ansagen für unbrauchbar empfunden: Amazon
Abseits der sehr störenden Ansagen bei voller Lautstärke hat es auch ohne galvanische Trennung keine übermäßigen Probleme mit Störgeräuschen. Allerdings: Lauter Knackser bei Powercycle, bei Pausen (auch bei kurzen <1s) im Song wird der DAC abgeschaltet und danach wieder angeschaltet. Erzeugt obigen 400-Hz Bupf.

Düse berichtet hier gutes über ein "xy-bt mini" Selbst noch nicht getestet, das macht aber offenbar keine Probeme bei gemeinsamer Masse zwischen Quelle und Amp.

Da ich jetzt eh die DCDCs bestellen muss, kann ich mir auch gleich noch n paar andere Bluetooth-Brettchen ordern, mal schauen, welche Fehler und Problemchen da so reingepfuscht wurden. ;)
CSR-irgendwas wird wohl dabei sein. Werde berichten.

Benutzeravatar
sukram
Beiträge: 1149
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: MH-M18, Bluetooth-Audio zum nachrüsten

Beitrag von sukram » Di 6. Apr 2021, 17:10

Wobei es da selbst innerhalb einer Bestellung verschiedene Module geben kann. Ich habe hier zwei identische BT Audio Module, aus einer Bestellung. Das eine macht keine Signaltöne, lässt nur eine Kopplung gleichzeitig zu und spielt unauffällig. Das zweite macht bei jedem Furz ansagen in Engrisch, kan dafür zwei Geräte gekoppelt haben und schaltet automatisch um, wer als letztes etwas sendet. :roll:

Ob es da Konfigtools gibt wie für CSR/Ftdi/Silabs Chips?

sysconsol
Beiträge: 3117
Registriert: Fr 8. Jul 2016, 17:22

Re: MH-M18, Bluetooth-Audio zum nachrüsten

Beitrag von sysconsol » Di 6. Apr 2021, 19:54

Später Gast hat geschrieben:
Di 6. Apr 2021, 13:11
Stromversorgung mit gemeinsamer Masse = Ground Loop. Gelöst durch Versorgung aus Powerbank + C.
Du hast etwas von NF-Übertragern geschrieben.
Wo hast du da eine Masseschleife her, die jetzt durch einen DC-DC-Wandler unterbrochen werden soll?

Ich habe angenommen, dass die NF-Übertrager direkt an das Board an die dafür vorgesehenen Kontakte angeschlossen wurden :?
Und natürlich, dass es getrennte Leitungen für Signal und Stromversorgung gibt - das betrifft auch das Bezugspotential (welches hier Masse genannt wird).


Was die CSR-Chipsets angeht:
Wer sich damit nochmals beschaftägen will, könnte überlegen, wie man sich den Inhalt des Konfig-ROM als hex-Datei ausgeben lässt und in den I2C-EEPROM schreibt.
Das spart den CSR USB-SPI-Adapter.
Alternativ: Hat jemand den Adapter und einen konfigurierten CSR-Chip?
Dann braucht man möglicherweise nur das EEPROM kopieren - solange der selbe CSR-Chip verwendet wird.
Das Abschaltgeräusch ist mir beim Byron BT noch nicht aufgefallen - muss ich am Wochenende mal probieren.
Entweder habe ich das noch nie gehört oder die Konfiguration lässt einen Timeout zu, der auf einem praktikablen Wert steht.
Bastelbruder hat geschrieben:
Di 6. Apr 2021, 13:13
Und ich bin relativ sicher daß ein Oszi oder der, der davor sitzt, den Fehler nicht findet. Hilfreich wäre ein Spektrumanalyzer mit Line-/Mikrofoneingang, den man AC-gekoppelt anschließt.
Kommt auf den an, der davor sitzt - eben ;)

Software-Spektrumanalysator für die Soundkarte gibt es aber auch im Internet zu finden - sogar legal ohne Bezahlung.


Es gibt noch eine ganz einfache Lösung:
Das viele Geld, was man in zig Boards investiert hat, zusammenrechnen und sich dann fragen, warum man nicht in einen Bluetooth-Audio-Receiver investiert hat.
z.B. der Renkforce BTR1500 macht keine Ansagen. Musser auch nicht, hat ja keinen Akku und kann nicht freisprechen.
Hat aber auch keine Taster/Fernbedienung.
Irgendwas ist immer :roll:
Die Eltern haben sich jedenfalls über die Kiste noch nicht beschwert, dann _muss_ die funktionieren. :lol:

sysconsol
Beiträge: 3117
Registriert: Fr 8. Jul 2016, 17:22

Re: MH-M18, Bluetooth-Audio zum nachrüsten

Beitrag von sysconsol » Di 6. Apr 2021, 19:56

sukram hat geschrieben:
Di 6. Apr 2021, 17:10
Ob es da Konfigtools gibt wie für CSR/Ftdi/Silabs Chips?
Ich habe außer für die CSR noch kein Konfigtool gefunden.
Noch nicht mal eine Beschreibung, wie man ein Konfig-EEPROM händisch erstellt.

Und für die CSR gibt es wohl auch nichts zugängliches mehr - oder war das eine Fehlinformation?

Benutzeravatar
Bastelbruder
Beiträge: 8514
Registriert: Mi 14. Aug 2013, 18:28
Wohnort: drunt' am Neckar - km142,7

Re: MH-M18, Bluetooth-Audio zum nachrüsten

Beitrag von Bastelbruder » Di 6. Apr 2021, 20:34

Ich hab gemeint daß es nicht unbedingt auf den ankommt der davor sitzt, weil auch das geschulte Auge ein "hintergründiges" Signal nicht mehr erkennt, geschweige denn der Trigger das Signal findet. Das Ohr bzw. die graue Masse zwischen den Ohren ist ein hervorragender Spektrum-Analyzer, der Signale aus dem Rauschen herausfischt, sogar welche die nicht existent sind!

Ich denke da an ein Phänomen welches mir das erste mal beim Empfang mit einem DSP-Radio aufgefallen ist: Wenn ich die Bandbreite verstellt habe, war aus dem Rauschen ganz eindeutig eine Resonanzüberhöhung an der oberen Filterflanke zu hören. Als ich das Signal vom Lautsprecher mit einem NF-Specki auf dem Bildschirm hatte, war dort eine quasi rechteckige Flanke vorhanden, nichts von Überhöhung. Und dann fielen mir die Schuppen aus den Haaren, der Bio-Specki hat mich verarscht!
Bloß weil der noch nie solch scharfe Flanken erlebt hat, hat der ein Pfeifen interpretiert. Es könnte also durchaus sein daß da garnix pfeift, sondern lediglich das Quantisierungsrauschen schlagartig aufhört ...

Benutzeravatar
Später Gast
Beiträge: 1052
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: MH-M18, Bluetooth-Audio zum nachrüsten

Beitrag von Später Gast » Di 6. Apr 2021, 21:22

sysconsol hat geschrieben:
Di 6. Apr 2021, 19:54
Später Gast hat geschrieben:
Di 6. Apr 2021, 13:11
Stromversorgung mit gemeinsamer Masse = Ground Loop. Gelöst durch Versorgung aus Powerbank + C.
Du hast etwas von NF-Übertragern geschrieben.
Wo hast du da eine Masseschleife her, die jetzt durch einen DC-DC-Wandler unterbrochen werden soll?

Ich habe angenommen, dass die NF-Übertrager direkt an das Board an die dafür vorgesehenen Kontakte angeschlossen wurden :?
Und natürlich, dass es getrennte Leitungen für Signal und Stromversorgung gibt - das betrifft auch das Bezugspotential (welches hier Masse genannt wird).
Naja, definiere direkt. :roll: Ich wollte nicht an dem Board rumlöten, also steckt es im Brotbrett, von dort gingen micro-Klemmen an die Übertrager. Weil ich auf der Ausgangsseite auch mit Widerlingen und Kondensatoren experimentiert hatte, waren da auch mehr Steckverbindungen als unbedingt nötig zwischen Platine und Übertrager. Die gemeinsame Masse (zwischen Bt-Empfänger und Amp, den ich mit dem gleichen Netzteil versorgt habe) ist jedenfalls trotz ausgangsseitiger Übertrager die Ursache der Übertragung von Störgeräuschen. Zumindest geht bei getrennter Versorgung das Störgeräusch weg. Warum ist mir schleierhaft, aber mit Versorgung aus der Batterie gehen die Störgeräusche weg. Ich habe das auch im Auto getestet, gleiches "Schadensbild".
Auch die CSR-Boards gibt es bereits fertig mit galvanisch trennendem DCDC als Paket, das ist also ein häufigeres Problem.

Für die CSR-boards und ihre Programmierung hat Jemand auf GitHub die nötigen Infos zusammengetragen. Hatte irgendwann die Software (von hier) am Laufen und sie hat auch den FTDI Adapter akzeptiert, dann sah die Software furchtbar unübersichtlich und kompliziert aus und ich hätte am Board rumlöten müssen, da hat mich die Motivation verlassen. :? Hatte ja noch Boards im Zulauf und wollte nichts kaputtflashen...

sysconsol
Beiträge: 3117
Registriert: Fr 8. Jul 2016, 17:22

Re: MH-M18, Bluetooth-Audio zum nachrüsten

Beitrag von sysconsol » Sa 10. Apr 2021, 16:52

Zum FTDI-Adapter:

Der hat nie etwas anderes gemacht als (ein FT232RL 1643C)

Code: Alles auswählen

C:\Program Files (x86)\CSR\BlueSuite 2.4>BlueFlashCmd.exe -trans "SPIMAXCLOCK=30 SPIDEBUG_FILE=con SPIDEBUG=ON" -identify
blueflashcmd, version 2.4
Copyright (C) 2002-2011, Cambridge Silicon Radio Ltd.
16:38:23.943960: all:spi.c:558:spi_init: csr-spi-ftdi 0.5.3, git rev 80b2ad0
16:38:24.650070: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024363968] read  002b - Failed
16:38:24.661049: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024363979] read  002b - Failed
16:38:24.667047: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024363986] read  002b - Failed
16:38:24.673013: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024363997] read  002b - Failed
16:38:24.692956: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024364011] read  002b - Failed
16:38:24.698942: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024364025] read  002b - Failed
16:38:24.711909: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024364036] read  002b - Failed
16:38:24.727864: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024364045] read  002b - Failed
16:38:24.741827: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024364060] read  002b - Failed
16:38:24.752796: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024364075] read  002b - Failed
16:38:24.763781: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024364089] read  002b - Failed
16:38:24.776743: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024364099] read  002b - Failed
16:38:24.791691: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024364109] read  002b - Failed
16:38:24.803664: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024364121] read  002b - Failed
16:38:24.807653: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024364131] read  002b - Failed
16:38:24.820614: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024364139] read  002b - Failed
16:38:24.834587: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024364153] read  002b - Failed
16:38:24.840570: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024364162] read  002b - Failed
16:38:24.853527: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024364171] read  002b - Failed
Core type bluecore
Not ready

Error detecting chip type (Could not communicate with chip)
*** FTDI Statistics ********************************************************
csr-spi-ftdi version: 0.5.3 (git rev 80b2ad0)
Time open: 0.33 s
Time in xfer: 0.00 s (0.00% of open time)
Reads: 19 (38 bytes, 2.00 bytes avg read size)
Writes: 19 (57 bytes, 3.00 bytes avg write size)
Xfer data rate: 1.#R KB/s (95 bytes in 0.00 s)
IOPS: 1.#R IO/s (38 IOs in 0.00 s)
FTDI chip: FT232R (3), buffer size: 384 bytes
FTDI stats: 1.#R xfers/s (1.#R short reads/s,
            48 xfers/8 short reads in 0.00 s,
            1.00 xfers/IO, 68.00 bytes/xfer)
SPI max clock: 30 kHz, min clock: 25 kHz, slowdowns: 6
****************************************************************************
Failed

C:\Program Files (x86)\CSR\BlueSuite 2.4>BlueFlashCmd.exe -trans "SPIMAXCLOCK=30 SPIDEBUG_FILE=con SPIDEBUG=ON" -identify
blueflashcmd, version 2.4
Copyright (C) 2002-2011, Cambridge Silicon Radio Ltd.
16:38:29.175059: all:spi.c:558:spi_init: csr-spi-ftdi 0.5.3, git rev 80b2ad0
16:38:29.865211: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024369183] read  002b - Failed
16:38:29.877196: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024369196] read  002b - Failed
16:38:29.884178: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024369203] read  002b - Failed
16:38:29.893138: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024369214] read  002b - Failed
16:38:29.902131: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024369220] read  002b - Failed
16:38:29.918069: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024369240] read  002b - Failed
16:38:29.938016: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024369256] read  002b - Failed
16:38:29.949989: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024369273] read  002b - Failed
16:38:29.971925: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024369291] read  002b - Failed
16:38:29.982895: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024369304] read  002b - Failed
16:38:29.997855: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024369319] read  002b - Failed
16:38:30.007837: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024369330] read  002b - Failed
16:38:30.023801: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024369346] read  002b - Failed
16:38:30.036751: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024369355] read  002b - Failed
16:38:30.052724: err:basics.cpp:481:spifns_sequence_read: Unable to start read (invalid control data)
[1024369372] read  002b - Failed
Core type bluecore
Not ready

Error detecting chip type (Could not communicate with chip)
*** FTDI Statistics ********************************************************
csr-spi-ftdi version: 0.5.3 (git rev 80b2ad0)
Time open: 0.32 s
Time in xfer: 0.00 s (0.00% of open time)
Reads: 15 (30 bytes, 2.00 bytes avg read size)
Writes: 15 (45 bytes, 3.00 bytes avg write size)
Xfer data rate: 1.#R KB/s (75 bytes in 0.00 s)
IOPS: 1.#R IO/s (30 IOs in 0.00 s)
FTDI chip: FT232R (3), buffer size: 384 bytes
FTDI stats: 1.#R xfers/s (1.#R short reads/s,
            39 xfers/7 short reads in 0.00 s,
            1.00 xfers/IO, 66.00 bytes/xfer)
SPI max clock: 30 kHz, min clock: 25 kHz, slowdowns: 5
****************************************************************************
Failed
Wer sich das anschauen möchte (.txt entfernen):
CSR8645-FTDI.logicsettings.txt
Einstellungen für Saleae Logic 1-2-18
(607 Bytes) 7-mal heruntergeladen
CSR8645-FTDI-Identify.logicdata.txt
Aufzeichnung mit Saleae Logic 1-2-18
(23.71 KiB) 4-mal heruntergeladen
Aufzeichnung und die Ausgabe der Konsole gehören zusammen - der Befehl wurde zwei mal abgesendet.

Ergänzung:
FTDI-Adapter
FTDI-Adapter
CSR8645 aus Mpow Cheetah
CSR8645 aus Mpow Cheetah

sysconsol
Beiträge: 3117
Registriert: Fr 8. Jul 2016, 17:22

Re: MH-M18, Bluetooth-Audio zum nachrüsten

Beitrag von sysconsol » So 11. Apr 2021, 18:43

Hier noch ein Gedanke zum Thema SBC, aptX oder was ganz anderes.
Falls das relevant werden sollte.

Benutzeravatar
Später Gast
Beiträge: 1052
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: MH-M18, CSR-8645**, Bluetooth-Audio zum nachrüsten

Beitrag von Später Gast » Di 27. Apr 2021, 19:53

n'abend zusammen,

ich hab mir mittlerweile endlich ein Bluetooth-Modul ins Auto gezimmert:
IMG_20210426_165736.jpg
es ist ein XY-BT-L geworden, das hatte jetzt nach recht zügiger Lieferung die stressfreisten Einbauoptionen. Bei niedrig eingestellter Lautstärke hat das zwar auch einen Hörbaren und bei Podcasts (wegen der Stille in Sprechpausen) ernsthaft störenden "bei Stille Abschalten"-Bug inclusive Bupfgeräusch, aber wenn der Empfänger auf vollen Pegel gestellt ist, tritt das nicht auf. Da ich im Auto die Lautstärke am Radio einstelle und der Empfänger nur auf volle Pulle läuft kein Problem. Klanqualität war für meine Ohren gut genug, konnte jetzt keine Artefakte oder lautes Grundrauschen oder so hören. Keine störenden Ansagen! :)

So'n CSR-Dingsbums ist auch eingetrudelt, allerdings nur die Platine ohne jedes Weiterverarbeitungsgedöns und da braucht man ja eigtl mindestens nen tpa6112 oder ähnliches, um das Audiosignal artgerecht am Verstärker abzuliefern.(war mir nicht klar) Hab das dann mit den Übertragern testweise gelöst, aber auch da hatte ich wieder das bekannte Störgeräusch bei Versorgung aus der gleichen Quelle. Außerdem: Die Dinger sind WINZIG! :shock:
Mit Lupenlampe und Nadelspitze am Löteisen CuL drangefummelt für Versorgung und Steuerung, Audio out und dann wollte mein Schmierfon das Dingens einfach nicht sehen. :evil: Das alte Samsung S5 hochgefahren, kein Problem, spielt, aber am aktuellen Honor, no Chance in Hell. Da die trennenden DCDC auch noch nicht da sind war die Wahl dann eindeutig und ich hab das jetzt fürs Erste mal vom Tisch. Gibt aber noch nen Haufen anderer Abspielgeräte, die Blauzahnbespaßung brauchen können.
Die Folientastatur ist zum Aufkleben und geht nach unten durch das Plastik, über Pfostenstecker und dann CuL direkt an die Microtaster. man könnte auch über eine Leitung und verschiedene Widerstände Drähte sparen, hätte dann aber die Platine und recht spezielle Widerstandswerte, mehr Kabel war einfacher. USB und µSD kann das Ding auch, aber das werde ich kaum nutzen, die SD-karte ist im Handy und da hab ich besseren Überblick.

-> Es ist echt ne Wohltat bei Podcasts einfach auf Tastendruck ohne Tatsch-Quatsch 10 Sekunden zurückzuspulen! :)

Antworten