Picchi casuali L3G4200D

Ho cercato questo forum un po 'per quanto riguarda il giroscopio L3G4200D e non ho visto menzionato questo problema, ma ho visto altri parlarne su altri forum. Sto vedendo uno strano grande valore nella mia uscita quando il giroscopio è fermo. Sfortunatamente nessuno sembra essere stato in grado di rispondere al perché, quindi ho pensato di chiedere in giro

Quindi, sto raccogliendo dati dal giroscopio usando i2c a 400kHz (modalità veloce), raccogliendo i dati del giroscopio usando la lettura multibyte (sei byte alla volta). Il campionamento a 100Hz (provato anche i primi 800Hz), ha anche provato con il filtro attivato e disattivato a valori diversi. Non sto usando il pin di interruzione, ma sto usando l'attributo 'aggiornamento dati blocco' in GYRCTRLREG4, in modo che i dati non vengano emessi fino a quando non vengono letti sia LSB che MSB. 2000dps completi e non fatto nulla con FIFO. Posso pubblicare i miei esatti valori di registro se mi aiuta, ma immagino che molti di voi non avranno il foglio dati a portata di mano.

L'immagine sotto mostra il mio problema. I dati in uscita sono buoni, calcolati correttamente (per quanto ne sappia) e il rumore generale è molto accettabile. Ma poi ho notato questi fastidiosi "bip" che appaiono in modo casuale quando il dispositivo è fermo. Se lo lascio fermo per un paio di secondi, otterrò uno di questi picchi, sempre pari a circa 250-255 (quindi ~ 18 quando convertito, usando '(output * 70) / 1000'). I picchi, come dico io, sono casuali, possono apparire su qualsiasi piano (nell'immagine qui sotto puoi vedere il primo picco nel piano X, secondo nella Y), sempre intorno allo stesso valore e uno, due o tutti tre possono accadere contemporaneamente. Il valore elevato è solo per un singolo campione, quindi torna alla normalità.

Ho visto in un altro thread da qualche parte che avrei dovuto usare la funzione di attesa dei dati di blocco in GYRCTRLREG4, come ho detto prima, ma nessuna modifica. Ho ridotto il problema a quando l'MSB è zero o superiore, cioè un numero positivo, quindi quando MSB e LSB sono combinati ottengo questi numeri grandi. Ad esempio, afferro i due byte necessari per il piano X, ottengo un -6 nell'LSB e uno 0 nell'MSB, combinandoli mi dà 250, quindi la conversione dà (250 * 70) / 1000 = 17,5 dps ( cioè troppo grande per fermo / errato). Nello stesso esempio, i due byte per il piano Y sono -3 LSB e -1 MSN, combinandoli da -3 e convertendo da -0,21 (ovvero previsto / corretto).

Sono su questo problema da giorni, vedo anche un po 'di questi picchi casuali con il mio magnetometro, quindi sto pensando che sto leggendo il dispositivo (tramite i2c) in modo errato?

Eventuali suggerimenti o cose da provare sono davvero benvenuti!

Dato che stai osservando un problema simile con il tuo magnetometro, suppongo che tu abbia un problema sul bus I2C. Anche se potrebbe essere un problema di codice a causa dell'operazione intermittente, prima verificherei come è collegato il bus. Alcune cose da controllare / provare:

• Se non si utilizzano resistenze pull-up esterne, provare le resistenze pull-up 10K su SDA e SCL. Il pull-up interno sulla maggior parte dei microcontrollori non sarà abbastanza forte.

• Se possibile, ridurre il più possibile la lunghezza del bus e cercare di mantenerlo lontano dai segnali ad alta velocità.

• Se si utilizza una breadboard, cercare di mantenere i collegamenti il ​​più diretti possibile per evitare capacità eccessive.

• Se stai usando schede prototipo che includono già resistenze di pull-up, potrebbero finire in parallelo e potresti avere un valore di resistenza di pull-up troppo basso.

• Se riesci ad organizzare l'accesso a un ambito che sarebbe l'ideale per assicurarti che l'orologio e le linee dati siano belle e quadrate e non siano troppo inclinate.

Se questi passaggi non funzionano, Texas Instruments ha il rapporto sull'applicazione della risoluzione dei problemi del protocollo I2C Bus che approfondisce il calcolo delle resistenze di pull-up e i problemi che si possono incontrare con la capacità.

Ciò che potrebbe accadere è che si sta prendendo un nuovo campione tra la lettura dell'LSB e l'MSB. Quindi se MSB = 0 e LSB = -4 dovresti ottenere 252, o circa 1g. Se la lettura successiva è MSB = 1 e LSB = 2, dovresti ottenere 258, il che è ragionevole. Il loro problema è quando solo per 1 campione l'MSB si è aggiornato a 1 e l'LSB è ancora -4 si ottiene 508, circa 2g, che potrebbe essere questo blip.

BDU su CTRL_REG4 dovrebbe prevenirlo. Magari leggi quel registro dal sensore e assicurati che il blocco bloccato sia abilitato?

prova con un filtro mediano e questi picchi svaniranno.

Si prega di fare riferimento alla mia domanda qui su StackExchange e quindi leggere questo post sullo stesso problema