Der Sure DSP Thread

Danke!
Da der DSP ohne Programmer problemlos am USB Netzteil funktioniert und nur die Verbindung mit dem Programmer wackelig ist, müsste es wohl doch eher eine Masseschleife sein, oder? Kann das überhaupt sein, wenn der fragliche Laptop und der Receiver, in dessen geschalteter Steckdose das USB Netzteil steckt, doch letztlich an der gleichen Wandsteckdose hängen?

Ich denke das lässt sich so aus der Ferne nicht sicher beantworten.
Vielleicht ist es auch das Laptopnetzteil, was stört und solange der DSP ausschließlich an der unsauberen Spannung hängt wirkt sich diese weniger aus und es funktioniert? Das wird dir aber niemand mit Sicherheit sagen können.
Wie verhält sich das denn, wenn der Laptop beim Programmieren auf Akkubetrieb läuft? Dann hätte der Rechner zumindest mal keine Masseverbindung mehr.

Mein Projekt soll ein 2.1 Sytem werden. Ich habe den TPA1100 mit integrierten DSP aber bisher noch keinen Schaltplan dafür gefunden.

Habe die wenigen downloads im Hobbyhifiladen, das Wiki und fast den ganzen Thread hier durchsucht, aber bisher nicht fündig geworden.

Mir fehlen folgende Verbindungen :
1) Welcher DAC des DSP's geht auf den integrierten Verstärker des Boards?
2) und welche DAC's sind mit den 2 Ausgängen verbunden?

Ich habe den TPA1100 mit dem DSP-Programmer verbunden, ein paar Icons auf dem Sigma Studio und möchte jetzt überprüfen ob alles so funktioiert wie ich mir das gedachte habe.
Ich habe versucht das Programm rüberzuschieben bin aber nicht sicher ob es geklappt hat.
Ich bin deshalb unsicher weil auf dem Programmer 3 LED's (Rx, Tx, Run) sind, die dabei aber nicht geblinkt haben!

Auch über den Programmer habe ich bisher nichts gefunden was die LED's angeht.

Verbinde erstmal einen Eingang mit T-Verbindern mit allen Ausgängen. Dann kommt das Signal auf jeden Fall an den Verstärker.
DAC0 und DAC1 gehen an den integrierten Verstärker, DAC2 und DAC3 werden unverstärkt ausgegeben.

Danke für deine Antwort DjDump,
Der TPA 1100 hat nur einen Verstärker an deshalb die Frage nach DAC?
Dann ist ein DAC unbenutzt und wohl auch nicht zugänglich!

Achso, ja das ist ganz komisch. Ich hab noch nicht so ganz herausgefunden wie das läuft, weil der Verstärker zwei Anschlüsse für Chassis hat. Und wenn ich mich recht entsinne hatte ich mal getestet, ob man die einzeln ansteuern kann und das ging. Also so als wäre es ein ganz normaler Stereo Verstärker.

Dann quasi als Brückenverstärker und somit sollten beide Kanäle angesprochen werden.
Noch eine Frage wie ist die Zugehörigkeit der Potis zu den DSP-Eingängen?
Poti1 Master Volume
Poti2 Low-pass
Poti3 High-pass
Poti4 Subwoofer Cut-off

Um da mal noch etwas Verwirrung zu stiften:
Die Mono und Stereo Amps sind Im Layout an mehreren Stellen eindeutig unterschiedlich beschaltet.
Falls es jemandem helfen sollte kann ich vielleicht mal ein paar Bilder schießen und entsprechende Stellen markieren.
Sure selbst rät ausdrücklich davon ab irgendwas zu Brücken was nicht gebrückt gehört, also ohne die Schaltung zu modifizieren. Ansonsten kann man da mal nach dem Schlagwort PBTL suchen um sich da etwas mehr in die Materie einzufuchsen, das ist wohl kein Brückenbetrieb wie man ihn von den herkömmlichen Car-Hifi/ PA Endstufen kennt.

Grüße

Die einfachste Variante: Datenblatt der Chips konsultieren, feststellen dass meistens einfach das Reference-Design umgesetzt wurde und dann weitergucken.
Technisch ändert sich dabei nicht all zu viel. Die äußere Beschaltung bleibt fast gleich, vor Allem wenn es jetzt um Sachen wie Stecker, Signalkonditionierung oder Versorgung geht

Um nochmal auf den Post von vor 6 Wochen zurückzukommen:

IPv6 (Beitrag #1736) schrieb:

Wenn noch jemand mal von den Sure Boards wegmöchte gibt es am 11.11. beim Aliexpress Rabatt-Tag ein Board für knapp 14 €. Klick mich! Da steht zwar ADAU1401 drauf, der 1401 ist allerdings scheinbar identisch mit dem 1701, er ist lediglich für eine größere Umgebungstemperaturspanne qualifiziert (für Automotiv). Da spart man sich dann wohl das Potis runterlöten, es ist eben mehr ein "nacktes" Board. Für den Einbau in irgendwelchen Projekten sicher teils bequemer als das Sure Board. Ich habe jedenfalls mal zwei Stück im Warenkorb liegen :D

Die Boards waren gestern in der Post und ich habe heute ein wenig damit rumgespielt.
Zunächst scheint es SigmaStudio egal zu sein, ob man als DSP den 1701 oder den 1401 auswählt. Der 1401 scheint also soweit identisch zum 1701 zu sein, dass man für die Konfiguration des 1401 im SigmaStudio Projekt auch einen 1701 wählen kann. Das ist ganz praktisch, da man nicht so ohne Weiteres den DSP im SigmaStudio ändern kann. Möchte man auf einen anderen Prozessor umstellen muss man wieder mit einem leeren Projekt starten. Somit können auch bestehende Projekte für den 1701 einfach auf das Board vom flotten Ali programmiert werden.

An Sonsten ist das Board, wie das Sure DSP auch, recht nah am Referenzdesign von Analog Devices.

"Besonderheiten" der Hardware:
- Es ist keine Writeback Trigger Schaltung vorhanden (also nichtmal eine nicht funktionierende wie beim Sure DSP)
- Kein Schalter für Write Protect vom EEPROM, zum EEPROM programmieren muss manuell GND auf den WP Pin gelegt werden
- An MP3 hängt eine blaue LED, finde ich ganz praktisch, kann man als Ein/Aus-LED verwenden, als Clip-LED oder natürlich für was auch immer einem einfällt
- 12,288 MHz Quarz vorhanden
- Wie beim Sure DSP rein passive Ausgangsfilter (Minimallösung)
- Recht sinnvolle Anordnung der Pins auf dem Stiftleisten, zwar alle MP-Pins ein wenig durcheinander, aber immer ein GND Pin neben Pins, die zusammen mit GND verwendet werden
- Kein Masterclock auf den Stiftleisten. Externe Masterclock dürfte daher etwas fummelig zum anbinden sein.

Ich hatte bei einem der Boards zwei Lötbrücken am DSP-Chip. Es ist ratsam, vor der ersten Inbetriebnahme das Board unter einer Lupe anzuschauen. Vielleicht war es nur ein sehr unwahrscheinlicher Zufall, doch je nach dem welche Pins da gebrückt sind könnte die Hardware Schaden nehmen.

Die Widerstände an den Audio Eingängen sind mit 10k etwas kleiner als die des Sure DSP (18k), somit ist Vollaussteuerung der Eingänge bei 1,2 V rms erreicht. Die Ausgänge machen nach wie vor 0,9 V rms, also ist ohne weitere Maßnahmen der Ausgang ca. 2,5 dB leiser als der Eingang, was natürlich wie beim Sure DSP mit etwas Gain im DSP angepasst werden kann.

Sonstiges:
- Auf dem Board sind Pads für einen unbestückten Dreibeiner ("U2"), dessen mögliche Funktion habe ich noch nicht durchgeklingelt
- Der verbaute Spannungsregler ist einem größeren Package als beim Sure DSP, womöglich kann das Ding auch etwas mehr Strom ab. Wirklich nötig dürfte das allerdings kaum sein
- Das vorhandene EEPROM trägt die Bezeichnung "ATMLH713 2EC L Y 3X5347A", dazu finden sich quasi keine Informationen im Netz. In einem Beitrag im Arduinoforum hatte scheinbar jemand ein Atmel AT24C256 bestellt und ein EEPROM mit der vorher genannten Bezeichnung geliefert bekommen. Vermutlich handelt es sich um einen Fake/Nachbau, die Beschriftung ist sehr undeutlich, unsauber und wirkt insgesamt billig. Funktionieren tut es allerdings (noch) problemlos. Sure scheint da immerhin EEPROMs von ST zu verbauen.

Unterm Strich kann ich die Boards sehr empfehlen!
Zumindest, wenn man es irgendwo einbauen möchte. Das Sure DSP wirkt da wesentlich klobiger durch die ganzen Stecker und Potis.
Man spart sich im Vergleich zum Sure DSP die eventuell unnötigen Wannenstecker, den Programmierstecker und die USB Buchse zur Stromversorgung. Auch kann man Potis verbauen ohne die alten runterzureißen.
Wenn man das Board eh irgendwo verbauen möchte und einem vorhandene Stecker und Potis eher im Weg sind hat man wohl auch ein ruhig genuges Händchen um eventuelle Lötbrücken aufzuspüren und zu beheben.

Hallo Zusammen,

ich versuche gerade die passive 2 Wege Weiche meiner Open1001 durch ein Sure DSP zu ersetzten.
Hat hier schon jemand eine 2Wege weiche für den Mono-Betrieb in SigmaStudio abgebildet und könnte mir evtl das Setup zur Verfügung stellen?

Danke und Grüße,
thomas

Ich bin ungern der Spielverderber und finde es normalerweise auch nicht schön, einfach zu sagen "lass es sein", aber ich glaube nicht, dass dein Ergebnis einer aktiven Weiche gut wird, wenn du nicht mal weißt, wie die Weiche aufgebaut wird..

Schau dir das Basis Setup einfach mal an.
Lösche die nicht benötigten Bausteine, dann wirds übersichtlicher.

ja ihr habt natürlich schon recht.
Ich hab aber auch schon ein Setup zusammengestellt. Weiß nur nicht genau ob das so zu verwenden ist und ob ich irgendwo nen groben Fehler drin hab.
Ebenso weiß ich nicht ganz genau wo ich den HT vom TT trennen muss. Ich hab jetzt mal bei 2500 Hz getrennt.

freeplay (Beitrag #1769) schrieb:

Ebenso weiß ich nicht ganz genau wo ich den HT vom TT trennen muss. Ich hab jetzt mal bei 2500 Hz getrennt.

Das sagen dir deine Messungen der unbeschalteten Chassis im Gehäuse (Achsfrequenzgang, Klirrverhalten und Winkelverhalten).
Das ist im Prinzip eine Neuentwicklung, Messungen entsprechend notwendig.

Einen groben Fehler hast du nicht. Es ist schon alles richtig, aber der Teufel steckt im Detail. Die Schwierigkeit ist nicht das Grundkonzept, sondern die Abstimmung.
Aber das Schöne am DSP ist ja, dass du alles ausprobieren kannst und man als Anfänger noch keine so hohen Ansprüche hat. Aber ohne Messmikrofon wird das ganze wenig Zielführend sein.

Ist zwar alles andere als optimal, aber für das "grobe" abstimmen, würde warschenlich auch ein Normales Mikro als messmikro herhalten, einfach um zu guncken ob es irgendwelche auslöschungen oder starke überhöhungen gibt.

Aber vorallem im Bass und Hochtonberiech darf man sich keinesfalls auf unkalibrierte mikrofone verlassen.

Hi, ich mal wieder mit meinem Wondom (Sure) Gespann aus Programmer und DSP.

Wie früher schon mal beschrieben habe ich mir einen Schalter in das Kabel zwischen Programmer und DSP gelötet, damit ich nicht jedes mal vor dem Anschließen des Programmers an USB das Verbindungskabel zum DSP abziehen muss. Ich habe nur SCL, SDA und GND verbunden, und diese drei Verbindungen werden vom dem Schalter gleichzeitig geschaltet. Das hat bis vor Kurzem auch einwandfrei funktioniert.

Dann hatte ich das Problem mit dem USB Netzteil: Ich wollte den DSP dauerhaft an einem USB Netzteil laufen lassen und den Programmer dann nur bei Bedarf an den Laptop anschließen. Der DSP allein lief problemlos am USB Netzteil, aber zum Programmieren muss ich das Gespann mit beiden USB Kabeln am Laptop anschließen.

Bei den vielen erfolglosen Verbindungsversuchen, als der DSP am USB Netzteil hing, habe ich so viel mit dem Kabel rumgemacht, dass eine Ader am Schalter abgegangen ist. Als ich die wieder angelötet habe, habe ich mich an den Post von TriplePower erinnert, der schrieb, dass man DSP und Programmer bei bestehender Verbindung (und in seinem fall mit Cypress Programmer) und ohne Umlegen des Schalters booten und dann programmieren kann, wenn man WP des Programmers auf GND legt. Mit dieser Verbindung:
DSP::Programmer
SCL::SCL
SDA::SDA
GND::WP
musste ich leider nach wie vor meinem Schalter betätigen. Aber immerhin funktionierte alles noch und ich konnte meine Setups auch ins EEPROM flashen.
vielleicht hat TriplePower das anders gemeint, z.B. dass WP des DSP auf GND gelegt werden muss!? Es wäre schon schön, wenn ich meinen blöden Schalter einsparen könnte.

Heute ist wieder ein Kabel am Schalter abgebrochen. Also habe ich alle Kabel vom Schalter abgelötet und mit Schrumpfschläuchen als Zugentlastung wieder angelötet. Bei der Gelegenheit habe ich das Kabel zwischen Schalter und DSP 1m länger gemacht, damit ich den Schalter bedienen kann, wenn ich auf dem Sofa sitze. Und ich habe WP und GND des Programmers zusammen mit GND des DSP verbunden.

Und jetzt kann ich zwar noch programmieren, aber nicht mehr flashen. Und muss immer noch den Schalter umlegen. Deshalb habe ich das Kabel, mit dem WP auf GND geht, wieder abgezwick. Flashen kann ich immer noch nicht.

Daher nun endlich die Fragen:
Darf das Programmer::DSP Kabel nicht länger gemacht werden??
Welches WP muss auf wessen GND, damit ich die Verbindung von Programmer und DSP beim Booten dranlassen kann?

Beste Grüße,
Danke,
Omeg.

Omegendorph (Beitrag #1773) schrieb:

Daher nun endlich die Fragen: Darf das Programmer::DSP Kabel nicht länger gemacht werden??

I2C ist zur Kommunikation zwischen Chips auf Platinen gedacht und nicht für Kabelverbindungen. Wenn dann würde ich den Programmer so nah wie möglich am DSP platzieren und eher ein längeres USB-Kabel verwenden.

Welches WP muss auf wessen GND, damit ich die Verbindung von Programmer und DSP beim Booten dranlassen kann?

Habe ich schon einige Male beschrieben:
Die I2C Busse von Programmer und DSP dürfen beim Booten nicht verbunden sein, da der Programmer ebenfalls via I2C aus seinem EEPROM ließt.
Praktischerweise stellt der Programmer (Chinamodell, ~3€) über einen Pin ein Signal zur Verfügung, wenn er mit booten fertig ist. USB_PWR_ON wenn ich mich recht entsinne.
Was man folglich braucht, sind lediglich 2 Transistoren die die I2C-lines durchschalten. Siehe hierzu Layout vom FreeUSBi. Kann man zur Not auf Lochraster braten (2 Buchsenleisten auf Bottom zum Aufstecken auf den Programmer, eine z.B. 6-Pol Wannenbuchse auf Top zur Verbindung mit dem DSP, Transistoren, Hühnerfutter).

Lediglich das Problem, den EEPROM zu beschreiben, lässt sich so einfach nicht in den Griff bekommen. Sure hat immerhin bei der letzten Hardware-Revision diesen Umstand bedacht und auf dem 6-poligen Programmierheader den WP-Pin herausgeführt.
Nun bräuchte man theoretisch einen eigenen Programmer und eine Software, in der man auswählen kann, ob in den DSP oder den EEPROM geschrieben werden soll.

MK_Sounds (Beitrag #1774) schrieb:

Habe ich schon einige Male beschrieben:

Sorry... ich hab schon gemerkt, dass ich letztlich nicht versiert genug bin für dieses Thema. Ich habe Deine Beschreibungen gelesen, aber ich konnte die Brücke zu meinem Wondom DSP/Programmer nicht schlagen.
Danke, dass Du trotzdem antwortest!

Hat schon mal jemand geguckt, ob der Wondom/Sure Programmer auch ein USB_PWR_ON Signal auf der 6-poligen Anschlussleiste hat? Lt. Beschriftung wohl eher nicht:
1 RST
2 VIN
3 GND
4 WP
5 SCL
6 SDA

Das Problem mit der Kabellänge ist, dass ich die Ausgangskabel, also die Audio-Kabel, die in 4 Cinch Steckern für den Verstärker münden, recht kurz gemacht habe. Die Idee war, dass lange USB Kabel und ein langes Verbindungskabel zwischen Programmer und DSP kein Problem wären, lange selbstkonfektionierte Audiokabel aber sehr wohl. Deshalb muss der DSP recht nach am Verstärker sein.

Bei mir ist der Mehrkanalvertärker in den Couchtisch eingebaut. Damit mein Schalter, mit dem ich beim Booten die Verbindung zwischen Programmer und DSP kappen kann, erreichbar ist, brauche ich mindestens 50cm zwischen Schalter und DSP. da mit nicht bewusst war, dass die Kabellänge begrenzt ist, habe ich aktuell 90cm zwischen DSP und Schalter, dann noch 10cm zwischen Schalter und Programmer. Zur Illustration ein Photo:



Jetzt werde ich das Verbindungskabel erst mal kürzen, bis ich wieder ins Eprom schreiben kann. GGfs. mache ich dann die Audio-Ausgangskabel länger, bis der Schalter zugänglich wird.

Sauber! Mit nur 20cm zwischen DSP und Programmer kann ich wieder ins EEPROM schreiben!
Und durch Aufräumen im Couchtisch habe ich den Schalter nun so gerade in Reichweite, ich muss den Tisch also nicht ständig abräumen und aufklappen.
()

Danke noch mal!

Omegendorph (Beitrag #1775) schrieb:

Hat schon mal jemand geguckt, ob der Wondom/Sure Programmer auch ein USB_PWR_ON Signal auf der 6-poligen Anschlussleiste hat?

Den Pin stellt beim Chinaprogrammer der Pin 20 auf der rechten Stiftleiste zur Verfügung. Sure hat vermutlich einen vergleichbaren Chip verwendet, allerdings ist das ja ein fertiger Programmer, da sollte das Feature natürlich integriert sein. Oder muss man den Sure-eigenen Programmer auch erst selbst booten lassen und dann mit dem DSP verbinden?

Hat schon mal jemand geguckt, ob der Wondom/Sure Programmer auch ein USB_PWR_ON Signal auf der 6-poligen Anschlussleiste hat?

Hat er nicht. Würde auch keinen Sinn machen. Das Feature müsste eigentlich im Signalfluss vor dem Ausgangsstecker am Programmer liegen, sprich die I2C-Lines werden durchgeschalten und gehen dann auf den 6-pol Stecker.
Allerdings hat Sure den völlig sinnlosen SBOOT-Pin auf dem 6-pol Programmierheader durch den WP-Pin ersetzt. Dies würde wie gesagt eine Treiber- und Programmerseitige automatische Programmierung des EEPROM ermöglichen, ohne einen Schalter umschalten zu müssen, um in den EEPROM zu schreiben.

Die Idee war, dass lange USB Kabel und ein langes Verbindungskabel zwischen Programmer und DSP kein Problem wären, lange selbstkonfektionierte Audiokabel aber sehr wohl.

Ist ein völliger Trugschluss. Ein selbstkonvektioniertes Audiokabel ist besser, als ca. 90% dessen was man kaufen kann (allein schon weil dann vernünftige Stecker zum Einsatz kommen). Vorausgesetzt man macht es ordentlich. Geschirmt sind Audiokabel auch unsymmetrisch über ein paar Meter ja kein Problem.

Ich habe mit dem ADAU1701 auch mal ein Pärchen Aktivlautsprecher gebaut. Zum Programmieren besitzen die Dinger einen 4-poligen Mini-DIN Stecker (bekannt als S-VIDEO Stecker), das dazugehöre Kabel zum Programmer lief immer mit 1,5 m einwandfrei. Das Kabel ist geschirmt, dürfte aber sonst keine weiteren Maßnahmen aufweisen, die eine I²C Kommunikation stabiler machen würden.

Wie MK Sound schon sagte kann nur ins EEPROM geschrieben werden, wenn der WP Pin auf Masse liegt.
Der Writeprotect Pin vom EEPROM ist mit einem Pin am ADAU1701 verbunden, findet sich im Datenblatt zum ADAU1701 im Abschnitt zum Selfboot bzw. auch später in den Beispielschaltungen.
Der WP Pin vom EEPROM wird (vermutlich über einen Pullup Widerstand) auf Highpegel gehalten. In diesem Zustand bootet der DSP sich selbst, indem er bei Strom an auf das EEPROM zugreift und sich das Programm holt. Der DSP selber hat auch die Möglicheit, den WP Pin auf Masse zu ziehen und somit den Schreibschutz aufzuheben, zum Beispiel wenn der DSP bei einer Writeback Operation selber eine Hand voll Parameter ins EEPROM schreiben muss.
Will man extern das EEPROM beschreiben muss man den WP Pin auf Masse legen, damit der Schreibschutz vom EEPROM aufgehoben ist. Dazu gibt es am Sure Board den Schalter. Wird dieser betätigt kann das EEPROM beschrieben werden. Bleibt der Schalter in der Position, ist der Selfboot vom DSP deaktiviert. Daher kommt der Effekt, dass der DSP nicht startet wenn nach dem EEPROM beschreiben der Schalter nicht wieder umgelegt wird.
Desswegen ist leider immer eine Form von Aktion erforderlich, bevor das EEPROM beschrieben werden kann. Denn das geht nur wenn WP auf Masse liegt, im gleichen Zug bootet der DSP aber nicht mehr. Liegt WP auf Highpegel bootet der DSP zwar, das EEPROM kann aber nicht beschrieben werden.
Wenn der Programmer nun auch mit dem WP Pin verbunden wäre könnte der Programmer für die Dauer des EEPROM beschreibens den WP Pin temporär auf Masse legen und dannach wieder "loslassen", sodass der DSP wieder booten kann. Sowas scheint von Sure grundsätzlich angedacht zu sein, da der WP Pin am Programmieranschluss verfügbar ist. Es scheint aber, dass die Funktion von Sure nicht implementiert ist.

@MK Sounds:
Ich nehem an, dass du dir sicher bist, dass der Programmer erstmal selber aus seinem EEPROM liest, sonst würdest du das wohl nicht so schreiben.
Wie passt da dann rein, dass bei mir auch schon Cypress Programmer ohne EEPROM liefen?
Ich hatte das schonmal hier irgendwo geschrieben meine ich, da war auf einem Board das EEPROM defekt, sodass der Programmer nicht funktionierte. Sobald das EEPROM entfernt wurde, konnte der Programmer ganz normal verwendet werden.
Weißt du, was auf dem EEPROM drauf ist? Was lädt sich das IC da vom EEPROM?

Das Feature der I²C Freigabe erst nach dem der Programmer bereit ist durch das FreeUSBi Board war mir bisher auch neu und hat mich dazu bewegt, mal in den Schaltplan von der Aufsteckplatine zu schauen. Sieht eigentlich recht sinnvoll aus, vielleicht waren die 20 €, die ich vor Jahren mal in das FreeUSBi Teil investiert hatte doch noch umsonst. Immerhin läuft das Zeug seit Anfang an problemlos, bis auf Treiberproblemchen, für das der Programmer wohl nichts kann.

Die ganze Programmerlösung scheint mir dennoch irgendwie schwindelig zu sein. Selbst der Sureprogrammer scheint da keine wesentliche Besserung zu bringen.

IPv6 (Beitrag #1778) schrieb:

@MK Sounds: Ich nehem an, dass du dir sicher bist, dass der Programmer erstmal selber aus seinem EEPROM liest, sonst würdest du das wohl nicht so schreiben. Weißt du, was auf dem EEPROM drauf ist? Was lädt sich das IC da vom EEPROM?

Sicher bin ich mir keinesfalls, nachdem ich keine Einsicht in den Treiber habe. Das war eher eine logische Schlussfolgerung: hängt der DSP beim Powerup am Programmer, kann man nicht programmieren (Comms failed error). Folglich muss auf dem I2C-Bus ein Konflikt vorliegen (zwei Master schreiben/lesen gleichzeitig auf dem gleichen Bus an unterschiedliche Slaves).
Nachdem du schreibst, dass der EEPROM nicht zwingend notwendig ist, wäre eine Kommunikation beim Booten ausgeschlossen. Eine sinnvolle Erklärung fällt mir adhoc auch nicht ein. Fakt ist, beim Einschalten des Programmers muss irgendeine Kommunikation auf dem I2C laufen, sonst gäbe es das ganze Problem nicht.
Was eine mögliche Erklärung sein könnte: der Programmer ist ja kein nativer Programmer ansich, sondern eine einfache USB -> I2C-Bridge. Nun könnte es sein, dass dieser Chip einen Default-Modus hat (der zum programmieren ausreicht), aber er zusätzliche Konfiguration aus einem EEPROM laden könnte. Entsprechend müsste der Programmer-Chip beim Starten überprüfen, ob ein EEPROM vorhanden ist. Diese „Anfrage“ könnte womöglich für den Konflikt schon ausreichen.

Das Feature der I²C Freigabe erst nach dem der Programmer bereit ist durch das FreeUSBi Board war mir bisher auch neu und hat mich dazu bewegt, mal in den Schaltplan von der Aufsteckplatine zu schauen. Sieht eigentlich recht sinnvoll aus, vielleicht waren die 20 €, die ich vor Jahren mal in das FreeUSBi Teil investiert hatte doch noch umsonst. Immerhin läuft das Zeug seit Anfang an problemlos, bis auf Treiberproblemchen, für das der Programmer wohl nichts kann.

So ist es, diese Kombination läuft bei mir mit eigenem HookOn-Board (wie FreeUS i) absolut stabil. Das einzige Problem ist der leidige Treiber mitsamt USB3 support.

Die ganze Programmerlösung scheint mir dennoch irgendwie schwindelig zu sein. Selbst der Sureprogrammer scheint da keine wesentliche Besserung zu bringen.

Sehe ich genau so. Da werden wir wohl mal einen Mikrocontroller mit ein paar Zeilen Code versorgen müssen
Z.B. ein ESP32 oder vergleichbares würde sich anbieten, hätte man Wlan und Bt gleich mit an Bord und könnte auch kabellos programmieren.
Im Grunde muss man ja nur das generierte hex-File in den DSP schreiben. Live-Programmieren wird dann schon eher tricky.
Ist für ab März in der Projektliste notiert

MK_Sounds (Beitrag #1777) schrieb:

Oder muss man den Sure-eigenen Programmer auch erst selbst booten lassen und dann mit dem DSP verbinden

Ja, beide Platinen booten nur, wenn sie mit Strom versorgt werden, während das Verbindungskabel ab ist. Unabhängig davon, ob WP auf Masse liegt oder nicht.
Noch mal ganz deutlich:
- Wenn die Verbindung besteht, während die USB eingesteckt werden, verklemmt sich auch der DSP. Es reicht nicht, die Verbindung zu lösen und nur den Programmer neu zu starten. Auch der DSP muss neu gestartet werden, damit das Programmieren geht.
- Sowohl für die Funktion (Programmieren und EEPROM Schreiben) als auch für die Verklemmung (no-Boot bei Power On mit bestehender Verbbindung) müssen SCL und SDA verbunden sein. Ob DSP-GND an Programmer GND oder an Programmer WP liegt, ist unerheblich, aber eins der beiden muss schon sein.

MK_Sounds (Beitrag #1779) schrieb:

Im Grunde muss man ja nur das generierte hex-File in den DSP schreiben. Live-Programmieren wird dann schon eher tricky. Ist für ab März in der Projektliste notiert

*Daumenhoch! Freue mich drauf!

Hat von Euch schon jemand versucht ein BRB4 Bluetoothmodul von Sure per I2S ans DSP zu klemmen?
Was ich auf die schnelle gefunden habe sollte der CSR8670 ja I2S unterstützen, jedoch kenn ich mich da absolut nicht aus und kann daher auch vom Sure Wiki keine parallelen ziehen.

Hab noch ein Foto von den zur Verfügung stehenden Pins gemacht, vielleicht kann ja mal kurz ein Fachkundiger drauf schauen ob da überhaupt dabei ist was man braucht


Grüße

Die CSR Module unterstützen zwar (zum Teil) die Tonausgabe per I²S, allerdings dürfte die standartmäßig nicht aktiv sein.
Dazu muss das Modul umprogrammiert werden. Gib dafür Programmieradapter für rund 20 $ beim flotten Ali oder von sonstigen asiatischen Händlern.
Die Software ist auch nicht offiziell zu beschaffen, da lohnt sich ein Blick in das stromrichter.org Forum, da gibt es zwei Threads die sich recht ausführlich mit der Thematik befassen.
https://www.stromrichter.org/showthread.php?tid=3920
https://www.stromrichter.org/showthread.php?tid=3840

Diese Teile sind aber grundsätzlich keine einfachen Bluetoothempfänger sondern wieder eigenständige Systeme mit DSP Funktionalität, also auch wieder recht umfangreich in der Konfiguration.
Muss man sich erstmal eine Weile einlesen, ist bei mir auch schon wieder ein Jahr her, das meiste Wissen ist da auch schon wieder in den Hintergrund gerückt.

Freundliches Hallo,

habe selber mit dem Wondom BRB4 „gespielt“ und meine, sicher sehr subjektiven Eindrücke, in meinem Thread http://www.hifi-forum.de/viewthread-71-13172.html geschildert … siehe dort
„Kleine Zwischenbilanz“

Eine I²S Ausgabe habe ich mit dem BRB4 nicht geschafft, was möglicherweise auch nicht geht, bzw. mich dafür „zu blöd“ angestellt habe?

Mit dem CSR8670 habe ich zwar keine Erfahrung, wohl aber inzwischen mit dem CSRA64215.
Und der scheint sich, auf den ersten Blick, nicht so grundsätzlich vom CSR8670 zu unterscheiden.
Von dem „Support for up to 6x touch sensor inputs“ mal abgesehen.
Beide bieten die Möglichkeit für eine I²S Ausgabe und müssen, wie IPv6 schon anmerkte, etwas umprogrammiert werden.
Zum Einem arbeiten wohl beide, von Hause aus, als Master (benötigt wir für den DSP Slave), zum Anderem muß auf I²S Ausgabe umgestellt werden.

Aber ich will es mal so sagen, wenn ich das geschafft habe, dann sollte es für Andere auch nicht das Problem sein.
Vom Preis her ist der CSRA64215 + Programmer sogar noch etwas preiswerter, wobei der Preis für den Programmer natürlich nur eine einmalige Ausgabe ist.
Und ja, der Platzbedarf ist kein Vergleich!
Alles in Allem eine Überlegung wert?

Wünsche jedenfalls viel Erfog!

MfG

Dieter

Moin,

bin gerade dabei, mit dem DSP und einem ESP32 herumzuspielen...
Die Idee ist, den ESP32 als A2DP Empfänger zu benutzen und den Audiostream über I2S an den DSP zu geben und im Livebetrieb Parameter ändern zu können. Das Ändern von Parametern über I2C habe ich schon zum laufen bekommen. Beim zuspielen von Audio über I2S kann ich dem DSP aber leider noch keine Töne entlocken Hab mich zwecks Verkabelung und Besonderheiten des DSPs bezüglich I2S an das Wiki gehalten. Für den ESP32 gibt es ein Beispiel-Code, mit dem das Empfangen via A2DP und weiterleiten über I2S möglich sein soll.
Mein Setup sieht derzeit so aus:
DSP:
-als Master
-fs=48kHz
-Frame Sync Type = LRCLK
-Frame Sync Freq = InternalClock/256
-MSB Position delay by 1
-Word length = 16 Bit
-BCLK Freq = InternalCock/8
-MP4 mit MP10 Verbunden und an LRCK Port vom ESP32
-MP5 mit MP11 Verbunden und an BCK Port vom ESP32
-MP0 an SDATA Port vom ESP32

ESP32: hier setzt ich beim erstellen des I2S Treibers folgendes:
.mode = I2S_MODE_SLAVE | I2S_MODE_TX
.sample_rate = 48000,
.bits_per_sample = 16,
.channel_format = I2S_CHANNEL_FMT_RIGHT_LEFT
.communication_format = I2S_COMM_FORMAT_I2S | I2S_COMM_FORMAT_I2S_MSB,
.dma_buf_count = 6,
.dma_buf_len = 60,
.fixed_mclk = 12288000,
.use_apll = true,
Über Debugging gitbt der DSP als SCLK 1536kHz an, das müssste soweit ja passen oder?

Hat jemand eine Idee wo das Problem liegen könnte?

Vielen Dank

rammst1 (Beitrag #1784) schrieb:

Mein Setup sieht derzeit so aus: DSP: -als Master -fs=48kHz -Frame Sync Type = LRCLK -Frame Sync Freq = InternalClock/256 -MSB Position delay by 1 -Word length = 16 Bit -BCLK Freq = InternalCock/8 -MP4 mit MP10 Verbunden und an LRCK Port vom ESP32 -MP5 mit MP11 Verbunden und an BCK Port vom ESP32 -MP0 an SDATA Port vom ESP32

Die Standard-Konfig ist folgende für 48 kHz:
Sample rate: 48 kHz
Bit depth: 24 bit
Data format: I2S

Clock master at the I²S output
MCLK = 256 * Fs = 12.288 MHz
BCLK = 64 * Fs = 3.072 MHz --> Internal / 16
LRCLK = Fs = 48 kHz --> Internal / 1024

Ein 24bit Sample wird normalerweise in einem Slot von 32 bit transferiert (ergibt 64 x fs bitclock). Entsprechend, wenn dein Slot 16 bit breit ist, musst du den Bitclock anpassen.

Das klingt sehr interessant, bitte unbedingt Rückmeldung geben wenn es funktioniert!

Mich würde dann auch interessieren, wie die Audioqualität ist.
Auch, ob das wohl eine Chance gegen die CSR Boards hat, die vermutlich deutlich optimierter sind was Audio über Bluetooth angeht.
Wenn das eine Alternative ist wäre das eine ziemlich schöne Sache, die CSR Boards halten ja doch immer wieder einige Stolperfallen bereit.

Moinmoin!
Schonmal danke für die Antworten!

@lucky_wolf:
Standardlautstärke vom BRB4 hätte man ziemlich easy im Headset Config Tool anpassen können, ansonsten finde ich in deinem Thema leider nichts brauchbares für mein Vorhaben. Zum besagten CSRA Chip ist ja im Wiki alles hinreichend dokumentiert.

@IPv6
Das mit dem umprogrammieren wäre wohl noch das geringste Problem, dafür hätte ich zumindest alles hier liegen, auch die stelle im Datenblatt mit den passenden PS_Keys hab ich schon gefunden..
Spannender wird da jedoch die passenden Unterlagen zu finden, habe nämlich keinen schimmer auf welche Pins das BRB4 das dann ausgeben würde. Wenn diese nicht rausgeführt wurden, würde ich mich ohnehin einfach nach einem anderen Modul umsehen.


Leider fehlt es mir am Oszi sowie dem Wissen für fachgerechten Umgang mit einem solchen, daher meine frage hier (+Bildchen) ob da schon mal jemand etwas mit gemacht hat, bevor ich versuche mich in etwas einzulesen, was ohnehin keine Aussicht auf Erfolg hat...

LG


EDIT:
Hat wohl SPI, UART, und noch irgend eine Programmierschnittstelle auf meinem Bildchen... Schaut also nicht nach problemlosem Anschluss von I2S...
Trotzdem merci!

@MK_Sounds danke für die Infos, probiere es nochmal am Wochenende. Wenns dann immer noch nicht tut, muss ich mal irgendwo die Möglichkeit finden, n Oszi zu benutzen um zu schauen, ob und was der ESP sendet....

@IPv6 ich geb auf jeden Fall Rückmeldung, wäre ja deutlich günstiger als n CSR Board & Programmer. Und man hätte natürlich noch viel mehr Möglichkeiten.

Gruß Raphael

Hallo Zusammen,
bin neu hier und noch Neuling auf dem Sure DSP gebiet.
Ich bin gerade beim bau einer Akku-Box wird ein klassisches 2-Wege System. 2xTT2xHT
Angeschoben wird das ganze von einer Wondom TPA230 AMP mit DSP für die HT´s und einer TAMP1200 für die Bässe. Das Grundgerüst steht auch soweit und die ersten Hörproben lassen großes erhoffen
Nun meine Fragen:

1. ich suche ein Tool in SigmaStudio womit ich Töne herausfiltern kann die man eh nicht hören kann um die Akkulaufzeit zu verbessern. Fall des sowas überhaupt gibt Hab mal gelesen das das wohl so beim Soundbok gemacht wird. Es sollte aber nicht hörbar sein also sich nicht auf den klang wiedergeben.

2. ich sehe das von vielen der compresor benutzt wird. kann mir jemand die genaue Funktion von diesem Tool erklären.

3. Ich möchte einen Limiter für den Bass integrieren der bei einer gewissen Lautstärke abregelt. Könnt ihr mir sagen welcher dafür am besten wäre?

Hier noch meinen Aktuelle Schaltung. Danke schonmal

manu97 (Beitrag #1789) schrieb:

1. ich suche ein Tool in SigmaStudio womit ich Töne herausfiltern kann die man eh nicht hören kann um die Akkulaufzeit zu verbessern.

Einen Hochpass am Eingang hast du doch schon Würde ich einfach als Filter höherer Ordnung machen. Klassischer Subsonic-Filter.

2. ich sehe das von vielen der compresor benutzt wird. kann mir jemand die genaue Funktion von diesem Tool erklären.

Dynamikfunktionen wie Kompressor und Limiter werden zum Schutz der Lautsprecher eingesetzt. Im Prinzip begrenzt der Kompressor die Signalamplitude in Abhängigkeit vom Pegel und der gewählten Kompressionskurve.
Ein Limiter ist ein Kompressor mit unendlich hoher Kompression.

Google wird dazu genug detaillierte Infos liefern. Vor allem im PA-Bereich ist das absolut Standard.

IPv6 (Beitrag #1718) schrieb:

Jetzt bin ich selber in der ungeschickten Lage, dass mein USBi Programmer nicht mehr erkannt wird. Ich habe aus dringenden Gründen meinen Rechner neu aufgesetzt, auf dem vorher SigmaStudio mit dem FreeUSBi immer seit Anfang an problemlos lief. Jetzt habe ich das SIgmaStudio runtergeladen (Version 4.2), Treibersignatur erzwingen deaktiviert und will den Treiber installieren, Windows meckert aber, dass in dem angegebenen Ordner keine Treiber zu finden sind. Hat da schon jemand Bekanntschaft mit solchen Problemen mit der neuen SigmaStudio Version gemacht und hat eine Lösung? Würde sehr helfen, ich bin gerade für meine Abschlussarbeit auf SigmaStudio und den Programmer angewiesen.

Angeregt vom aktuellen Nachbar-Thread zum Thema USBi-Treiber auch hier der Hinweis:

Es scheint sich wohl in der Tat so zu verhalten, dass die Installation nach FreeUSBi Anleitung mit der Version der Datei "ADI_USBi.spt" ab Sigma Studio 4.2 nicht mehr funktioniert. Die meisten werden vermutlich noch auf einer älteren Version unterwegs sein, deshalb ist das Problem nicht verstärkt aufgepoppt. Habe es nun auch mal selbst auf einem blanken Rechner getestet. Mit dem Treiberfile aus Sigma Studio 4.2 schlägt die Installation fehl. Mit dem Treiber von Version 4.1 funktioniert es nach wie vor. Bevor man aber anfängt völlig umständlich am EEPROM herumzuflashen, könnte man sich natürlich auch eine vorherige Treiberversion besorgen. Nun zum produktiven Teil: Für die Treiberversion von Sigma Studio 4.1 habe ich ein Git Repo angelegt und dort den Treiberordner für Windows 10 x64 als Zip hochgeladen. Für andere Betriebssysteme kann das File "ADI_USBi.spt" mit den Treibern des entsprechenden Systems kombiniert werden. Link USBi-Driver-SigmaStudioVers.4.1

Ich gehe mal davon aus, dass ich das File aus Copyright Gründen nicht auf Dauer online lassen kann. Deswegen habe ich es hier zusätzlich gepostet, damit die meisten aktiven DSP‘ler es downloaden können. Würde das Repo dann im Laufe des Wochenendes wieder löschen.
Danach kann man das ggf. per PM verteilen.

Ich habe das mal schnell ins Wiki übernommen, da dürften ab sofort sonst immer mehr Leute drüber stolpern, die sich SigmaStudio neu herunterladen.
Ist das so einigermaßen richtig und schlüssig im Wiki?

Würde eher n ganzen Abschnitt dafür schreiben.
So ist das nicht sofort ersichtlich

Nur zu!

Zeitlich ist aktuell nur Schadensbegrenzung statt Neufassung drin...

Klausurenphase?
Ich weiß nicht mal mein PW momentan
Kommt auf die ToDo, ggf wird das ganze bald sowieso aufn deutlich flotteren Server umgezogen, dann kann mans vielleicht sogar ein wenig mehr aufarbeiten.

Klausurenphase plus Abschlussarbeit plus zig Projekte gleichzeitig. Der ganz normale Wahnsinn eben.

jo die mind 50 Projekte gleichzeitig machens nicht einfacher... Abschlussarbeit ist erst im nächsten Semester bei mir.

Naja b2t: jeder darf sich angesprochen fühlen etwas anzupassen.

Doppelpost.
Den Treiber gibts nicht mehr auf Github, hat den wer parat? Würde ihn einfach mutig hochladen.
Oder gabs Ärger?

Vielleicht kann MK Sounds was zum Grund sagen?

danny08 (Beitrag #1798) schrieb:

Doppelpost. Den Treiber gibts nicht mehr auf Github, hat den wer parat? Würde ihn einfach mutig hochladen. Oder gabs Ärger?

Hab ich wie angekündigt wieder raus genommen.
Hatte keine Zeit mich mit den rechtlichen Gegebenheiten auseinander zu setzen. Wenn man das Ding aber vllt nicht gerade "Sigma DSP USBi Treiber" nennt, sollte eigentlich nichts passieren. Wenn wir das direkt im Wiki hätten, wäre das natürlich ideal (ob kommende Versionen von Sigma Studio dann wieder wie gehabt funktionieren werden, wird sich zeigen).
Wer den Treiber braucht, dem kann ich die Files natürlich schicken. Einfach eine kurze PM an mich.

Moin,
mein free USBi wird auf meinen beiden Rechnern quasi gleicchzeitig nicht mehr richtig erkannt, ohne dass ich was gemacht hätte... Im Gerätemanager erscheint er, aber eben nur als unbekanntes USB-Gerät. Mein Fehler ist also ganz ähnlich, wie schon oben beschrieben, allerdings habe ich noch nicht mal eine neue Sigma Version installiert...

Liegt es vielleicht an einem der neuen Windows-Updates?

tscheikop (Beitrag #1801) schrieb:

Liegt es vielleicht an einem der neuen Windows-Updates?

Das ist durchaus möglich. Ich hatte das zumindest schon 2-3 Mal am Anfang von Windows 10.
Es schien, als würde Microsoft die Treiber, die ohne Signatur installiert wurden, einfach rauszuschmeißen. Treibersignatur erzwingen deaktiviert, Treiber installiert und dann ging es wieder.

MK_Sounds (Beitrag #1802) schrieb:

tscheikop (Beitrag #1801) schrieb: Liegt es vielleicht an einem der neuen Windows-Updates? Das ist durchaus möglich. Ich hatte das zumindest schon 2-3 Mal am Anfang von Windows 10. Es schien, als würde Microsoft die Treiber, die ohne Signatur installiert wurden, einfach rauszuschmeißen. Treibersignatur erzwingen deaktiviert, Treiber installiert und dann ging es wieder.

Jap, Windows schmeißt bei Updates gern den Treiber raus.

MK_Sounds (Beitrag #1802) schrieb:

tscheikop (Beitrag #1801) schrieb: Liegt es vielleicht an einem der neuen Windows-Updates? Es schien, als würde Microsoft die Treiber, die ohne Signatur installiert wurden, einfach rauszuschmeißen. Treibersignatur erzwingen deaktiviert, Treiber installiert und dann ging es wieder.

Das war der entscheidende Tipp, geht wieder...
Ich brauchte den Programmer unbedingt, vielen Dank!

Grüße aus Bremen