Ummm, non è il contrario
Cioè sapendo l'accelerazione, per calcolare la velocità faccio la derivata, derivando ancora una volta ho la posizione
ops
si, hai ragione è il contrario.... scusami... la stanchezza
Citazione:
In pratica hai messo un ciclo (forse while?) in cui accumuli i valori di "accX" e "vel" (rispettivamente in accTOTx e velTOT) e man mano che ti arrivano i "dati" calcoli la velocità e la posizione, right?
in pratica quelle operazioni sono in una funzione che viene chiamata ogni volta che si riceve un nuovo dato dall'USB, quindi non è un vero e proprio ciclo, cmq il concetto è quello che hai detto.
Citazione:
Come mai hai messo nell'if accX<0 e anche vel<0, può accadere che questi siano negativi?
potendo il sensore rilevare accelerazioni negative, si potrebbero gestire anche questi valori, ma non mi interessava, quindi sarebbe stata una complicazione inutile.
Registrato: Apr 10, 2007 Messaggi: 15 Località: Pianeta terra
Inviato: Dom 13 Mag 2007, 11:07 Oggetto:
Demetrius ha scritto:
CUT
Ciao Demetrius,
dopo quasi 1 mese passati sui libri a studiare per gli esami, ho ripreso in mano il progettino dell'adxl
Mi sono assemblato tutto il circuito (in realtà ne ho fatti due: uno del pic ed uno dell'adxl e li ho connessi tramite un cavo da 4 poli, il cavetto audio usato nei pc per collegare la scheda audio al lettore CD ).
A dirti la verità non ho ancora capito bene se funge o meno (ma io penso di si ).
Ti elenco sinteticamente quello che ho fatto:
1) Ho utilizzato esclusivamente le procedure ad 8 bit
2) Nella funzione main c'è questa parte di codice:
In pratica per ottenere l'A(g) in base al datasheet faccio:
A(g)=(out_data[0]-out_data[2])/0.125
Giusto?
Per ottenerlo in milliG dovrei dividere per 1000?
La formula che mi scrivesti nello scorso post:
"accX=(dx-zeroX)*1000 / ppgX;",
non l'ho capita
Perchè moltiplichi per 1000 e dividi per 12.5?
12.5 è un termine percentuale quindi non si dovrebbe scrivere 0.125?
Per avere in milliG non si dovrebbe dividere per 1000?
Comunque muovendo l'adxl ottengo dei valori che cambiano in base a come lo muovo (sintomo che forse funge ).
Un'ultima cosa: Come interpreto i byte che ricevo?
Nel senso: li devo trattare come valori hex con segno o senza segno?
per la formula che ti ho dato, in realtà devi tenere conto che nel codice che t ho dato c'è un fattore ADXL_SCALING_FACTORl = 0.01
quindi sarebbe:
accX=(T1/(T2*0.01)-T1calib/(T2calib*0.01))*1000 / ppgX=(T1/T2-zeroG)*1000/(0.01*12.5)=(T1/T2-zeroG)*1000/0,125
il 1000 serve per avere il valore in mG: la formula ti dà il valore in G, se per esempio ottieni 1.2G, moltiplicando per 1000 si ha 1200milliG.
per verificare che il sensore funzioni, basta che lo metti in verticale e dovresti leggere un valore prossimo ad 1G.
per quanto riguarda l'usb... i valori in ricezione sono interi senza segno, smanettando nelle librerie usb del ccs mi pare si possa cambiare l'impostazione.... ma non mi ricordo molto bene questo aspetto
valore sarebbe (T1/T2-zeroG) comprensivo del ADXL_SCALING_FACTORl (se hai usato le stesse routine del mio codice), quindi per ottenere il valore finale devi moltiplicare solo per 1000/12.5=80.
prova a farti mandare i valori out_data e vedi cosa contengono, per vedere se è un problema di calcoli del PIC, oppure un problema di lettura dal sensore.
printf(usb_cdc_putc, "\r%u ", valore );
usb_cdc_putc non c'è nella mia versione del compilatore, cosa fa esattamente?
Registrato: Apr 10, 2007 Messaggi: 15 Località: Pianeta terra
Inviato: Mar 15 Mag 2007, 15:47 Oggetto:
Demetrius ha scritto:
CUT
Allora...io ho implementato l'USB CDC praticamente crea un'emulazione USB sulla seriale (il pc me lo vede come COM4).
Mi serve fare in questo modo perchè dovrei interfacciare il sensore ad un programma scritto in LabView in cui ho già in precedenza lavorato con la seriale
Comunque ho reso il codice molto simile al tuo, eccoti l'ennesimo pezzo :
in effetti sembrano valori sballati, anche se non casuali visto che quando lo tieni fermo ottieni valori simili.
vedi se tutte le impostazioni relative al CCP, Interrupt Timer, ecc. sono corrette.... tieni conto di eventuali differenze di Clock tra il mio codice e quello che hai messo tu.
se è tutto a posto, prova la versione a 16bit e vedi che valori ti dà quella.
Registrato: Apr 10, 2007 Messaggi: 15 Località: Pianeta terra
Inviato: Mer 16 Mag 2007, 8:49 Oggetto:
Demetrius ha scritto:
CUT
Umm effettivamente mi era sfuggito il fatto che nel tuo progetto è stato usato un quarzo da 10MHz e io sto usando uno da 20MHz
Penso quindi che qualcosa non vada qui:
A questo punto faccio visualizzare sull'RS232 il valore:
Codice:
valore = (out_data[0]-out_data[2]);
printf(usb_cdc_putc, "\r%d ", valore );
usb_cdc_putc è definito cosi (nelle librerie del CCS):
Codice:
//// usb_cdc_putc(char c) - Puts a character into the transmit ////
//// buffer. If the transmit buffer is full it will wait until ////
//// the transmit buffer is not full before putting the char ////
//// into the transmit buffer. The transmit buffer is read by ////
//// the PC very quickly, and therefore the buffer should only ////
//// be full for a few milli-seconds. If you are concerned ////
//// and don't want to be stuck in a long or infinite loop, ////
//// use usb_cdc_putready() to see if there is space in the ////
//// transmit buffer before putting data into the transmit ////
//// buffer.
In pratica invio "valore" alla rs232 e la faccio visualizzare in formato intero con segno (%d).
Collego l'interfaccia al pc ed ottengo (con il sensore parallelo al piano) valori prossimi allo zero e in perpendicolare leggo 11/12 (che moltiplicato per 80 sarebbero 880-960milliG).
Il fatto è che facendo l'arcoseno per ricavare i gradi dall'accelerazione, le angolazioni che ottengo sono ben lontane dalla realtà (invece di stare a 30° ottengo 60°)
Poi ho provato anche le routine a 16BIT ed ho ottenuto questi dati:
con 8bit è praticamente impossibile avere risultati attendibili per la misura dell'inclinazione, perché la risoluzione è troppo bassa, tieni anche conto che va fatta una calibrazione molto più accurata proprio perché bastano pochi milliG di differenza e si hanno salti di diversi gradi in inclinazione
per quanto riguarda i timer, settalo in modo che non vada in overflow prima che finisca il periodo dell'onda PWM del sensore: se il periodo è 10ms (quindi mi pare con una resistenza di circa 1.2Mohm) il timer deve essere settato di conseguenza per es. a 10,5ms.Nel PCW c'è una procedura guidata che ti indica ogni quanto un timer viene incrementato e quando va in overflow a secondo del clock e puoi vedere il codice associato a quelle opzioni.
per l'adxl210 ti posso dire chè è tutto uguale, cambia solo per calcolo dell'accelerazione: devi dividere per 4 invece di 12.5
Registrato: Apr 10, 2007 Messaggi: 15 Località: Pianeta terra
Inviato: Mer 16 Mag 2007, 16:29 Oggetto:
Demetrius ha scritto:
i valori a 16bit mi sembrano abbastanza corretti.
In che modo li interpreti i valori?
C'è qualcosa che non riesco a capire
Ti faccio una panoramica sui nuovi sviluppi
Allora è assodato che utilizzando un quarzo da 20Mhz (che in realtà sono 48MHz perchè ho abilitato il PLL a 5, in quanto in usb CDC il quarzo deve essere per forza a 48MHz) devo settare il Timer con DIV pari a 2 (ho utilizzato l'utility del CCS che mi conferma che l'overfloy avviene a 10.8ms, avendo utilizzato una resistenza da 1Mohm a 5% di tolleranza sono a riparo (ho usato esattamente il tuo schema con i tuoi stessi valori ).
Usando invece il DIV a 1 avrei avuto l'overflow a 5ms (circa).
Assodato questo, non riesco a capire i valori
Ad esempio questi sono gli ultimi dati che ho acquisito dal sensore (16Bit):
Dove le 4 colonne sono (da sx verso dx):
DutyX, DutyY, zeroGx, zeroGy
Ho già eliminato lo "spazio" tra la parte alta e bassa del numero
Come li interpreti?
Ad esempio, prendendo l'ultima riga e calcolando l'A(g) relativa all'asse X ottengo (in hex):
1A35-158D=4A8
Se convertiamo in decimale otteniamo:
1192
Che dovrei moltiplicare per 1000 e dividere per 12.5, ma cosi ottengo un numero senza senso !
P.S. Ho fatto una misurazione con il tester e ho visto che in posizione parallela al pavimento la tensione tra X-Out rispetto a massa è di 2.68V quasi il 50% del duty cycle (devi tener presente dell'errore compiuto dal mio tester che di regola non legge onde quadre, ma solo continue e/o sinusoidali), quando è perpendicolare arriva a 3.25V.
Non ci sto a capire più niente
Perdonami se ti sto rompendo i OO
Ciao _________________ Non condivido la tua idea, ma darei la vita perché tu la possa esprimere (Voltaire)
Registrato: Apr 10, 2007 Messaggi: 15 Località: Pianeta terra
Inviato: Gio 17 Mag 2007, 8:32 Oggetto:
Demetrius ha scritto:
quindi 1192 * 10/12.5=953,6 mG
Allèèèè perfetto !
Purtroppo non avevo pensato al fatto che rilevare angolazioni trai 75 e 90° è praticamente impossibile perchè dai 75° in poi la variazione dell'arcoseno entra in una zona curva e i valori si compattano troppo (= piccolissime variazioni per molti gradi)....
Vabbè pazienza
Per quanto riguarda il filtro numerico, quale hai utilizzato?
L'hai implementato, per caso in matlab, o direttamente in delphi?
Grazie di tutto
Ciao _________________ Non condivido la tua idea, ma darei la vita perché tu la possa esprimere (Voltaire)
Tutti i fusi orari sono GMT + 1 ora Vai a pagina Precedente1, 2
Pagina 2 di 2
Non puoi inserire nuovi Topic in questo forum Non puoi rispondere ai Topic in questo forum Non puoi modificare i tuoi messaggi in questo forum Non puoi cancellare i tuoi messaggi in questo forum Non puoi votare nei sondaggi in questo forum
:: Home :: RSS News :: Privacy :: Disclaimer :: Contatti :: Google Sitemap ::
Copyright by DemiSoft. Tutti i diritti riservati. Leggere attentamente il Disclaimer. Engine by PHP-Nuke Generazione pagina: 0.55 Secondi
FAQ
Cerca
Gruppi utenti
Profilo
Messaggi Privati
Login
(ma io penso di si 
?
