Hallo Forengemeinde, der Prototyp eines semi-professionellen Audio-Recorders ist fertig. Er ist im Zuge einer Studie zum neuen ATMEL XMega128A1 Controllers und aus dem Bedarf nach einem unkompliziert zu bedienenden, handlichen Audio-Recorder entstanden, welcher ohne Datenkompression auskommt und studiotauglichen Klang bietet. Die Entwicklung ist noch nicht abgeschlossen und die Pläne müssen nochmal überarbeitet werden, aber die erste Generation läuft und arbeitet zufriedenstellend. Der Technische Aufbau ist wie folgt: Hauptcontroller: ATXMega128A1 @ 36.864MHz (3x12.288Mhz) Nebencontroller: 2x ATTiny2313 @12.288Mhz Anzeige (grafisch): Electronic Assembly DOG, 132 x 32 Pixel, HG-Beleuchtung A/D-Wandler: Cirrus CS5343 D/A-Wandler: Cirrus CS4344 I2S->SPDIF-Converter: Cirrus CS8406 Kopfhörer-Verstärker: TDA1308A Puffer-SRAM: CY7C1019 (128kByte) Step-Up-Converter, Buchsen und Hühnerfutter Die Features sind momentan: Aufzeichnung im RAW-PCM-Format 48kHz, 16Bit Anzeige Speicherkarten-Kapazität in Minuten+Sekunden Anzeige aktuelle Position in Minuten+Sekunden Anzeige Pufferfüllstand bei der Aufzeichnung Anzeige Pegel l. & r. Kanal, audiotechnisch relevante Bereiche markiert Anzeige SD-Kartenstatus Anzeige Akku-Füllstand Umgebungslichtabhängige Hintergrundbeleuchtung der Anzeige 1x Line-Eingang analog 1x Line-Ausgang analog 1x Kopfhörer-Ausgang 1x optischer SPDIF-Ausgang Aufzeichnung, Wiedergabe, schnelles Spulen vor und zurück, Stop gemeinsame, digitale Lautstärke-Steuerung aller Ausgänge Das Gerät fungiert wie eine Art Bandmaschine, die Aufnahme/Wiedergabe erfolgt fortlaufend ab der aktuellen Position und unmittelbar auf Knopfdruck. Es soll bei länger andauernden Aufnahmesitzungen den Computer ersetzen. Eine Trackmarkierung ist noch geplant, die Positionen sollen auf der Karte in einem separaten Sektor abgespeichert werden. Die Audiodaten liegen auf der Karte als durchgehender Stream und ohne Dateisystem vor, um die Schreib-Performance zu wahren. Ein Puffer-Ram von 128kByte (64kByte verwendet) verhindert Aussetzer durch Sektorsprünge, die die SD-Karten von Zeit zu Zeit willkürlich aufgrund des Wear-Levellings durchführen. Ab etwa 32kByte waren alle getesteten Karten bei dem gegebenem Datenaufkommen zuverlässig zu beschreiben. Ein Import der Daten auf PC oder MAC ist über passende Software, bspw. HEX-Editoren, möglich. Die Schaltpläne und das Layout folgen noch, ebenso audiotechnische Messungen des Frequenzganges, des Signal-Rausch-Verhältnisses und der Verzerrungen. Vielen Dank für die Aufmerksamkeit. Anregungen und Fragen sind willkommen. Grüße! TravelRec.
Hallo Travel Rec, ich verneige mein Haupt. Wie lange läuft das Gerät mit den Akkus? Welchen Step Up verwendest Du? Sind das alles leicht zu beziehende Bauteile?
Hallo Michael, die Bauteile habe ich in der Hauptsache von CSD-electronics und das Display ist von Angelika. Der Step-Up ist ein LM2621, bezogen über Mercateo. Das Gerät braucht etwa 200mA bei 2.4V (120mA nach Step-Up) beim Schreiben oder bei der Wiedergabe, ein Satz 2000er Mignon hält also knapp 10 Stunden.
Anbei der erste Performance-Test: Analoger Soundkarten-Ausgang über 1.5m Kabel an den SD-Wave-Recorder, SPDIF-Ausgang zürück auf SPDIF-Eingang der Soundkarte. Die Daten enstprechen der Aufnahmequalität. Testsoftware ist der RightMarkAudioAnalyzer, Version 6.2
Das ist in der Tat sehr beeindruckend. Aber, weil das hier die Codesammlung ist, wo ist der Code den du uns gerne zeigen möchtest?
Kommt bald - als *. hex vorerst, da ich zum Bereinigen noch etwas Zeit brauche. Außerdem gibt es keine "Hardwaresammlung".
Ja hallo nochmal, ich hatte noch eine neue Messung getätigt, diesmal mit anständigem und kurzen analogem Kabel. Die Ergebnisse im Anhang.
Hi Travel, ich bin wirklich sehr beeindruckt von deiner Leistung ;) Gruß Anselm p.S: Wenn ich mal viel Zeit habe (kommt letzte Zeit so wenig vor) lasse ich mir noch eine XLR dafür einfallen (dadurch direkt am Mischpult anschliessbar) Und Eingangsstufe mit Dämpfungsmöglichkeit. Aber vielleicht hat jemand weiteres noch Zeit und Interesse daran ;)
Hallo Anselm, es sind noch viele Erweiterungs- und Verbesserungsmöglichkeiten da. Wenn der Kern der Schaltung erstmal funktioniert, kann man noch einiges an Peripherie dranstricken, zum Beispiel auch eine MIDI-Steuerung der Funktionen oder eine Fernbedienung über Funk/IR oder die Möglichkeit, mehrere Recorder zu synchronisieren, um Mehrspuraufnahmen zu machen. Und man kann sich natürlich auch noch einige Finessen in der Software ausdenken ;-)
Hallo, ist es denn möglich den code iwi zu bekommen ? wäre angesichts der tollen ergebnisse ja eine wunderbare sache. Vielen Dank schonmal PS ist es vll möglich auch an den source-code zu kommen (also nicht nur an die *.hex?) KarlMonster
Hallo Karl, wenn Du das Teil 1:1 nachbauen möchtest, dann nur zu. Die Codes schicke ich Dir als *.hex. Wenn Du in ASM fit bist, kannst Du auch die Sources haben, die sind aber noch ein bisschen dreckig ;-).
Hallo, ja das wäre super wenn du mir beide Files schicken könntest. Ich werde erstmal 1:1 nachbauen und dann bisschen mich am code zu schaffen machen. willst du die files hier hochladen oder willst du meine e-mail ? Vielen Dank nochmal KarlMonster
Gib mir mal gelegentlich Deine Mail. Es sind 3 Codes hochzuladen, jeweils einer für die Tinys und einer für den XMega. Die meisten Bauteile, speziell die Spezial-ICs von Cirrus, das SRAM, TDA1308 und den Quarz-Oszi 12.288Mhz gibt es bei CSD-electronics. Das EA-Dog-Display und die Folien-Cs sind von Reichelt. Der Step-Up-Converter + Induktivität ist von Mercateo geliefert.
Hab dir ne PN geschrieben mit meiner mail ... sagste wennse ned bekommsch oder sonst was ... Achja noch was: macht der µC denn testroutines mit dem SPDIF-Converter Cirrus CS8406? Ich habe im moment nämlich keine intresse an SPDIF und daher dachte ich ans weglassen des Bereiches. Wenn der µC das allerdings testet ob da was ist oder ob der in Ordnung ist wäre das iwi doof. Danke KarlMonster
Der SPDIF-Controller ist optional, er hängt quasi als Aufsatz an den Digital-Leitungen des DAC und ist für den XMega nicht sichtbar.
Hi, sry möchte dich nicht nerven, aber könntest du mir die codes schicken ? ich bin mit der hardware fast fertig ^^ jetzt bräucht ich noch die codes zum rumfeilen bzw zum direkt mal ausprobieren. Was für eine Software bzw. welchen Hex-Editor verwendest du denn um den stream dann letztendlich zur "richtigen" datei zu machen ? Danke nochmals & schöne weihnachten KarlMonster
Oohh, hi nochmal. Ich habe Deine PN leider irgendwie nicht erhalten. Geh mal bitte auf www.electricstart.de und schreibe mir auf der Kontaktseite Deine Adresse, dann melde ich mich sofort. Ich verwende AVR-Studio4.14. Die Fuse-Einstellungen brauchst Du ja dann auch noch. Bis denne.
@travelrec Das hier ist eine Codesammlung! Das Projekt posten und damit angeben wie toll du bist und dann noch nichtmal den Code mitliefern, finde ich etwas erbärmlich.
Ich gebe den Code deswegen noch nicht ´raus, weil er nicht fertig und nicht ausreichend dokumentiert ist. Wenn jemand das Projekt nachbauen möchte, bekommt er selstverständlich die Sources. Ich möchte lediglich verhindern, daß über Programmierstil oder Formsachen hergezogen wird, weil ich das Forum kenne ;-). Finde es erbärmlich, wenn Du magst.
Ich konstruiere auch seit ein paar Monaten so ein Viech, allerdings mit eingebauter Festplatte. Das deshalb, weil ich die direkte Aufzeichnung auf SD-Karte irgendwie mutig finde: Bei verschiedenen Versuchen von Chan und anderen wars mit der Schreibrate immer verdammt knapp. Völlig wertfrei, also quasi nur, um dich unter Druck zu setzen, mal meine Vorstellung *grins*: - 44,1kHz bei 16 Bit - ATmega16 vermutlich - symmetrische XLR-Ein- und Ausgänge - SD-Kartenslot zum Datenaustausch Viel Erfolg und Chapeau!
>Das deshalb, weil ich die direkte Aufzeichnung >auf SD-Karte irgendwie mutig finde: Bei verschiedenen Versuchen von Chan >und anderen wars mit der Schreibrate immer verdammt knapp. Direkt ist relativ, bei dem hier vorgestellten Gerät nutze ich 64kByte externes SRAM zum puffern, falls die Karte mal ihr wear-levelling ausführt und nicht schnell genug die Daten abnimmt. > mal meine Vorstellung *grins*: >- 44,1kHz bei 16 Bit >- ATmega16 vermutlich >- symmetrische XLR-Ein- und Ausgänge >- SD-Kartenslot zum Datenaustausch Echtes Wave mit ATMega16? Das wird sportlich. An welche externen Wandler hast Du dabei gedacht? Ich finde die Interrupt-Response-Time vom Mega16 bei 16Mhz etwas zu lang. Bei seriellen Wandlern könnte es da zu Laufzeitproblemen kommen. Das war der Grund, weshalb ich mit XMega und 2 Sub-Controllern gearbeitet habe. Symmetrische XLRs sind cool, erweitern die technischen Anforderungen an die analoge Sektion aber doch erheblich und setzen den Stromverbrauch hoch. Naja - kommt immer drauf an, wofür man das Teil im Alltag einsetzen möchte.
"Rohdaten-WAV", joa. Mit SPI-Wandlern von TI haut das schon hin, viel Zeit fürs Display bleibt aber nicht, das ist wahr.
Momentan hab ich vorne ADS8517 und hinten DAC8831 verplant. Bin allerdings selbst auch noch gespannt, ob das alles hinhaut :-}
Aha. Der ADS8517 ist aber kein Audio-ADC, was bedeutet, daß er keinerlei Filter onboard hat. Du mußt also das Anti-Aliasing analog und diskret vor dem ADC aufbauen. Desweiteren ist das Teil nur einkanalig, also "Mono". Gleiches trifft für den DAC8831 zu. Was dazu kommt ist, daß Du das Timing zumindest für den DAC mittels des Controllers generieren mußt, wodurch Du Dir einen nicht unerheblichen Jitter im DAC einfängst. Der nachfolgende Tiefpaß muß auch extern und diskret aufgebaut werden. Also nichts für empfindliche Ohren.
Travel Rec. wrote: > Aha. Der ADS8517 ist aber kein Audio-ADC Korrekt >, was bedeutet, daß er keinerlei Filter onboard hat. Korrekt, so kann ich aber im Zweifelsfall den Filter noch auf die Samplingfrequenz abstimmen. Da ich ohnehin Analoggeraffel drinnehab (Desymmetrierer, Vorverstärker usw.) geht das in Einem. > Du mußt also das Anti-Aliasing analog und diskret > vor dem ADC aufbauen. Korrekt > Desweiteren ist das Teil nur einkanalig, also "Mono". Gleiches > trifft für den DAC8831 zu. Korrekt und korrekt. Es werden je zwei ADC und zwei DAC verbaut. > Was dazu kommt ist, daß Du das Timing zumindest für den DAC mittels > des Controllers generieren mußt, Korrekt. > wodurch Du Dir einen nicht unerheblichen Jitter im DAC einfängst. Nicht zwangsläufig. Wie du schon sagst, sportlich wirds allemal, aber die beiden Klicker sind ziemlich überschaubar, sodass der Drift doch vernachlässigbar ist. > Der nachfolgende Tiefpaß muß auch extern und diskret aufgebaut werden. Korrekt. Auch hier geht das in Einem, da ich wieder den Symmetrierer brauche. > Also nichts für empfindliche Ohren. Das wollen wir noch sehn :-} Ganz astrein ist das alles sicherlich nicht (ich erfind gern das Rad neu, ist mir bewusst...), aber der Lerneffekt steht ganz eindeutig im Vordergrund, zumal ich die Wandler bereits aus anderen Projekten übrig hatte. Mal nen guten Platinenentwurf vorausgesetzt, dürfte die Sache so übel garnicht werden, zumindest die Simulation meiner Vorstellung an Filtern sieht schonmal ganz gut aus.
Ich habe gehörig Respekt vor Deinem Vorhaben. Meine ersten Experiemente mit dem XMega bezogen sich auf die internen Wandler. Diese haben zwar nur 12 Bit, aber zum Testen war das schon ganz gut. Was mir dabei aufgefallen war, ist die Tatsache, daß ein vernünftiges analoges Filter mit steiler Charakteristik ein fieses Unterfangen ist. Du willst das nun gleich 4x aufbauen. Bei den externen Wandlern von Cirrus wird digital gefiltert und das sowas von steil, daß man den Cut oberhalb von 22kHz wirklich nicht wahrnimmt. Bei meinen vormals analogen Filtern war ein deutlicher Transparenzverlust gegenüber dem Originalsignal zu hören, obwohl ich mit der Grenzfrequenz testhalber auch mal ein Stück über fsample/2 gegangen war. Also ich wünsch Dir Glück und bin auf die Ergebnisse gespannt.
Es wäre schön wenn Du noch was zu den Kosten sagen könntest. Kann man die Platine per Toner-Transfer hinbekommen oder ist sie "error-prone"? Ist schon ein Verstärker eingebaut, oder braucht man noch einen (Mikrofon-)Verstärker um ein Audiosignal von ~1V zu bekommen?
Kann ich Dir nicht sagen, ob Tonertransfer da funkioniert, weil ich das noch nicht probiert habe. Ich habe die Platine mittels Ink-Jet-Ausdruck auf Papier und normaler Belichtung hergestellt. Die dünnsten Leiterbahnen sind 0.25mm breit und die schmalsten Abstände zwischen den Leiterbahnen sind ebenfalls 0.25mm, in der Hauptsache um den XMEGA herum. Alle anderen Leiterbahnen und Abstände sind breiter. Die Kosten belaufen sich inklusive der Spezial-ICs und des Grafik-Displays auf etwa 50 EUR. Das Gerät verarbeitet unsymmetrischen Line-Pegel, für Mikrofonanschluß muß also ein externer Verstärker vorgeschaltet werden.
Hi! Zuerst mal: Super Projekt und sauber ausgeführt! Eine Frage zum Display: Ich habe hier das gleiche Modell auf meinem Steckbrett, läuft einwandfrei. Allerdings habe ich als Kondensatoren für die Spannungswandler, wie im Datenblatt abgegeben, 1uF genommen. Laufen die auch mit 100nF? Die wären ja um einiges kleiner. Hast Du spezielle Einstellungen benutzt? Danke und Gruss, Micha68
Danke für die Blumen :o). Ja, diese Ausführung des Displays läuft mit 100nF Kondensatoren stabil und ohne Probleme, ich hatte es einfach mal mit den Pillen getestet und es lief. Ich habe die Standard-Init aus dem Datenblatt genommen.
Hier die Init, ist ein Software-SPI: ;--------------------------------------------------------- EA_DOG_INIT: sbi VPORT2_Out, DispReset cbi VPORT2_Out, DispComDat ldi Temp, $40 rcall EA_DOG_Write ldi Temp, $A1 rcall EA_DOG_Write ldi Temp, $C0 rcall EA_DOG_Write ldi Temp, $A6 rcall EA_DOG_Write ldi Temp, $A2 rcall EA_DOG_Write ldi Temp, $2F rcall EA_DOG_Write ldi Temp, $F8 rcall EA_DOG_Write ldi Temp, $00 rcall EA_DOG_Write ldi Temp, $23 rcall EA_DOG_Write ldi Temp, $81 rcall EA_DOG_Write ldi Temp, $1F rcall EA_DOG_Write ldi Temp, $AC rcall EA_DOG_Write ldi Temp, $00 rcall EA_DOG_Write ldi Temp, $AF rcall EA_DOG_Write ret ;--------------------------------------------------------- EA_DOG_Write: cbi VPORT2_Out, DispCS ldi TempH, 8 _DWLoop: lsl Temp brcs _DataHigh _DataLow: cbi VPORT2_Out, DispData rjmp _DWClock _DataHigh: sbi VPORT2_Out, DispData _DWClock: sbi VPORT2_Out, DispClock nop cbi VPORT2_Out, DispClock dec TempH brne _DWLoop sbi VPORT2_Out, DispCS ret
Es hatte sich ein kleiner Fehler im Layout des CS8406 eingeschlichen, das Valid-Bit war falsch angeschlossen. Somit wurde zwar ein Audio-SPDIF-Stream ausgegeben, dieser war aber als ungültig markiert. Einige Geräte haben damit Probleme (A/V-Receiver). Beste Grüße, TravelRec.
Ich würde mittelfristig das Gerät auch gerne nachbauen, um mal den Klang zu vergleichen mit den Geräten, die ich so gebaut habe. (Das Gerät hier ist bestimmt besser!) :-) Als Vorbereitung habe ich mal aus Eagle die Partlist exportiert und versucht, die Bauteile, die mir vertraut vorkamen, in Bestellinformationen umzusetzen (auch um zu sehen, wieviel das Ganze dann kostet). Dazu habe ich beiliegende Excel-Tabelle erstellt. Wie man sieht, gibt es offene Fragen zu Lieferanten, Bauformen etc. @Karl - Du bist ja wahrscheinlich inzwischen fertig - wie läuft es so? Wärst Du so nett, für andere potentielle Nachbauer und mich, in der Tabelle ein paar Zellen mit den Fragezeichen auszufüllen? Ich habe es nicht eilig, hab sowieso wenig Zeit, bei mir wird sich das mindestens ein paar Wochen sicher hinziehen. Deshalb wären bei weiteren Nachbauinteressenten Sammelbestellungen und Platinenfertigung denkbar (ich löte SMD dann doch lieber mit Lötstoplack..) Wer macht mit?
Hallo Carsten, bin gerade am durchgucken, was meinst Du denn mit den Eintragungen "andere Bauform!"?
Wahrscheinlich ist es kein Problem: Eagle sagte, die Bauform wäre 0603, die, die ich gefunden habe, waren 0403. Einfach die Frage, ob es anzulöten geht und auf die Platine paßt (interessanter bei den Tastern).
Alle passiven BE auf dem Recorder bis auf wenige Ausnahmen sind 0603, CSD hat in 0603 eigentlich alles da. Falls nicht, in Kürze auf Anfrage.
Wenn wir schon teilweise in Polen bestellen, vielleicht paßt auch der SD-Slot "MCC-SD" bei www.TME.pl? Aber Du hast ja gesagt, es ist nur ein Zwischenstand.. nur kein Stress.. :-)
Hi travel rec, nettes Projekt - gibt es hier eigentlich schon Neuigkeiten? Wie hast Du die Anbindung der CODECS gelöst? I2S in Software? Gruß tuxscreen
>nettes Projekt - gibt es hier eigentlich schon Neuigkeiten? Welche Neuigkeiten erwartest Du? Mein Gerät läuft und läuft. Mit ein paar Einschränkungen im Programm - aus Zeitmangel :-( >Wie hast Du die Anbindung der CODECS gelöst? I2S in Software? Ja genau. In den beiden Tiny2313 Controllern, einer macht die Eingabe vom ADC zum Xmega, der andere macht die Ausgabe vom XMega zum DAC / SPDIF Interface.
@Travel Rec. Ich hätte auch Interesse am Code (besonders an dem im Tiny2313), wurscht ob er schön ist oder nicht.
Hi TravelRec, tolles Projekt. Meinen Respekt. Ich plane bin im Moment etwas sehr ähnliches, aber doch etwas anders. Im Moment überlege ich, welche Kondensatoren ich nehme, da das ja nicht zu unterschätzen ist. An verschiedenen Stellen habe ich gelesen, dass man MKP-Typen nehmen sollte, doch sind die, die ich bisher gefunden habe bei 1uF recht groß. Welche verwendest du? Viele Dank und Grüße, Gigi
Die Line-Ein- und Auskoppelkondensatoren sind die roten MKS-Kondensatoren mit 63V Gleichspannungsfestigkeit, sind bei 4µ7 etwa 6x6x10mm, 1µ ist etwas schmaler. Für die Kopfhörerauskopplung sind 105°C Elkos mit 100µ/10V eingesetzt worden. Weitere Koppelkondensatoren sind nicht nötig.
Ja hallo nochmal, wollte nur vermelden, daß die Firmware derzeit gerade gewartet wird. Eine Indizierung der aufgezeichneten Musikdaten wird eingebaut, so daß direktes Anspringen der Titel möglich ist, nützlich z.B für die Untermalung von Veranstaltungen. Die sogenannte TOC (Table Of Contents) wird auf Kartensektor $000001 abgelegt und bietet Platz für 99 Indexmarken. Einige Kleinigkeiten gibt es noch zu verbessern, dann kommt die neue .hex, für eventuelle Nachkonstrukteure ;-)
@travel rec erstmal : respekt !! klasse projekt. auch was die daten bezüglich klangqualität angeht. saubere arbeit :-) vllt bau ich mir das teil auch nach (wenn ich die entsprechenden ic's bekommen kann). aber die idee mit dem mehrspurgerät find ich echt witzig. dann müsste man nur die reinen tinys+xmega+rams+sd auf ner kleine platine unterbringen (also so das quasi nur i2s signale gespeichert werden) das ganze mal 4 oder mal 8, das routing der i2s signale von einem cpld/fpga machen lassen (mit einschleifmöglichkeit für einen tas3103 oder so) und dann ne adat schnittstelle dranmachen ;-)) ... ok ist vllt etwas weit gesponnen, aber man darf ja noch träumen ;-)) trotzdem, riesen respekt, allein für den analog-teil. allein diesen würd ich mir als wandler wahrscheinlich mal nachbauen wollen ;-)
Ja, danke für die Blumen. >dann müsste >man nur die reinen tinys+xmega+rams+sd auf ner kleine platine >unterbringen (also so das quasi nur i2s signale gespeichert werden) das >ganze mal 4 oder mal 8, das routing der i2s signale von einem cpld/fpga >machen lassen (mit einschleifmöglichkeit für einen tas3103 oder so) und >dann ne adat schnittstelle dranmachen ;-)) ... ok ist vllt etwas weit >gesponnen, aber man darf ja noch träumen ;-)) Mach, was Du nicht lassen kannst ;-). Sofern meine Zeit das erlaubt, werde ich mal gucken, was der XMega noch an Daten wegschaufeln kann. Am sichersten wäre es wohl, die Geräte modular aufzubauen und zu synchroniseiren, da eine einzige Speicherkarte schon an 4 Spuren 48k/16Bit zu kämpfen hätte oder die RAM-Puffer elendig groß sein müßten. Außerdem hätte man im Fall eines Kartenfehlers zur Laufzeit nur 2 Spuren Verlust und das Kartenformat wäre einfacher gestaltet. Mal gucken...
@travel rec >Am sichersten wäre es wohl, die Geräte modular aufzubauen und zu >synchroniseiren, da eine einzige Speicherkarte schon an 4 Spuren >48k/16Bit zu kämpfen hätte so meinte ich das auch ... 4 spur auf ner sd karte wäre overkill, aber wenn man aus dem tiny-xmega-ram-sd-karten-verbund kleine module machen würde (also immer 2 stereo-kanäle pro sd karte) wärs sicherlich denkbar. aber das ganze ist wohl denke ich sehr aufwendig, aber ne nette idee ;-)
Najaa... da das Projekt einmal läuft, könnte man über eine Miniaturisierung mit kleineren Bauelementen durchaus nachdenken. Die Platinen müßten dann allerdings angefertigt werden, mit selberätzen wird das <200µ Leiterbahnbreite nichts mehr. Die Sache ist doch die, daß man für etwa 50EUR Materialwert ein Modul für 2 Spuren hinbekommen müßte, so daß man für etwa 250EUR mit Mastermodul einen vollwertigen 8-Spur-Recorder hätte. Anstatt einen PC mitzuschleppen, sicher eine Alternative.
Hallo Zusammen, wollte mal wissen ob sich hier noch Neues ergibt bzw. ob der Quellcode für die µCs erhältlich ist - inkl. aktuellsten Schaltplan. Ist denn der Schaltplan auf http://www.electricstart.de der aktuellste ? Also den *.rar verpackten mein ich. Gibt es denn beim 1:1 Nachbau etwas zu beachten? Wie wird die Wav denn auf dem Computer ausgelesen. Diese muss ja - soweit ich das verstanden habe - noch von der SD umgewandelt und zur *.wav gemacht werden. Sorry das habe ich noch nicht so ganz verstanden. Vielen Dank Hut ab Travel Rec. Respektable Leistung - machst du das als Hobby oder Beruf ? Gruß Günter
>wollte mal wissen ob sich hier noch Neues ergibt bzw. ob der Quellcode >für die µCs erhältlich ist - inkl. aktuellsten Schaltplan. >Ist denn der Schaltplan auf http://www.electricstart.de der aktuellste ? >Also den *.rar verpackten mein ich. Das neuste ist sicher die Firmware, die wurde noch etwas aufgebohrt, zwecks Titelmarkierung, schnellem Titelsprung und optischer Aufwertung des Peak-Meters mit Peak-Hold. Der Schaltplan an sich ist aktuell. Die neuen .hex-files müßte ich mal hochladen. Gibt es denn beim 1:1 Nachbau etwas zu beachten? Ja, es gibt verschiedene Pinouts bei den TOSLINK-Transmittern, bitte vorher das Datenblatt konsultieren. Außerdem darf die Eingangsspannung vor dem Step-Up-Converter nicht höher als 3.3V sein. Ist mit 2 Akkus sichergestellt. >Wie wird die Wav denn auf dem Computer ausgelesen. Diese muss ja - >soweit ich das verstanden habe - noch von der SD umgewandelt und zur >*.wav gemacht werden. Im Sektor 0x000000 der Karte befindet sich die TOC, dort werden die Start-Sektoren der einzelnen Titel in je 3 Bytes abgelegt. Die Rohdaten der Titel entsprechen einer .wav-Datei 16Bit/48kHz. Mit einem Disk-Editor kann man diese auslesen und in Files schreiben. Alternativ kann man die Titel mit dem Recorder über SPDIF in ein Sequencerprogramm auf dem PC überspielen, was urprünglich der Plan war. Neuere Geräte würden sicher eine USB-Unterstützung bekommen, aber das war mir jetzt noch nicht wichtig genug... Geplant ist noch eine SDHC-Unterstützung. >...machst du das als Hobby oder Beruf ? Ist inzwischen dasselbe :-]
Hey, Super, dass ich das bekommen konnte. Also es stimmt alles - ich kann das *.brd mir ausdrucken und gleich ätzen. Keine Fehler mehr oder so. Sehr gut der Tipp mit den TOSLINK Pinouts. Vielen Vielen Dank. Ich bin gerade schon am überlegen, ob ich das in ein 19" Zoll Gehäuse reinbringe. Mit dem Display muss ich schaun ob ich das in so ein schmuckes 1HE Gehäuse reinbringe. Ich meinte bei Pollin mal recht billige schwarze Rackgehäuse gesehen zu haben. Werde mich dessen mal annehmen. Ausserdem dachte ich an ein "billig" - USB-Interface. Ich nimm mal einen alten CardReader auseinander und schau, ob ich den noch integrieren kann. So ists zwar nicht sehr elegant aber ich erspare mir den "Eingriff" in die Firmenware. Danke nochmal Gruss Günter
Also Du willst dann die Karte von dem originalen Schacht in den Kartenreader umstecken, um sie dann im Rechner zu lesen? Dann kannst Du sie doch gleich in den Rechner stecken...
Ach so, ich sehe gerade, daß in der *.brd-Datei der Bottom-Layer nicht eingeschaltet ist, aber das hast Du sicher auch bemerkt...
neeeee - oje um gottes willen nein ich will doch die karte nicht umstecken, sondern das so integrieren, dass umgeschaltet wird, sobald ein usb kabel angesteckt wird bzw. man macht einen schalter ...
So ein Umschalter würde mich auch interessieren.. Wie passt man die Betriebsspannung an? Umschalten müßte man ja nur die MOSI MISO CLOCK und CS oder?
Ja, aber beim Umschalten darf dann auch nicht irgendetwas wackeln, sonst sieht die Karte unter Umständen einen falschen Befehl und meldet sich dauerhaft ab. Die Betriebsspannungen an USB sind auch meist 3.3V (in den USB-Chips von 5V herunterstabilisiert), also muß man nichts anpassen.
Hallo! Erstmal: Schönes Projekt! Sehe ich das richtig, dass du die SD-Karte per SPI ansteuerst? Auf was für eine Datenrate kommst du denn da? Ich beschäftige mich in meiner Diplomarbeit auch mit dem Aufnehmen von Audiodaten, und auch ich möchte sie auf eine SD-Karte speichern, allerdings mit FAT-Dateisystem. Bei den Zahlen, die man so im Internet liest, scheint das im SPI-Modus aber sehr knapp bis unmöglich zu werden... Gruß, Tim
Der SPI-Modus ist weniger das Problem, das Hauptproblem ist die wechselnde Abnahmegeschwindigkeit der Daten seitens der Karte beim Schreiben. Durch das Wear-Levelling sind die Busyzeiten, die auf einen Block-Schreibbefehl folgen, nicht verhersagbar und können im ungünstigsten Fall schon mal 200 ms lang sein. In dieser Zeit kann die Karte keinen weiteren Schreibbefehl und somit keine Daten annehmen. Das ist auch im 4-Bit Modus so. Man muß den Datenstrom also erstmal in einem RAM puffern und im Multiblock-Write auf die Karte bringen. Ohne Dateisystem sind hier Raten bis etwa 500kByte/s kein Problem, getestet mit einem 128kByte Puffer. Muß das Schreiben durch einen Adresssprung unterbrochen werden, um z.B. die FAT zu aktualisieren, sinkt die Datenrate drastisch. Das kannst Du mal probieren, indem Du mit einem Kartenleser versuchst, eine .wav oder .aiff - Datei 48k/16 stereo mit einem Wave-Editor direkt auf die Karte aufzeichnest. Der im 4-Bit Modus arbeitende Kartenleser wird ganz schön Gymnastik machen müssen.
was auch ganz gut funktioniert: man schafft sich auf der Karte einen genügend großen freien Bereich, schreibt da hin mit multiblock-write und schreibt später die FAT in Ruhe "drumherum".
Ja, aber wie groß ist genügend groß und wie verhindere ich Fragmentierung, die ebenfalls die Zugriffszeit verlängert? Hohe Datenraten mit SD-Karte sind auf Dauer nur ohne Dateisystem oder mit sehr großen Puffern möglich. Dies mag sich in Zukunft ändern. Professionelle SD-Recorder laufen zumeist auch nur mit 2 oder maximal 4 Spuren zu 48kHz oder 44kHz/16Bit, weil mehr nicht geht oder zu teuer wird.
Hey bin neu kann man des gerät fertig oder im stile eines ELV bausatz mit doku irgendwo erwerben und zu welchem preis bitte mir eine mail schreiben tthorsten@gmx.net. oder gibts was fertiges evlt in 19" des günstig und gut ist. auf USB stick direkt auf zu zeichnen wäre mir amliebsten SD karte ist wieder was mehr an format das man haben muss. MFG thorsten
Warum nicht einen einzelnen CODEC und ein Mikrocontroller mit I2S Interface (z.B. AT91SAM7)? Da wäre dann u.U. auch der Headphone Amp mit drin gewesen. Der ATXMega fühlt sich doch bestimmt unterfordert als Datenschaufler. Ansonsten trotzdem ein solides Projekt, wirkt nur so als ob du möglichst alles "zu fuß" erledigen wolltest.
>kann man des gerät fertig oder im stile eines ELV* bausatz mit doku >irgendwo erwerben und zu welchem preis Nein. Kein Preis. >Warum nicht einen einzelnen CODEC und ein Mikrocontroller mit I2S >Interface (z.B. AT91SAM7)? Da wäre dann u.U. auch der Headphone Amp mit >drin gewesen. Der XMega sollte evaluiert werden und bot sich somit an. ARMs kann ich nicht programmieren. Codecs mit ADC, DAC und HP-Amp haben meist nicht die Qualität bzw. sind zu teuer oder zu kompliziert (DSP-Protokoll) anzusteuern. Die Cirrus-Teile hatte ich da. >Der ATXMega fühlt sich doch bestimmt unterfordert als Datenschaufler. Naja - er muß auch noch ein wenig rechnen und die Anwenderschnittstelle bereitstellen. Die Geschwindigkeit wird auch für den Datentransfer zur SD-Karte gebraucht, also sooo langweilig ist dem Controller gar nicht. Und mit den Gefühlen ist das bei Controllern ja auch so eine Sache ;-) >wirkt nur so als ob du möglichst >alles "zu fuß" erledigen wolltest. Ich hatte schon einige Erfahrung mit den verwendeten Komponenten und habe sie deswegen verwendet. Bei der Erstellung der Platine mußte ich keine Klimmzüge machen und das Gerät war auch preislich tragbar ;-)
Hallo, auch wenn schon viel Text den Bildschirm runter ist, möchte ich auf meinen Beitrag zum Xmega-Soundcheck verweisen. Beitrag "Re: Xmega Soundcheck" Da habe ich eine Möglichkeit zur Klangverbesserung/Komprimierung aufgezeigt, (8 Bit Delta-Sigma) die so einfach umzusetzen sind, dass die CPU das schafft.
Hallo! Ich hab mal eine Verständnisfrage zum Audio A/D-Wandler: Welcher Spannungswert am Analogen Input wird eigentlich auf den digitalen Höchstpegel 0dBfs und welcher auf den niedrigsten Pegel abgebildet? Und wie funktoniert das mit negativen Spannungen? Dein Eingangssignal ist ja ein symmetrisches Signal um GND herum, es hat also positive und negative Halbwellen. Die Eingänge des Wandlers sind aber spezifiziert von -0.7V bis VA + 0.7V, was ja nur den positiven Bereich abdeckt. Oder sind das RMS-Werte? Und wenn ich dan den Eingang eine Gleichspannung anlege, wird die dann überjaupt gewandelt oder weggefiltert? Hoffe, du kannst meine Verwirrung aufklären. :-) Danke und viele Grüße, Tim
Tim schrieb: > Welcher > Spannungswert am Analogen Input wird eigentlich auf den digitalen > Höchstpegel 0dBfs und welcher auf den niedrigsten Pegel abgebildet? Bei dem verwendeten Cirrus-Wandler sind etwa 1.4Vss 0db, bezogen auf 3.3V Versorgungsspannung. Tim schrieb: > Und > wie funktoniert das mit negativen Spannungen? Gar nicht. Der ADC-Eingang ist auf Vcc/2 vorgespannt und das Signal wird mit Koppel-C eingespeist, so daß sich die Spannung innerhalb der Versorgung abbildet. Das sollte auch Deine anderen Fragen beantworten. Ach und bitte nicht diesen Thread hijacken, sondern den anderen weiterbenutzen: Beitrag "Re: Xmega Soundcheck"
Hallo Knut, bei einem Versuch mit einem Xmega16A4 Audiosignale durch den µC zu schicken, bin ich (zwangsläufig;-)) bei deinem Thread über den Wave Recorder gelandet. Du schreibst an einer Stelle, das du mit den internen Wandlern auch recht gute Ergebnisse erzielt hast, dieses kann ich bei meinem Projekt leider nicht bestätigen. Ich bekomme über den ADC trotz aller Bemühungen (Software / Hardware) das rauschen nicht in den Griff (ca. 5 LSB Bits ) so dass das Ergebnis mehr als bescheiden ist. Jetzt bin ich am überlegen, ob ich dirket die von dir benutzten Wandler mitbestelle, oder ob die Wandler vom Xmega128A1 einfach besser als die aus dem Xmega16A4 sind. Ich brauche keinen HIFI Standard (es geht um eine Loop-Station für Gitarre) aber ruhig sollte das Signal schon sein. Würde mich über einen Tipp sehr freuen, viele Grüße Michael
saxosun schrieb: > Du schreibst an einer Stelle, das du mit den internen Wandlern auch > recht gute Ergebnisse erzielt hast, dieses kann ich bei meinem Projekt > leider nicht bestätigen. Das hängt stark von dem verwendeten XMEGA ab. Die A1 sind ziemlich mies. Die Wandler der neueren A3U sind deutlich besser, dafür fehlt hier das Speicherinterface... saxosun schrieb: > oder ob die Wandler vom Xmega128A1 einfach besser als die > aus dem Xmega16A4 sind. Nein. > Jetzt bin ich am überlegen, ob ich dirket die von dir benutzten Wandler > mitbestelle, Wäre zu empfehlen. Du kannst im Übrigen die Subcontroller sparen, wenn Du für das I2S-Interface 1 UART im Master-SPI-Mode betreibst und einen Timer für die L/R-Clock synchronisierst. Mit DMA und Eventsystem funktioniert das einwandfrei habe ich letztens getestet. Die Wandler werden hierzu verkoppelt und im Slave-Betrieb verwendet. Wenn Du einigermassen fit auf dem XMega bist und einen Logic-Analyzer hast, bekommst Du das bestimmt hin. saxosun schrieb: > Ich brauche keinen HIFI Standard (es geht um > eine Loop-Station für Gitarre) Ha, das schließt sich aber beinahe aus ;-). Nee, nimm lieber die externen Wandler, damit sparst Du Dir Ärger und Du hast einen sauberen Sound.
Ok, vielen Dank für die Infos. Ich werde dann die Wandler mit bestellen, und zunächst einen Aufbau mit den Subcontrollern machen. Wenn es dann so läuft wie ich mir das vorstelle, kann man später sehen, ob man die noch einsparen kann. Ich bin gerade erst mit den Xmegas angefangen, von daher.... vielen Dank und viele Grüße Michael
saxosun schrieb: > und zunächst einen Aufbau mit den Subcontrollern machen. Würde ich nicht empfehlen, denn das macht die Sache komplizierter, weil dann mehrere Interfaces passen und viel mehr Pins angeschlossen werden müssen, das erhöht die Fehlerrate. Wenn Du einen LA oder einen Speicheroszi nutzen kannst, würde ich mich an Deiner Stelle lieber in die Hardware des XMega einarbeiten und schrittweise die gewünschten Signale generieren.
Hallo Knut, oben ist ein Beitrag von Dir, der einen youtube Link enthält, der nicht mehr existiert. Vielleicht löscht Du den, wenn es Dir möglich ist. Ich habe kein Eagle. Vielleicht wäre es möglich, den Schaltplan/-pläne mal als DINa3 PDF zu drucken und zu posten. Das wäre sehr lieb von Dir. Danke. Ansonsten hat das sicher sehr viel Mühe und Zeit gekostet. Mein Respekt. Viele Grüße und ein Frohes Weihnachtsfest
megan schrieb: > oben ist ein Beitrag von Dir, der einen youtube Link enthält, der nicht > mehr existiert. Vielleicht löscht Du den, wenn es Dir möglich ist. Hmm, weiss nicht, wie das kommt... Löschen kann ich den Beitrag oben leider nicht, sorry. megan schrieb: > Ich habe kein Eagle. Kannst Du Dir die Demo ´runterladen? Anzeigen kannst Du damit alles. Ansonsten muss ich mal gucken...
Knut Ballhause schrieb: > Wäre zu empfehlen. Du kannst im Übrigen die Subcontroller sparen, wenn > Du für das I2S-Interface 1 UART im Master-SPI-Mode betreibst und einen > Timer für die L/R-Clock synchronisierst. Mit DMA und Eventsystem > funktioniert das einwandfrei habe ich letztens getestet. Die Wandler > werden hierzu verkoppelt und im Slave-Betrieb verwendet. Wenn Du > einigermassen fit auf dem XMega bist und einen Logic-Analyzer hast, > bekommst Du das bestimmt hin. Wenn du das schon mal gemacht hast, hast du da zufällig noch ein paar Code Schnipsel? Bin erst noch dabei mich mit DMA und Event System anzufreunden :) Tobias
Hallo, auch wenn der thread schon etwas älter ist, mein Kompliment zu dem Recorder. Ich hätte großes Interesse das auch mal nachzubauen, jedoch etwas kleiner vom Layout. Da ich nur die Light Version von Eagle habe, kann ich keine weiteren Elemente hinzu fügen. Es wäre schön, wenn Pinheader für Display und die ganzen Tasten eingefügt werden könnten, um diese als Sandwich auf 2 Platinen unterzubringen und die Platinengröße zu schrumpfen. Wäre das möglich? Das wäre toll, wenn sich jemand die Arbeit machen könnte. Wurde das Projekt nochmal weiterentwickelt wie im Thread angekündigt? Grüße supasond
Hey, super projekt! könntest du vielleicht auch mir die sourcecodes zusenden? ich möchte eine etwas abgespeckte version davon bauen. für meine zwecke ist beispielsweise kein display erforderlich. falls du diesem thread noch folgst würde ich mich freuen wenn du die sources an jeffrey.remien@gmx.de schicken könntest danke!
Tobias Müller schrieb: > Wenn du das schon mal gemacht hast, hast du da zufällig noch ein paar > Code Schnipsel? Sicher, aber nicht zur Freigabe. Die Tests liegen schon länger zurück und um das wieder aufzugreifen, müsste ich den Testaufbau nochmal zusammenstecken und den Code kommentieren, wofür mir die Zeit fehlt. Sorry.
Chapeau. So ein super-sexy Platinchen sieht man selten. 1) Wie hast du belichtet? Mit nem Film (Laserdrucker) oder R-Katalogpapier aufgebügelt? 2) Wie hast du das gemacht, nirgendswo nen bisschen Zinn zu verkleckern? "Lötstoppmaske" aus Karton? Beim Löten das Zinn gegen die Schwerkraft fließen lassen? Auch sehe ich nirgends Fingerabdrücke auf dem Cu. Bist du Berufseinbrecher? Bei mir wäre bald eine Patinaschicht zu sehen. 3) Ich hab mal bei Bungard in ner Art Sammelbestellung chemisches Zinn gekauft; das muffelnde Zeugs hat gut funktioniert. Vielleicht wär das auch für dich was.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.