AIRWiki - User contributions [en]

IIT-Lab

2008-11-06T08:24:10Z

AndreaSgarlata: /* Booking */

== What is the IIT-Lab ==

AIRLab-IITLab is dedicated to activities founded by the Italian Institute of Technology.
The lab hosts activities related to Brain-Computer Interfaces (BCI) and Affective Computing.

=== Location ===
It is located in the Rimembranze di Lambrate building of the Department of Electronics and Information, Via Rimembranze di Lambrate, 14, Milan.

=== Access Rules ===
The access to AIRLab-IITLab is reserved to registered users. If you are student and want to register, you have to fill the AIRLab registration form (to be signed by your tutor) and the security form. The key of the lab is provided to registered users by the doorkeeper at the main entrance of the Lambrate building.

=== Booking ===

Please book the instrument you want to use by adding an entry to the table; the booking of an instrument implies the booking of the room. If you want to use a different instrument at the same time of an existing booking, please contact the other person involved and check that you can share the room; alternatively, you can ask the doorkeeper for an empty room in the building.


{| border="1"
! Day !! Time !! Person !! Instrument
|-
| Wednesday 5 November || 15:00-18:00 || [[User:CristianoAlessandro]] || ProComp
|-
| Thursday 6 November || 15:00-18:00 || [[User:TizianoDalbis]] || EEG
|-
| Monday 10 November || 10:00-18:00 || [[User:AndreaSgarlata]] || EEG
|-
| Thursday 13 November || 10:00-15:00 || [[User:AndreaSgarlata]] || EEG
|-
| Thursday 13 November || 15:00-18:00 || [[User:TizianoDalbis]] || EEG
|-
| Thursday 20 November || 15:00-18:00 || [[User:TizianoDalbis]] || EEG
|-
|}

== Links ==

* [[Brain-Computer Interface]] page on this Wiki
* [[Affective Computing]] page on this Wiki
* [http://www.airlab.elet.polimi.it/index.php/airlab/visitor_info/airlab_iitlab AIRLab - IITLab]

IIT-Lab

2008-11-06T08:22:57Z

AndreaSgarlata: /* Booking */

== What is the IIT-Lab ==

AIRLab-IITLab is dedicated to activities founded by the Italian Institute of Technology.
The lab hosts activities related to Brain-Computer Interfaces (BCI) and Affective Computing.

=== Location ===
It is located in the Rimembranze di Lambrate building of the Department of Electronics and Information, Via Rimembranze di Lambrate, 14, Milan.

=== Access Rules ===
The access to AIRLab-IITLab is reserved to registered users. If you are student and want to register, you have to fill the AIRLab registration form (to be signed by your tutor) and the security form. The key of the lab is provided to registered users by the doorkeeper at the main entrance of the Lambrate building.

=== Booking ===

Please book the instrument you want to use by adding an entry to the table; the booking of an instrument implies the booking of the room. If you want to use a different instrument at the same time of an existing booking, please contact the other person involved and check that you can share the room; alternatively, you can ask the doorkeeper for an empty room in the building.


{| border="1"
! Day !! Time !! Person !! Instrument
|-
| Wednesday 5 November || 15:00-18:00 || [[User:CristianoAlessandro]] || ProComp
|-
| Thursday 6 November || 15:00-18:00 || [[User:TizianoDalbis]] || EEG
|-
| Monday 10 November || 10:00-18:00 || [[User:AndreaSgarlata]] || EEG
|-
| Thursday 13 November || 15:00-18:00 || [[User:TizianoDalbis]] || EEG
|-
| Thursday 20 November || 15:00-18:00 || [[User:TizianoDalbis]] || EEG
|-
|}

== Links ==

* [[Brain-Computer Interface]] page on this Wiki
* [[Affective Computing]] page on this Wiki
* [http://www.airlab.elet.polimi.it/index.php/airlab/visitor_info/airlab_iitlab AIRLab - IITLab]

Talk:Online P300 and ErrP recognition with BCI2000

2008-09-17T09:44:35Z

AndreaSgarlata: /* Addestramento */

==Plugin Galileo/Modulo sorgente BCI2000==
*Riferimento su Airbat del sorgente modulo Plugin: sgarlata/Plugin

*Riferimento su Airbat del sorgente modulo sorgente BCI2000: sgarlata/GalileoSource

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, tenendo conto del fatto che durante l'esecuzione di una registrazione online la quantità di dati ricevuti dal plugin risulta molto regolare e costante.
In questo modo ogni invio di dati tramite pipe rappresenta il trascorrere di un tempo prefissato che risulta pari a 1/16 di secondo.

Sono stati effettuati diversi test (aggiunta di un buffer di accumulo, invio di blocchi di dimensione maggiore 0.1 secondi) per cercare di mantenere il più possibile costante l'intervallo che trascorre tra l'invio di un blocco dati e quello successivo, nonostante questi tentativi abbiamo riscontrato il fatto che l'intervallo tra due blocchi risulta in media molto regolare, questa regolarità viene persa però nei momenti in cui il sistema viene perturbato da fattori esterni dovuti all'intervento dell'utente, quali ad esempio: apertura nuova finestra, spostamento finestre, apertura cartelle ecc...
Tutti questi fattori possono essere trascurati, in quanto durante l'esecuzione dell'intero sistema l'utente non deve interagire direttamente con il sistema, ma deve solamente essere sottoposto a delle stimolazioni, e se l'utente decide di interagire è perché sta effettuando modifiche ed in quel momento non necessita di un sistema sincrono e regolare.
:Noi speriamo che non capiti durante il funzionamento normale o sia molto raro ([[User:BernardoDalSeno|BernardoDalSeno]] 20:21, 24 May 2008 (CEST))

Per tutte queste motivazioni si è deciso che il plugin non appena accumulato un blocco dati pari a 1/16 di secondo deve subito inviarlo tramite pipe, in modo da mantenere una regolarità tra l'invio consecutivo di due blocchi.

Nel sever Airbat sono presenti i sorgenti dei differenti plugin implementati con le differenti stategie di funzionamento:

*Cartella sgarlata/old/PluginPipe: il plugin implementato consente un invio di dati in blocchi di 0.1secondi, consentendo al modulo sorgente di BCI2000 di occuparsi dell'invio di blocchi dati di dimensioni inferiori all'interno del sistema di BCI2000. Questa strategia è stata abbandonata perchè abbiamo notato che a 512Hz il plugin riceveva blocchi di 32 campioni per ogni chiamata, e doveva inviare blocchi di 51 campioni, questa differenza faceva si che l'invio di blocchi non era regolare in quanto ad esempio dopo due chiamate inviavo un blocco da 51 campioni e poi dovevo aspettare 3 chiamate per inviare un nuovo blocco dati.

*Cartella sgarlata/old/PluginBuffer: il plugin implementato mantiene un buffer di N blocchi dati pari a 1/16 di secondo, ed inizia l'invio di un blocco dati nel momento in cui mezzo buffer è stato riempito, utilizzando come clock di invio l'orologio di invocazione del plugin, dato che in maniera molto regolare vi era un invocazione ogni 1/16 di secondo a 512Hz. La strategia dell'utilizzo del buffer è stata abbandonata in quanto, si introduceva ritardo con il buffer ed in oltre i problemi di perdita di regolarità si verificavano comunque perchè non erano dovuti a dei mancati invii di dati da parte del plugin,ma erano dovuti al fatto che il sistema veniva perturbato da un utente esterno ed il modulo sorgente di BCI2000 attendeva nella lettura di un nuovo blocco.

*Cartella sgarlata/old/PluginTemporizzato: questo plugin utilizza un blocco dati pari a 1/16 di secondo, ma diversamente dal plugin finale manca della stampa di diversi valori di debug e della possibilità di connessione con il sistema di BCI2000 non sincrona.

Le diverse strategie di sviluppo del plugin sono state studiate ed implementate per poter utilizzare un applicativo di stimolazione che rimanesse sincrono con l'intero sistema e quindi che avesse la possibilità di essere implementato da un modulo applicativo di BCI2000.
Uno stimolatore sincrono è un vantaggio in quanto consente di farlo evolvere durante l'acquisizione dei segnali e di effettuare diverse scelte sulla base di questi e dei risultati fin ora ottenuti.

Per quanto riguarda il modulo sorgente di BCI2000 questo si occupa di leggere dalla pipe: il numero di canali, il numero di campioni per canale e la frequenza di campionamento. Una volta letti questi valori controlla che l'utente abbia inserito tra i parametri gli stessi valori letti tramite pipe, se questo non avviene blocca l'intero sistema e comunica l'errore all'utente con i valori esatti da inserire. Questa procedura viene ripetuta finché l'utente non inserisce gli stessi parametri letti dal modulo source. Si è visto che invece non si riesce a passare i parametri dal modulo sorgente agli altri moduli di BCI2000 durante la fase di inizializzazione.

A run time il modulo source si occupa di leggere dalla pipe una blocco di dati e di inviarlo al modulo successivo (modulo filtro); ogni blocco viene inoltrato non appena è disponibile.

===Da fare===

* (alta) Misurare il numero di campioni per chiamata a varie frequenze.
* (alta) Fare in modo che non vengano segnalati gli errori di pipe piena relativi a quando non si sta registrando. Suggerimento: far mandare dal modulo sorgente sulla pipe ogni cambiamento di stato (registro/non registro); il plugin quindi aggiornerà lo stato internamento e lo userà per segnalare solo gli errori rilevanti.
* (alta) Fare in modo che '''trigger.txt''' e '''triggerData.txt''' vengano scritti solo se sia definita una costante specifica per quello (non quella generica di debug); non definire la costante.
* (media) Script per il confronto tra dati registrati da BCI2000 e da Galileo; si lancia passandogli il nome dei due file e una soglia, e restituisce un valore binario per dire se sono uguali (all'interno della soglia) oppure no; eventualmente disegna qualche grafico.

=== Fatto ===

* Eliminare la finestra del plugin, e salvare eventuali tempi (istanti) di perdite di dati (pipe piena) su file e alla fine della registrazione avvisare l'utente se ci sono state perdite. Il file verrà cancellato se non contiene errori. Nessun file di log va sovrascritto.
:Per come è fatto il sistema, è inevitabile che la pipe si riempia prima dell'inizio della registrazione vera e propria. Questo periodo non va segnalato né salvato su file (andrà ideato un opportuno sistema per identificarlo).

==Modulo di elaborazione del segnale 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:

#filtro spaziale
#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.
#*PARAMETRI DEFINITI:
#**WindowSize = definisce la dimensione della finestra mobile utilizzata per filtrare il segnale
#**TriggerChannel = definisce il numero del segnale sul quale identificare i trigger
#*STATI DEFINITI:
#**TriggerFound = posto a 1 se il filtro identifica nel blocco analizzato l'inizio di una stimolazione
#**TriggerIndex = se TriggerFound è posto a 1, questo stato contiene indice del campione nel blocco analizzato che ha determinato l'inizio dello stimolo.
#**Riferimento su Airbat del sorgente filtro Trigger: sgarlata/P3ErrPSignalProcessingGalileo/TriggerFilterAutoThreshold
#filtro butterworth passa banda con banda passante definibile tramite l'impostazione di appositi parametri (default banda passante 5Hz-10Hz, dato che i potenziali evocati hanno un andamento lento nel tempo). L'output di questo filtro è utilizzato in fase di riconoscimento dell'ErrP.
#*PARAMETRI DEFINITI:
#**ButterworthBPLowCorner = definisce il valore di banda passante minimo
#**ButterworthBPHighCorner = definisce il valore di banda passante massimo
#**Riferimento su Airbat del sorgente filtro ButterworthBP: sgarlata/P3ErrPSignalProcessingGalileo/ButterworthBP
#un filtro che si occupa solamente di accumulare le forme d'onda con un ring buffer che memorizza una porzione di segnale precedente.
#*PARAMETRI DEFINITI:
#**EpochLength = lunghezza in secondi dell'epoca da accumulare
#**LengthBeforeStimulus = lunghezza in secondi della porzione di segnale da accumulare prima dell'inizio di una stimolazione
#**VisualizeCollectorFiltering = se settato questo parametro consente di visualizzare l'intera epoca accumulata
#*STATI DEFINITI:
#**StimulusCodeDone = il codice dello stimolo la cui relativa epoca è stata interamente accumulata
#**StimulusTypeDone = il tipo relativo all'epoca appena accumulata
#*Riferimento su Airbat del sorgente filtro Collector: sgarlata/P3ErrPSignalProcessingGalileo/CollectorFilterGALILEO
#filtro di classificazione per P300 ed ErrP.
Per la classificazione P300 attualmente è implementato il classificatore lineare "Logistic", mentre per la classificazione ErrP è implementato un classificatore LDA.
#*PARAMETRI DEFINITI:
#**ClassifierFunction = identifica la funzione di classificazione P300 da utilizzare (attualmente è solamente implementato il classificatore Logistic)
#**P3WeightMatrix = matrice in cui ogni colonna indica un canale e il numero di righe è pari al numero di campioni dell'epoca in ingresso aumentato di 1 . La prima riga di ogni colonna indica il canale sul quale applicare i pesi definiti nelle righe successive.
#**P3Constant = costante utilizzata dal classificatore P300 Logistic
#**ErrPSamplesIndex = matrice in cui per ogni riga è indicato nella prima colonna il canale segiuto dall'indice dei campioni da prelevare dal segnale d'ingresso
#**ErrpClassifS, ErrpClassifMm, ErrpClassifMsT, ErrpClassifC = matrici utilizzate dal classificatore ErrP
#*STATI DEFINITI:
#**ErrPFound = questo stato è posto a 0 durante il calcolo dell'ErrP, terminato il calcolo se viene identificato un ErrP questo stato è posto a 1 altrimenti è posto a 2.
#*Riferimento su Airbat del sorgente filtro Collector: sgarlata/P3ErrPSignalProcessingGalileo/P3ErrPClassifier
#filtro che effettua la media dei valori in uscita dal filtro di classificazione
#*PARAMETRI DEFINITI:
#**EpochsToAverage = il numero di classificazioni da mediare
#*STATI DEFINITI:
#**StimulusCodeRes = il codice dello stimolo del quale è stata calcolata la media di "EpochsToAverage" stimolazioni
#**StimulusTypeRes = il tipo relativo allo StimulusCodeRes appena determinato
#*Riferimento su Airbat del sorgente filtro Media: sgarlata/P3ErrPSignalProcessingGalileo/MeanFilter
#un filtro di normalizzazione

===Da Fare===

* (alta) Cambiare i nomi dei parametri del classificatore ErrP; esempio: "S" diventa "ErrpClassifS".
* (bassa) Fare un filtro FIR (c'è già una classe nel sorgente BCI2000) da usare in alternativa al filtro Butterworth. Il filtro prende come parametri il vettore di pesi. L'idea è che si genera il filtro durante l'addestramento in Matlab, e viene usato anche online. Il problema del Butterworth è che ha una fase non lineare e quindi deforma la forma d'onda.

===Fatto===

*Filtro che rileva i trigger
*Adattamento automatico della soglia per i trigger (Analisi switch riquadro: Bianco->Nero->Bianco per un tempo definito dall'utente)
*Accumulare forme d'onda con parti che precedono il trigger
*Script Matlab per verificare l'accuratezza della rilevazione dei fronti d'onda.
*Elencare stati e parametri usati dai filtri, e documentare quelli nuovi.
*Il classificatore per P300 usi questa formula:
<math>L_{\rm P300} = \frac{1}{1 + exp( c + \sum_i w_i x_i )}</math>
dove <math>x_i</math> sono i campioni EEG di tutti i canali, mentre ''c'' e <math>w_i</math> sono dei pesi oppurtuni.
I <math>w_i</math> saranno organizzati in una matrice bidimensionale, in cui ogni riga contiene: il numero del canale, seguito da tutti i pesi per quel canale. Poi con un ulteriore parametro si potrà selezionare una funzione alternativa alla logistica.

==Modulo applicativo speller P300==

*Riferimento su Airbat del sorgente modulo Applicativo: sgarlata/P3Speller

Il modulo applicativo deve essere 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.
Alla fine di ogni treno di stimolazioni lo speller P300 determina, in base alle classificazioni ricevute, qual'è la stimolazione con classificazione maggiore mostrandola a video. A questo punto inizia una nuova fase in cui viene controllata la presenza dell'ErrP, se è stato identificato una forma d'onda ErrP lo speller non effettua alcuna selezione (modalità "free mode") altrimenti seleziona la stimolazione mostrata a video precedentemente, riprendendo con una nuova 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.

===Da fare===

* (alta) Misurare lo sfasamento tra sync e stimolo
* (media) Segnalare (e recuperare, se possibile) eventuali problemi con la sincronizzazione tra stimolazione e trigger. Alla fine di ogni treno di stimolazioni, verificare che il numero di trigger e di stimolazioni siano uguali. Gli stati devono fornire abbastanza informazioni perché si possa caricare da file una registrazione "rovinata" ignorando (tutto e solo) il treno di stimolazioni fuori sincronia.
:Scrivere un codice di test opportuno per forzare/simulare errori nella rilevazione del trigger (non riconoscimento di un trigger o riconoscimento di un trigger spurio).
* (bassa) Scrivere specifiche per comunicazione tra BCI2000 e un modulo applicativo P300 esterno che gira su una macchina Linux separata

===Fatto===

* Modificare lo stato StimulusBegin anche per lo stimulo ErrP
* Verifica del sistema per associare la stimolazione ai trigger rilevati dall'apposito filtro

==Integrazione con ErrP==

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

Ciò che si vuole sviluppare è un sistema che si basi su una procedura di verifica automatica tramite l'integrazione del controllo anche sui potenziali d'errore.
La verifica dell'Errp non è effettuato tramite media di più forme d'onda così come avviene con le rilevazioni della P300, ma sulla singola prova.
Infatti, dopo l'analisi delle forme d'onda P300 e la determinazione del target voluto dall'utente, si introduce una ulteriore fase in cui si mostra all'utente la probabile selezione voluta e si valuta la presenza del potenziale d'errore. Se non viene riscontrata questa forma d'onda si seleziona il target precedentemente identificato, altrimenti si ripete una nuova sequenza di stimolazioni per identificare nuovamente il target voluto.

Schema del comportamento del classificatore LDA di Gianmaria:
: c - ((x - media_tr) * scala_tr * medie_tr)
cioè
: y = c1 + x * matrice
e la classe è l'indice del valore minimo del vettore y (che è lungo 2)

===Da fare===

===Fatto===

*Introdurre una nova fase di controllo Errp nel modulo applicativo dello speller
*Introdurre un nuovo filtro nella catena dei filtri che si occupa del'accumulo dei potenziali d'errore
*Modificare opportunamente i filtri di: classificazione, media e normalizzazione per supportare il controllo dell'Errp
*Fare uno script Matlab nuovo, derivato da quelli di Gianmaria, che faccia l'addestramento su dati salvati dallo speller BCI2000 in modalità "copy" e restituisca (su file) le tabelle per il classificatore pronte per essere caricate nel modulo di BCI2000.
:Questo viene meglio diviso in diversi script: 1. Uno script che carica un file BCI2000 in una struttura eeg_p300_data; meglio se accetta gli stessi parametri di load_eeg_data_dei.m 2. Uno script che prende una struttura eeg_p300_data, calcola l'intervallo ottimo, addestra il classificatore e salva le matrici per l'uso online. 3. Uno script che usa i 2 precedenti: carica i dati da un po' di file, li concatena, e addestra il classificatore ([[User:BernardoDalSeno|BernardoDalSeno]] 17:39, 9 July 2008 (CEST))
*Far funzionare lo speller in modalità "copy": il testo viene specificato all'utente e la lettera giusta viene scelta dall'applicazione con una probabilità dell'80% (parametro), in modo da avere dati per l'addestramento sia della P300 che dell'ErrP. Negli stati va salvata l'informazione su qual è la stimolazione che contiene una P300 (questo dovrebbe esserci già per la P300) e quale contiene un ErrP.
*Assicurarsi che l'attuale classificatore ErrP faccia esattamente le stesse cose di quello usato da Gianmaria (LDA sui dati grezzi).
*Nel filtro P3ErrPClassifier: ogni riga specifica più campioni per un solo canale; più righe possono riferirsi allo stesso canale.

==Addestramento==
Il sistema per il corretto funzionamento on line richiede l'addestramento dei classificatori per il riconoscimento del potenziale P300 e del potenziale d'errore (ErrP).
L'intera sequenza di addestramento è divisa in 3 diverse 'sessioni'. Ogni 'sessione' corrisponde a una giornata, ed è suddivisa a sua volta in diversi 'run', dove per 'run' si intende un nuovo ciclo di esecuzione dell'applicativo(speller). Per ogni sessione deve essere creata una cartella con nome: 'Iniziale_nome_utenteCognomeNumero_sessione' (es. Andrea Sgarlata sessione 001: 'asgarlata001') contenente tutte le registrazioni (file .dat) effettuate nella stessa sessione.
In oltre per ogni sessione deve essere compilato un file di log (log-sessione.txt da inserire nella stessa cartella della sessione, template già precompilato nella cartella sgarlata/TestParam), con i dati dell'utente e per ogni 'run' il modo di funzionamente le impedenze registrate per ogni canale ed eventuali note per esempio livello di stanchezza e concentrazione dell'utente ecc...
Prima di iniziare l'addestramento bisogna spiegare all'utente cosa deve fare e come si deve comportare durante l'utilizzo del sistema.
La prima sessione è necessaria per l'addestramento del classificatore per il potenziale P300 ed ErrP; questa sessione è svolta in modalità copy ed è suddivisa in 10 run, i diversi run si differenziano per la parola mostrata nella barra 'textToSpell'.
Per una corretta impostazione dell'intero sistema in questa sessione, bisogna:
* avviare il sistema (Galileo + BCI2000)
* caricare il file Sgarlata/TestParam/P3ErrpSpeller-trainingSessione001.prm in BCI2000
* modificare nella scheda 'Storage' di BCI2000 il campo 'SubjectName' indicando 'Iniziale_nome_utenteCognome'
:: Assicuriamoci che non ci si possa dimenticare di fare quest'ultimo passo. 'DataDirectory' nel file parametri dovrebbe già contenere un percorso inesistente. Esiste un valore illegale per 'SubjectName'? e.g., vuoto, oppure con qualche carattere strano, oppure un nome troppo lungo... ([[User:BernardoDalSeno|BernardoDalSeno]] 15:17, 11 September 2008 (CEST))
::Infatti ho modificato il file .prm in modo che metta il carattere '?' nel campo 'SubjectName' in modo che se l'utente non lo modifica BCI2000 da errore
* Chiudere la schermata di configurazione e cliccare sul pulsante 'Set Config' di BCI2000, in modo da permettere al sistema di creare la cartella 'Iniziale_nome_utenteCognomeNumero_sessione' che conterrà tutte le registrazioni effettuate in questa sessione.
* compilare il log di sessione.

Impostato il sistema, tramite le operazioni appena elencate, non rimane che per ogni run caricare il file contenente la sola parola da inserire nella barra 'textToSpell' (file presenti nella cartella Sgarlata/TestParam/traning_words/Sessione001), quindi al primo run verrà caricato il file di parametri 'LearningRun01.prm', al secondo run il parametro 'LearningRun02.prm' e così via fin al completamento dei 10 run.
Terminata la prima sessione con i dati raccolti si procede all'addestramento del classificatore P300 tramite lo script run_ga_speller_dei.m (si veda l'help dello script per il funzionamento), questo script utilizza un'algoritmo genetico di conseguenza è consigliabile utilizzare come parametro di ingresso la creazione di almeno 10 generazioni. E' consigliabile utilizzare per l'addestramento i dati relativi ai primi 8 run, ed utilizzare gli ultimi 2 run (run 9, run 10) come dati ti test. Annotare comunque nel file di log quale insieme di dati è stato utilizzato per l'addestramento e quale per il test.
:Specifica quali run usare per addestramento e test ([[User:BernardoDalSeno|BernardoDalSeno]] 15:17, 11 September 2008 (CEST))

Se non vi sono stati errori lo script genera un file di parametri che deve essere caricato nel sistema consentendo così l'addestramendo del classificatore P300 ed il passaggio alla seconda sessione.

Nella seconda sessione si mantiene il sistema configurato come nella sessione precedente con la differenza che questa sessione è svolta in modalità copy ma con il classificatore P300 funzionante, di conseguenza il target visualizzato è quello selezionato dal classificatore P300. :Bisogna aggiustare il numero di ripetizioni per controllare gli errori, però ([[User:BernardoDalSeno|BernardoDalSeno]] 15:17, 11 September 2008 (CEST))
In questa sessione si deve:
* caricare in BCI2000 il file di parametri generato dallo script run_ga_speller_dei.m.
* caricare il file Sgarlata/TestParam/P3ErrpSpeller-trainingSessione002.prm in BCI2000
* Chiudere la schermata di configurazione e cliccare sul pulsante 'Set Config' di BCI2000.
* compilare il log di sessione.

Effettuate queste modifiche si può ripartire nuovamente con il caricare in sequenza per ogni run solamente le ulteriori 10 parole (file: 'LearningRun#.prm') definite nella cartella 'Sgarlata/TestParam/traning_words/Sessione002', indicando, nel file di log, per ogni run il numero di lettere selezionate errate.
:Questa informazione è presente nel file di log che viene generato da BCI2000 ("*_summary.txt")? Se no, possiamo aggiungerla? ([[User:BernardoDalSeno|BernardoDalSeno]] 15:17, 11 September 2008 (CEST))
:Userei altri 10 file per le parole, non vorrei far annoiare i soggetti. ([[User:BernardoDalSeno|BernardoDalSeno]] 15:17, 11 September 2008 (CEST))
Terminata la seconda sessione si può procedere all'addestramento del classificatore per il riconoscimento dei potenziali d'errore (ErrP). A questo scopo si utilizza uno script matlab che richiama la funzione 'train_errp_visconti_bci2000( params )' generando il file .prm con i parametri necessari al classificatore ErrP. Per l'addestramento dell'ErrP è consigliabile utilizzare tutti i dati registrati nelle primi due sessioni (001 e 002), suddividendo i primi 18 (10 run 001 e 8 run 002) run come dati di addestramento, e gli ultimi 2 run (19, 20) come dati di test. Annotare comunque nel file di log quale insieme di dati è stato utilizzato per l'addestramento e quale per il test. Se lo script non raggiunge una soglia di almeno 70% di recall sia per ErrP che non-ErrP bisogna procede alla registrazione di ulteriori run nella seconda sessione, oppure provare ad introdurre nuovi canali all'interno dei parametri passati e, contemporaneamente allargare la sezione temporale in cui individuare la forma d'onda ErrP.
:Specifica quali run usare per addestramento e test. Fissiamo una soglia per decidere se possiamo utilizzare gli ErrP online: direi almeno il 70% di recall sia per ErrP che non-ErrP. Hai ancora il foglio con indicato lo schema per l'addestramento? ricordo che avevo pensato di provare subito il classificatore ErrP con uno o due run di prova. ([[User:BernardoDalSeno|BernardoDalSeno]] 15:17, 11 September 2008 (CEST))
:L'insieme dei dati usati per l'addestramento va annotato. ([[User:BernardoDalSeno|BernardoDalSeno]] 03:31, 15 September 2008 (CEST))

Se non vi sono stati errori lo script genera un file di parametri che può essere caricato per addestrare questa volta il classificatore ErrP. A questo punto è possibile passare alla terza sessione.

Nella terza sessione si può effettuare una serie di run (un qualsiasi numero) in modalità free mode.
: Solo se il classificatore ErrP funziona bene, altrimenti questa è ancora una sessione di addestramento; per cui servono altre parole. ([[User:BernardoDalSeno|BernardoDalSeno]] 15:17, 11 September 2008 (CEST))
In questa sessione è necessario:
* caricare il file Sgarlata/TestParam/P3ErrpSpeller-FreeModeSession003.prm in BCI2000
* caricare in BCI2000 il file di parametri generato dallo script run_ga_speller_dei.m.
* caricare in BCI2000 il file di parametri generato dallo script train_errp_visconti_bci2000.m
* Chiudere la schermata di configurazione e cliccare sul pulsante 'Set Config' di BCI2000, in modo da permettere al sistema di creare la cartella 'Iniziale_nome_utenteCognomeNumero_sessione' che conterrà tutte le registrazioni effettuate in questa sessione.
* compilare il log di sessione.

L'utente decide quale parola, lettera per lettera, vuole scrivere, e nel caso in cui il sistema scrive un carattere errato l'utente dovrà eliminarlo selezionando l'icona 'BS' che si occupa di cancellare l'ultima lettera inserita. La parola (o frase) che l'utente ha scelto va segnata sul file di log insieme a tutte le informazioni che si ritengono necessarie.

===Da fare===
* (altissima) Scrivere una funzione definita tra in <math>[0,1]</math> parametrica che valga: 1 in 0 e 1; <math>1-\epsilon</math> in ''a'' e ''c'', 0 in ''b''. <math>\epsilon</math> è un parametro.
* (alta) Fare un file di parametri per addestrare la gente per P300 e ErrP (modalità copy).
* (alta) Fare N (con N oppurtuno) file di parametri che contengano le parole da scrivere; considerare lunghezza oppurtuna per singole registrazioni e sessioni. Il file e il nome del file contenga già il numero di sessione e registrazione.
* (alta) Aggiustare il protocollo per gli esperimenti secondo i commenti. Fare delle mini-procedure - come per la prima sessione - anche per i run delle sessioni successive.
* (media) Lo speller in modalità copy quando genera dei feedback sbagliati (per l'addestramento ErrP) deve selezionare effettivamente un simbolo sbagliato a caso tra tutti i simboli disponibili, e non usare il classificatore P300 per questo.
* (bassa) Far funzionare lo speller in modalità "mista", cioè: la stringa da scrivere è assegnata; il classificatore P300 viene usato per selezionare le lettere; in caso di lettera sbagliata viene scritta la lettera selezionata, e il simbolo successivo da selezionare sarà BackSpace. Perché questa cosa funzioni, il tasso di errori deve essere contenuto entro un certo intervallo, definito da 3 valori (''a'',''b'',''c'') in un opportuno parametro (si potrebbe riutilizzare il parametro attualmente usato per il tasso di errori nella stimolazione ErrP); operativamente:
# Selezionare una lettere con il classificatore P300
# Calcolare la statistica ''s'' delle selezioni correte sulle ultime N selezioni
# Si ricava una probabilità ''p'' a partire dall'entità della deviazione dall'intervallo ammesso, usando un'opportuna funzione che dipende da ''a'', ''b'', ''c'', ''s''.
# Con probabilità ''p'' modificare la selezione in questo modo:
#* Se ''s'' < ''b'', la selezione corrente viene corretta, se è sbagliata
#* Se ''s'' > ''b'', la selezione corrente viene fatta diventare sbagliate, se è corretta
:Il risultato dovrebbe essere che la statistica sia quasi sempre all'interno dell'intervallo ''a''-''c'', e che i valori fuori dall'intervallo non si allontanino troppo dai limiti fissati.
:Suggerimento: Per questa cosa, fare una classe (e usare un'istanza) in cui ci sia un metodo per aggiornare la statistica e uno per dire se bisogna fare correzioni all'ultima selezione.
* (bassissima) Fare esperimenti con almeno un paio di soggetto in cui lo speller funziona nella modalità "mista" di cui sopra.
:Per scegliere il numero di ripetizioni ottimo, bisogna valutare l'accuratezza del classificatore P300 con diversi numeri di ripetizioni (offline sui dati di test) e da questa, insieme all'accuratezza del classificatore ErrP, calcolare la velocità globale dell'interfaccia usando la formula che c'è nella tesi di Bernardo Dal Seno.

==Varie==
Le priorità indicate per le varie attività servono per fissare un'ordine. La tesi si conclude quando tutte le attività sono complete.

Talk:Online P300 and ErrP recognition with BCI2000

2008-09-17T08:10:03Z

AndreaSgarlata: /* Modulo di elaborazione del segnale BCI2000 */

==Plugin Galileo/Modulo sorgente BCI2000==
*Riferimento su Airbat del sorgente modulo Plugin: sgarlata/Plugin

*Riferimento su Airbat del sorgente modulo sorgente BCI2000: sgarlata/GalileoSource

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, tenendo conto del fatto che durante l'esecuzione di una registrazione online la quantità di dati ricevuti dal plugin risulta molto regolare e costante.
In questo modo ogni invio di dati tramite pipe rappresenta il trascorrere di un tempo prefissato che risulta pari a 1/16 di secondo.

Sono stati effettuati diversi test (aggiunta di un buffer di accumulo, invio di blocchi di dimensione maggiore 0.1 secondi) per cercare di mantenere il più possibile costante l'intervallo che trascorre tra l'invio di un blocco dati e quello successivo, nonostante questi tentativi abbiamo riscontrato il fatto che l'intervallo tra due blocchi risulta in media molto regolare, questa regolarità viene persa però nei momenti in cui il sistema viene perturbato da fattori esterni dovuti all'intervento dell'utente, quali ad esempio: apertura nuova finestra, spostamento finestre, apertura cartelle ecc...
Tutti questi fattori possono essere trascurati, in quanto durante l'esecuzione dell'intero sistema l'utente non deve interagire direttamente con il sistema, ma deve solamente essere sottoposto a delle stimolazioni, e se l'utente decide di interagire è perché sta effettuando modifiche ed in quel momento non necessita di un sistema sincrono e regolare.
:Noi speriamo che non capiti durante il funzionamento normale o sia molto raro ([[User:BernardoDalSeno|BernardoDalSeno]] 20:21, 24 May 2008 (CEST))

Per tutte queste motivazioni si è deciso che il plugin non appena accumulato un blocco dati pari a 1/16 di secondo deve subito inviarlo tramite pipe, in modo da mantenere una regolarità tra l'invio consecutivo di due blocchi.

Nel sever Airbat sono presenti i sorgenti dei differenti plugin implementati con le differenti stategie di funzionamento:

*Cartella sgarlata/old/PluginPipe: il plugin implementato consente un invio di dati in blocchi di 0.1secondi, consentendo al modulo sorgente di BCI2000 di occuparsi dell'invio di blocchi dati di dimensioni inferiori all'interno del sistema di BCI2000. Questa strategia è stata abbandonata perchè abbiamo notato che a 512Hz il plugin riceveva blocchi di 32 campioni per ogni chiamata, e doveva inviare blocchi di 51 campioni, questa differenza faceva si che l'invio di blocchi non era regolare in quanto ad esempio dopo due chiamate inviavo un blocco da 51 campioni e poi dovevo aspettare 3 chiamate per inviare un nuovo blocco dati.

*Cartella sgarlata/old/PluginBuffer: il plugin implementato mantiene un buffer di N blocchi dati pari a 1/16 di secondo, ed inizia l'invio di un blocco dati nel momento in cui mezzo buffer è stato riempito, utilizzando come clock di invio l'orologio di invocazione del plugin, dato che in maniera molto regolare vi era un invocazione ogni 1/16 di secondo a 512Hz. La strategia dell'utilizzo del buffer è stata abbandonata in quanto, si introduceva ritardo con il buffer ed in oltre i problemi di perdita di regolarità si verificavano comunque perchè non erano dovuti a dei mancati invii di dati da parte del plugin,ma erano dovuti al fatto che il sistema veniva perturbato da un utente esterno ed il modulo sorgente di BCI2000 attendeva nella lettura di un nuovo blocco.

*Cartella sgarlata/old/PluginTemporizzato: questo plugin utilizza un blocco dati pari a 1/16 di secondo, ma diversamente dal plugin finale manca della stampa di diversi valori di debug e della possibilità di connessione con il sistema di BCI2000 non sincrona.

Le diverse strategie di sviluppo del plugin sono state studiate ed implementate per poter utilizzare un applicativo di stimolazione che rimanesse sincrono con l'intero sistema e quindi che avesse la possibilità di essere implementato da un modulo applicativo di BCI2000.
Uno stimolatore sincrono è un vantaggio in quanto consente di farlo evolvere durante l'acquisizione dei segnali e di effettuare diverse scelte sulla base di questi e dei risultati fin ora ottenuti.

Per quanto riguarda il modulo sorgente di BCI2000 questo si occupa di leggere dalla pipe: il numero di canali, il numero di campioni per canale e la frequenza di campionamento. Una volta letti questi valori controlla che l'utente abbia inserito tra i parametri gli stessi valori letti tramite pipe, se questo non avviene blocca l'intero sistema e comunica l'errore all'utente con i valori esatti da inserire. Questa procedura viene ripetuta finché l'utente non inserisce gli stessi parametri letti dal modulo source. Si è visto che invece non si riesce a passare i parametri dal modulo sorgente agli altri moduli di BCI2000 durante la fase di inizializzazione.

A run time il modulo source si occupa di leggere dalla pipe una blocco di dati e di inviarlo al modulo successivo (modulo filtro); ogni blocco viene inoltrato non appena è disponibile.

===Da fare===

* (alta) Misurare il numero di campioni per chiamata a varie frequenze.
* (alta) Fare in modo che non vengano segnalati gli errori di pipe piena relativi a quando non si sta registrando. Suggerimento: far mandare dal modulo sorgente sulla pipe ogni cambiamento di stato (registro/non registro); il plugin quindi aggiornerà lo stato internamento e lo userà per segnalare solo gli errori rilevanti.
* (alta) Fare in modo che '''trigger.txt''' e '''triggerData.txt''' vengano scritti solo se sia definita una costante specifica per quello (non quella generica di debug); non definire la costante.
* (media) Script per il confronto tra dati registrati da BCI2000 e da Galileo; si lancia passandogli il nome dei due file e una soglia, e restituisce un valore binario per dire se sono uguali (all'interno della soglia) oppure no; eventualmente disegna qualche grafico.

=== Fatto ===

* Eliminare la finestra del plugin, e salvare eventuali tempi (istanti) di perdite di dati (pipe piena) su file e alla fine della registrazione avvisare l'utente se ci sono state perdite. Il file verrà cancellato se non contiene errori. Nessun file di log va sovrascritto.
:Per come è fatto il sistema, è inevitabile che la pipe si riempia prima dell'inizio della registrazione vera e propria. Questo periodo non va segnalato né salvato su file (andrà ideato un opportuno sistema per identificarlo).

==Modulo di elaborazione del segnale 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:

#filtro spaziale
#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.
#*PARAMETRI DEFINITI:
#**WindowSize = definisce la dimensione della finestra mobile utilizzata per filtrare il segnale
#**TriggerChannel = definisce il numero del segnale sul quale identificare i trigger
#*STATI DEFINITI:
#**TriggerFound = posto a 1 se il filtro identifica nel blocco analizzato l'inizio di una stimolazione
#**TriggerIndex = se TriggerFound è posto a 1, questo stato contiene indice del campione nel blocco analizzato che ha determinato l'inizio dello stimolo.
#**Riferimento su Airbat del sorgente filtro Trigger: sgarlata/P3ErrPSignalProcessingGalileo/TriggerFilterAutoThreshold
#filtro butterworth passa banda con banda passante definibile tramite l'impostazione di appositi parametri (default banda passante 5Hz-10Hz, dato che i potenziali evocati hanno un andamento lento nel tempo). L'output di questo filtro è utilizzato in fase di riconoscimento dell'ErrP.
#*PARAMETRI DEFINITI:
#**ButterworthBPLowCorner = definisce il valore di banda passante minimo
#**ButterworthBPHighCorner = definisce il valore di banda passante massimo
#**Riferimento su Airbat del sorgente filtro ButterworthBP: sgarlata/P3ErrPSignalProcessingGalileo/ButterworthBP
#un filtro che si occupa solamente di accumulare le forme d'onda con un ring buffer che memorizza una porzione di segnale precedente.
#*PARAMETRI DEFINITI:
#**EpochLength = lunghezza in secondi dell'epoca da accumulare
#**LengthBeforeStimulus = lunghezza in secondi della porzione di segnale da accumulare prima dell'inizio di una stimolazione
#**VisualizeCollectorFiltering = se settato questo parametro consente di visualizzare l'intera epoca accumulata
#*STATI DEFINITI:
#**StimulusCodeDone = il codice dello stimolo la cui relativa epoca è stata interamente accumulata
#**StimulusTypeDone = il tipo relativo all'epoca appena accumulata
#*Riferimento su Airbat del sorgente filtro Collector: sgarlata/P3ErrPSignalProcessingGalileo/CollectorFilterGALILEO
#filtro di classificazione per P300 ed ErrP.
Per la classificazione P300 attualmente è implementato il classificatore lineare "Logistic", mentre per la classificazione ErrP è implementato un classificatore LDA.
#*PARAMETRI DEFINITI:
#**ClassifierFunction = identifica la funzione di classificazione P300 da utilizzare (attualmente è solamente implementato il classificatore Logistic)
#**P3WeightMatrix = matrice in cui ogni colonna indica un canale e il numero di righe è pari al numero di campioni dell'epoca in ingresso aumentato di 1 . La prima riga di ogni colonna indica il canale sul quale applicare i pesi definiti nelle righe successive.
#**P3Constant = costante utilizzata dal classificatore P300 Logistic
#**ErrPSamplesIndex = matrice in cui per ogni riga è indicato nella prima colonna il canale segiuto dall'indice dei campioni da prelevare dal segnale d'ingresso
#**ErrpClassifS, ErrpClassifMm, ErrpClassifMsT, ErrpClassifC = matrici utilizzate dal classificatore ErrP
#*STATI DEFINITI:
#**ErrPFound = questo stato è posto a 0 durante il calcolo dell'ErrP, terminato il calcolo se viene identificato un ErrP questo stato è posto a 1 altrimenti è posto a 2.
#*Riferimento su Airbat del sorgente filtro Collector: sgarlata/P3ErrPSignalProcessingGalileo/P3ErrPClassifier
#filtro che effettua la media dei valori in uscita dal filtro di classificazione
#*PARAMETRI DEFINITI:
#**EpochsToAverage = il numero di classificazioni da mediare
#*STATI DEFINITI:
#**StimulusCodeRes = il codice dello stimolo del quale è stata calcolata la media di "EpochsToAverage" stimolazioni
#**StimulusTypeRes = il tipo relativo allo StimulusCodeRes appena determinato
#*Riferimento su Airbat del sorgente filtro Media: sgarlata/P3ErrPSignalProcessingGalileo/MeanFilter
#un filtro di normalizzazione

===Da Fare===

* (alta) Cambiare i nomi dei parametri del classificatore ErrP; esempio: "S" diventa "ErrpClassifS".
* (bassa) Fare un filtro FIR (c'è già una classe nel sorgente BCI2000) da usare in alternativa al filtro Butterworth. Il filtro prende come parametri il vettore di pesi. L'idea è che si genera il filtro durante l'addestramento in Matlab, e viene usato anche online. Il problema del Butterworth è che ha una fase non lineare e quindi deforma la forma d'onda.

===Fatto===

*Filtro che rileva i trigger
*Adattamento automatico della soglia per i trigger (Analisi switch riquadro: Bianco->Nero->Bianco per un tempo definito dall'utente)
*Accumulare forme d'onda con parti che precedono il trigger
*Script Matlab per verificare l'accuratezza della rilevazione dei fronti d'onda.
*Elencare stati e parametri usati dai filtri, e documentare quelli nuovi.
*Il classificatore per P300 usi questa formula:
<math>L_{\rm P300} = \frac{1}{1 + exp( c + \sum_i w_i x_i )}</math>
dove <math>x_i</math> sono i campioni EEG di tutti i canali, mentre ''c'' e <math>w_i</math> sono dei pesi oppurtuni.
I <math>w_i</math> saranno organizzati in una matrice bidimensionale, in cui ogni riga contiene: il numero del canale, seguito da tutti i pesi per quel canale. Poi con un ulteriore parametro si potrà selezionare una funzione alternativa alla logistica.

==Modulo applicativo speller P300==

*Riferimento su Airbat del sorgente modulo Applicativo: sgarlata/P3Speller

Il modulo applicativo deve essere 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.
Alla fine di ogni treno di stimolazioni lo speller P300 determina, in base alle classificazioni ricevute, qual'è la stimolazione con classificazione maggiore mostrandola a video. A questo punto inizia una nuova fase in cui viene controllata la presenza dell'ErrP, se è stato identificato una forma d'onda ErrP lo speller non effettua alcuna selezione (modalità "free mode") altrimenti seleziona la stimolazione mostrata a video precedentemente, riprendendo con una nuova 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.

===Da fare===

* (alta) Misurare lo sfasamento tra sync e stimolo
* (media) Segnalare (e recuperare, se possibile) eventuali problemi con la sincronizzazione tra stimolazione e trigger. Alla fine di ogni treno di stimolazioni, verificare che il numero di trigger e di stimolazioni siano uguali. Gli stati devono fornire abbastanza informazioni perché si possa caricare da file una registrazione "rovinata" ignorando (tutto e solo) il treno di stimolazioni fuori sincronia.
:Scrivere un codice di test opportuno per forzare/simulare errori nella rilevazione del trigger (non riconoscimento di un trigger o riconoscimento di un trigger spurio).
* (bassa) Scrivere specifiche per comunicazione tra BCI2000 e un modulo applicativo P300 esterno che gira su una macchina Linux separata

===Fatto===

* Modificare lo stato StimulusBegin anche per lo stimulo ErrP
* Verifica del sistema per associare la stimolazione ai trigger rilevati dall'apposito filtro

==Integrazione con ErrP==

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

Ciò che si vuole sviluppare è un sistema che si basi su una procedura di verifica automatica tramite l'integrazione del controllo anche sui potenziali d'errore.
La verifica dell'Errp non è effettuato tramite media di più forme d'onda così come avviene con le rilevazioni della P300, ma sulla singola prova.
Infatti, dopo l'analisi delle forme d'onda P300 e la determinazione del target voluto dall'utente, si introduce una ulteriore fase in cui si mostra all'utente la probabile selezione voluta e si valuta la presenza del potenziale d'errore. Se non viene riscontrata questa forma d'onda si seleziona il target precedentemente identificato, altrimenti si ripete una nuova sequenza di stimolazioni per identificare nuovamente il target voluto.

Schema del comportamento del classificatore LDA di Gianmaria:
: c - ((x - media_tr) * scala_tr * medie_tr)
cioè
: y = c1 + x * matrice
e la classe è l'indice del valore minimo del vettore y (che è lungo 2)

===Da fare===

===Fatto===

*Introdurre una nova fase di controllo Errp nel modulo applicativo dello speller
*Introdurre un nuovo filtro nella catena dei filtri che si occupa del'accumulo dei potenziali d'errore
*Modificare opportunamente i filtri di: classificazione, media e normalizzazione per supportare il controllo dell'Errp
*Fare uno script Matlab nuovo, derivato da quelli di Gianmaria, che faccia l'addestramento su dati salvati dallo speller BCI2000 in modalità "copy" e restituisca (su file) le tabelle per il classificatore pronte per essere caricate nel modulo di BCI2000.
:Questo viene meglio diviso in diversi script: 1. Uno script che carica un file BCI2000 in una struttura eeg_p300_data; meglio se accetta gli stessi parametri di load_eeg_data_dei.m 2. Uno script che prende una struttura eeg_p300_data, calcola l'intervallo ottimo, addestra il classificatore e salva le matrici per l'uso online. 3. Uno script che usa i 2 precedenti: carica i dati da un po' di file, li concatena, e addestra il classificatore ([[User:BernardoDalSeno|BernardoDalSeno]] 17:39, 9 July 2008 (CEST))
*Far funzionare lo speller in modalità "copy": il testo viene specificato all'utente e la lettera giusta viene scelta dall'applicazione con una probabilità dell'80% (parametro), in modo da avere dati per l'addestramento sia della P300 che dell'ErrP. Negli stati va salvata l'informazione su qual è la stimolazione che contiene una P300 (questo dovrebbe esserci già per la P300) e quale contiene un ErrP.
*Assicurarsi che l'attuale classificatore ErrP faccia esattamente le stesse cose di quello usato da Gianmaria (LDA sui dati grezzi).
*Nel filtro P3ErrPClassifier: ogni riga specifica più campioni per un solo canale; più righe possono riferirsi allo stesso canale.

==Addestramento==
Il sistema per il corretto funzionamento on line richiede l'addestramento dei classificatori per il riconoscimento del potenziale P300 e del potenziale d'errore (ErrP).
L'intera sequenza di addestramento è divisa in 3 diverse 'sessioni'. Ogni 'sessione' corrisponde a una giornata, ed è suddivisa a sua volta in diversi 'run', dove per 'run' si intende un nuovo ciclo di esecuzione dell'applicativo(speller). Per ogni sessione deve essere creata una cartella con nome: 'Iniziale_nome_utenteCognomeNumero_sessione' (es. Andrea Sgarlata sessione 001: 'asgarlata001') contenente tutte le registrazioni (file .dat) effettuate nella stessa sessione.
In oltre per ogni sessione deve essere compilato un file di log (log-sessione.txt da inserire nella stessa cartella della sessione, template già precompilato nella cartella sgarlata/TestParam), con i dati dell'utente e per ogni 'run' il modo di funzionamente le impedenze registrate per ogni canale ed eventuali note per esempio livello di stanchezza e concentrazione dell'utente ecc...
Prima di iniziare l'addestramento bisogna spiegare all'utente cosa deve fare e come si deve comportare durante l'utilizzo del sistema.
La prima sessione è necessaria per l'addestramento del classificatore per il potenziale P300 ed ErrP; questa sessione è svolta in modalità copy ed è suddivisa in 10 run, i diversi run si differenziano per la parola mostrata nella barra 'textToSpell'.
Per una corretta impostazione dell'intero sistema in questa sessione, bisogna:
* creare la cartella (es: 'asgarlata001').
* compilare il log di sessione.
* avviare il sistema (Galileo + BCI2000)
* caricare il file Sgarlata/TestParam/P3ErrpSpeller-training.prm in BCI2000
* modificare nella scheda 'Storage' di BCI2000 il campo 'DataDirectory' indicando la cartella della sessione appena generata ed il campo 'SubjectName' indicando 'Iniziale_nome_utenteCognome'
:: Assicuriamoci che non ci si possa dimenticare di fare quest'ultimo passo. 'DataDirectory' nel file parametri dovrebbe già contenere un percorso inesistente. Esiste un valore illegale per 'SubjectName'? e.g., vuoto, oppure con qualche carattere strano, oppure un nome troppo lungo... ([[User:BernardoDalSeno|BernardoDalSeno]] 15:17, 11 September 2008 (CEST))

Impostato il sistema, tramite le operazioni appena elencate, non rimane che per ogni run caricare il file contenente la sola parola da inserire nella barra 'textToSpell' (file presenti nella cartella Sgarlata/TestParam/traning_words), quindi al primo run verrà caricato il file di parametri 'LearningSession1.prm', al secondo run il parametro 'LearningSession1.prm' e così via fin al completamento dei 10 run.
Terminata la prima sessione con i dati raccolti si procede all'addestramento del classificatore P300 tramite lo script run_ga_speller_dei.m (si veda l'help dello script per il funzionamento), questo script utilizza un'algoritmo genetico di conseguenza è consigliabile utilizzare come parametro di ingresso la creazione di almeno 10 generazioni.
:Specifica quali run usare per addestramento e test ([[User:BernardoDalSeno|BernardoDalSeno]] 15:17, 11 September 2008 (CEST))

Se non vi sono stati errori lo script genera un file di parametri che deve essere caricato nel sistema consentendo così l'addestramendo del classificatore P300 ed il passaggio alla seconda sessione.

Nella seconda sessione si mantiene il sistema configurato come nella sessione precedente con la differenza che questa sessione è svolta in modalità copy ma con il classificatore P300 funzionante.
:Bisogna aggiustare il numero di ripetizioni per controllare gli errori, però ([[User:BernardoDalSeno|BernardoDalSeno]] 15:17, 11 September 2008 (CEST))
Quindi, si procede a creare una nuova cartella per la sessione 002, si modifica il campo 'DataDirectory' e nella scheda 'Application' deve essere posto il campo 'RightSelectionProbabiliity' uguale a 0, in questo modo il target visualizzato è quello che è stato selezionato dal classificatore P300.
:Facciamo invece un file di parametri per la seconda sessione che contiene già questa impostazione; è più semplice.
Effettuate queste modifiche si può ripartire nuovamente con il caricare in sequenza per ogni run solamente le 10 parole definite nei parametri 'LearningSession#.prm', indicando, nel file di log, per ogni run il numero di lettere selezionate errate.
:Questa informazione è presente nel file di log che viene generato da BCI2000 ("*_summary.txt")? Se no, possiamo aggiungerla? ([[User:BernardoDalSeno|BernardoDalSeno]] 15:17, 11 September 2008 (CEST))
:Userei altri 10 file per le parole, non vorrei far annoiare i soggetti. ([[User:BernardoDalSeno|BernardoDalSeno]] 15:17, 11 September 2008 (CEST))
Terminata la seconda sessione si può procedere all'addestramento del classificatore per il riconoscimento dei potenziali d'errore (ErrP). A questo scopo si utilizza uno script matlab che richiama la funzione 'train_errp_visconti_bci2000( params )' generando il file .prm con i parametri necessari al classificatore ErrP. Se lo script non è in grado di identificare una sezione dell'epoca in cui distinguere o meno la presenza di un potenziale d'errore bisogna procede alla registrazione di ulteriori run oppure provare ad introdurre nuovi canali, all'interno dei parametri passati, e ad allargare la sezione temporale in cui individuare la forma d'onda ErrP.
:Specifica quali run usare per addestramento e test. Fissiamo una soglia per decidere se possiamo utilizzare gli ErrP online: direi almeno il 70% di recall sia per ErrP che non-ErrP. Hai ancora il foglio con indicato lo schema per l'addestramento? ricordo che avevo pensato di provare subito il classificatore ErrP con uno o due run di prova. ([[User:BernardoDalSeno|BernardoDalSeno]] 15:17, 11 September 2008 (CEST))
:L'insieme dei dati usati per l'addestramento va annotato. ([[User:BernardoDalSeno|BernardoDalSeno]] 03:31, 15 September 2008 (CEST))

Se non vi sono stati errori lo script genera un file di parametri che può essere caricato per addestrare questa volta il classificatore ErrP. A questo punto è possibile passare alla terza sessione.

Nella terza sessione si può effettuare una serie di run (un qualsiasi numero) in modalità free mode.
: Solo se il classificatore ErrP funziona bene, altrimenti questa è ancora una sessione di addestramento; per cui servono altre parole. ([[User:BernardoDalSeno|BernardoDalSeno]] 15:17, 11 September 2008 (CEST))
L'utente decide quale parola, lettera per lettera, vuole scrivere, e nel caso in cui il sistema scrive un carattere errato l'utente dovrà eliminarlo selezionando l'icona 'BS' che si occupa di cancellare l'ultima lettera inserita. La parola (o frase) che l'utente ha scelto fa segnata sul file di log.
Anche in questa sessione è necessario creare una nuova cartella con identificativo sessione 003, modificare il campo 'DataDirectory' e nella cartella 'Application' bisogna impostare il campo 'InterpretMode' con il valore 'online free mode'. Naturalmente in fase è nuovamente necessario compilare il file di log introducendo tutte le informazioni necessarie.

===Da fare===
* (altissima) Scrivere una funzione definita tra in <math>[0,1]</math> parametrica che valga: 1 in 0 e 1; <math>1-\epsilon</math> in ''a'' e ''c'', 0 in ''b''. <math>\epsilon</math> è un parametro.
* (alta) Fare un file di parametri per addestrare la gente per P300 e ErrP (modalità copy).
* (alta) Fare N (con N oppurtuno) file di parametri che contengano le parole da scrivere; considerare lunghezza oppurtuna per singole registrazioni e sessioni. Il file e il nome del file contenga già il numero di sessione e registrazione.
* (alta) Aggiustare il protocollo per gli esperimenti secondo i commenti. Fare delle mini-procedure - come per la prima sessione - anche per i run delle sessioni successive.
* (media) Lo speller in modalità copy quando genera dei feedback sbagliati (per l'addestramento ErrP) deve selezionare effettivamente un simbolo sbagliato a caso tra tutti i simboli disponibili, e non usare il classificatore P300 per questo.
* (bassa) Far funzionare lo speller in modalità "mista", cioè: la stringa da scrivere è assegnata; il classificatore P300 viene usato per selezionare le lettere; in caso di lettera sbagliata viene scritta la lettera selezionata, e il simbolo successivo da selezionare sarà BackSpace. Perché questa cosa funzioni, il tasso di errori deve essere contenuto entro un certo intervallo, definito da 3 valori (''a'',''b'',''c'') in un opportuno parametro (si potrebbe riutilizzare il parametro attualmente usato per il tasso di errori nella stimolazione ErrP); operativamente:
# Selezionare una lettere con il classificatore P300
# Calcolare la statistica ''s'' delle selezioni correte sulle ultime N selezioni
# Si ricava una probabilità ''p'' a partire dall'entità della deviazione dall'intervallo ammesso, usando un'opportuna funzione che dipende da ''a'', ''b'', ''c'', ''s''.
# Con probabilità ''p'' modificare la selezione in questo modo:
#* Se ''s'' < ''b'', la selezione corrente viene corretta, se è sbagliata
#* Se ''s'' > ''b'', la selezione corrente viene fatta diventare sbagliate, se è corretta
:Il risultato dovrebbe essere che la statistica sia quasi sempre all'interno dell'intervallo ''a''-''c'', e che i valori fuori dall'intervallo non si allontanino troppo dai limiti fissati.
:Suggerimento: Per questa cosa, fare una classe (e usare un'istanza) in cui ci sia un metodo per aggiornare la statistica e uno per dire se bisogna fare correzioni all'ultima selezione.
* (bassissima) Fare esperimenti con almeno un paio di soggetto in cui lo speller funziona nella modalità "mista" di cui sopra.
:Per scegliere il numero di ripetizioni ottimo, bisogna valutare l'accuratezza del classificatore P300 con diversi numeri di ripetizioni (offline sui dati di test) e da questa, insieme all'accuratezza del classificatore ErrP, calcolare la velocità globale dell'interfaccia usando la formula che c'è nella tesi di Bernardo Dal Seno.

==Varie==
Le priorità indicate per le varie attività servono per fissare un'ordine. La tesi si conclude quando tutte le attività sono complete.

Talk:Online P300 and ErrP recognition with BCI2000

2008-09-11T10:02:01Z

AndreaSgarlata: /* Addestramento */

==Plugin Galileo/Modulo sorgente BCI2000==
*Riferimento su Airbat del sorgente modulo Plugin: sgarlata/Plugin

*Riferimento su Airbat del sorgente modulo sorgente BCI2000: sgarlata/GalileoSource

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, tenendo conto del fatto che durante l'esecuzione di una registrazione online la quantità di dati ricevuti dal plugin risulta molto regolare e costante.
In questo modo ogni invio di dati tramite pipe rappresenta il trascorrere di un tempo prefissato che risulta pari a 1/16 di secondo.

Sono stati effettuati diversi test (aggiunta di un buffer di accumulo, invio di blocchi di dimensione maggiore 0.1 secondi) per cercare di mantenere il più possibile costante l'intervallo che trascorre tra l'invio di un blocco dati e quello successivo, nonostante questi tentativi abbiamo riscontrato il fatto che l'intervallo tra due blocchi risulta in media molto regolare, questa regolarità viene persa però nei momenti in cui il sistema viene perturbato da fattori esterni dovuti all'intervento dell'utente, quali ad esempio: apertura nuova finestra, spostamento finestre, apertura cartelle ecc...
Tutti questi fattori possono essere trascurati, in quanto durante l'esecuzione dell'intero sistema l'utente non deve interagire direttamente con il sistema, ma deve solamente essere sottoposto a delle stimolazioni, e se l'utente decide di interagire è perché sta effettuando modifiche ed in quel momento non necessita di un sistema sincrono e regolare.
:Noi speriamo che non capiti durante il funzionamento normale o sia molto raro ([[User:BernardoDalSeno|BernardoDalSeno]] 20:21, 24 May 2008 (CEST))

Per tutte queste motivazioni si è deciso che il plugin non appena accumulato un blocco dati pari a 1/16 di secondo deve subito inviarlo tramite pipe, in modo da mantenere una regolarità tra l'invio consecutivo di due blocchi.

Nel sever Airbat sono presenti i sorgenti dei differenti plugin implementati con le differenti stategie di funzionamento:

*Cartella sgarlata/old/PluginPipe: il plugin implementato consente un invio di dati in blocchi di 0.1secondi, consentendo al modulo sorgente di BCI2000 di occuparsi dell'invio di blocchi dati di dimensioni inferiori all'interno del sistema di BCI2000. Questa strategia è stata abbandonata perchè abbiamo notato che a 512Hz il plugin riceveva blocchi di 32 campioni per ogni chiamata, e doveva inviare blocchi di 51 campioni, questa differenza faceva si che l'invio di blocchi non era regolare in quanto ad esempio dopo due chiamate inviavo un blocco da 51 campioni e poi dovevo aspettare 3 chiamate per inviare un nuovo blocco dati.

*Cartella sgarlata/old/PluginBuffer: il plugin implementato mantiene un buffer di N blocchi dati pari a 1/16 di secondo, ed inizia l'invio di un blocco dati nel momento in cui mezzo buffer è stato riempito, utilizzando come clock di invio l'orologio di invocazione del plugin, dato che in maniera molto regolare vi era un invocazione ogni 1/16 di secondo a 512Hz. La strategia dell'utilizzo del buffer è stata abbandonata in quanto, si introduceva ritardo con il buffer ed in oltre i problemi di perdita di regolarità si verificavano comunque perchè non erano dovuti a dei mancati invii di dati da parte del plugin,ma erano dovuti al fatto che il sistema veniva perturbato da un utente esterno ed il modulo sorgente di BCI2000 attendeva nella lettura di un nuovo blocco.

*Cartella sgarlata/old/PluginTemporizzato: questo plugin utilizza un blocco dati pari a 1/16 di secondo, ma diversamente dal plugin finale manca della stampa di diversi valori di debug e della possibilità di connessione con il sistema di BCI2000 non sincrona.

Le diverse strategie di sviluppo del plugin sono state studiate ed implementate per poter utilizzare un applicativo di stimolazione che rimanesse sincrono con l'intero sistema e quindi che avesse la possibilità di essere implementato da un modulo applicativo di BCI2000.
Uno stimolatore sincrono è un vantaggio in quanto consente di farlo evolvere durante l'acquisizione dei segnali e di effettuare diverse scelte sulla base di questi e dei risultati fin ora ottenuti.

Per quanto riguarda il modulo sorgente di BCI2000 questo si occupa di leggere dalla pipe: il numero di canali, il numero di campioni per canale e la frequenza di campionamento. Una volta letti questi valori controlla che l'utente abbia inserito tra i parametri gli stessi valori letti tramite pipe, se questo non avviene blocca l'intero sistema e comunica l'errore all'utente con i valori esatti da inserire. Questa procedura viene ripetuta finché l'utente non inserisce gli stessi parametri letti dal modulo source. Si è visto che invece non si riesce a passare i parametri dal modulo sorgente agli altri moduli di BCI2000 durante la fase di inizializzazione.

A run time il modulo source si occupa di leggere dalla pipe una blocco di dati e di inviarlo al modulo successivo (modulo filtro); ogni blocco viene inoltrato non appena è disponibile.

===Da fare===

* (alta) Misurare il numero di campioni per chiamata a varie frequenze.
* (alta) Fare in modo che non vengano segnalati gli errori di pipe piena relativi a quando non si sta registrando. Suggerimento: far mandare dal modulo sorgente sulla pipe ogni cambiamento di stato (registro/non registro); il plugin quindi aggiornerà lo stato internamento e lo userà per segnalare solo gli errori rilevanti.
* (alta) Fare in modo che '''trigger.txt''' e '''triggerData.txt''' vengano scritti solo se sia definita una costante specifica per quello (non quella generica di debug); non definire la costante.
* (media) Script per il confronto tra dati registrati da BCI2000 e da Galileo; si lancia passandogli il nome dei due file e una soglia, e restituisce un valore binario per dire se sono uguali (all'interno della soglia) oppure no; eventualmente disegna qualche grafico.

=== Fatto ===

* Eliminare la finestra del plugin, e salvare eventuali tempi (istanti) di perdite di dati (pipe piena) su file e alla fine della registrazione avvisare l'utente se ci sono state perdite. Il file verrà cancellato se non contiene errori. Nessun file di log va sovrascritto.
:Per come è fatto il sistema, è inevitabile che la pipe si riempia prima dell'inizio della registrazione vera e propria. Questo periodo non va segnalato né salvato su file (andrà ideato un opportuno sistema per identificarlo).

==Modulo di elaborazione del segnale 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:

#filtro spaziale
#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.
#*PARAMETRI DEFINITI:
#*WindowSize = definisce la dimensione della finestra mobile utilizzata per filtrare il segnale
#*TriggerChannel = definisce il numero del segnale sul quale identificare i trigger
#*STATI DEFINITI:
#*TriggerFound = posto a 1 se il filtro identifica nel blocco analizzato l'inizio di una stimolazione
#*TriggerIndex = se TriggerFound è posto a 1, questo stato contiene indice del campione nel blocco analizzato che ha determinato l'inizio dello stimolo.
#*Riferimento su Airbat del sorgente filtro Trigger: sgarlata/P3ErrPSignalProcessingGalileo/TriggerFilterAutoThreshold
#filtro butterworth passa banda con banda passante definibile tramite l'impostazione di appositi parametri (default banda passante 5Hz-10Hz, dato che i potenziali evocati hanno un andamento lento nel tempo). L'output di questo filtro è utilizzato in fase di riconoscimento dell'ErrP.
#*PARAMETRI DEFINITI:
#*ButterworthBPLowCorner = definisce il valore di banda passante minimo
#*ButterworthBPHighCorner = definisce il valore di banda passante massimo
#*Riferimento su Airbat del sorgente filtro ButterworthBP: sgarlata/P3ErrPSignalProcessingGalileo/ButterworthBP
#un filtro che si occupa solamente di accumulare le forme d'onda con un ring buffer che memorizza una porzione di segnale precedente.
#*PARAMETRI DEFINITI:
#*EpochLength = lunghezza in secondi dell'epoca da accumulare
#*LengthBeforeStimulus = lunghezza in secondi della porzione di segnale da accumulare prima dell'inizio di una stimolazione
#*VisualizeCollectorFiltering = se settato questo parametro consente di visualizzare l'intera epoca accumulata
#*STATI DEFINITI:
#*StimulusCodeDone = il codice dello stimolo la cui relativa epoca è stata interamente accumulata
#*StimulusTypeDone = il tipo relativo all'epoca appena accumulata
#*Riferimento su Airbat del sorgente filtro Collector: sgarlata/P3ErrPSignalProcessingGalileo/CollectorFilterGALILEO
#filtro di classificazione per P300 ed ErrP.
Per la classificazione P300 attualmente è implementato il classificatore lineare "Logistic", mentre per la classificazione ErrP è implementato un classificatore LDA.
#*PARAMETRI DEFINITI:
#*ClassifierFunction = identifica la funzione di classificazione P300 da utilizzare (attualmente è solamente implementato il classificatore Logistic)
#*P3WeightMatrix = matrice in cui ogni colonna indica un canale e il numero di righe è pari al numero di campioni dell'epoca in ingresso aumentato di 1 . La prima riga di ogni colonna indica il canale sul quale applicare i pesi definiti nelle righe successive.
#*P3Constant = costante utilizzata dal classificatore P300 Logistic
#*ErrPSamplesIndex = matrice in cui per ogni riga è indicato nella prima colonna il canale segiuto dall'indice dei campioni da prelevare dal segnale d'ingresso
#*S, Mm, MsT, C = matrici utilizzate dal classificatore ErrP
#*STATI DEFINITI:
#*ErrPFound = questo stato è posto a 0 durante il calcolo dell'ErrP, terminato il calcolo se viene identificato un ErrP questo stato è posto a 1 altrimenti è posto a 2.
#*Riferimento su Airbat del sorgente filtro Collector: sgarlata/P3ErrPSignalProcessingGalileo/P3ErrPClassifier
#filtro che effettua la media dei valori in uscita dal filtro di classificazione
#*PARAMETRI DEFINITI:
#*EpochsToAverage = il numero di classificazioni da mediare
#*STATI DEFINITI:
#*StimulusCodeRes = il codice dello stimolo del quale è stata calcolata la media di "EpochsToAverage" stimolazioni
#*StimulusTypeRes = il tipo relativo allo StimulusCodeRes appena determinato
#*Riferimento su Airbat del sorgente filtro Media: sgarlata/P3ErrPSignalProcessingGalileo/MeanFilter
#un filtro di normalizzazione

===Da Fare===

* (alta) Cambiare i nomi dei parametri del classificatore ErrP; esempio: "S" diventa "ErrpClassifS".
* (bassa) Fare un filtro FIR (c'è già una classe nel sorgente BCI2000) da usare in alternativa al filtro Butterworth. Il filtro prende come parametri il vettore di pesi. L'idea è che si genera il filtro durante l'addestramento in Matlab, e viene usato anche online. Il problema del Butterworth è che ha una fase non lineare e quindi deforma la forma d'onda.

===Fatto===

*Filtro che rileva i trigger
*Adattamento automatico della soglia per i trigger (Analisi switch riquadro: Bianco->Nero->Bianco per un tempo definito dall'utente)
*Accumulare forme d'onda con parti che precedono il trigger
*Script Matlab per verificare l'accuratezza della rilevazione dei fronti d'onda.
*Elencare stati e parametri usati dai filtri, e documentare quelli nuovi.
*Il classificatore per P300 usi questa formula:
<math>L_{\rm P300} = \frac{1}{1 + exp( c + \sum_i w_i x_i )}</math>
dove <math>x_i</math> sono i campioni EEG di tutti i canali, mentre ''c'' e <math>w_i</math> sono dei pesi oppurtuni.
I <math>w_i</math> saranno organizzati in una matrice bidimensionale, in cui ogni riga contiene: il numero del canale, seguito da tutti i pesi per quel canale. Poi con un ulteriore parametro si potrà selezionare una funzione alternativa alla logistica.

==Modulo applicativo speller P300==

*Riferimento su Airbat del sorgente modulo Applicativo: sgarlata/P3Speller

Il modulo applicativo deve essere 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.
Alla fine di ogni treno di stimolazioni lo speller P300 determina, in base alle classificazioni ricevute, qual'è la stimolazione con classificazione maggiore mostrandola a video. A questo punto inizia una nuova fase in cui viene controllata la presenza dell'ErrP, se è stato identificato una forma d'onda ErrP lo speller non effettua alcuna selezione (modalità "free mode") altrimenti seleziona la stimolazione mostrata a video precedentemente, riprendendo con una nuova 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.

===Da fare===

* (alta) Misurare lo sfasamento tra sync e stimolo
* (media) Segnalare (e recuperare, se possibile) eventuali problemi con la sincronizzazione tra stimolazione e trigger. Alla fine di ogni treno di stimolazioni, verificare che il numero di trigger e di stimolazioni siano uguali. Gli stati devono fornire abbastanza informazioni perché si possa caricare da file una registrazione "rovinata" ignorando (tutto e solo) il treno di stimolazioni fuori sincronia.
:Scrivere un codice di test opportuno per forzare/simulare errori nella rilevazione del trigger (non riconoscimento di un trigger o riconoscimento di un trigger spurio).
* (bassa) Scrivere specifiche per comunicazione tra BCI2000 e un modulo applicativo P300 esterno che gira su una macchina Linux separata

===Fatto===

* Modificare lo stato StimulusBegin anche per lo stimulo ErrP
* Verifica del sistema per associare la stimolazione ai trigger rilevati dall'apposito filtro

==Integrazione con ErrP==

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

Ciò che si vuole sviluppare è un sistema che si basi su una procedura di verifica automatica tramite l'integrazione del controllo anche sui potenziali d'errore.
La verifica dell'Errp non è effettuato tramite media di più forme d'onda così come avviene con le rilevazioni della P300, ma sulla singola prova.
Infatti, dopo l'analisi delle forme d'onda P300 e la determinazione del target voluto dall'utente, si introduce una ulteriore fase in cui si mostra all'utente la probabile selezione voluta e si valuta la presenza del potenziale d'errore. Se non viene riscontrata questa forma d'onda si seleziona il target precedentemente identificato, altrimenti si ripete una nuova sequenza di stimolazioni per identificare nuovamente il target voluto.

Schema del comportamento del classificatore LDA di Gianmaria:
: c - ((x - media_tr) * scala_tr * medie_tr)
cioè
: y = c1 + x * matrice
e la classe è l'indice del valore minimo del vettore y (che è lungo 2)

===Da fare===

===Fatto===

*Introdurre una nova fase di controllo Errp nel modulo applicativo dello speller
*Introdurre un nuovo filtro nella catena dei filtri che si occupa del'accumulo dei potenziali d'errore
*Modificare opportunamente i filtri di: classificazione, media e normalizzazione per supportare il controllo dell'Errp
*Fare uno script Matlab nuovo, derivato da quelli di Gianmaria, che faccia l'addestramento su dati salvati dallo speller BCI2000 in modalità "copy" e restituisca (su file) le tabelle per il classificatore pronte per essere caricate nel modulo di BCI2000.
:Questo viene meglio diviso in diversi script: 1. Uno script che carica un file BCI2000 in una struttura eeg_p300_data; meglio se accetta gli stessi parametri di load_eeg_data_dei.m 2. Uno script che prende una struttura eeg_p300_data, calcola l'intervallo ottimo, addestra il classificatore e salva le matrici per l'uso online. 3. Uno script che usa i 2 precedenti: carica i dati da un po' di file, li concatena, e addestra il classificatore ([[User:BernardoDalSeno|BernardoDalSeno]] 17:39, 9 July 2008 (CEST))
*Far funzionare lo speller in modalità "copy": il testo viene specificato all'utente e la lettera giusta viene scelta dall'applicazione con una probabilità dell'80% (parametro), in modo da avere dati per l'addestramento sia della P300 che dell'ErrP. Negli stati va salvata l'informazione su qual è la stimolazione che contiene una P300 (questo dovrebbe esserci già per la P300) e quale contiene un ErrP.
*Assicurarsi che l'attuale classificatore ErrP faccia esattamente le stesse cose di quello usato da Gianmaria (LDA sui dati grezzi).
*Nel filtro P3ErrPClassifier: ogni riga specifica più campioni per un solo canale; più righe possono riferirsi allo stesso canale.

==Addestramento==
Il sistema per il corretto funzionamento on line richiede l'addestramento dei classificatori per il riconoscimento del potenziale P300 e del potenziale d'errore (ErrP).
L'intera sequenza di addestramento è divisa in 3 diverse 'sessioni'. Ogni 'sessione' è suddivisa a sua volta in diversi 'run', dove per 'run' si intende un nuovo ciclo di esecuzione dell'applicativo(speller). Per ogni sessione deve essere creata una cartella con nome: 'Iniziale_nome_utenteCognomeNumero_sessione' (es. Andrea Sgarlata sessione 001: 'asgarlata001') contenente tutte le registrazioni (file .dat) effettuate nella stessa sessione.
In oltre per ogni sessione deve essere compilato un file di log (log-sessione.txt da inserire nella stessa cartella della sessione, template già precompilato nella cartella sgarlata/TestParam), con i dati dell'utente e per ogni 'run' il modo di funzionamente le impedenze registrate per ogni canale ed eventuali note per esempio livello di stanchezza e concentrazione dell'utente ecc...
Prima di iniziare l'addestramento bisogna spiegare all'utente cosa deve fare e come si deve comportare durante l'utilizzo del sistema.
La prima fase di addestramento è necessaria per l'addestramento del classificatore per il potenziale P300, questa fase è svolta in modalità copy ed è suddivisa in 10 run, i diversi run si differenziano per la parola mostrata nella barra 'textToSpell'.
Per una corretta impostazione dell'intero sistema in questa sessione, bisogna:
* creare la cartella (es: 'asgarlata001').
* compilare il log di sessione.
* avviare il sistema
* caricare il file Sgarlata/TestParam/P3ErrpSpeller-training.prm
* modificare nella scheda 'Storage' il campo 'DataDirectory' indicando la cartella appena generata della sessione ed il campo 'SubjectName' indicando 'Iniziale_nome_utenteCognome'

Impostato il sistema, tramite le operazioni appena elencate, non rimane che per ogni run caricare il file contenente la sola parola da inserire nella barra 'textToSpell' (file presenti nella cartella Sgarlata/TestParam/traning_words), quindi al primo run verrà caricato il file di parametri 'LearningSession1.prm', al secondo run il parametro 'LearningSession1.prm' e così via fin al completamento dei 10 run.
Terminata la prima fase con i dati raccolti si procede all'addestramento del classificatore P300 tramite lo script run_ga_speller_dei.m (si veda l'help dello script per il funzionamento), questo script utilizza un'algoritmo genetico di conseguenza è consigliabile utilizzare come parametro di ingresso la creazione di almeno 10 generazioni.

Se non vi sono stati errori lo script genera un file di parametri che deve essere caricato nel sistema consentendo così l'addestramendo del classificatore P300 ed il passaggio alla seconda sessione.

Nella seconda fase si mantiene il sistema configurato come nella fase precedente con la differenza che questa sessione è svolta in modalità copy ma con il classificatore P300 funzionante.
Quindi, si procede a creare una nuova cartella per la sessione 002, si modifica il campo 'DataDirectory' e nella scheda 'Application' deve essere posto il campo 'RightSelectionProbabiliity' uguale a 0, in questo modo il target visualizzato è quello che è stato selezionato dal classificatore P300.
Effettuate queste modifiche si può ripartire nuovamente con il caricare in sequenza per ogni run solamente le 10 parole definite nei parametri 'LearningSession#.prm', indicando, nel file di log, per ogni run il numero di lettere selezionate errate.
Terminata la seconda fase si può procedere all'addestramento del classificatore per il riconoscimento dei potenziali d'errore (ErrP). A questo scopo si utilizza uno script matlab che richiama la funzione 'train_errp_visconti_bci2000( params )' generando il file .prm con i parametri necessari al classificatore ErrP. Se lo script non è in grado di identificare una sezione dell'epocha in cui distinguere o meno la presenza di un potenziale d'errore bisogna procede alla registrazione di ulteriori run oppure provare ad introdurre nuovi canali, all'interno dei parametri passati, e ad allargare la sezione temporale in cui individuare la forma d'onda ErrP.

Se non vi sono stati errori lo script genera un file di parametri che può essere caricato per addestrare questa volta il classificatore ErrP. A questo punto è possibile passare alla terza fase.

Nella terza sessione si può effettuare una serie di run (un qualsiasi numero) in modalità free mode. L'utente decide quale parola ,lettera per lettera, vuole scrivere, e nel caso in cui il sistema scrive un carattere errato l'utente dovrà eliminarlo selezionando l'icona 'BS' che si occupa di cancellare l'ultima lettera inserita.
Anche in questa sessione è necessario creare una nuova cartella con identificativo sessione 003, modificare il campo 'DataDirectory' e nella cartella 'Application' bisogna impostare il campo 'InterpretMode' con il valore 'online free mode'. Naturalmente in fase è nuovamente necessario compilare il file di log introducendo tutte le informazioni necessarie.

===Da fare===
* (altissima) Scrivere una funzione definita tra in <math>[0,1]</math> parametrica che valga: 1 in 0 e 1; <math>1-\epsilon</math> in ''a'' e ''c'', 0 in ''b''. <math>\epsilon</math> è un parametro.
* (alta) Fare un file di parametri per addestrare la gente per P300 e ErrP (modalità copy).
* (alta) Fare N (con N oppurtuno) file di parametri che contengano le parole da scrivere; considerare lunghezza oppurtuna per singole registrazioni e sessioni. Il file e il nome del file contenga già il numero di sessione e registrazione.
* (alta) Scrivere il protocollo per gli esperimenti; cioè, quante acquisizioni fare per ogni sessione, in che modalità, quando addestrare i classificatori...
* (media) Lo speller in modalità copy quando genera dei feedback sbagliati (per l'addestramento ErrP) deve selezionare effettivamente un simbolo sbagliato a caso tra tutti i simboli disponibili, e non usare il classificatore P300 per questo.
* (bassa) Far funzionare lo speller in modalità "mista", cioè: la stringa da scrivere è assegnata; il classificatore P300 viene usato per selezionare le lettere; in caso di lettera sbagliata viene scritta la lettera selezionata, e il simbolo successivo da selezionare sarà BackSpace. Perché questa cosa funzioni, il tasso di errori deve essere contenuto entro un certo intervallo, definito da 3 valori (''a'',''b'',''c'') in un opportuno parametro (si potrebbe riutilizzare il parametro attualmente usato per il tasso di errori nella stimolazione ErrP); operativamente:
# Selezionare una lettere con il classificatore P300
# Calcolare la statistica ''s'' delle selezioni correte sulle ultime N selezioni
# Si ricava una probabilità ''p'' a partire dall'entità della deviazione dall'intervallo ammesso, usando un'opportuna funzione che dipende da ''a'', ''b'', ''c'', ''s''.
# Con probabilità ''p'' modificare la selezione in questo modo:
#* Se ''s'' < ''b'', la selezione corrente viene corretta, se è sbagliata
#* Se ''s'' > ''b'', la selezione corrente viene fatta diventare sbagliate, se è corretta
:Il risultato dovrebbe essere che la statistica sia quasi sempre all'interno dell'intervallo ''a''-''c'', e che i valori fuori dall'intervallo non si allontanino troppo dai limiti fissati.
:Suggerimento: Per questa cosa, fare una classe (e usare un'istanza) in cui ci sia un metodo per aggiornare la statistica e uno per dire se bisogna fare correzioni all'ultima selezione.
* (bassissima) Fare esperimenti con almeno un paio di soggetto in cui lo speller funziona nella modalità "mista" di cui sopra.
:Per scegliere il numero di ripetizioni ottimo, bisogna valutare l'accuratezza del classificatore P300 con diversi numeri di ripetizioni (offline sui dati di test) e da questa, insieme all'accuratezza del classificatore ErrP, calcolare la velocità globale dell'interfaccia usando la formula che c'è nella tesi di Bernardo Dal Seno.

==Varie==
Le priorità indicate per le varie attività servono per fissare un'ordine. La tesi si conclude quando tutte le attività sono complete.

Electroencephalographs

2008-08-29T11:44:41Z

AndreaSgarlata: /* Booking */

== BeLight ==

A brief description of EbNeuro BeLight should go here.

=== Connectors ===
* '''1-21:''' EEG inputs
* '''A, B, C, D''' Bipolar inputs
* '''NE:''' EEG reference
* '''ISOGN:''' EEG ground (Isolated ground)
* '''22-24:''' Poly channels
* '''NEP:''' Poly reference

=== Booking ===



{| border="1"
! Day !! Time !! Person
|-
| Mond 25 August || 10:30-19:00 || Rossella
|-
| Wednesday 03 September || 10:00-19:00 || Bernardo
|}

=== Electrodes ===

There are two types of electrodes: electrodes pre-mounted on caps, and single electrodes. They are very simple, but as they are very important for the quality of the signal and are delicate (and also incredibly expensive, btw), please treat them carefully (avoid rattling them against each other, for example).

==== Maintenance ====

The paste or gel used during acquisitions must be thoroughly removed after use. Please follow the following procedure:
# Rinse the electrodes under running water. This step can remove only a part of the gel/paste. Please avoid washing or wetting the plugs.
# Put the electrodes in a container half-filled with water (there is a suitable container in the cabinet of the IITLab), so that the electrodes are completely submerged. Leave them there for some minutes, until all the gel/paste become dissolved. Change the water if it becomes too murky. Do not leave the electrodes underwater for too long.
# Rinse the electrodes under running water (and also rinse the container).
# Put the electrodes in a dry place, where they can dry up. You can accelerate this phase by first patting them with a towel. Again, make sure that plugs don't come in contact with water; if you hang a cap, make sure that water cannot drip along the cable onto the plug.
# Put the electrodes away in their bag in their box. Please make sure that they are absolutely dry before you put them away; the coating of electrodes is rather delicate.

Please take into account also the time for electrode cleaning when you plan your EEG acquisitions.

== Presets ==

Description of the presets saved in the Galileo software.

===P300===
Used for P300 and ErrP recordings. There are 4 EEG channels, 1 EOG, 2 external signals in DC; sampling frequency is 512 Hz.
;Channels and connectors:
:'''EOG''': EOG, input "A"; the "+" input for the electrode above the eye, the "-" input for the one below
:'''Fz''': Fz, input 7
:'''Cz''': Cz, input 12
:'''Pz''': Pz, input 17
:'''Oz''': Oz, input 20 (labeled as "O1" on the amplifier)
:'''Sync''': phototransistor for stimulus synchronization; positive lead (red) in input 22, negative lead (black) in input NEP
:'''Button''': button, used for target signaling; positive lead in input 23, negative lead in input NEP. If it's not used, please short the input 23 with NEP.

== Links ==

* [[Brain-Computer Interface]] page on this Wiki
* [[EEG Montage]] for instructions on how to mount electrodes

Electroencephalographs

2008-08-21T22:48:45Z

AndreaSgarlata: /* Booking */

== BeLight ==

A brief description of EbNeuro BeLight should go here.

=== Connectors ===
* '''1-21:''' EEG inputs
* '''A, B, C, D''' Bipolar inputs
* '''NE:''' EEG reference
* '''ISOGN:''' EEG ground (Isolated ground)
* '''22-24:''' Poly channels
* '''NEP:''' Poly reference

=== Booking ===



{| border="1"
! Day !! Time !! Person
|-
| Thursday 21 August || 10:00-19:00 || Bernardo
|-
| Wed (Friday?) 22 August || 10:00-14:00 || Rossella
|-
| Wednesday 27 August || 10:00-19:00 || Bernardo
|-
| Thursday 28 August || 10:00-19:00 || Bernardo
|-
|}

=== Electrodes ===

There are two types of electrodes: electrodes pre-mounted on caps, and single electrodes. They are very simple, but as they are very important for the quality of the signal and are delicate (and also incredibly expensive, btw), please treat them carefully (avoid rattling them against each other, for example).

==== Maintenance ====

The paste or gel used during acquisitions must be thoroughly removed after use. Please follow the following procedure:
# Rinse the electrodes under running water. This step can remove only a part of the gel/paste. Please avoid washing or wetting the plugs.
# Put the electrodes in a container half-filled with water (there is a suitable container in the cabinet of the IITLab), so that the electrodes are completely submerged. Leave them there for some minutes, until all the gel/paste become dissolved. Change the water if it becomes too murky. Do not leave the electrodes underwater for too long.
# Rinse the electrodes under running water (and also rinse the container).
# Put the electrodes in a dry place, where they can dry up. You can accelerate this phase by first patting them with a towel. Again, make sure that plugs don't come in contact with water; if you hang a cap, make sure that water cannot drip along the cable onto the plug.
# Put the electrodes away in their bag in their box. Please make sure that they are absolutely dry before you put them away; the coating of electrodes is rather delicate.

Please take into account also the time for electrode cleaning when you plan your EEG acquisitions.

== Presets ==

Description of the presets saved in the Galileo software.

===P300===
Used for P300 and ErrP recordings. There are 4 EEG channels, 1 EOG, 2 external signals in DC; sampling frequency is 512 Hz.
;Channels and connectors:
:'''EOG''': EOG, input "A"; the "+" input for the electrode above the eye, the "-" input for the one below
:'''Fz''': Fz, input 7
:'''Cz''': Cz, input 12
:'''Pz''': Pz, input 17
:'''Oz''': Oz, input 20 (labeled as "O1" on the amplifier)
:'''Sync''': phototransistor for stimulus synchronization; positive lead (red) in input 22, negative lead (black) in input NEP
:'''Button''': button, used for target signaling; positive lead in input 23, negative lead in input NEP. If it's not used, please short the input 23 with NEP.

== Links ==

* [[Brain-Computer Interface]] page on this Wiki
* [[EEG Montage]] for instructions on how to mount electrodes

Talk:Online P300 and ErrP recognition with BCI2000

2008-08-17T09:11:43Z

AndreaSgarlata: /* Fatto */

Talk:Online P300 and ErrP recognition with BCI2000

2008-08-17T09:07:11Z

AndreaSgarlata: /* Modulo applicativo speller P300 */

Talk:Online P300 and ErrP recognition with BCI2000

2008-08-17T08:54:51Z

AndreaSgarlata: /* CATENA DI FILTRI DI BCI2000 */

Talk:Online P300 and ErrP recognition with BCI2000

2008-06-14T12:59:35Z

AndreaSgarlata: /* CATENA DI FILTRI DI BCI2000 */

Talk:Online P300 and ErrP recognition with BCI2000

2008-06-14T12:57:05Z

AndreaSgarlata: /* Plugin Galileo/Modulo sorgente BCI2000 */

Talk:Online P300 and ErrP recognition with BCI2000

2008-06-14T12:55:51Z

AndreaSgarlata: /* Da fare */

Talk:Online P300 and ErrP recognition with BCI2000

2008-06-14T12:54:59Z

AndreaSgarlata: /* Da fare */

Talk:Online P300 and ErrP recognition with BCI2000

2008-06-14T12:52:41Z

AndreaSgarlata: /* Fatto */

Talk:Online P300 and ErrP recognition with BCI2000

2008-06-14T12:52:24Z

AndreaSgarlata: /* Da fare */

Talk:Online P300 and ErrP recognition with BCI2000

2008-05-25T08:25:10Z

AndreaSgarlata: /* Da fare */

Talk:Online P300 and ErrP recognition with BCI2000

2008-05-25T08:22:55Z

AndreaSgarlata:

Talk:Online P300 and ErrP recognition with BCI2000

2008-05-24T09:28:46Z

AndreaSgarlata:

User:AndreaSgarlata

2008-05-13T14:14:31Z

AndreaSgarlata:

{{User
|firstname=Andrea
|lastname=Sgarlata
|email=andrea (dot) sgarlata (at) mail (dot) polimi (dot) it
|advisor=Matteo Matteucci - Bernardo Dal Seno
|projectpage=Command a wheelchair using BCI2000
|photo=Andrea.jpg
}}

User:AndreaSgarlata

2008-05-13T14:14:02Z

AndreaSgarlata:

Talk:Online P300 and ErrP recognition with BCI2000

2008-05-13T13:58:33Z

AndreaSgarlata:

==PLUGIN==
*Riferimento su Airbat del sorgente modulo Plugin: sgarlata/PluginTemporizzato

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:

[[Image:plugin.jpg]]

* 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? ([[User:BernardoDalSeno|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. Comunque non è un problema quanti campioni riceve il plugin, l'importante è che questo invia blocchi dati da 1/16 di secondo e che ogni blocco inviato rappresenta il trascorrere di 1/16 di secondo.
Nell'immagine seguente è mostrato una parte di una sequenza di dati che riceve il plugin (25 canali a 128Hz).
[[Image:pluginSamp.jpg]]
* 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
*Riferimento su Airbat del sorgente filtro Trigger: sgarlata/P3SignalProcessingGalileo/FiltroTriggerSogliaAutomatica

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
*Riferimento su Airbat del sorgente filtro P300: sgarlata/P3SignalProcessingGalileo/FiltroAccumulatoreP300

4)filtro di classificazione

5)filtro che effettua la media dei valori in uscita dal filtro di classificazione
*Riferimento su Airbat del sorgente filtro Media: sgarlata/P3SignalProcessingGalileo/FiltroMedia

6)un filtro di normalizzazione

===Fatto===

Filtro che rileva i trigger

Adattamento automatico della soglia per i trigger (Analisi switch riquadro: Bianco->Nero->Bianco per un tempo definito dall'utente)

Accumulare forme d'onda con parti che precedono il trigger

===Da fare===

==Modulo applicativo speller P300==
*Riferimento su Airbat del sorgente modulo Applicativo: sgarlata/P3SpellerQuadratino

Il modulo applicativo deve essere 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===

Aggiungere quadrato di sync nell'applicazione speller

===Da fare===

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

Ciò che si vuole sviluppare è un sistema che si basi su una procedura di verifica automatica tramite l'integrazione del controllo anche sui potenziali d'errore.
La verifica dell'Errp non è effettuato tramite media di più forme d'onda così come avviene con le rilevazioni della P300, ma sulla singola prova.
Infatti, dopo l'analisi delle forme d'onda P300 e la determinazione del target voluto dall'utente, si introduce una ulteriore fase in cui si mostra all'utente la probabile selezione voluta e si valuta la presenza del potenziale d'errore. Se non viene riscontrata questa forma d'onda si seleziona il target precedentemente identificato, altrimenti si ripete una nuova sequenza di stimolazioni per identificare nuovamente il target voluto.

===Fatto===

===Da fare===

Introdurre una nova fase di controllo Errp nel modulo applicativo dello speller

Introdurre un nuovo filtro nella catena dei filtri che si occupa del'accumulo dei potenziali d'errore, oppure modificare il filtro P300 in modo che in base ad una variabile di switch effettui l'accumulo della forma d'onda P300 oppure dei potenziali d'errore

Modificare opportunamente i filtri di: classificazione, media e normalizzazione per supportare il controllo dell'Errp

==Varie==

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

Aggiungere riferimenti alla posizione dei progetti (directory) su Airbat per ognuno dei moduli sviluppati descritti nelle pagina.

Talk:Online P300 and ErrP recognition with BCI2000

2008-05-13T13:56:10Z

AndreaSgarlata:

==PLUGIN==
*Riferimento su Airbat del sorgente modulo Plugin: sgarlata/PluginTemporizzato

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:

[[Image:plugin.jpg]]

* 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? ([[User:BernardoDalSeno|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. Comunque non è un problema quanti campioni riceve il plugin, l'importante è che questo invia blocchi dati da 1/16 di secondo e che ogni blocco inviato rappresenta il trascorrere di 1/16 di secondo.
Nell'immagine seguente è mostrato una parte di una sequenza di dati che riceve il plugin (25 canali a 128Hz).
[[Image:pluginSamp.jpg]]
* 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
*Riferimento su Airbat del sorgente filtro Trigger: sgarlata/P3SignalProcessingGalileo/FiltroTriggerSogliaAutomatica

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
*Riferimento su Airbat del sorgente filtro P300: sgarlata/P3SignalProcessingGalileo/FiltroAccumulatoreP300

4)filtro di classificazione

5)filtro che effettua la media dei valori in uscita dal filtro di classificazione
*Riferimento su Airbat del sorgente filtro Media: sgarlata/P3SignalProcessingGalileo/FiltroMedia

6)un filtro di normalizzazione

===Fatto===

Filtro che rileva i trigger

Adattamento automatico della soglia per i trigger (Analisi switch riquadro: Bianco->Nero->Bianco per un tempo definito dall'utente)

Accumulare forme d'onda con parti che precedono il trigger

===Da fare===

==Modulo applicativo speller P300==
*Riferimento su Airbat del sorgente modulo Applicativo: sgarlata/P3SpellerQuadratino

Il modulo applicativo deve essere 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===

Aggiungere quadrato di sync nell'applicazione speller

===Da fare===

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

Ciò che si vuole sviluppare è un sistema che si basi su una procedura di verifica automatica tramite l'integrazione del controllo anche sui potenziali d'errore.
La verifica dell'Errp non è effettuato tramite media di più forme d'onda così come avviene con le rilevazioni della P300, ma sulla singola prova.
Infatti, dopo l'analisi delle forme d'onda P300 e la determinazione del target voluto dall'utente, si introduce una ulteriore fase in cui si mostra all'utente la probabile selezione dell'utente e si valuta la presenza del potenziale d'errore. Se non viene riscontrata questa forma d'onda si seleziona il target precedentemente identificato, altrimenti si ripete una nuova sequenza di stimolazioni per identificare nuovamente la selezione voluta dall'utente.

===Fatto===

===Da fare===

Introdurre una nova fase di controllo Errp nel modulo applicativo dello speller

Introdurre un nuovo filtro nella catena dei filtri che si occupa del'accumulo dei potenziali d'errore, oppure modificare il filtro P300 in modo che in base ad una variabile di switch effettui l'accumulo della forma d'onda P300 oppure dei potenziali d'errore

Modificare opportunamente i filtri di: classificazione, media e normalizzazione per supportare il controllo dell'Errp

==Varie==

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

Aggiungere riferimenti alla posizione dei progetti (directory) su Airbat per ognuno dei moduli sviluppati descritti nelle pagina.

Talk:Online P300 and ErrP recognition with BCI2000

2008-05-12T09:18:09Z

AndreaSgarlata:

==PLUGIN==
*Riferimento su Airbat del sorgente modulo Plugin: sgarlata/PluginTemporizzato

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:

[[Image:plugin.jpg]]

* 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? ([[User:BernardoDalSeno|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. Comunque non è un problema quanti campioni riceve il plugin, l'importante è che questo invia blocchi dati da 1/16 di secondo e che ogni blocco inviato rappresenta il trascorrere di 1/16 di secondo.
Nell'immagine seguente è mostrato una parte di una sequenza di dati che riceve il plugin (25 canali a 128Hz).
[[Image:pluginSamp.jpg]]
* 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
*Riferimento su Airbat del sorgente filtro Trigger: sgarlata/P3SignalProcessingGalileo/FiltroTriggerSogliaAutomatica

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
*Riferimento su Airbat del sorgente filtro P300: sgarlata/P3SignalProcessingGalileo/FiltroAccumulatoreP300

4)filtro di classificazione

5)filtro che effettua la media dei valori in uscita dal filtro di classificazione
*Riferimento su Airbat del sorgente filtro Media: sgarlata/P3SignalProcessingGalileo/FiltroMedia

6)un filtro di normalizzazione

===Fatto===

Filtro che rileva i trigger

Adattamento automatico della soglia per i trigger (Analisi switch riquadro: Bianco->Nero->Bianco per un tempo definito dall'utente)

Accumulare forme d'onda con parti che precedono il trigger

===Da fare===

==Modulo applicativo speller P300==
*Riferimento su Airbat del sorgente modulo Applicativo: sgarlata/P3SpellerQuadratino

Il modulo applicativo deve essere 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===

Aggiungere quadrato di sync nell'applicazione speller

===Da fare===

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.

Aggiungere riferimenti alla posizione dei progetti (directory) su Airbat per ognuno dei moduli sviluppati descritti nelle pagina.

Talk:Online P300 and ErrP recognition with BCI2000

2008-05-12T09:16:01Z

AndreaSgarlata:

==PLUGIN==
*Riferimento su Airbat del sorgente modulo Plugin: sgarlata/PluginTemporizzato

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:

[[Image:plugin.jpg]]

* 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? ([[User:BernardoDalSeno|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. Comunque non è un problema quanti campioni riceve il plugin, l'importante è che questo invia blocchi dati da 1/16 di secondo e che ogni blocco inviato rappresenta il trascorrere di 1/16 di secondo.
Nell'immagine seguente è mostrato una parte di una sequenza di dati che riceve il plugin (25 canali a 128Hz).
[[Image:pluginSamp.jpg]]
* 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
*Riferimento su Airbat del sorgente filtro Trigger: sgarlata/P3SignalProcessingGalileo/FiltroTriggerSogliaAutomatica

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
*Riferimento su Airbat del sorgente filtro P300: sgarlata/P3SignalProcessingGalileo/FiltroAccumulatoreP300

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

Adattamento automatico della soglia per i trigger (Analisi switch riquadro: Bianco->Nero->Bianco per un tempo definito dall'utente)

Accumulare forme d'onda con parti che precedono il trigger

===Da fare===

==Modulo applicativo speller P300==
*Riferimento su Airbat del sorgente modulo Applicativo: sgarlata/P3SpellerQuadratino

Il modulo applicativo deve essere 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===

Aggiungere quadrato di sync nell'applicazione speller

===Da fare===

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.

Aggiungere riferimenti alla posizione dei progetti (directory) su Airbat per ognuno dei moduli sviluppati descritti nelle pagina.

Talk:Online P300 and ErrP recognition with BCI2000

2008-05-05T10:11:35Z

AndreaSgarlata:

==PLUGIN==
*Riferimento su Airbat del sorgente modulo Plugin: sgarlata/PluginTemporizzato

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:

[[Image:plugin.jpg]]

* 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? ([[User:BernardoDalSeno|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. Comunque non è un problema quanti campioni riceve il plugin, l'importante è che questo invia blocchi dati da 1/16 di secondo e che ogni blocco inviato rappresenta il trascorrere di 1/16 di secondo.
Nell'immagine seguente è mostrato una parte di una sequenza di dati che riceve il plugin (25 canali a 128Hz).
[[Image:pluginSamp.jpg]]
* 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
*Riferimento su Airbat del sorgente filtro Trigger: sgarlata/P3SignalProcessingGalileo/FiltroTriggerSogliaAutomatica

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
*Riferimento su Airbat del sorgente filtro P300: sgarlata/P3SignalProcessingGalileo/FiltroP300

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

Adattamento automatico della soglia per i trigger (Analisi switch riquadro: Bianco->Nero->Bianco per un tempo definito dall'utente)

===Da fare===

Accumulare forme d'onda con parti che precedono il trigger

==Modulo applicativo speller P300==
*Riferimento su Airbat del sorgente modulo Applicativo: sgarlata/P3SpellerQuadratino

Il modulo applicativo deve essere 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===

Aggiungere quadrato di sync nell'applicazione speller

===Da fare===

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.

Aggiungere riferimenti alla posizione dei progetti (directory) su Airbat per ognuno dei moduli sviluppati descritti nelle pagina.

Talk:Online P300 and ErrP recognition with BCI2000

2008-05-05T10:09:51Z

AndreaSgarlata:

==PLUGIN==
*Riferimento su Airbat del sorgente modulo Plugin: sgarlata/PluginTemporizzato

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:

[[Image:plugin.jpg]]

* 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? ([[User:BernardoDalSeno|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. Comunque non è un problema quanti campioni riceve il plugin, l'importante è che questo invia blocchi dati da 1/16 di secondo e che ogni blocco inviato rappresenta il trascorrere di 1/16 di secondo.
Nell'immagine seguente è mostrato una parte di una sequenza di dati che riceve il plugin (25 canali a 128Hz).
[[Image:pluginSamp.jpg]]
* 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
*Riferimento su Airbat del sorgente filtro Trigger: sgarlata/P3SignalProcessingGalileo/FiltroTriggerSogliaAutomatica

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
*Riferimento su Airbat del sorgente filtro P300: sgarlata/P3SignalProcessingGalileo/FiltroP300

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

Adattamento automatico della soglia per i trigger (Analisi switch riquadro: Bianco->Nero->Bianco per un tempo definito dall'utente)

===Da fare===

Accumulare forme d'onda con parti che precedono il trigger

==Modulo applicativo speller P300==
*Riferimento su Airbat del sorgente modulo Applicativo: sgarlata/P3SpellerQuadratino

Il modulo applicativo deve essere 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===

Aggiungere quadrato di sync nell'applicazione speller

===Da fare===

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.

Aggiungere riferimenti alla posizione dei progetti (directory) su Airbat per ognuno dei moduli sviluppati descritti nelle pagina.

Talk:Online P300 and ErrP recognition with BCI2000

2008-05-05T09:59:07Z

AndreaSgarlata:

==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:

[[Image:plugin.jpg]]

* 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? ([[User:BernardoDalSeno|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. Comunque non è un problema quanti campioni riceve il plugin, l'importante è che questo invia blocchi dati da 1/16 di secondo e che ogni blocco inviato rappresenta il trascorrere di 1/16 di secondo.
Nell'immagine seguente è mostrato una parte di una sequenza di dati che riceve il plugin (25 canali a 128Hz).
[[Image:pluginSamp.jpg]]
* 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

Adattamento automatico della soglia per i trigger (Analisi switch riquadro: Bianco->Nero->Bianco per un tempo definito dall'utente)

===Da fare===

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===

Aggiungere quadrato di sync nell'applicazione speller

===Da fare===

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.

Aggiungere riferimenti alla posizione dei progetti (directory) su Airbat per ognuno dei moduli sviluppati descritti nelle pagina.

Talk:Online P300 and ErrP recognition with BCI2000

2008-05-05T09:54:38Z

AndreaSgarlata:

==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:

[[Image:plugin.jpg]]

* 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? ([[User:BernardoDalSeno|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. Comunque non è un problema quanti campioni riceve il plugin, l'importante è che questo invia blocchi dati da 1/16 di secondo e che ogni blocco inviato rappresenta il trascorrere di 1/16 di secondo.
Nell'immagine seguente è mostrato una parte di una sequenza di dati che riceve il plugin (25 canali a 128Hz).
[[Image:pluginSamp.jpg]]
* 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

Adattamento automatico della soglia per i trigger

===Da fare===

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===

Aggiungere quadrato di sync nell'applicazione speller

===Da fare===

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.

Aggiungere riferimenti alla posizione dei progetti (directory) su Airbat per ognuno dei moduli sviluppati descritti nelle pagina.

Talk:Online P300 and ErrP recognition with BCI2000

2008-05-02T09:12:24Z

AndreaSgarlata:

==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:

[[Image:plugin.jpg]]

* 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? ([[User:BernardoDalSeno|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. Comunque non è un problema quanti campioni riceve il plugin, l'importante è che questo invia blocchi dati da 1/16 di secondo e che ogni blocco inviato rappresenta il trascorrere di 1/16 di secondo.
Nell'immagine seguente è mostrato una parte di una sequenza di dati che riceve il plugin (25 canali a 128Hz).
[[Image:pluginSamp.jpg]]
* 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

File:PluginSamp.jpg

2008-05-02T09:08:11Z

AndreaSgarlata:

Talk:Online P300 and ErrP recognition with BCI2000

2008-05-02T09:07:55Z

AndreaSgarlata:

==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:

[[Image:plugin.jpg]]

* 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? ([[User:BernardoDalSeno|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.
[[Image:pluginSamp.jpg]]
* 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

Talk:Online P300 and ErrP recognition with BCI2000

2008-04-30T13:42:04Z

AndreaSgarlata:

'''MODIFICHE DA EFFETTUARE AL 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.

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:

[[Image:plugin.jpg]]

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

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

'''MODIFICHE DA EFFETTUARE ALLA 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

'''MODIFICHE DA EFFETTUARE AD UNO SPELLER P300 IN MODO DA RENDERLO CONPATIBILE CON LE CARATTERISTICHE DEL MODULO FILTRO'''

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.

Talk:Online P300 and ErrP recognition with BCI2000

2008-04-30T13:14:40Z

AndreaSgarlata:

'''MODIFICHE DA EFFETTUARE AL 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.

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:

[[Image:plugin.jpg]]

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

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

'''MODIFICHE DA EFFETTUARE ALLA 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

4)filtro di classificazione

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

6)un filtro di normalizzazione

'''MODIFICHE DA EFFETTUARE AD UNO SPELLER P300 IN MODO DA RENDERLO CONPATIBILE CON LE CARATTERISTICHE DEL MODULO FILTRO'''

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.

Talk:Online P300 and ErrP recognition with BCI2000

2008-04-30T08:43:10Z

AndreaSgarlata:

'''MODIFICHE DA EFFETTUARE AL 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.

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:

[[Image:plugin.jpg]]

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

'''MODIFICHE DA EFFETTUARE ALLA 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

4)filtro di classificazione

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

6)un filtro di normalizzazione

'''MODIFICHE DA EFFETTUARE AD UNO SPELLER P300 IN MODO DA RENDERLO CONPATIBILE CON LE CARATTERISTICHE DEL MODULO FILTRO'''

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.

Talk:Online P300 and ErrP recognition with BCI2000

2008-04-30T08:42:52Z

AndreaSgarlata:

'''MODIFICHE DA EFFETTUARE AL 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.

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:

[[Image:plugin.jpg]]

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

'''MODIFICHE DA EFFETTUARE ALLA 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

4)filtro di classificazione

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

6)un filtro di normalizzazione

'''MODIFICHE DA EFFETTUARE AD UNO SPELLER P300 IN MODO DA RENDERLO CONPATIBILE CON LE CARATTERISTICHE DEL MODULO FILTRO'''

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.

Online P300 and ErrP recognition with BCI2000

2008-04-30T08:42:34Z

AndreaSgarlata:

== '''Part 1: project profile''' ==

=== Project name ===
''Comandare una sedia a rotelle usando BCI2000''

=== Project short description ===
''Il progetto si pone l'obiettivo di sviluppare un software in grado di garantire la navigazione all'interno di menù con l'attivazione delle relative funzioni che consentono la navigazione di una sedia a rotelle all'interno degli ambienti domestici. L'iterazione tra uomo e computer è effettuata tramite interfaccia BCI''

=== Dates ===
Start date: 2008/01/01

End date: 2008/07/01

=== Internet site(s) ===
''''

=== People involved ===
''''

Andrea Sgarlata

==== Project head(s) ====
''''
Matteo Matteucci
Bernardo Dalseno

==== Other Politecnico di Milano people ====
''if any, other people participating to the project: ''

==== Students ====

'''Students currently working on the project'''

Andrea Sgarlata

'''Students working on the project in the past'''

==== External personnel: ====
''''

=== Laboratory work and risk analysis ===
''''

== '''Part 2: project description''' ==

Il software per la rileviazione della P300 e la relativa navigazione nei menù è sviluppato a partire dal tool open source 'BCI2000' che mette a disposizione una struttura ed una serie di funzioni flessibili ed adattabili alle nostre esisgenze.
Per la rilevazione delle onde celebrali è utilizzato un amplificatore con il relativo software 'EBneuro'.
Il sistema sottopone l'utente a delle stimolazioni visive, nel frattempo rileva la sua attività celebrale e tramite l'analisi di questa cerca di determinare quale stimolazione visiva l'utente ha selezionato. Identificata la stimolazione, si attiva la funzione associata a quella stimolazione che può essere l'attivavione di un nuovo sottomenù, lo spostamento della sedia a rotelle in un altra stanza oppure l'accensione di una lampadina o radio ecc...

User:AndreaSgarlata

2008-04-30T08:41:35Z

AndreaSgarlata:

Talk:Online P300 and ErrP recognition with BCI2000

2008-04-30T08:36:22Z

AndreaSgarlata:

'''MODIFICHE DA EFFETTUARE AL 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.

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:

[[Image:plugin.jpg]]

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

'''MODIFICHE DA EFFETTUARE ALLA 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

4)filtro di classificazione

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

6)un filtro di normalizzazione

'''MODIFICHE DA EFFETTUARE AD UNO SPELLER P300 IN MODO DA RENDERLO CONPATIBILE CON LE CARATTERISTICHE DEL MODULO FILTRO'''

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.

Talk:Online P300 and ErrP recognition with BCI2000

2008-04-30T08:11:53Z

AndreaSgarlata:

'''MODIFICHE DA EFFETTUARE AL 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.

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:

[[Image:plugin.jpg]]

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

'''MODIFICHE DA EFFETTUARE ALLA 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

4)filtro di classificazione

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

6)un filtro di normalizzazione

'''MODIFICHE DA EFFETTUARE AD UNO SPELLER P300 IN MODO DA RENDERLO CONPATIBILE CON LE CARATTERISTICHE DEL MODULO FILTRO'''

Talk:Online P300 and ErrP recognition with BCI2000

2008-04-30T08:11:02Z

AndreaSgarlata:

'''MODIFICHE DA EFFETTUARE AL 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.

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:

[[Image:plugin.jpg]]

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

'''MODIFICHE DA EFFETTUARE ALLA 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
4)filtro di classificazione
5)filtro che effettua la media dei valori in uscita dal filtro di classificazione
6)un filtro di normalizzazione

'''MODIFICHE DA EFFETTUARE AD UNO SPELLER P300 IN MODO DA RENDERLO CONPATIBILE CON LE CARATTERISTICHE DEL MODULO FILTRO'''

Talk:Online P300 and ErrP recognition with BCI2000

2008-04-30T08:05:14Z

AndreaSgarlata:

Talk:Online P300 and ErrP recognition with BCI2000

2008-04-30T07:53:49Z

AndreaSgarlata:

Talk:Online P300 and ErrP recognition with BCI2000

2008-04-29T13:03:25Z

AndreaSgarlata:

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:

[[Image:plugin.jpg]]

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

Talk:Online P300 and ErrP recognition with BCI2000

2008-04-29T13:03:10Z

AndreaSgarlata:

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:

[[Image:plugin.jpg]]

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

Talk:Online P300 and ErrP recognition with BCI2000

2008-04-29T12:50:43Z

AndreaSgarlata:

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:

[[Image:plugin.jpg]]

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

Talk:Online P300 and ErrP recognition with BCI2000

2008-04-29T12:47:17Z

AndreaSgarlata:

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:

[[Image:plugin.jpg]]

- 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), quindi 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.

Talk:Online P300 and ErrP recognition with BCI2000

2008-04-29T12:47:07Z

AndreaSgarlata:

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:
[[Image:plugin.jpg]]
- 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), quindi 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.

Talk:Online P300 and ErrP recognition with BCI2000

2008-04-29T12:46:19Z

AndreaSgarlata:

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:

[[Image:plugin.jpg]]

- 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), quindi 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.

File:Plugin.jpg

2008-04-29T12:44:24Z

AndreaSgarlata: