ho pensato di generare un'onda (quadra, rumore, etc) con il software audaticy.
e collegare l'uscita audio (cuffia) ai pin analogici dell'arduino per acquisire il segnale.
si può fare oppure è un'idea malvaggia.
Una volta acquisito il segnale, che cosa ci fai?
Ricorda che le prestazioni del campionamento dell'Arduino sono da: "Morto-di-sonno".
l'idea è di generare un segnale variabile (noto), e di acquisirlo per vedere se l'adc e l'eventuale amplificatore funzionano correttamente.
Beh, si. Al netto di quanto ti ho detto (campionamento da MCU economica) a livello sperimentale puoi senz'altro farlo.
Puoi anche provare a replicare il segnale in uscita ricostruendolo con un PWM (il DAC dei poveri) e vedere quanta differenza c'è tra segnale in ingresso, e segnale in uscita (basta che non ti spaventi! 
)
BaBBuino:
....
Puoi anche provare a replicare il segnale in uscita ricostruendolo con un PWM (il DAC dei poveri) ...
Occhio BaBBuino, il thread parla di Arduino Due ... che ha a bordo 2 veri DAC ... quindi non gli serve il PWM !!! 
Guglielmo
P.S. ... inoltre, pur non essendo una "scheggia" ... non è esattamente un "Morto-di-sonno" 
quindi supponendo di generare un segnale impulsivo a bassa frequenza (fra 1 e 50 hz) di una determinata ampiezza. Acquisendo il segnale con arduino due, posso verificare la frequenza e l'ampiezza.
Nel caso del DAC di arduino due, io posso generare un'onda
e acquisire utilizzando l'adc di arduino, ed eventualmente amplificare per valutare il gain.
gpb01:
BaBBuino:
....
Puoi anche provare a replicare il segnale in uscita ricostruendolo con un PWM (il DAC dei poveri) ...Occhio BaBBuino, il thread parla di Arduino Due ... che ha a bordo 2 veri DAC ... quindi non gli serve il PWM !!!
Guglielmo
P.S. ... inoltre, pur non essendo una "scheggia" ... non è esattamente un "Morto-di-sonno"
Hai ragione! Ho letto veloce!
Mi rimangio tutto, tra l'altro ha anche una notevole velocità di campionamento, siamo sul milione di campionamenti al sec, per una risoluzione di 12 bit.
Certo che con la DUE cambia tutto rispetto alla UNO.
gpb01:
P.S. ... inoltre, pur non essendo una "scheggia" ... non è esattamente un "Morto-di-sonno"
L'ADC della DUE arriva fino a 1 Msps, però tocca vedere con quale velocità viene realmente utilizzato da wiring.
gcam:
quindi supponendo di generare un segnale impulsivo a bassa frequenza (fra 1 e 50 hz) di una determinata ampiezza. Acquisendo il segnale con arduino due, posso verificare la frequenza e l'ampiezza.Nel caso del DAC di arduino due, io posso generare un'onda
http://arduino.cc/en/Tutorial/DueSimpleWaveformGenerator
e acquisire utilizzando l'adc di arduino, ed eventualmente amplificare per valutare il gain.
Quello che descrivi è un circuito closed loop, ad anello chiuso.
Generi un'onda e poi fai delle verifiche sulla stessa, magari con un qualche sistema di feedback per rimanere entro dei parametri stabiliti.
ma per arduino due è necessario utilizzare le istruzioni per velocizzare l'adc come per l'arduino uno
tipo
#define FASTADC 1
#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#endif
#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
#endif
oppure è veloce già di suo senza la necessità di ulteriori impostazioni.
il mio dubbio nel campionare il segnale di audaticy è la tensione in uscita dal pc e di entrata nell'arduino.
o posso rischiare di rompere arduino due.
Se ho capito bene, vuoi usare l'uscita cuffie...
In genere la tensione disponibile all'uscita è di qualche volt, ma per evitare di superare i 3.3V massimi degli ingressi della DUE, è meglio se metti un partitore resistivo, o ancora meglio un trimmer di "volume"
Avete definito ARDUINO UNO un "Morto-di-sonno"
però da un test eseguito è uscito fuori:
ARDUINO UNO acquisizione di 24000 campioni su 3 canali senza inviare i dati 430 ms circa.
ARDUINO DUE acquisizione di 24000 campioni su 3 canali senza inviare i dati 943 ms circa.
La differenza è notevole.
Per arduino uno ho utilizzato le seguenti istruzioni per accelerare l'ADC
#define FASTADC 1
#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#endif
#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
#endif
e
#if FASTADC
// set prescale to 16
sbi(ADCSRA,ADPS2) ;
cbi(ADCSRA,ADPS1) ;
cbi(ADCSRA,ADPS0) ;
#endif
Non utilizzando le istruzioni di cui sopra anche l'adc dell'arduino uno è lento.
Come faccio a velocizzare l'adc dell'arduino due ?
Mi pare che il clock dell'ADC del SAM3X sia fisso a 1 MHz, non vedo la possibilità di modificarlo come si può fare sull'Atmega328.
Non capisco.
1 Msps su 16 canali.
L'acquisizione per singolo canale dovrebbe aggirarsi intorno a 62 ksps, cioè 1Msps /16 = 0.0625 Msps = 62,5 ksps
gcam
Però può capitare questo!!!
ARDUINO 1.5.5 BETA
(....)
sam: Fixed wrong initialization for ADC timings (analogRead speed Arduino DUE improved by a factor x10)
L'ho letto giusto ora.
E' stata implementata nell'IDE 1.5.5 di prossima uscita una modifica che permette di migliorere i tempi di acquisizione dell'ADC su Arduino DUE.
[core]
- sam: Fixed wrong initialization for ADC timings (analogRead speed Arduino DUE improved by a factor x10)
(Evaluating Arduino and Due ADCs)
Edit: Preceduto da Leo.
L'IDE aggiornato è disponibile come versione nightly-build. (http://arduino.cc/en/Main/Software)
dobbiamo aspettare quindi la versione 1.5.5 per vedere risolto questo problema.
gcam:
dobbiamo aspettare quindi la versione 1.5.5 per vedere risolto questo problema.
Puoi compilarla anche ora, basta che ti scarichi i sorgenti.
PaoloP:
L'IDE aggiornato è disponibile come versione nightly-build.
perfetto. Provata la nuova versione.
Acquisizione di 24000 campioni su tre canali in 109 ms.
Però...
Nell'inviare i dati al pc sulla seriale, solo 1500 valori a gruppi di tre, l'acquisizione si allunga a 3 secondi circa. serial baud è settato a 115200
Come fare ad inviare i dati al pc in modo veloce ?
gcam