DAC col TDA1541A per CD723 (o altri CD Philips)

[andypairo]

Ecco la risposta di Fabien:

Hi Andrea,

The hacker worked perfectly for me, exept when you change the volume with the cd723 remote control. You have to let it at max (20) and block it by pressing edit two seconds.

For the clock frequency, 2.11mhz bck is ok and correspond to no oversampling.
Difference between i2s and eiaj (original format) is not a bitclock frequency, but in bit order and shifting of one bit of the left/right clock and bit clock.
You can't see it by measuring the frequency, maybe you can with a good scope.

At least is the oversampling rate changing works, no reason for i2s/eiaj to don't.

Good luck in your modification, it's worth the trouble !

regards,
Fabien

Quindi sembrerebbe che la cosa sia possibile, ma voglio verificare (ho sempre visto 2,8MHz come frequenza IIS). Proverò attaccando un TDA1543 e vediamo cosa esce.

Ciao

Andrea

[Davide]

Salve a tutti,

mi intrometto nella discussione poichè credo di poter dare qualche utile chiarimento.

I due protocolli standard per bus seriale I2S ed EJAI definiscono di fatto
la struttura dati delle linee DATA e WCK e le relative commutazioni ma non pongono vincoli particolari sulla lunghezza della parola digitale o sulla frequenza del bit clock BCK.

Sta di fatto comunque che in tutte le macchine di derivazione Sony e standard EJAI il datastream primario (non oversampling) ha sempre
un BCK a 2.11 MHz e WCK=BCK/48 quindi la max lunghezza di parola (DATA) è 48 bit (per canale).
In tutte le macchine di derivazione Philips I2S il datastream ha in genere:
BCK=2.82 MHz e WCK=BCK/64 quindi con max lunghezza di parola di 64 bit.

Nelle macchine "ibride" in cui c'è la necessità di intefacciare chipset che adottano formati diversi la conversione viene fatta introducendo opportuni ritardi sulle linee DATA e WCK generalmente utilizzando qualche flip-flop o registro.
Risulta invece piuttosto difficile - nonchè praticamente inutile - modificare la frequenza del BCK che quindi viene mantenuta come nello standard sorgente.

Quindi si potrà avere, come nell' esempio in questione, un bus codificato I2S ma con BCK=2,11 MHz e lunghezza max di parola 48 bit.
La cosa non crea problemi al chip che riceve il bus convertito I2S anche perchè la frequenza di clock è anche più bassa!

Quello che conta veramente è che la frequenza di WCK sia la stessa perchè WCK determina la frequenza di campionamento e quindi il latch del convertitore DA.
Infatti in entrambi i casi si ha:

2,11MHz/48= 44,1KHz
2,82MHz/64= 44,1KHz

In sostanza l'accrocco...dovrebbe funzionare....

Spero di aver chiarito qualche dubbio.

Ciao

Davide

[andypairo]

Ciao Davide,
il tuo intervento è certamente gradito e utile, come lo sono eventuali considerazioni relative al progetto in studio che ti invito a fare .

In ogni caso verificherò "ad orecchio" se il formato è a posto.

La buona notizia è che un BCK a 2.11 MHz permette una efficace strategia di reclocking e sincronizzazione della meccanica a partire dalla frequenza standard impiegata di 8.4 MHz senza dover ricorrere ad accrocchi strani

Ciao

Andrea

[Davide]

Ciao Davide,
il tuo intervento è certamente gradito e utile, come lo sono eventuali considerazioni relative al progetto in studio che ti invito a fare .

In ogni caso verificherò "ad orecchio" se il formato è a posto.

La buona notizia è che un BCK a 2.11 MHz permette una efficace strategia di reclocking e sincronizzazione della meccanica a partire dalla frequenza standard impiegata di 8.4 MHz senza dover ricorrere ad accrocchi strani

Ciao

Andrea


Originally posted by andypairo - 27/10/2006 :  11:40:50

Ciao Andrea,

una considerazione importante da fare quando si parla di reclocking è che il circuito deve essere progettato e realizzato con estrema attenzione.

Il reclocking sincrono (perchè è di questo che parliamo immagino) può essere un ottimo sistema per ridurre il jitter associato a bus "rumorosi".
Tuttavia va fatto con cognizione di causa altrimenti può diventare esso stesso la sorgente principale di Jitter.

Bisogna conoscere accuratamente le relazioni temporali fra i segnali del bus ed il Clock reference con il quale si vogniono sincronizzare, considerando attentamente i ritardi introdotti dai percorsi di segnale (linee di trasmissione) e soprattutto i parametri temporali di commutazione delle porte logiche utilizzate per il reclocking... poi bisogna utilizzare ovviamente le stesse porte previste dal progetto!!

Molti dei circuiti di reclocking che si vedono in giro sembrano non considerare questi fattori fondamentali, ed assomigliano di più a dei generatori che a dei riduttori di jitter.

Non ho ora il tempo ed il modo di verificare attentamente i circuiti di reclocking adottati nei link che hai proposto, quindi non so dirti a quale "categoria" appartengano.
Mi conforta però il fatto che queste problematiche sembra siano satte considerate dagli autori e che dietro sembra esserci un studio serio dei circuiti proposti (verifiche strumentali comprese!), questo depone a loro favore...

Ciao.

Davide

[andypairo]

Nuovo aggiornamento: ho provato il tutto "ad orecchio" e in effetti in modalità IIS col TDA1545A si sente quasi esclusivamente rumore e, a tratti qualcosa che ricorda la musica, per cui il cambio di formato direi che c'è.

Riprendo allora il discorso abortito per i dubbi esposti pochi post sopra: il reclocking.

Parte 1 - reclock

Lo schema di base riprende quello presente sul sito di Peufeu, visto che sia il TDA1541A che il TDA1545 campionano il dato sul fronte di salita del BCK successivo al cambio di stato di WS: gli adattamenti sono semplicemente di piedinatura.

Frequenza del master clock: il quarzo montato sul CD723 è da 8,4x MHz ma occorre fare alcune considerazioni:
- è sufficiente che la frequenza di reclock sia un multiplo del BCK (2,1MHz * fattore sovracampionamento), quindi se vogliamo sfruttare tutte le possibilità offerte dal lettore (max 4x OS ) ci serve un multiplo di 8.4x MHz
- bisogna generare una frequenza idonea per il DEM reclocking, compresa tra 4xfs (176 kHz) e 8xfs(384 kHz)
-il filtro digitale usa un PLL per ricavare una frequenza multipla di 8.4 Mhz per lavorare ed esiste la possibilità di usare un clock a 33.2 MHz disattivando il PLL interno. Sicuramente senza reclock ci sarebbe un vantaggio ma visto che riclocchiamo i dati non credo si abbiano grossi vantaggi

In sostanza per ridurre al minimo le frequenze in gioco e semplificare la circuiteria (divisori per ricavare il DEM reclock) io opterei per stare sugli 8.4 MHz.
Dividendo questa frequenza con un contatore sincrono per 32 otteniamo un DEM reclock a 264 kHz (6xfs)

Il tutto è possibile perchè usando l'hacker non c'è cambio di bitrate ma solo di formato dati (nei DAC con formato dati Philips solitamente il BCK è di 2,8Mhz) e quindi un clock unico fa sia da "master clock" per la conversione che da clock di sistema.

Per una descrizione sul principio del reclock adottato e per la motivazione delle scelte vi rimando al sito di Peufeu, non sarei in grado di spiegarlo meglio.

Per oggi basta... ogni commento è ben accetto.

Ciao

Andrea

[andypairo]

Nel file zippato trovate la prima implementazione delle sezioni di reclock.

Commenti ben accetti, possibilmente non a lavoro già fatto .

Ciao

Andrea


Allegato: Reclock.zip ( 25028bytes )

[PPoli]

Ma allora il buon Tent ci ha pensato anche lui.

http://www.tentlabs.com/Products/diycd/index.html

http://www.tentlabs.com/Products/diycd/assets/test%20CD%20speler%20ME%20UK.pdf

[andypairo]

Pur non avendolo mai visto direi che abbiamo pensato a soluzioni simili.... diciamo che le varie tipologie sono note, occorre metterle assieme in modo adeguato....

Una domanda a Marco (o a chi intende partecipare) sulle alimentazioni: d'accordo i regolatori separati per le varie sezioni (+5 -5 e -15 TDA, Clock, porte reclock e dem reclock, stadio di uscita...), conviene anche separare i secondari?
Io seguirei l'approccio "alla Pedja" (per il cui DAC ho organizzato un gruppo d'acquisto presso la Tector), ma un trafo custom del genere costò circa 40-45€ , in pratica quanto ho pagato il CD723.
E' vero che era un tantino sovradimensionato (1A per secondario)...ma non credo che si possa scendere sotto i 25-30 anche dimezzando le correnti.

Gradirei pareri in merito.

Inoltre in uno scambio di email ho sentito dire miracoli della separazione delle alimentazioni delle varie sezioni della meccanica... attendo dettagli prima di approfondire!

Ciao

Andrea

[plovati]

Prova a darmi le specifiche del trafo che vorresti, abbiamo un poco di cose in ballo e spero che il trasformatorista ci tratti meglio portandogli un pacchetto di lavoro più consistente.

_________
Piergiorgio

[andypairo]

Ciao,
diciamo che è ancora un po' presto per avere delle specifiche precise.
Il trafo per il DAC di Pedja aveva:
- 5 secondari da 8V - 1A
-2 secondari da 17V - 1A
-1 secondario da 22V - 1A
-due secondari da 80V 50 mA (anche se poi ne hanno dimenticato uno)
-un secondario 6,3V 1,5 A

Era un toroidale incapsulato, il secondario dimenticato è stato "barattato" con la resinatura.

Ciao

Andrea

[titano]

Io credo che l'ideale sarebbe separare i trasformatori.

Uno per gli stadi "digitali" (raggruppando dac, SAA7XXXX ed eventualemnte il clock), uno per gli stadi analogici e uno per servo e motori.

Motore e servo funzionano con basse correnti "nominali", con spunti di corrente piuttosto elevati. Meglio sperare galvanicamente dalle altre alimentazioni questi rami.

Gli stadi digitali sono "rumorosi" e separarli il più possibile dalle altre alimentazioni pare essere il modo migliore di evitare di inquinare il resto.

Mi baso su alcuni scambi di missive con Thorsten Leasch. Tra l'altro secondo lui separare il master clock e alimentarlo con una alimentazione dedicata a basso "leakege" era secondo lui l'unico modo per limitare fortemente l'introduzione di jittler eccessivo (invece di limitarlo...)

Nessuno di questi trasformatori in realtà ha bisogno di essere molto "grande" (leggi VA) quindi volendo si potrebbe far stare 3/4 piccoli trasformatori anche commerciali nella zona a dx del lettore, ripensando completamente le pcb interne.

Tutto questo sempre che si decida per stadi di conversione I/V e buffer non a tubi. Nell'ottica di mantenere tutto nel telaio originale scarterei a priori questa soluzione.

Che ne dite?


Marco

[andypairo]

Per quanto riguarda motore e servo, oltre che per le logiche di funzionamento del player credo si possa riutilizzare il trafo originale, magari separando con regolatori dedicati le varie funzioni.

Per il resto vedo che siamo d'accordo sulla separazione, anche se tu mi sembri più drastico
Non credo sia così necessario, usando alimentazioni shunt caricate da CCS, separare anche i trafo.
Io poi contavo di riutilizzare uno dei trafo del GB....comunque lo scopo del mio post era di decidere se optare almeno per avere secondari separati in modo da buttare giù uno schema di massima.

Ciao

Andrea

[marziom]

sono lento lo so.... ma sto rileggendo piano piano il 3D e mi è venuta una domanda:
nessuno ha mai provato a bufferare il segnale proveniente da un ricevitore (es. 8412) e poi ributtarlo fuori con un clock locale stabile?
.... si eliminerebbe il probelma alla radice.

marzio

[cantinaro]

Ciao Davide,
il tuo intervento è certamente gradito e utile, come lo sono eventuali considerazioni relative al progetto in studio che ti invito a fare .

In ogni caso verificherò "ad orecchio" se il formato è a posto.

La buona notizia è che un BCK a 2.11 MHz permette una efficace strategia di reclocking e sincronizzazione della meccanica a partire dalla frequenza standard impiegata di 8.4 MHz senza dover ricorrere ad accrocchi strani

Ciao

Andrea


Originally posted by andypairo - 27/10/2006 :  11:40:50

Ciao Andrea,

una considerazione importante da fare quando si parla di reclocking è che il circuito deve essere progettato e realizzato con estrema attenzione.

Il reclocking sincrono (perchè è di questo che parliamo immagino) può essere un ottimo sistema per ridurre il jitter associato a bus "rumorosi".
Tuttavia va fatto con cognizione di causa altrimenti può diventare esso stesso la sorgente principale di Jitter.

Bisogna conoscere accuratamente le relazioni temporali fra i segnali del bus ed il Clock reference con il quale si vogniono sincronizzare, considerando attentamente i ritardi introdotti dai percorsi di segnale (linee di trasmissione) e soprattutto i parametri temporali di commutazione delle porte logiche utilizzate per il reclocking... poi bisogna utilizzare ovviamente le stesse porte previste dal progetto!!

Molti dei circuiti di reclocking che si vedono in giro sembrano non considerare questi fattori fondamentali, ed assomigliano di più a dei generatori che a dei riduttori di jitter.

Non ho ora il tempo ed il modo di verificare attentamente i circuiti di reclocking adottati nei link che hai proposto, quindi non so dirti a quale "categoria" appartengano.
Mi conforta però il fatto che queste problematiche sembra siano satte considerate dagli autori e che dietro sembra esserci un studio serio dei circuiti proposti (verifiche strumentali comprese!), questo depone a loro favore...

Ciao.

Davide


Originariamente inviato da Davide - 27/10/2006 :  12:29:20

Scusate se intervengo in questo punto, ma il reclocking è un produttore di jitter, serve proprio a produrne di più.
Serve a generare un jitter con uno spettro ripetitivo per combattere quello casuale.
Il reclocking innalzando il livello del jitter uniforma lo spettro risultante con un floor noise più alto.
Se avete un'idea diversa forse è fuori strada...
marco

[Davide]

Scusate se intervengo in questo punto, ma il reclocking è un produttore di jitter, serve proprio a produrne di più.
Serve a generare un jitter con uno spettro ripetitivo per combattere quello casuale.
Il reclocking innalzando il livello del jitter uniforma lo spettro risultante con un floor noise più alto.
Se avete un'idea diversa forse è fuori strada...
marco



Originally posted by cantinaro - 07/11/2006 :  15:15:25

Quello di cui parli è il cosidetto reclocking asincrono, fatto cioè con un clock reference a frequenza molto più alta del system clock originale e non sincronizzato con quest'ultimo (è quello proposto dal noto giapponese, tanto per intenderci.... ) e fa più o meno quello che dici tu anche se non sono molto d'accordo sul discorso ripetitivo/casuale, ma potrebbe essere un problema di diverso.... understanding.

Il reclocking sincrono, fatto cioè con un reference system clock, se fatto come si deve può ridurre il jitter causato dalla propagazione del segnale di clock attraverso numerosi stadi del percorso del segnale numerico.

Ovviamente se non è fatto come si deve introduce un maggior livello di jitter che non è cosi "benefico" come quello introdotto dall' asynchronous reclocking! Questo purtroppo è il caso più frequente nelle soluzioni che si trovano in giro......

Ciao

Davide

[mauropenasa]

Giusto per capire:

Visto che è abbastanza consolidata l' opinione che un bassissimo jiitter porta semplicemente a "sonorità fredde" (intese termoionicamente parlando ovviamente), ha un senso porsi questo problema in ambienti in cui la THD e IMD finale ottenuta non si è manco in grado di analizzarla ?
Cioè, dato che qui si parla non di raggiungere traguardi prestazionali ma solo sonici, qualcuno si è posto il problema di cosa faccia o non faccia alle proprie orecchie il jiitter, ed in particolare se queste configurazioni con TDA1541 risente in modo particolare di questo problema ?

Personalmente credo che questo sia semplicemente un "non problema", nel senso che "sonicamente" ho sentito molti più dac collegati in spdif (ottico o coax) "suonare bene" che questi famigerati sistemi "jiitter free".....
Qualche maligno potrebbe far notare che nella maggior parte dei sistemi di demodulazione analogica usati per il TDA, ma anche nel TDA stesso esistono dinamiche distorsive spesso maggiori anche di un ordine di grandezza rispetto a quelle del jiitter.

Poi sulla reale entità di questo fenomeno (jiitter) ci sarebbe molto da considerare. Ne sento parlare come se fosse una cosa che "gira sul tavolino" di tutti.
Singolare che ci siano migliaia di diys che non dormono la notte a causa di questo "presunto" problema (sempre inferiore a -80dB anche in casi limite), mentre di avere stadi I/V o amplificatori con il 3% di THD (-30dB !!) fa solo colore....

ciao

Mauro
http://www.webalice.it/mauro.penasa/index.html

[andypairo]

Dunque....

marzio: un reclocking come lo descrivi tu non è fattibile perchè due clock, anche fossero della stessa frequenza nominale, non sarebbero mai uguali e avresti una fase relativa che cambia, fino al punto di avere perdita di dati (quando il ritardo supera una certa soglia). Occorre mantenere il sincronismo tra i due, e lo si può fare "passando" il clock alla meccanica oppure usando un VCO sempre sulla meccanica come viene fatto se non erro nel Tent Link.

marco (cantinaro) : ti ha già risposto Davide

mauro: il tuo discorso è un tantino disfattista, nel senso che nessuno di noi ha la pretesa di essere un guru per cui, ben consci dei nostri limiti, cerchiamo di imparare qualcosa magari solo mettendo in pratica (con un poco di "granu salis") ciò che ci sembra maggiormente valido tra le proposte che vediamo in giro.

Non so quanti abbiano a disposizione la strumentazione per poter fare valutazioni del genere, per cui ci dovremo basare su buon senso e sull'esperienza (altrui e propria).

In ogni caso le "dinamiche distorsive" interne al TDA le sto prendendo in considerazione (mi riferisco al condizionamento dei segnali IIS per ridurre le interferenze sul substrato) ma onestamente fare un discorso di soli numeri su jitter e distorsioni sai bene che non è corretto, soprattutto dal punto di vista tecnico/scientifico che contraddistingue solitamente i tuoi interventi.

Nessuna polemica, spero però in interventi più costruttivi...

Ciao

Andrea

[mauropenasa]

mauro: il tuo discorso è un tantino disfattista, nel senso che nessuno di noi ha la pretesa di essere un guru per cui, ben consci dei nostri limiti, cerchiamo di imparare qualcosa magari solo mettendo in pratica (con un poco di "granu salis") ciò che ci sembra maggiormente valido tra le proposte che vediamo in giro.

Non so quanti abbiano a disposizione la strumentazione per poter fare valutazioni del genere, per cui ci dovremo basare su buon senso e sull'esperienza (altrui e propria).

In ogni caso le "dinamiche distorsive" interne al TDA le sto prendendo in considerazione (mi riferisco al condizionamento dei segnali IIS per ridurre le interferenze sul substrato) ma onestamente fare un discorso di soli numeri su jitter e distorsioni sai bene che non è corretto, soprattutto dal punto di vista tecnico/scientifico che contraddistingue solitamente i tuoi interventi.

Nessuna polemica, spero però in interventi più costruttivi...

Mi dispiace che tu lo viva come "disfattista".
Sicuramente è colpa del modo in cui pongo le questioni, ma questo vale per molti argomenti, come nel "caso preconcetto"....

Ovviamente tutti sono liberi di giocare con soluzioni inventate a tavolino dai loro colleghi autocostruttori, cosi come porsi problemi inventati ad arte dai grossi nomi audio per giustificare i costi dei loro apparecchi.....

Se volete posso "rispondere a gettone" dicendo di credere fermamente a tutti gli argomenti ed inventandomi di volta in volta elementi teorici a conferma di esse (come fanno quelli a pagamento sulle riviste)..... :p

Non preoccuparti, non metto giù polemiche gratuite....; )

ciao






Mauro
http://www.webalice.it/mauro.penasa/index.html

[andypairo]

Piccolo aggiornamento: ecco lo schema di base delle sezioni di reclock.
Per ora sono utilizzati regolatori shunt per tutto (valori da verificare).
Potrebbe essere il caso di passare a regolatori differenti per le logiche digitali (mi viene in mente un regolatore low-noise della Linear che era consigliato per l'XO Tent)

Infine uno studio più approfondito sul DEM reclock ha rivelato che sono stati presentati 3 circuiti differenti, quello di HtP, uno che non inverte il segnale verso il pin 17 e uno che omette i PNP e entra solo sul pin 16 lasciando sconnesso il 17.
Di quest'ultimo ho ricevuto conferma da gente che l'ha costruito riguardo al funzionamento, per cui potrebbe essere il caso di passare a questo schema (che consente una certa semplificazione tra l'altro)

Sto studiando un'altro po' di info su come realizzare i decoupling, cosa non banale per via della costruzione del chip.

Per quanto riguarda il condizionamento dei segnali IIS:
- HtP citava che lo swing necessario di tensione, essendo le logiche a commutazione di corrente - current routing- è di circa +/-200 mV intorno a 1,3V e inoltre per diminuire le interferenze sul substrato sarebbe bene limitare lo slew rate dei segnali
- non ci sono stati riscontri unanimi sui miglioramenti ottenibili in questo modo (al massimo "subtle improvement"), se non un caso citato su una rivista in cui l'autore, condizionando i segnali ripulendoli dagli overshoot legati alla cattiva progettazione degli stadi a monte aveva ottenuto un drastico miglioramento.

Viste le due cose credo sia possibile eliminare parte dei problemi usando logiche a 3.3V (e 5V tolerant in ingresso) per il reclock dei segnali IIS. Il "problema" è che la serie LVX c'è solo SMD, ma credo che forse era già in preventivo l'uso di tali componenti.

Ciao

Andrea


Allegato: Reclock-Dem01.pdf ( 96289bytes )

[andypairo]

In attesa di commenti sul circuito postato verificherei le possibilità per le alimentazioni:

-Shunt con TL431 pilotato da CCS
-Alim. discreto "open loop" come usato da Pedja per le alimentazioni del TDA
-Regolatori low noise?

Ciao

Andrea