Difference between revisions of "Talk:Online P300 and ErrP recognition with BCI2000"
| Line 16: | Line 16: | ||
- come mostrato in figura si può vedere che l'accumulo medio varia da 1 a 0 campioni (accumulo calcolato come il numero di campioni rimanenti in memoria dopo l'invio di un blocco dati) | - come mostrato in figura si può vedere che l'accumulo medio varia da 1 a 0 campioni (accumulo calcolato come il numero di campioni rimanenti in memoria dopo l'invio di un blocco dati) | ||
| − | - il numero di blocchi inviati varia da 1 a 2 blocchi con una media di blocchi ogni 10 chiamate leggermente inferiore a 2 (nella schermata specifica 1.71) | + | - il numero di blocchi inviati varia da 1 a 2 blocchi con una media di blocchi ogni 10 chiamate leggermente inferiore a 2 (nella schermata specifica 1.71). Nell'esempio sono stati inviati circa 14 campioni che equivalgono circa a 109 msec di dati. |
| + | |||
- il variare del numero di blocchi inviati dipende dall'accumulo verificatosi nelle chiamate precedenti e dal fatto che al plugin non arriva una quantità di dati costanti. | - il variare del numero di blocchi inviati dipende dall'accumulo verificatosi nelle chiamate precedenti e dal fatto che al plugin non arriva una quantità di dati costanti. | ||
Possiamo affermare comunque che sfruttando l'invio di una quantità di dati costanti, rappresentanti un certo intervallo di tempo, si riesce ad ottenere una temporizzazione dell'intero sistema BCI2000 che in media si posiziona nell'intorno della temporizzazione dettata dal plugin che è di 1/16 di secondo per ogni blocco dati processato. | Possiamo affermare comunque che sfruttando l'invio di una quantità di dati costanti, rappresentanti un certo intervallo di tempo, si riesce ad ottenere una temporizzazione dell'intero sistema BCI2000 che in media si posiziona nell'intorno della temporizzazione dettata dal plugin che è di 1/16 di secondo per ogni blocco dati processato. | ||
Revision as of 13:50, 29 April 2008
Il sistema attualmente è composto da un plugin che si occupa di inviare i dati tramite pipe ad un altro modulo che fa parte dell'intero sistema di BCI2000.
Per ottenere una corretta temporizzazione del sistema di BCI2000 abbiamo sfruttato il fatto che il plugin è più lento nell'invio dei dati rispetto all'intero sistema BCI2000. Infatti si è deciso di inviare tramite plugin una quantità di dati costante pari a 1/16 di secondo, nonostante che, i dati ricevuti dal plugin non sono un valore costante ma variabile intorno ad un certo valore medio, monitorando nel frattempo l'accumulo medio di campioni. In questo modo ogni invio di dati rappresenta il trascorrere di un tempo prefissato che è in media è 1/16 di secondo.
Test effettuato: - freq. campionamento: 128Hz - numero campioni per blocco dati da 1/16 di secondo: 8 - visualizzazione accumulo medio ogni 10 chiamate al plugin - visualizzazione numero blocchi di dati inviati ogni 10 chiamate
Risultati:
- come mostrato in figura si può vedere che l'accumulo medio varia da 1 a 0 campioni (accumulo calcolato come il numero di campioni rimanenti in memoria dopo l'invio di un blocco dati) - il numero di blocchi inviati varia da 1 a 2 blocchi con una media di blocchi ogni 10 chiamate leggermente inferiore a 2 (nella schermata specifica 1.71). Nell'esempio sono stati inviati circa 14 campioni che equivalgono circa a 109 msec di dati.
- il variare del numero di blocchi inviati dipende dall'accumulo verificatosi nelle chiamate precedenti e dal fatto che al plugin non arriva una quantità di dati costanti.
Possiamo affermare comunque che sfruttando l'invio di una quantità di dati costanti, rappresentanti un certo intervallo di tempo, si riesce ad ottenere una temporizzazione dell'intero sistema BCI2000 che in media si posiziona nell'intorno della temporizzazione dettata dal plugin che è di 1/16 di secondo per ogni blocco dati processato.
