Difference between revisions of "Talk:Online P300 and ErrP recognition with BCI2000"

Revision as of 10:07, 2 May 2008

PLUGIN

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.

Fatto

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 inviati 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.

Non mi è chiaro; il plugin non dovrebbe ricevere e inviare in media 1 blocco di 1/16 di secondo alla volta? (BernardoDalSeno 20:07, 30 April 2008 (CEST))

Il plugin invia blocchi dati di 1/16 di secondo, ma riceve dall'applicativo EBNeuro per ogni invocazione della LoadData(...) (quindi ogni chiamata del plugin) un numero di campioni variabile (1-2 campioni). Probabilmente vi sono temporizzazioni interne che dipendono da diveri parametri, ad esempio con 9 canali a 512Hz vi era un'invocazione del plugin ogni 1/16 di secondo con il passaggio di una media di 32 campioni per canale, mentre con 25 canali a 128Hz vi è un'invocazione del plugin ogni 1/64 di secondo con l'invio di circa 2 campioni per canale. Nell'immagine seguente è mostrato una parte di una sequenza di dati che riceve il plugin.

• 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.

Da fare

Pensare a un modo per misurare la temporizzazione online.

Test online per verificare la temporizzazione.

CATENA DI FILTRI DI BCI2000

Attualmente la catena di filtri del modulo di BCI2000 è suddivisa nel seguente modo:

1)un filtro spaziale

2)un filtro di Trigger che si occupa di rilevare gli inizi delle stimolazioni tramite l'analisi del segnale proveniente dal fototransistor

3)un filtro che si occupa di accumulare più forme d'onda p300 relative alla stessa stimolazione e tra queste farne la media

4)un filtro di classificazione

5)un filtro di normalizzazione

Si vuole modificare sia la sequenza di filtri che il funzionamento di alcuni di questi nel seguente modo:

1)filtro spaziale

2)filtro di Trigger che determina in maniera automatica, tramite una fase iniziale dettata dal modulo applicativo, il valore di soglia per distinguere gli istanti di tempo in cui il riquadro è nero oppure bianco

3)un filtro che si occupa solamente di accumulare le forme d'onda p300 con un ring buffer che memorizza una porzione di segnale precedente, dato che noi rileviamo l'inizio di una stimolazione con un ritardo che è pari alla dimensione della finestra mobile fatta scorrere lungo il segnale di trigger

4)filtro di classificazione

5)filtro che effettua la media dei valori in uscita dal filtro di classificazione

6)un filtro di normalizzazione

Fatto

Filtro che rileva i trigger

Da fare

Adattamento automatico della soglia per i trigger

Accumulare forme d'onda con parti che precedono il trigger

Modulo applicativo speller P300

Il modulo applicativo deve adattato al sistema di trigger.

Per quanto riguarda il modulo applicativo bisogna introdurre un riquadro posto nell'angolo superiore destro dello schermo e farlo variare (bianco/nero) ogni qual volta viene effettuata una stimolazione e, prima dell'inizio della sequenza di stimolazioni, introdurre una fase preliminare in cui si fa variare (bianco/nero) il riquadro per un tempo totale preimpostato in modo da poter far determinare in maniera automatica dal filtro di Trigger il valore di soglia che permette di distinguere se siamo in fase di stimolazione (riquadro nero) o in fase di non stimolazione (riquadro bianco). Terminata la fase di taratura del valore di soglia, lo speller può effettuare la sua sequenza di stimolazioni.

Per le modifiche da effettuare al modulo applicativo di BCI2000 quando questo deve comunicare tramite protocollo UDP con un altro applicativo che effettua le stimolazioni su una differente macchina Linux si è invitati a visionare la relativa discussione di Roberto Massimini.

Fatto

Da fare

Aggiungere quadrato di sync nell'applicazione speller

Misurare lo sfasamento tra sync e stimolo

Sviluppare sistema per associare la stimolazione ai trigger rilevati dall'apposito filtro

Scrivere specifiche per comunicazione tra BCI2000 e un modulo applicativo P300 esterno che gira su una macchina Linux separata

Integrazione con ErrP

Il sistema basato su BCI2000 che usa P300 va espanso per poter usar anche i potenziali d'errore

Fatto

Da fare

Tutto, anche il dettaglio delle cose da fare...

Varie

Rinominare le directory dei sorgenti in conformità allo stile di BCI2000 e senza usare spazi