Arduo Memory Reminder Medicine

Normalmente un orecchio umano giovane sente suoni fino a 20 kHz. Con l'invecchiare tale soglia cala più in là che si va con gli anni. Alcuni hanno una soglia massima molto bassa, anche 5 kHz.
Capirai che se hai dei tali soggetti insieme la forbice di frequenze gestibili è ristretta, es: da 1 kHz a 5 kHz sono 4 kHz di forbice che, per 9 differenti tonalità, fanno toni con intervalli da 444 kHz. Troppo pochi, secondo me: sfido uno a riconoscere un tono a 4 kHz da un tono a 4,444 kHz :wink:

Potresti però usare la tecnica dei rintocchi dei campanili!
Un suono prolungato seguito da una sequenza di toni brevi il cui numero corrisponde al paziente chiamato in causa, così come i campanili battono i rintocchi contando le ore.
Esempio:
suono lungo - pausa - tono breve - pausa - tono breve
2 toni brevi = paziente n° 2

Ecc..

:roll_eyes:
Non è per forza così, io intendo creare 9 seglazioni composte da più tonalità, utilizzando frequenze audio e pause differenti, in maniera che al momento dell' installazione, si possa scegliere il suono più udibile dal paziente.
Se vogliamo, si possono chiamare suonerie, anzi le chiamerò proprio così.
Quello di cui ho bisogno però, è che qualcuno della comunità, esperto di udito, mi indichi quali possono essere le frequenze migliori da utilizzare, visto che per il mio orecchio, ci sono delle frequenze che effettivamente mi danno quasi fastidio e sento molto di più, ed altre no, le quali invece potrebbero essere udibili dai pazienti.

:fearful:
Girando un pò su internet, ho trovato questo (Psicoacustica - Wikipedia) alla voce "INTENSITA'" viene specificato che orecchie più anziane hanno una sensibilità minore se si superano i 2Khz, proprio come indicavi tu Leo72.

Effettivamente un pò limitati per creare una suoneria, ecco perchè mi piacerebbe inserire queste per poterle testare direttamente con il paziente. Ora provo a generare un pò di effetti con frequenze che non superano i 2-2,5khz inserendo pause al loro interno.

Mentre scrivevo questo, mi è venuta in mente un'altra idea, per implementare il sistema e renderlo più efficace.

:slight_smile:

Se collego il device ad un combinatore telefonico (o cellulare) o telecomando, che fà squillare / vibrare un cellulare o ricevitore (cercapersone) che il paziente avrà sempre con sè, lo si potrà avvisare anche senza l'ausilio di un altoparlante da utilizzare nel device stesso.
Il paziente si recherà davanti ad esso, dove vedrà il lampeggio del led il quale indicherà la medicina da assumere.

Si potrebbe predisporre il device per 9 suonerie a basse frequenze, qualora le suonerie non fossero udibili dal paziente, lo si munisce di un dispositivo (cell, cerca pers. ecc....) e lo si avvisa con questo.

Certo il costo sale un pò visto che se si utilizzano due cellulari (low cost), oltre al loro prezzo, occorre poi aggiungere le schede telefoniche e ricaricarle (penso almeno 50Euro in più).

Se invece si utilizzassero due xbee, uno in TX e uno in RX, cosa che non saprei come renderlo funzionante, forse si risparmierebbe qualcosa!

Non sò, forse le idee corrono troppo veloce, ma questo era già previsto come implementazione per poter effettuare le chiamate di emergenza da telecomando con eventualmente un arduino DUE o MEGA.
Il telecomendo fungerebbe anche da ricevitore con un vibro ed un piezo per l'audio al suo interno per avvisare il paziente.

.................................. ok! per adesso

comincio con l'audio, ma prevedo che l'uscita per l'altoparlante si possa collegare ad un dispositivo di segnalazione esterno.

Ciao.

Sempre per la serie idee da buttare nel calderone... nel mio cestino delle cianfrusaglie elettroniche ho trovato una serie di sensori di prossimità a corto raggio (1), quasi certamente provenienti da fax o stampanti. Mi è venuto in mente allora che si potrebbe aggiungere ad ogni cella un sensore di "presenza medicina", che dica al micro se nella casella c'è una scatola oppure è vuota.
In questo modo si potrebbe emettere un suono di avvertimento se la medicina (scatola) non viene prelevata dalla cella evidenziata dal led.

Un'altra idea (poi mi taccio!) è realizzare il casellario in plastica semitrasparente, e posizionare i led in modo tale che tutta la "scatola" che compone una cella diventi luminescente. Ciò potrebbe aiutare un utilizzatore ipovedente...

(1) Tipo RPR-359F o Sharp 2L01F

:roll_eyes:
Bella l'idea della casella che si illumina, un pò costosa e non semplice la realizzazione, ma comunque futuristica.

La presenza della scatola del medicinale, implica però la dimensione della casella stessa. Occorrerebbe creare una bacheca di certe dimensioni, in relazione alle dimensioni delle scatole utilizzate.
Utilizzando un fotodiodo, quando la casella si illumina, con la scatola al suo interno, questo non viene impressionato alla prima accensione, e di conseguenza non segnala la mancanza. Ma il punto è: dove posizionare il fotodiodo?
Se invece su usasse un sensore del tipo che hai menzionato, servirebbe un sostegno a levetta, che sente la presenza del peso della scatola, e libera o copre il passaggio dei raggi all'interno del sensore. Anche questa non semplice da realizzare.

:stuck_out_tongue:
Dimenticavo........
Postato sul sito del FABLAB, nuova versione R05H con sistemazione bug parametro configurazione lingua in conflitto con ore allarme 1 nella R05G1 ed inserimento segnalazioni sonore con frequenze basse differenti per i due pazienti, selezionabili in configurazione del sistema e memorizzate in eprom, come consigliato da Leo72.

Ciao.

In merito al sensore di presenza scatola: i sensori che ho trovato penso (e sottolineo penso) che diano segnale "presente" quando un corpo gli è molto vicino. Se la mia ipotesi su come funzionano è corretta, lo metterei in una posizione tale che quando c'è la scatola, copre il sensore, quando la tolgo, il sensore rimane non coperto e dà segnale negativo.

Ma come ho detto, sono per ora solo speculazioni... :slight_smile:

Ultimamente latito il forum ma quando posso leggo e questa volta posso anche rispondere.

In merito al sensore cassetto, posso dire che ad esempio le grattuggie industriali hanno un magnete incorporato nel contenitore ed un sensore magnetico sulla macchina e grazie a questi il motore non parte se il cassetto non è in sede, stesso sistema per il pressa cacio.

Come sensore magnetico può bastare un rele red, es. la coppia sensori magnete usati per impianti di allarme e molto economica, tra l'altro Giuseppe di allarmi dovrebbe saperne qualcosa (ardualarm) :stuck_out_tongue:

Finisce che lo producono e lo vendono a tutti gli ospedali, diventanto ricchi. :stuck_out_tongue:

Un saluto a tutti i componenti di questo bellissimo forum.

L'idea è che l'utente prelevi la scatola di medicinale, non l'intero cassetto. Quindi l'utilizzo di un reed richiederebbe di applicare un magnete alla scatola. (Ho come l'impressione di non aver capito bene... :stuck_out_tongue: )

tuxduino:
L'idea è che l'utente prelevi la scatola di medicinale, non l'intero cassetto. Quindi l'utilizzo di un reed richiederebbe di applicare un magnete alla scatola. (Ho come l'impressione di non aver capito bene... :stuck_out_tongue: )

Ho travisato la parola scatola. :slight_smile:

Quindi niente red, ma un sensore di presenza economico può essere fatto con diodo e fotodiodo IR, ricordo che gioblu con i sensori IR ci ha fatto cose molto più complesse, addirittura ha usato dei comuni led, ma questi sono troppo sensibili alla luce diurna.

Ciao.

:%
Aggiornato il progetto completo nel sito ufficiale del FABLAB Torino con semplice descrizione del funzionamento, elenco componeti progetto base, istruzioni per la programmazione fino alla release R05H, stesura idee per le implementazioni future e ringraziamenti a tutti coloro che hanno partecipato a dare un consiglio / contributo per una migliore realizzazione del device.

Un saluto a tutti.
Giuseppe G.

Ho aggiunto alla versione 05H la gestione della localizzazione. Ora le stringhe en/it sono raccolte in un array all'inizio del programma, ed ho sostituito le righe "if (lang==0) print(vers inglese) else print(vers italiano)" con un più manutenibile lcd.print(getString(STR_xxxx)).

Non ho usato la libreria di localizzazione che avevo scritto http://arduino.cc/forum/index.php/topic,131966.0.html perché non sono ancora soddisfatto del risultato. L'idea che sta alla base comunque è la stessa.

Per quanto riguarda la mia versione, sono entrato in "loop da libreria" :smiley: per cui oltre alla libreria per la localizzazione (che però come ho detto è da migliorare) ne ho scritto un'altra per la gestione dei comandi via seriale http://arduino.cc/forum/index.php/topic,133148.0.html e un'ultima per la gestione delle "pagine" del display LCD. Con quest'ultima ho (ri)scritto la parte dedicata all'impostazione di data e ora direttamente usando tastiera e lcd, e conto di usarla come "framework" per tutta l'applicazione. Aggiornamenti a breve.

Per finire un paio di annotazioni...
Rinominerei pushPin in keyACK per consistenza con keyUP e keyDW. Inoltre è rimasto un commento a proposito del led sul pin 13 che ora è sbagliato, visto che si usa come input :slight_smile:

Ciao! :smiley:

A_M_R_05H.pde (29 KB)

Per fare delle prove ho estratto il codice della localizzazione e l'ho messo in uno sketch autonomo, che stampa sulla seriale tutte le stringhe nei due linguaggi:

#include <EEPROM.h>

byte _lang;

// list of defined languages
enum {
    LANG_FIRST = 0,
    LANG_EN = 0,
    LANG_IT = 1,
    LANG_LAST = 1,
};

// eeprom memory address of language setting
const byte EE_LANG_ADDR = 128;

// number of defined languages
const byte NUM_LANGS = LANG_LAST + 1;

// max size of localized string (including null-terminator)
//const byte MAX_STR_LEN = 17

// localized strings
const char* strings[][NUM_LANGS] = {
//   0123456789012345    0123456789012345
    "SetDefault_ALARM", "Allarmi_predef. ",        //  0
    "Patient_"        , "Paziente"        ,        //  1
    "Medicine______"  , "Medicina______"  ,        //  2
    "____NO_ALARM____", "_NESSUN_ALLARME_",        //  3
    "SET_hours_______", "Impostazione_ore",        //  4
    "SET_minutes_____", "Impostaz._minuti",        //  5
    "SET_day_________", "Impostaz._giorno",        //  6
    "SET_month_______", "Impostaz.___mese",        //  7
    "SET_year________", "Impostaz.___anno",        //  8
    "SET_ADJ_sec_time", "Regol.sec.giorno",        //  9
    "SET_Legal___time", "Attiv.ora_legale",        // 10
    "SET_Lang.__EN/IT", "Linguaggio_EN/IT",        // 11
    "SET_Sound.Pat._1", "Suoneria_Paz.__1",        // 12
    "SET_Sound.Pat._2", "Suoneria_Paz.__2",        // 13
    "  Time:"         , "   Ore:"         ,        // 14
    "Pat.:"           , "Paz.:"           ,        // 15
    "SET_hour____AL"  , "SET_ore_____AL"  ,        // 16
    "SET_min.____AL"  , "SET_minuti__AL"  ,        // 17
    "SET_Patient_AL"  , "SET_Pazient_AL"  ,        // 18
    "SET_Medicin_AL"  , "SET_Medicin_AL"  ,        // 19
};


// localized strings identifiers
enum {
    STR_FIRST = 0,
   STR_SET_DEFAULT_ALARM = 0,
   STR_PATIENT     = 1,
   STR_MEDICINE    = 2,
   STR_NO_ALARM    = 3,
   STR_SET_HOURS   = 4,
   STR_SET_MINUTES = 5,
   STR_SET_DAY     = 6,
   STR_SET_MONTH   = 7,
   STR_SET_YEAR    = 8,
   STR_ADJ_SEC     = 9,
   STR_SET_LEGAL_TIME = 10,
   STR_SET_LANG    = 11,
   STR_SET_SOUND_PAT_1 = 12,
   STR_SET_SOUND_PAT_2 = 13,
   STR_TIME        = 14,
   STR_PAT         = 15,
   STR_SET_HOUR_AL = 16,
   STR_SET_MIN_AL  = 17,
   STR_SET_PATIENT_AL = 18,
   STR_SET_MEDICINE_AL = 19,
   STR_LAST = 19
};

// the the localized version of the specified string
const char* getString(byte stringId) {
    return strings[stringId][_lang];
}

// select language; the selection is stored in eeprom
void setCurrLang(byte langId) {
    if (langId < NUM_LANGS) {
        _lang = langId;
        EEPROM.write(EE_LANG_ADDR, _lang); 
    }
}

// get current language selection
byte getCurrLang() {
    return _lang;
}


void dumpStrings() {
    char buf[20];
    byte saveLang;
    
    saveLang = _lang;
    for (byte strIdx = STR_FIRST; strIdx <= STR_LAST; strIdx++) {
        for (_lang = LANG_FIRST; _lang <= LANG_LAST; _lang++) {
            sprintf(buf, "%-16s  ", getString(strIdx));
            Serial.print(buf);
        }
        Serial.println();
    }
    _lang=saveLang;
}


void setup() {
    Serial.begin(115200);
    
    delay(2000);
    dumpStrings();
}


void loop() {
}

In inglese non si dice "legal time" per l'ora legale ma DST, Daylight Saving Time.

:stuck_out_tongue: :wink:
Ottimo lavoro tuxduino!!! Ho provato lo sketch 05H modificato da te e tutto funziona correttamente!
Ho verificato la sram occupata e risultano ancora circa 640 byte liberi, mentre per la flash si và ad occupare 13570 byte, ancora meno della metà della memoria totale.

Ho sistemato la descrizione in inglese dell' ora legale consigliata da leo72, ho sistemato il bug della selezione medicina 00 paziente 2, il tutto postato sul sito ufficiale con una nuova release R05i.

Un saluto a tutti.
Giuseppe G.

Bene! :slight_smile:

Colgo l'occasione per segnalarti che nell'ottica di inserire un RTC, i pin A4 e A5 sarebbero occupati dalla trasmissione I2C. Ora sono utilizzati uno per un led e l'altro per il suono, se non ricordo male.

Complimenti, bel progetto :wink:
butto lì due idee..
per sentire la presenza o meno della scatola, si potrebbero usare più fotoresistenze in serie per avere un effetto sensibile più "diffuso" posizionandole a dovre (io ne metterei 5 per slot), essendo un componente abbastanza lowcost si potrebbe abbondare ed è anche semplice da interfacciare.
anche usare i led non sarebbe male, visto che potreste usarli come segnalazione e come sensore allo stesso tempo, (es. LED Sensing) :wink:
vedo che non hai usato la libreria TimeAlarm, come mai?
ref: http://arduino.cc/forum/index.php/topic,37693.0.html
fra l'altro la libreria prevede già di essere usata insieme ad un rtc e funziona in coppia con la libreria Time che già usi.

:roll_eyes:
Ciao tuxduino,

Colgo l'occasione per segnalarti che nell'ottica di inserire un RTC, i pin A4 e A5 sarebbero occupati dalla trasmissione I2C. Ora sono utilizzati uno per un led e l'altro per il suono, se non ricordo male.

l'idea di utilizzare i pin A4 e A5, può andare bene, ma bisogna risolvere prima il problema per la segnalazione delle 8 medicine che si perderebbero, utilizzandoli per I2C.
Implementare un integrato di basso costo come driver led, può avere effetto, mentre implementare un LCD seriale che come minimo costa 20-30 euro, un po meno.
Conosco 74LS138 che converte da 3 a 8 bit singoli (3 to 8 line decoder), che, rivedendo il circuito, ed usandolo in combinazione con con altri 3 pin di arduino, si riuscirebbe a risparmiare 2 pin ed avere 64 led a disposizione polarizzati direttamente (8 linee x 8 righe).
Poi servirebbe una NOT per comandare il catodo delle 8 linee o righe, tipo un 40106.
Il problema è che il 78LS138 è ormai obsoleto e credo non si trovi più, in compenso ci dovrebbe essere l'Hitachi HD74HCT238, ma non capisco quanta corrente può supportare nel pin out sia verso GND che verso la VCC.
Questo invece potrebbe fare al caso nostro MC74HC259ADG, con +/-25mA output, e costa meno di 50 cent., naturalmente in internet.

Qualcuno ha idee a riguardo?

In alternativa si potrebbe usare una tastiera analogica (vedi ad esempio lo shield lcd+keypad di nuelectronics). Con un unico pin analogico si implementano facilmente 5 o 6 tasti. Non ho controllato bene lo schema, ma mi pare che questo permetterebbe di guadagnare 2 pin.

:*
Ciao BrainBooster,
utilizzare le fotoresistenze, potrebbe essere molto semplice, ma hai idea di quanti ingressi analogici occorrono? Come per i diodi!
Occorre trovare una soluzione per comandate il sensore, e leggerne lo stato, sempre con un multiplex, magari lo stesso dei led, ma con una logica specifica per controllarne la risposta.
Ad esempio, nel caso dei diodi led o fotodiodi, una volta polarizzati, si potrebbe leggere lo stato traminte un pin analogico.
Bisogna lavorarci un pò, per restare alla UNO, altrimenti, questa opzione, si dovrà implementare solo quando si passerà alla DUE o al MEGA.
I riferimenti che hai postato, indicano che per ogni fotodiodo, c'è dedicato un ingresso ed in questo caso ne avremmo bisogno di ben 32!!!!!

Per le prove, prenderemo comunque in considerazione le modalità di utilizzo dei diodi.

Pensa..... se hai compreso il funzionamento del circuito, quando il led della medicina si accende, ed in parallelo a questo, colleghiamo un diodo emitter, dall'altra parte ci sarà bisogno solo di un controllo in ingresso, perchè il led e quindi la medicina presa in considerazione sarà solo quella attivata.
Se ricevo il segnale nel fotodiodo ricevitore, la medicina non è presente, quindi eseguo una sub che ne segnala la mancanza, se non lo ricevo, la medicina si trova al suo posto, quindi attivo solo la chiamata al paziente per l'assunzione. :wink:

Per quanto riguarda la libreria "TimeAlarm", ho voluto tener separata la possibilità di settare gli allarmi in modo indipendente, senza alcun vincolo, in maniera che le variabili possano essere gestite senza alcun problema.

Ciao.