Filtro per il microfono

[ariutti]

Dopo diversi esperimenti sono emersi alcuni problemi derivanti dall'uso del microfono.

Premessa: il microfono e connesso alla centralina attraverso una cavo bipolare schermato lungo 5mt;

Dato il seguente codice:

#define MIC A0

const int sampleWindow = 50; // Sample window width in mS (50 mS = 20Hz)
unsigned int sample;

// SETUP //////////////////////////////////////////////////////////////////////
void setup() 
{
   Serial.begin(9600);
}

// LOOP ///////////////////////////////////////////////////////////////////////
void loop() 
{
   unsigned long startMillis= millis();  // Start of sample window
   unsigned int peakToPeak = 0;          // peak-to-peak level

   unsigned int signalMax = 0;
   unsigned int signalMin = 1024;

   // collect data for 50 mS
   while (millis() - startMillis < sampleWindow)
   {
      sample = analogRead( MIC );
      Serial.print("\t"); Serial.print(sample); Serial.println(";");
      if (sample < 1024)  // toss out spurious readings
      {
         if (sample > signalMax)
         {
            signalMax = sample;  // save just the max levels
         }
         else if (sample < signalMin)
         {
            signalMin = sample;  // save just the min levels
         }
      }
   }
   peakToPeak = signalMax - signalMin;  // max - min = peak-peak amplitude
   double volts = (peakToPeak * 3.3) / 1024;  // convert to volts

   Serial.print("[");
   Serial.print(signalMin); Serial.print(" - ");
   Serial.print(signalMax); Serial.print("] ");
   Serial.print(peakToPeak); Serial.println(" - ");
}

Da una stampa a monitor seriale del valore grezzo del sample registrato dal microfono, sembra che ci siano momenti in cui tale valore è molto grande (1023) il che fa sì che il valore massimo si attesti molto distante dal valore minimo.

Di conseguenza la differenza signalMax -signalMin, al termine della finestra temporale di interesse, risulta essere maggiore della threshold impostata, anche se il valore spurio si è manifestato solo una volta assieme magari ad un altra decina di letture valide.

Una possibile soluzione potrebbe essere quella di creare un filtro passa basso software? così i valori numerici in ingresso dal sensore potrebbero essere filtrati ed evitare letture troppo ballerine.

[ariutti]

Ho notato inoltre che le letture del microfono sono di gran lunga peggiori quando sulla stessa linea di alimentazione si trova anche il BlueSmirf. Per questo il modulo BlueTooth è stato spostato altrove.

A nulla sembra servire posizionare un condensatore da 10microFarad tra alimnetazione e massa in prossimità del microfono.

[ariutti]

Ho notato inoltre un altra cosa: i valori sample misurati dal microfono, quando in serie all'alimentazione attacco un amperometro (allo scopo di monitorare i consumi) sono valori nettamente più bassi rispetto a quelli che si avrebbero connettendo il microfono direttamente alla scheda Arduino. Questo non so a che cosa possa essere dovuto...

[ariutti]

E' chiaro che, con un componente come l'amperometro in serie, i valori misurati all'ingresso del convertitore ADC saranno diversi rispetto a quelli misurati in condizioni normali.

Il circuito non cambia in teoria, questo sarebbe vero nella realtà se l'amperometro fosse un componente ideale. Invece introduce una caduta di tensione che si ripercuote sul microfono. Il segnale in output dal microfono infatti varai tra 0 e Vcc, ma se Vcc si abbassa perchè pari a Vcc = 5V - Vamperometro allora anche i valori misurati all'ingresso ADC si riducono proporzionalmente.

[ariutti]

Altre possibili soluzioni:

• non preoccuparsi del modulo BlueTooth il quale probabilmente, appena instaurata la connessione con il dispositivo all'altro capo, smetterà di generare disturbi sulla linea di alimentazione comune;
• programmare un filtro DSP numerico via software (IIR) magari implementando la libreria FFT:
• ecco alcuni link d'esempio link1, link2, link3;
• costruire un filtro passabasso fisico con componenti discrete prima di campionare (R e C);
• accorciare il cavo che connette il microfono alla centralina.

[ariutti]

Incredibile ma il problema sembra essersi risolto (almeno in parte*) collegando la centralina alla alimentazione attraverso apposito alimentatore.

Evidentemente, pur la corrente richiesta minore del massimo fornibile dalla porta USB, essa non è abbastanza stabile e provoca fluttuazioni e false letture sul microfono.

[*] in parte nel senso che la soglia può essere impostata ad un livello inferiore. Evidentemente con l'alimentatore collegato non ci sono più così tante fluttuazioni legate al rumore.

[ariutti]

E' probabile che si debba alimentare il BlueSmirf con un alimentatore esterno così che non dia problemi alle componenti circuitali che sono alimentate dai 5V di Arduino. O in questo modo: O in quest'altro: