Stai visualizzando 8 post - dal 57 a 64 (di 98 totali)
  • Autore
    Post
  • #5023
    mau22
    Partecipante

    Ciao ragazzi.

    Sto facendo alcune prove con il file RR ottenuto da Theremino ECG, e qualcosa non mi convince, ma non riesco a capire cosa.
    Purtroppo, non ho ancora modo di collegare degli elettrodi, e solo uno dei file di esempio di Theremino ECG ha una durata maggiore di 5 minuti.

    Nel frattempo, ho ragionato sull’ultimo intervento di Livio di Theremino.
    Alla prima lettura, non mi era chiaro il motivo per il quale l’analisi successiva del tracciato produca tempi RR diversi da quelli dell’analisi in tempo reale.
    Ma poi mi sono chiesto come farei io per estrarre questi dati, ed ho ipotizzato una risposta.
    L’istante esatto del ciclo cardiaco al quale attribuire il punto del tempo al quale riferirsi nel calcolo del periodo RR è localizzato, secondo la letteratura, nel picco più alto della forma d’onda, che viene appunto denominato R.
    Immagino che la determinazione di questo punto venga fatta dal software analizzando tutte le letture precedenti, e facendo un auto-set di un trigger al valore più prossimo alla media di quelli letti in precedenza.
    Questo implica, tra l’altro, la necessità di analizzare inizialmente un certo numero di battiti prima di poter iniziare ad estrarre i tempi RR.
    Ovviamente, un set del trigger molto vicino al massimo delle letture è più preciso nella determinazione del tempo, ma potrebbe non attivarsi con letture di ampiezza un pochino inferiore, saltando così dei battiti e inficiando gravemente la bontà della lettura totale.
    Se invece impostiamo il trigger troppo basso, il riconoscimento del punto massimo del picco R si sposta indietro nel tempo, in quanto viene localizzato prima del punto più alto del picco.
    Se questo è il metodo attualmente utilizzato, è chiaro che i parametri per l’impostazione automatica del punto di trigger possono essere solo quelli precedenti nel tempo reale, mentre ci si può riferire alla totalità delle letture (quindi comprendendo anche quelle successive) nell’analisi pre-processo del file con i dati RAW (penso che possiamo definire in questo modo il file di Theremino ECG che permette di riprodurre l’intero grafico delle forme d’onda).
    In prima battuta, concordo con Livio quando dice che l’impiego dell’analisi di tutte le ampiezze prima dell’estrazione dei dati RR possa consentire un miglioramento globale della precisione delle durate RR.
    Ma se ci ragiono con più attenzione, mi rendo conto che il tracciato potrebbe essere affetto da variazioni di ampiezza durante il periodo di acquisizione dei dati.
    Il motivo più banale, e forse più probabile, è la variazione di conduttività del contatto tra elettrodi e pelle, a seguito di movimenti del soggetto, ma non possiamo escludere variazioni di ampiezza della forma d’onda indotte dal sistema stesso che stiamo osservando.
    Anzi, potrebbe anche essere interessante fare una valutazione statistica delle variazioni di ampiezza in riferimento alle misure HRV.
    Ovviamente, questo tipo di valutazione sarà difficilissimo, dato il legame strettissimo tra i due valori, almeno finché utilizziamo un trigger di ampiezza per valutare il picco R.
    Sto pensando (e forse è lo stesso pensiero di Theremino) a un metodo diverso.
    Anziché riferire il trigger a un valore di ampiezza, perché non riferirlo a un valore di derivata del segnale?
    Si potrebbe estrarre la media dei valori massimi precedenti, e in questo modo creare un range di auto trigger relativamente ampio (comunque più ampio dei valori minimi e massimi dei picchi precedenti), entro il quale fare un’ulteriore analisi della derivata del segnale, e in questo modo localizzare esattamente il punto nel quale la forma d’onda ha derivata 0, ovvero localizzare la cresta dell’onda.
    Il primo filtro riferito ai valori di ampiezza permette di escludere dal calcolo della derivata quelle parti della forma d’onda diverse dal picco R.
    Questo sistema ha un difetto: la sua precisione dipende direttamente dal numero di campioni al secondo con il quale vengono acquisiti i dati RAW, per cui potrebbero non esistere due campioni appartenenti al un punto della curva con derivata 0.
    Una alternativa potrebbe essere quella di localizzare due punti di derivata leggermente diversa da 0, uno prima e uno dopo il picco massimo, e calcolare l’istante R in mezzo tra le due letture.
    Mi rendo conto che un sistema di questo tipo richiede parecchio calcolo e molta programmazione, e penso che valga la pena di approfondire per capire se abbiamo davvero bisogno di questa precisione.
    Il prossimo passo è la compilazione a mano di alcuni file di dati RR, simulando diverse situazioni standard e inserendo errori di misura di 5 ms o meno, per vedere di quanto cambiano i risultati in Kubios.

    Vi lascio un nuovo link molto interessante.
    https://www.biot.it/images/pdf/Dossier-HRV-e-ambiti-applicativi.pdf

    Ciao
    Maurizio

    #5025
    theremino
    Amministratore del forum

    I problemi di lettura sono esattamente quelli che hai descritto.
    Aggiungerei solo che il punto più alto contiene anche del rumore che può ingannare e far prendere i tempi in anticipo o in ritardo.
    E anche che la comunicazione tra Master e PC, via USB, ha una incertezza di uno o due millisecondi.
    Theremino ECG campiona ogni due mS e non potrebbe fare altrimenti, se campionasse ogni millisecondo i tempi diventerebbero totalmente inaffidabili ( a volte zero mS, a volte 2 mS ).

    Se intendete continuare per questa strada e mi dite che ne vale la pena, nei prossimi giorni potrei migliorare un po’ la precisione individuando il punto più alto (per quanto possibile).

    Però, come spiegato, avremo sempre errori di alcuni millisecondi. E certamente sotto al +/- 2mS non si potrà mai andare a causa della comunicazione USB.

    Se qualche millisecondo fa la differenza, allora vi consiglio di abbandonare questo sistema e fare tutto in firmware dentro a un PIC o un Arduino.

    #5027
    lorenzo58sat
    Partecipante

    Comprendo i problemi che vengono fuori. Credo che siano tutti legati all’algoritmo di calcolo dell’intervallo RR. Lo stesso gruppo di ricercatori finlandesi nel programma premium (a pagamento) rilasciano insieme al programma l’algoritmo di calcolo ed avvertono che ci possono essere molte differenze nella analisi se si trascurano gli artefatti. Il software Consensys Pro per la interpretazione del GSR (Galvanic Skin Response) fa uguale. La differenza è che mentre per Kubios te la cavi con 300 euro gli amici irlandesi di Shimmer Sensing te ne chiedono 1200 per il programma che ricava l’intervallo RR dalla PPG o dall’ECG
    Lasciamo stare e vediamo cosa ho nel cassetto io. Ho scaricato un po di letteratura tempo fa. Ci sono anche riferimenti all’algoritmo. Più tardi ci guardo. Il problema è che in questi giorni ho bisogno di 48 ore. Mi è arrivata la scheda AD8232 … l’ho messa accanto al Theremino … ho scaricato il programma di Livio … ma ancora non ho acquisito nulla di tracciati. Ora vediamo che trovo …

    • Questa risposta è stata modificata 4 anni, 8 mesi fa da lorenzo58sat.
    • Questa risposta è stata modificata 4 anni, 8 mesi fa da lorenzo58sat.
    #5030
    lorenzo58sat
    Partecipante

    Ciao Livio. Non credo che qualche millisecondo faccia la differenza. Se si trattasse di 10 millisecondi (venendo elevati al quadrato) diventerebbe un fattore di 100. Comunque ci sarebbe da dire che si dovrebbe trattare di un errore sistematico e quindi quasi ininfluente su tutta la misura. Mettiamola così: la misura deve durare almeno 6 minuti ( non di piu) ed in quel periodo abbiamo circa 430 battiti (e quindi 429 intervalli RR). Ok perché 6 minuti? Perché è la finestra minima prima che intervengano effetti di attivazione del vago o del simpatico. In realtà quando si effettua la pratica del tilting (passaggio dal clino all’ortostatismo) la misura dovrebbe essere entro 2 minuti ma nessun soft analizza HRV su 2 minuti. Ci vogliono almeno 500 battiti perché la FT sia attendibile. Ne bastano meno nel caso della FFT. Per cui ok. Tranquillo Livio io ho TOTALE fiducia nella tua esperienza, intuizione e capacità tecnica. Cerco la bibliografia sull’algoritmo di individuazione dei picchi RR. Sono sicuro che è interessatissimo anche Maurizio …😁

    • Questa risposta è stata modificata 4 anni, 8 mesi fa da lorenzo58sat.
    • Questa risposta è stata modificata 4 anni, 8 mesi fa da lorenzo58sat.
    #5033
    mau22
    Partecipante

    Ciao Lorenzo.
    Non avevo ancora indagato sui prezzi, ma da quanto dici capisco che la mia intuizione era giusta.
    L’analisi del file RAW e la conseguente estrazione dei tempi RR è un punto critico, ed è molto importante per noi capire di quale precisione abbiamo bisogno.
    Penso che risoluzioni al di sotto dei 2 ms siano difficili da raggiungere con precisione scientifica, anche lavorando con micro programmati appositamente, e sono convinto che i prodotti commerciali che usano interfacce acquisite con app da cellulare garantiscano tempi e precisioni inferiori.
    Questo non significa che una maggiore precisione non sia utile per fare la differenza tra un giocattolo e uno strumento professionale.
    Non concordo invece sulla tua affermazione relativa gli errori sistematici, perché in realtà questi errori sarebbero legati ai tempi e alle ampiezze, quindi per nulla ripetitivi.
    L’elevazione al quadrato dei tempi RR in realtà non l’ho ancora capita. Il Kubios acquisisce valori in secondi con risoluzione in ms.
    Mentre resto in attesa dei tuoi aggiornamenti teorici, faccio qualche prova pratica con l’acquisizione dei file da parte di Kubios.

    Ciao Livio.
    Come ho già scritto, non sappiamo ancora di quale livello di precisione abbiamo bisogno.
    Di certo, la rigorosità dell’acquisizione dei tempi RR è la chiave per ottenere risultati scientificamente attendibili anziché oroscopi.
    Quindi, ben venga un tuo impegno per il miglioramento della conversione del file RAW in tempi RR, ma prima di lavorare duramente per ottenere precisioni al millisecondo, accertiamoci della effettiva necessità.
    Per quanto riguarda il rumore sulla sommità della forma d’onda, penso che l’unico metodo affidabile sia il filtraggio, soprattutto hardware, per ridurre il rumore elettrico (ad esempio un filtro passa basso), e poi affidarsi a Kubios per eliminare gli artefatti.
    Non dico questo perché io abbia una particolare simpatia per Kubios, ma da quello che ho letto è considerato un programma super partes, quindi possiamo prenderlo inizialmente come riferimento per verificare se i nostri futuri programmi di analisi sono affidabili.

    #5035
    lorenzo58sat
    Partecipante

    Buongiorno Maurizio e buongiorno Livio.
    Ho trovato 2 elementi interessanti per il QRS detection necessario al calcolo del periodo RR.
    Il primo è una tesi di laurea del dr. Ramshur (2010).
    La trovi qui https://www.researchgate.net/profile/John_Ramshur/publication/324038902_Design_evaluation_and_application_of_Heart_Rate_Variability_Analysis_Software_HRVAS/links/5ae349aba6fdcc9139a18b36/Design-evaluation-and-application-of-Heart-Rate-Variability-Analysis-Software-HRVAS.pdf
    A pagina 60 spiega il suo algoritmo che ha inserito nel programma (simile a Kubios e che gira sotto MathLAB) HRVAS 1.0.0 di cui ho parlato qualche giorno fa.
    Il secondo è un articolo molto interessante che ricalca le deduzioni di Maurizio ed è del 2016.
    Lo trovi qui https://www.researchgate.net/publication/290536979_A_Novel_Approach_for_Detection_of_RR_Interval/download
    Di articoli sul WEB adesso ce ne sono moltissimi, ma forse questi sono i due più interessanti.
    In particolare in quello del 2016 nella figura 3 si vede come l’accuratezza dell’algoritmo nel rilevare il picco R (e quindi nel successivo calcolo dell’intervallo RR) sia veramente minima anche se il suo metodo (sovrapponibile a quello proposto da Maurizio) appare molto performante.

    #5037
    mau22
    Partecipante

    Buongiorno Lorenzo e Livio.

    Per motivi di tempo non ho ancora letto il primo link, ma ho letto di fretta il secondo perché ero contento di aver pensato da solo a un sistema che ha interessato un ricercatore universitario che ha pubblicato su una rivista scientifica.
    Se ho ben capito con la veloce letture, in apparenza il mio sistema è molto simile, ma diverso nel modo di identificare il picco R.
    Lui squadra il segnale, e poi analizza le pendenze per distinguere il picco R dal picco T. Non capisco esattamente consa intende, dovrei mettermi a leggere con attenzione la flow chart e le formule contenute.
    Il mio metodo utilizza la differenza di ampiezza di due campioni (o quattro, ma questo è un dettaglio probabilmente ininfluente) per ottenere una valore di derivata da utilizzare per localizzare con precisione il picco.
    Anche io, come lui, mi ero fatto inizialmente delle domande sull’impiego delle risorse delle CPU per l’analisi, temendo che una complessità di calcolo potesse influire sui risultati.
    Ma poi non ho citato, nel mio intervento, questo particolare, in quanto mi sono reso conto che non è affatto necessario fare l’analisi RR in real time.
    Anzi, la configurazione con un dispositivo che fa il log e un altro che analizza il file ottenuto è molto più logica ed efficiente dal punto di vista della precisione.
    In questo caso, il logger deve fare bene solo il suo lavoro di logger, memorizzando la forma d’onda con una frequenza di campionamento il più possibile elevata, che dovremo calcolare in modo da avere un dettaglio sufficiente ma senza esagerare raccogliendo dettagli inutili.
    Bisogna considerare che alla fine dei conti, con il metodo che sto proponendo, oltre un certo limite un aumento del dettaglio di campionamento non introduce un reale aumento della precisione di localizzazione del punto R, in quanto la determinazione non è legata alla effettiva ampiezza del segnale, ma solo al suo comportamento nel tempo, che può essere determinato anche con un numero di campioni relativamente modesto.
    Il passo successivo di analisi del file viene fatto utilizzando tutto il tempo che occorre.
    Il software di analisi può fare tranquillamente più passate sui dati del file, ottenendo progressivamente:
    – i valori di ampiezza massimi
    – la media dei massimi
    – il range entro il quale considerare i massimi come appartenenti all’insieme delle zone di onda R
    – i punti appartenenti a queste zone di onda che hanno derivata prossima a 0 (oppure precedenti e successive a 0)

    Questo approccio si presta ad ulteriori sviluppi, seguendo una strada diversa e più impegnativa dal punto di vista del calcolo.
    L’analisi continua della derivata di tutti i punti, comparata con le relative ampiezze, permette di identificare con buona precisione non solo il picco R, ma anche qualunque altro punto della forma d’onda, e permette anche di riconoscere forme d’onda non standard.

    Vi aggiornerò sui miei progressi

    Ciao
    Maurizio

    #5041
    theremino
    Amministratore del forum

    Lorenzo, grazie di aver trovato questo PDF, la figura 3 è davvero illuminante.
    A quanto pare anche gli algoritmi più sofisticati sbagliano di decine di millisecondi, quindi ne desumo tre cose:
    1) Qualche decina di millisecondi di errore è trascurabile e non impedisce di fare le analisi.
    2) Già ora siamo decisamente più precisi di un apparecchio di media qualità.
    3) L’algoritmo che ho in mente per trovare la punta potrà dare una precisione paragonabile a quella dei più costosi algoritmi a pagamento.

    Riguardo agli errori residui concordo con Maurizio, non sono errori sistematici ma casuali.
    Anche con il migliore algoritmo resteranno sempre errori casuali intorno ai +/- 2mS, e questi errori diventeranno anche molto maggiori (decine di millisecondi) se gli impulsi sono disturbati da rumore e variano in ampiezza.

    Le misure di tempo che fa la applicazione ECG in tempo reale resteranno imprecise e non le modificherei. Non sono intese per fare analisi RR ma solo per dare una informazione approssimativa della frequenza cardiaca.

Stai visualizzando 8 post - dal 57 a 64 (di 98 totali)
  • Devi essere connesso per rispondere a questo topic.