Abiura! Cavi USB

Pagina 12 di 22
prima
... 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 ... ultimo
Visualizzazione dei risultati da 111 a 120 su 216
  1. #111
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da UnixMan
    ...

    per avere maggiori dettagli bisognerebbe chiedere direttamente a chi le ha fatte, se volesse intervenire...


    esatto (se non vado errato puoi chiudere la catena con ->ADC->PC->software di misura).

    Non conosco precisamente i dettagli ma, per quanto ne so, stava facendo (per tutt'altro scopo) delle normali misure di jitter sui suoi DAC con la solita tecnica della misura di intermodulazione a due toni (piuttosto raffinate, con fondi decisamente bassi).

    Nel farle si è accorto che, sostituendo il cavo USB tra il PC e l'interfaccia USB/UAC2 (se non erro proprio la JLsound), il risultato delle misure cambiava (i cavi USB in questione erano due normalissimi cavi "industriali" diversi... tipo "il cavo della stampante" o quello di un Hard Disk esterno, per intenderci).

    ...

    Sperando che l'autore della scoperta voglia intervenire, cerco di stendere un ponte sull'abisso della mia ignoranza tecnica. Lasciamo stare il problema di quale dei due suona meglio, è irrisolvibile, ma prendendo atto che il segnale in uscita è diverso, sarebbe interessante capire dove si origina la diversità.

    Mi spiego: Qualcuno riporta che l'interfaccia USB/I2S JLSound è 'particolarmente' sensibile ai cavi, tanto che con alcuni cavi, specie se più lunghi di 1 - 1.5 m. non aggancia proprio. E' ovvio che due cavi diversi, pur entrambi funzionanti in un contesto diverso, hanno caratteristiche diverse, al punto da non consentire, in un caso, il funzionamento dell'interfaccia, quindi producono la massima differenza in uscita ipotizzabile.

    E' corretto, in questo caso, imputare l'origine della differenza (integralmente) ai cavi? Credo di no, visto che con altre interfacce, pur rimanendo il diverso comportamento dei due cavi, l'entità delle differenze sul segnale in uscita sarebbe molto inferiore.

    Non so se ho espresso correttamente il mio dubbio, ma potendo analizzare il segnale I2S, con - esempio - audiodiffmaker (certamente esistono metodipiù accurati), sarebbe possibile identificare eventuali differenze nel flusso di bit (che tenderei ad escluderei) e/o nel clock, che non essendo trasportato da USB ma rigenerato dall'interfaccia, se risultasse diverso nei due casi prefigurerebbe un'influenza indiretta del cavo su questo aspetto.

    L'effetto prodotto, comunque, dipenderebbe anche dalla capacità di reieizione dell'interfaccia, non solo dalla 'rumorosità' del cavo. Quello che rileveremmo in uscita, non sarebbe il rumore del cavo, ma l'effetto di questo sul clock dell'interfaccia e quindi sul segnale i2s in iingresso al DAC.

    In caso contrario, se il segnale I2s dovesse risultare assolutamente identico (compreso il clock) - a patto di riuscire a stabilirlo - sarebbe il DAC stesso ad essere influenzato dal rumore del cavo, ma per via indiretta, non correlata al segnale di ingresso, il che è diverso.

    Ultima domanda, a fortissimo rischio di essere una baggianata, nel qual caso ci facciamo tutti una bella risata:

    Qualche tempo fa, confrontando con Audiodiffmaker due successive esecuzioni dello stesso file, mi accorsi che il risultato non era identico, le differenze erano dello stesso ordine di grandezza di quelle inserite dalla presenza di due clock non sincronizzati nella catena di conversione DA/AD. Indagando un po, mi spiegarono che in tempi diversi lo stesso clock, per svariate motivazioni (tra cui il rumore termico) non produce mai eattamente la stessa sequenza, ma ha una tolleranza, un drift che non è eliminabile in alcun modo, ma solo riducibile usando clock sempre più precisi.

    Le differenze di cui stiamo parlando, sono dello stesso ordine di grandezza o superiori?
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  2. #112
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,529
    configurazione

    Predefinito

    Originariamente inviato da marcoc1712
    Sperando che l'autore della scoperta voglia intervenire,
    purtroppo no. Non vuole rischiare di rimanere impantanato in possibili discussioni (e polemiche) infinite.

    Originariamente inviato da marcoc1712
    prendendo atto che il segnale in uscita è diverso, sarebbe interessante capire dove si origina la diversità.
    mi ha spiegato ieri sera che, a giudicare da quanto mostrano le misure, secondo lui si tratta banalmente di rumore di modo comune che probabilmente si propaga attraverso il collegamento di massa. La mia ipotesi che potesse essere un problema legato ad eventuali disadattamenti di impedenza (almeno nel suo caso) l'ha scartata, in quanto lo spettro in uscita non corrisponde a quello che dovrebbe essere in tal caso. Ad ulteriore supporto della sua ipotesi c'è anche il fatto che uno dei due cavi (quello che dà risultati più "puliti") è dotato del classico toroide di ferrite (che serve proprio ad ostacolare il rumore di modo comune), mentre l'altro no.

    Resta il problema che non è affatto chiaro come tale rumore - o suoi effetti indiretti - si propaghino fino all'uscita analogica, superando anche la barriera dell'isolamento galvanico della JLsounds.

    Originariamente inviato da marcoc1712
    L'effetto prodotto, comunque, dipenderebbe anche dalla capacità di reieizione dell'interfaccia, non solo dalla 'rumorosità' del cavo.
    questo è ovvio... a prescindere.

    Originariamente inviato da marcoc1712
    Indagando un po, mi spiegarono che in tempi diversi lo stesso clock, per svariate motivazioni (tra cui il rumore termico) non produce mai eattamente la stessa sequenza, ma ha una tolleranza, un drift che non è eliminabile in alcun modo, ma solo riducibile usando clock sempre più precisi.
    no, non è questo il caso. Le misure sono ripetibili e consistenti.
    Ultima modifica di UnixMan : 15-07-2015 a 16:43
    Ciao, Paolo.

    «Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»

  3. #113
    byte
    Registrato
    Oct 2014
    Località
    Latina
    Età
    68
    Messaggi
    190

    Predefinito

    Originariamente inviato da UnixMan

    mi ha spiegato ieri sera che, a giudicare da quanto mostrano le misure, secondo lui si tratta banalmente di rumore di modo comune che probabilmente si propaga attraverso il collegamento di massa. La mia ipotesi che potesse essere un problema legato ad eventuali disadattamenti di impedenza (almeno nel suo caso) l'ha scartata, in quanto lo spettro in uscita non corrisponde a quello che dovrebbe essere in tal caso. Ad ulteriore supporto della sua ipotesi c'è anche il fatto che uno dei due cavi (quello che dà risultati più "puliti") è dotato del classico toroide di ferrite (che serve proprio ad ostacolare il rumore di modo comune), mentre l'altro no.

    Resta il problema che non è affatto chiaro come tale rumore - o suoi effetti indiretti - si propaghino fino all'uscita analogica, superando anche la barriera dell'isolamento galvanico della JLsounds.
    Paolo, quindi oltre al peggioramento del jitter, c'è un problema di peggioramento del rumore.
    Una domanda: la JLsounds era alimentata tramite USB o alimentatore separato?
    Ma non potrebbero essere anche le famigerate capacità parassite che oltre a propagare il rumore alla linea ground, potrebbero provocare riflessioni a volontà ( con qualsiasi rapporto di fase) ?
    Alessandro

  4. #114
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da aletas
    Paolo, quindi oltre al peggioramento del jitter, c'è un problema di peggioramento del rumore.
    Una domanda: la JLsounds era alimentata tramite USB o alimentatore separato?
    Ma non potrebbero essere anche le famigerate capacità parassite che oltre a propagare il rumore alla linea ground, potrebbero provocare riflessioni a volontà ( con qualsiasi rapporto di fase) ?
    Ma che il Jitter (al dac) peggiori non è stato stabilito, mi pare.
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  5. #115
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,529
    configurazione

    Predefinito

    Originariamente inviato da aletas
    Paolo, quindi oltre al peggioramento del jitter, c'è un problema di peggioramento del rumore.
    no: se non ho capito male, ciò che si vede nelle misure non è un aumento del fondo o la presenza di altri disturbi "diversi" ma in sostanza un aumento dell'ampiezza delle "gonne" nello spettro di intermodulazione, in modo del tutto analogo a quanto prodotto da un aumento del jitter.

    In altre parole, presumibilmente l'effetto del rumore proveniente dal bus USB si ripercuote sotto forma di un aumento del jitter sul bus I2S che arriva al DAC.

    Originariamente inviato da aletas
    Ma non potrebbero essere anche le famigerate capacità parassite che oltre a propagare il rumore alla linea ground, potrebbero provocare riflessioni a volontà ( con qualsiasi rapporto di fase) ?
    Che siano in gioco accoppiamenti parassiti (capacitivi e/o di altro tipo) è pressoché certo, altrimenti il disturbo non avrebbe modo di propagarsi fino al "lato pulito" a valle degli isolatori...

    Non ho capito che cosa volevi dire con il discorso sulle riflessioni.
    Ciao, Paolo.

    «Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»

  6. #116
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da UnixMan
    no: se non ho capito male, ciò che si vede nelle misure non è un aumento del fondo o la presenza di altri disturbi "diversi" ma in sostanza un aumento dell'ampiezza delle "gonne" nello spettro di intermodulazione, in modo del tutto analogo a quanto prodotto da un aumento del jitter.

    In altre parole, presumibilmente l'effetto del rumore proveniente dal bus USB si ripercuote sotto forma di un aumento del jitter sul bus I2S che arriva al DAC...
    Colgo l'occasione per porre una domanda che mi frulla in testa da un bel po:

    Se la definzione di jitter è di 'devianza' rispetto al 'tempo', essendo il tempo stesso ricostruito in un'interfaccia asincrona, di che devianza si sta parlando? Rispetto a cosa?

    Chiedo scusa se la risposta è ovvia per tutti, ma (vista l'abissale ignoranza) a me sfugge.

    Sempre che non si intenda parlare di 'errore' di jitter, cioè della varianza massima nel segnale del clock rispetto al suo valore teorico, dovuto alla 'precisione' del clock stesso, ma anche - in misura probabilmente maggiore - generato dal chip dell'interfaccia stessa, influenzato dalle condizioni ambientali di funzionamento. In questo caso però - ancora una volta - il cavo sarebbe solo la causa 'indiretta', il problema risiede altrove.
    Ultima modifica di marcoc1712 : 18-07-2015 a 16:06
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  7. #117
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,529
    configurazione

    Predefinito

    Originariamente inviato da marcoc1712
    Se la definzione di jitter è di 'devianza' rispetto al 'tempo', essendo il tempo stesso ricostruito in un'interfaccia asincrona, di che devianza si sta parlando? Rispetto a cosa?
    Jitter è un termine generico che può riferirsi ad un gran numero di situazioni e di variabili differenti: “Jitter is the deviation from true periodicity of a presumed periodic signal”.

    Nel nostro caso per jitter si intendono le piccole differenze nell'intervallo di tempo tra due commutazioni successive, differenze intese rispetto all'intervallo "atteso". Che idealmente dovrebbe essere sempre perfettamente costante, uguale a sé stesso.

    Nota bene che, evidentemente, questo non ha nulla a che fare con la "precisione" del clock, cioè con una differenza del periodo effettivo rispetto a quello atteso (=differenza di frequenza). Quello di cui parliamo sono le inevitabili differenze (più o meno casuali) nella durata di ciascun singolo intervallo rispetto a quello precedente:

    Jitter Parte 1
    Clicca sull'immagine per ingrandirla

Nome:   jitter001.gif
Visite: 197
Dimensione:   4.7 KB
ID: 16487

    Ovviamente stiamo parlando del jitter del segnale di clock e/o dello stream di dati sincrono che giunge al DAC (cioè dei segnali sul bus I²S, non su quello USB), che è l'unico ad avere una influenza diretta sul processo di conversione e quindi sul segnale di uscita.

    Il "jitter" sul bus USB/UAC2 (che in questo caso si può riferire alla variabilità rispetto al clock del bus stesso oppure alla variabilità nel tempo di arrivo dei "pacchetti", ecc) nonché il rumore ed altri disturbi di qualsiasi natura ovviamente non hanno alcun effetto diretto sullo stream I²S che giunge al DAC, che è generato indipendentemente e comandato dal clock locale (ed è quindi sincrono a questo).

    Però possono esserci (e ci sono) effetti indiretti. Ad es., le commutazioni prodotte dal segnale in arrivo dal bus USB producono correnti impulsive "sincrone" a queste (e quindi al segnale sul bus USB) nei rail di alimentazione e nelle masse dei circuiti che trattano tale segnale. A causa delle impedenze delle alimentazioni e dei collegamenti stessi (che per quanto piccole non sono mai nulle, specie alle alte frequenze) si produce una "modulazione" corrispondente delle linee di alimentazione e delle masse. Se vi sono elementi in comune con gli oscillatori di clock e/o con i circuiti che gestiscono lo stream I²S di uscita (ed è praticamente impossibile evitarlo del tutto), il risultato è che tali "modulazioni" spurie producono (piccole) variazioni nei tempi di commutazione dei circuiti - e quindi jitter - nei segnali di uscita (in qualche modo correlati con il segnale e/o con i disturbi provenienti dal bus USB).

    Grosso modo è questo il meccanismo attraverso il quale ciò che accade sul bus USB (e quindi, almeno in linea di principio, anche il relativo cavo) può arrivare ad influenzare l'uscita audio nonostante il link asincrono, l'isolamento galvanico, il reclocking, ecc.
    Ultima modifica di UnixMan : 18-07-2015 a 20:23
    Ciao, Paolo.

    «Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»

  8. #118
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da UnixMan
    Jitter è un termine generico che può riferirsi ad un gran numero di situazioni e di variabili differenti: “Jitter is the deviation from true periodicity of a presumed periodic signal”.

    Nel nostro caso per jitter si intendono le piccole differenze nell'intervallo di tempo tra due commutazioni successive, differenze intese rispetto all'intervallo "atteso". Che idealmente dovrebbe essere sempre perfettamente costante, uguale a sé stesso.

    Nota bene che, evidentemente, questo non ha nulla a che fare con la "precisione" del clock, cioè con una differenza del periodo effettivo rispetto a quello atteso (=differenza di frequenza). Quello di cui parliamo sono le inevitabili differenze (più o meno casuali) nella durata di ciascun singolo intervallo rispetto a quello precedente:

    Jitter Parte 1
    Clicca sull'immagine per ingrandirla

Nome:   jitter001.gif
Visite: 197
Dimensione:   4.7 KB
ID: 16487

    Ovviamente stiamo parlando del jitter del segnale di clock e/o dello stream di dati sincrono che giunge al DAC (cioè dei segnali sul bus I²S, non su quello USB), che è l'unico ad avere una influenza diretta sul processo di conversione e quindi sul segnale di uscita.
    Grazie Paolo per la spiegazione molto chiara, mi pare di capire che stiamo parlando di quello che io ho chiamato 'errore' di jitter, cioè - più o meno - casuali discrepanze tra il periodo atteso (teorico) e quello reale.

    Non ho capito perché escludi la 'precisione' del clock dai fattori di origine, o meglio capisco che non comprendi qui un sistemico delta in frequenza, ma escludi che il clock stesso possa originare "piccole differenze nell'intervallo di tempo tra due commutazioni successive"? puoi chiarire meglio il perché?


    Originariamente inviato da UnixMan
    Il "jitter" sul bus USB/UAC2 (che in questo caso si può riferire alla variabilità rispetto al clock del bus stesso oppure alla variabilità nel tempo di arrivo dei "pacchetti", ecc) nonché il rumore ed altri disturbi di qualsiasi natura ovviamente non hanno alcun effetto diretto sullo stream I²S che giunge al DAC, che è generato indipendentemente e comandato dal clock locale (ed è quindi sincrono a questo).

    Però possono esserci (e ci sono) effetti indiretti. Ad es., le commutazioni prodotte dal segnale in arrivo dal bus USB producono correnti impulsive "sincrone" a queste (e quindi al segnale sul bus USB) nei rail di alimentazione e nelle masse dei circuiti che trattano tale segnale. A causa delle impedenze delle alimentazioni e dei collegamenti stessi (che per quanto piccole non sono mai nulle, specie alle alte frequenze) si produce una "modulazione" corrispondente delle linee di alimentazione e delle masse. Se vi sono elementi in comune con gli oscillatori di clock e/o con i circuiti che gestiscono lo stream I²S di uscita (ed è praticamente impossibile evitarlo del tutto), il risultato è che tali "modulazioni" spurie producono (piccole) variazioni nei tempi di commutazione dei circuiti - e quindi jitter - nei segnali di uscita (in qualche modo correlati con il segnale e/o con i disturbi provenienti dal bus USB).

    Grosso modo è questo il meccanismo attraverso il quale ciò che accade sul bus USB (e quindi, almeno in linea di principio, anche il relativo cavo) può arrivare ad influenzare l'uscita audio nonostante il link asincrono, l'isolamento galvanico, il reclocking, ecc.
    Questa distinzione mi è chiara, come riesco ad intuire come il funzionamento di USB possa riflettersi sul segnale di uscita mediante modulazione sulle alimentazioni, ad esempio del clock.

    Ammettendo senza difficoltà che due distinti cavi possano apportare 'variazioni' ai parametri elettrici del segnale da essi trasportato, ritengo, forse peccando di ingenuità, che queste siano ordini di grandezza inferiori al segnale in se (-90 db?), di conseguenza, le modulazioni sull'alimentazione (o qualsiasi fenomeno indotto) sarebbe in gran parte dovuta al segnale in se ed in minima parte dovuta alle variazioni apportate dal cavo.

    Ipotizzando che le prime siano nell'ordine di -90db rispetto al segnale al dac, la componente dovuta alla varianza del cavo sarebbe almeno a -180db, direi trascurabile.

    Sempre con il rischio di dire panzane, non è forse più probabile che le diverse caratteristiche del segnale a valle del cavo USB rendano più o meno facile il lavoro del chip USB (dall'impossibile con cavi > 2m per JLSOUND a semplice con un cavo 'perfetto') che deve ricostruire il segnale, originando in questo modo più o meno elevati livelli di rumore (galvanico, RFI o EMI)? Ovviamente aggiungendosi a quello generato dalla presenza stessa di una connessione USB, come citavi tu. D'altro canto FPGA o il microcontroller, è certamente il componente più rumoroso di tutta la catena a valle del pc.

    Rimarrebbe vero l'effetto della sostituzione del cavo, ma sarebe 'indiretta' e si aprirebbero potenziali spiragli di 'miglioramento' del sistema da esso indipendenti (come ad esempio l'uso di uno di questi).

    Che ne pensi? Se ho scritto c*****e, denunciale pure, servirà ad evitare errori ad altri.
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  9. #119
    byte
    Registrato
    Jun 2015
    Messaggi
    152

    Predefinito differenza cavi USB

    Solo per dimostrarvi come sono veloce, vorrei contribuire anche io a questo 3D.. sono passate non voglio sapere quanti.. cca due?! anni, solo, dal originale sollecitazione del nostro grande Daniele..
    Ma se non avevo nei mani qualcosa valido, potevo solo aumentare la confusione..

    Ecco, oggi pero, per puro caso, sento di avere trovato / visto qualcosa piu solido..
    E vorrei condividere.
    L'iniziativa questa volta era il richiamo di Gianluca.. con la sua ricerca pe i rumori / disturbi
    in una sistema liquida.

    Allora, mentre per questo non posso rispondere subito positivo, le misure richieste sono toste,
    e principalmente richiedono strumentazione ad alto costo..
    Ma.
    Io questa cosa, studiare / cercare/ 'hunt down' i disturbi di ~alta frequenza nei sistemi nostri, lo pratico per lavoro..
    E per questa attivita ~mia c'ho percorso diverse strade, anche con strumenti costosi (analizzatori di spettro) -- ma alla fine ho sviluppato un metodo apparentemente piu semplice ma tantissimo efficace.
    Ho costruito un piccolo ricevitore 'radio' a larga banda, con una (in realta diverse) antenna 'spacciato' per larga banda, (in verita non lo e, ma con una accettabile inefficenza, si).
    Questo ricevitore consiste di una piccolo amplificatore molto silenzioso e veloce, che amplifica il segnale della antenna ad un livello che appena basti per un buon oscilloscopio. Nel altra canale del oscilloscopio generalmente introduco un segnale del nostro sistema, e se posso cerco di triggerare sul specifico disturbo che da fastidio nella presa dati.
    Poi con il ricevitore faccio il giro della stanza, vado a toccare i diversi punti sospetti con l'antenna.

    Quando trovo il vero sorgente del nostro rumore, le due traccie sul oscilloscopio vengono sincronizzati da soli.. tutto qui.

    Allora, onestamente non capisco perche, ma non mi e venuto in mente mai di portare questo agieggo in casa mia, usare 'contro' il mio sistema audio.. Ecco, sulla iniziativa di Gianluca, adesso l'ho fatto!

    Ed ho trovato il finimondo creato dall alimentatore 'mattoncino' del mio laptop.. ed ho dovuto combattere per abattere il fastidioso onnipresente disturbo creato da esso.

    Pero.. quando finalmente sono riuscito, c'hanno cominciato a venire a galle le finezze.

    Per esemplio, puntando l'antenna sul cavo USB, ci si percepiscono i campi EM generati dal flusso dati, dispersi intorno del cavo.
    Adesso, un buon cavo pero dovrebbe fare proprio questo, contenere entro di se, nascondere fuori questi campi.
    Pero, l'integrita del cavo viene interrotto bruscamente dai connettori USB. Non ce niente da fare, e la natura delle cose: i connetori USB irradiano i campi elettromagnetici generato dal flusso dei dati.
    Ci si puo sfruttare questa occasione: il connettore all ricevitore USB, all' entrata del DAC, e un punto ideale per rilevare se il flusso dati ha subito qualche deformazione, percorrendo il cavo..

    Ok, tante parole per pochi fatti:

    Ecco le foto dell oscilloscopio aggianciato alla ricevitore, puntato al punto di entrata USB sul DAC.

    Avvertimento:le foto sono a leggere da destra a sinistra!!

    1.) un cavo generic:


    2.) WireWorld UltraViolet 7:


    3.) WireWorld Starlight 5:


    4.) diyCAT7:
    Immagini allegate Immagini allegate
    Ultima modifica di JosephK : 20-10-2016 a 12:03

  10. #120
    byte
    Registrato
    Jun 2015
    Messaggi
    152

    Predefinito

    Un po di spiegazione:

    c'ho ri-allegato il cavo WW starlight.
    Ci sto sincronizzando su un blocco dati. Ci vede chiaro i preamb iniziali, con il bitlength piu lunghi e assimmetrici, poi il corpo di blocco dati di alta velocita / densita, poi i block markers ai confini, un secondo block poi il marker finale.
    Osservare la regolarita, compostezza e chiarezza del quadro..


Pagina 12 di 22
prima
... 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 ... ultimo

Informazioni Thread

Users Browsing this Thread

Ci sono attualmente 3 utenti che stanno visualizzando questa discussione. (0 utenti e 3 ospiti)

Regole d'invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
nexthardware.com - © 2002-2022