Aurora rev2 (Hardware redesign)

[rkv]

@capslock:
zu 1) Ich hätte da schon ein MagJack eingebaut zwecks galvanische Trennung.

zu 2) Naja, es war schon so gedacht, die Schaltung so zu lassen und nur das +-Signal abzugreifen und auf Cinch zu führen. Die IDCs für das symmetrische Signal bleiben.

zu 3) Takt generiert der DSP aus einem Quartz und verteilt diese auf die Sports.

Raphael

[capslock]

Will heißen, das Quarz sitzt direkt am DSP und wird von einem unbuffered gate auf dem DSP-Chip angetrieben? Das ist ein recht sicheres Rezept für Jitter. Ein kleines single-HCU mit eigenem Stützkondensator wird da schon deutlich besser.

[kboe]

Wenn ich eine kleine Bitte einbringen dürfte:
Die 68R Schutzwiderstände für die AusgangsOPs gehören unbedingt aufs Board und nicht aufs AddOn -> Betriebssicherheit.

Gruß
Bernhard

[danny_aux]

Ich habe dann auch noch eine kleine Frage. Wenn es dir neue Auflage von Aurora gibt, wird es dann für die erste Generation noch Firmware Updates geben ?

[rkv]

Ein weiterer Grund möglichst nahe an rev1 zu bleiben und nicht in eine ganz anderer Richtung zu gehen. Zwei unterschiedliche Produkte werde ich sicher nicht supporten können und ich werde garantiert nicht eine neue Version machen, wo noch mehr Elektronikgrundkenntnisse beim Anwender notwendig sind, eher die andere Richtung. Das hat mich rev1 gelehrt.

[danny_aux]

Ja, das würde keinen Sinn machen. Ziel war ja mal, so vielen Menschen wie möglich guten Sound nach Hause zu bringen.

[Leif]

Ein weiterer Grund möglichst nahe an rev1 zu bleiben und nicht in eine ganz anderer Richtung zu gehen. Zwei unterschiedliche Produkte werde ich sicher nicht supporten können und ich werde garantiert nicht eine neue Version machen, wo noch mehr Elektronikgrundkenntnisse beim Anwender notwendig sind, eher die andere Richtung. Das hat mich rev1 gelehrt.

Hallo Raphael,

genau aus diesem Grund würde ich dem Kunden auch nicht damit belasten, ein Netzteil mit zwei verschiedenen Spannungen suchen zu müssen.
Eine Ethernetbuchse würde ich Wifi auf jedem Fall vorziehen. Ich finde die Verbindung einfach sichererer und möchte nicht überall (Metallgehäuse) außen eine Antenne dran haben.
Zudem kann man mit Ethernet auch den DSP aus einem Raum steuern, von dem keine WiFi Verbindung möglich ist.

[Micha_HK]

Ein weiterer Grund möglichst nahe an rev1 zu bleiben und nicht in eine ganz anderer Richtung zu gehen. Zwei unterschiedliche Produkte werde ich sicher nicht supporten können und ich werde garantiert nicht eine neue Version machen, wo noch mehr Elektronikgrundkenntnisse beim Anwender notwendig sind, eher die andere Richtung. Das hat mich rev1 gelehrt.

Verständlich.
Wäre es ev. möglich im Layout vorzusehen, den ESP32 zu umgehen, d.h. relevante Signale wie I2C, SPI, etc. auf nicht bestückte Testpins zu legen und auf der Platine nicht bestückte 0 Ohm Widerstände (frei kratzbare Leiterbahnverbindung) zum ESP32 vorzusehen?
So könnten Spielfreudige auch nen Raspi dran hängen.

[rkv]

Verständlich.
Wäre es ev. möglich im Layout vorzusehen, den ESP32 zu umgehen, d.h. relevante Signale wie I2C, SPI, etc. auf nicht bestückte Testpins zu legen und auf der Platine nicht bestückte 0 Ohm Widerstände (frei kratzbare Leiterbahnverbindung) zum ESP32 vorzusehen?
So könnten Spielfreudige auch nen Raspi dran hängen.

Das kannst Du schon mit rev1 sehr leicht haben ohne die Platine mechanisch bearbeiten zu müssen:
In der Software den ESP32 als I2C slave konfigurieren oder noch brutaler: Das Programm durch ein Nichts-tu-proggi ersetzen und dann die gesamte Kontrollfunktion an den RasPi übergeben. Die I2C-Leitungen liegen auf dem Expansion-Header.

[Micha_HK]

:eek: ...hatte den Schaltplan nicht im Kopf. Dachte es sind noch weitere I/Os vom Esp32 nötig.

:thumbup:

[saddevil]

Stromversorgung getrennt sowieso..

Aber symmetrische Versorgung macht nur Sinn wenn dann auch DC gekoppelt werden kann.

Ich würde aber vlt auf etwas höhere Spannung gehen um den theoretischen headroom zu haben.
Das dürfte im Normalfall den klirr senken.

Zur Aufteilung digital und analog..
Da würde ich nur gut Filtern.
Ggf nen gyrator der als Impedanzwandler den analogteil entkoppelt.



Gibt's vlt den Schaltplan dann öffentlich ?
Täte mich interessieren.
Mache das ja auch beruflich...



Wegen IP
Ja der ESP kann auch ETH.

Ich würde da lieber nen Cortex M7 nehmen.
Beruflich bin ich da fitter ^^

Das würde aber bedeuten daß man die SW nochmal stark anfassen müsste.
Da kann. Ich das gut verstehen.

[autoschrauberix]

Gibt's vlt den Schaltplan dann öffentlich ?
Täte mich interessieren.
Mache das ja auch beruflich...

Den gibt es doch schon, ist doch ein Github Projekt

https://github.com/freeDSP/freeDSP-aurora/tree/master


Leider scheint meine Frage untergegangen zu sein. Wie sieht's aus mit einem 2. Erweiterungsport ?

[Mr.Zuk]

Hat das ganze Auswirkung auf die AddOns? Ich meine jetzt speziell das Addon-B - ist hier auch ein redesign notwendig? Ich befürchte dass ich auch etwas vom Rattenschwanz abbekomme...

[rkv]

Leider scheint meine Frage untergegangen zu sein. Wie sieht's aus mit einem 2. Erweiterungsport ?

Ja und nein, bin da zwiespältig. Beim zweiten Port wäre nur ein I2S/TDM8-Ausgang möglich, ein entsprechender Eingang jedoch nicht, weil dieser am DSP schon durch den ESP32 belegt ist (für die Option den ESP32 für Streaming einzusetzen). Ich sehe da meine email-Postfach schon wieder überquellen mit der Frage, warum man nichts hört, wenn man einen ADC an Port 2 anschliesst. Handbücher werden ja bekanntlich nicht gelesen...

[rkv]

Hat das ganze Auswirkung auf die AddOns? Ich meine jetzt speziell das Addon-B - ist hier auch ein redisign notwendig? Ich befürchte dass ich auch etwas vom Rattenschwanz abbekomme...

Erstmal nicht, allenfalls wenn sich die Ethernet-Variante durchsetzt.

[autoschrauberix]

Ja und nein, bin da zwiespältig. Beim zweiten Port wäre nur ein I2S/TDM8-Ausgang möglich,

Genau den könnte ich gut brauchen
Vorschlag dann nennen wir den einfach so und bleiben bei einem Erweiterungsport. Wer das Handbuch liest findet den zusätzlichen I2S/TDM8 Ausgang

Ich würde übringens auch Ethernet bevorzugen, WLAN schalte ich nur für die Programmierung ein und das ist ein bischen umständlich.

[dipoluser]

Hallo,

da wir ja aktuell eine Adapterplatine entwickeln, die speziell auf X301 zielt, wäre die bekannte PIN-Belegung der Stiftleiste wichtig. Cinch I/O als Aufsteckplatine hätte ggf. Charme und würde das Board auch nicht "überfrachten", jedoch stellen die AddOns hinreichende Möglichkeiten schon jetzt dar.

Eine Ansteuerung der digitalen Eingangsquellen wäre cool (könnten die Schalter auf AddOn A ersetzen). Bei einer dann nötigen Revision von AddOn A könnten wir unterstützen.

Ethernet wäre auch unser Favorit!

Einen OpenCollector-Ausgang für "Amp-Enable nach Hochlauf der DSP/DACs" -> Plopp freie Zu-und Abschaltung von Endstufen (z.B. Hypex oder Purifi) wäre sehr wünschenswert.

Einen besonderen Blick auf die Qualität des 8-fach DAC und die ausgangsseitigen analogen Treiber (mit SV-Trennung zur digitalen Umgebung) könnten wir uns vorstellen. Somit ein klares Ja zur SV-Erweiterung.

[saddevil]

Gibt es eine Erklärung warum so viel Kapazität nach dem LDO verbaut ist ?

Sowas verursacht manchmal schwingen weil der Regler am Ausgang gebremst wird.

Wenn man Puffern will ist vor dem Regler wesentlich mehr Energie vorhanden.

Daher lieber dick vor dem Regler Puffern, danach zweckgebunden.

[Rainer]

Hallo,

wäre es nicht möglich Ethernet über den XMOS XE216 laufen zu lassen.
Dann sollte doch auch Audio over IP (AoIP) möglich sein.

Der Controller hat bis jetzt kaum was zu tun außer warmzuwerden.

[audiobob]

a) finde ich gut. WLAN würde ich deaktivieren und optional aktivierbar lassen.
b) ist ganz nett für schnelles testen. dann wäre auch 2 Chinch Out auf dem Board ganz gut.
c) warum denn eigentlich? Was spricht gegen die 12V Vorgabe vom FreeDSP Projekt?

Wann soll das re-design kommen? Überlege mir gerade einen Aurora zu bauen. Du hast die nicht mehr auf Lager, oder?