Guida completa alla costruzione di xBridge versione 2.47e. Idea e realizzazione di John Stevens.
Traduzione in italiano a cura di Cristiana Murgia, Alessandro Pesce, Alessandro Vignolini e Leo Minno.
Nota Bene
- La prima sezione, denominata “Specifiche tecniche“, è per utenti esperti e tratta gli aspetti relativi alla programmazione. È adatta ai programmatori e a chi vuole approfondire il funzionamento di xBridge.
- La seconda sezione, denominata “Costruzione di xBridge“, è di media difficoltà ed è invece adatta a chi, pur non conoscendo la programmazione, ha bisogno di costruire xBridge e di utilizzarlo. È dunque la sezione più adatta alla maggioranza dei lettori.
XBridge2 – v2.47e
XBridge2 è un firmware per il Wixel Pololu e circuiti aggiuntivi, che permettono al Wixel di funzionare come un ponte tra un trasmettitore Dexcom G4 e uno smartphone, utilizzando Bluetooth 4.0 (BLE) con moduli HM-10/11 o Bluetooth 4.1 con moduli HM -16/17. Xbridge2 richiede che il Wixel sia collegato al modulo HM-1x BLE, utilizzando, come minimo, il design originario creato da Stephen Black per il suo sistema xDrip. E’ richiesta una piccola modifica hardware affinché sia possibile ricevere il voltaggio della batteria e monitorarlo tramite l’applicazione e una modifica ai collegamenti che permette al HM-1x di disattivarsi quando il Wixel è in modalità basso consumo e riaccendersi quando ne esce. Guarda gli schemi dei circuiti riportati di seguito.
La versione V2.47e aggiunge il supporto per i moduli HM-16/17 e ha un circuito più semplice. Se avete già costruito un circuito xBridge2, NON SONO NECESSARIE MODIFICHE per utilizzare la versione 2.47e.
NOTA: Questa applicazione può essere utilizzata con un xDrip-Wixel classico, ma non sarà disponibile la funzione di risparmio batteria prevista dal software.Il software del xBridge2 riconoscerà automaticamente se stai utilizzando un xDrip-Wixel e la velocità del modulo HM-1x
La seguente guida può anche essere scaricata in formato PDF.
Ringraziamenti
Il codice originale, l’ingegnerizzazione e la decodifica del pacchetto di dati Dexcom sono stati fatti da Adrien de Croy, senza il quale questo progetto non sarebbe stato possibile.
L’ispirazione di continuare è venuta da Lorelei Lane, Jason Calabrese e altri della comunità e fondazione Nightscout.
Il circuito originale XDrip su cui si basa questo lavoro è stato progettato da Stephen Black, che ha anche creato l’applicazione XDrip.
Il circuito di monitoraggio della batteria è stato progettato da Chris Botelho.
Il metodo di spegnimento e di accensione del modulo HM-10 è stato progettato da Gabor Szakacs.
Il metodo integrato in v2.47e che migliora la stabilità BLE con i telefoni Android è stato ispirato dall’opera di @keencave e @danpowell88 nella stanza Gitter di xDrip+.
Voglio inoltre riconoscere il lavoro di Lumos e Slasi del forum Pololu Wixel per il loro lavoro nel disattivare correttamente il Wixel e la parte radio. Ho fatto abbondante uso della libreria radio di “slasi” e ho usato alcuni dei codici presenti nella libreria di disattivazione di “lumos”, nel codice Wixel xBridge.
SPECIFICHE TECNICHE
Panoramica
Come suggerisce il nome, questo dispositivo funziona puramente come un ponte tra il trasmettitore Dexcom G4 e un dispositivo compatibile Bluetooth, ad esempio un telefono cellulare o un tablet. Questo ritrasmette copia di un pacchetto dati ottenuti da un trasmettitore Dexcom G4. IL DISPOSITIVO NON ALTERA O RICALCOLA QUESTI DATI. Non traduce ed effettua calcoli con i dati grezzi presenti nei pacchetti dati per ottenere una stima del valore glicemico.
Va notato che solo tre parti dei dati vengono ritrasmessi dal Dexcom G4. Questi sono i due valori di 32bit che rappresentano i dati di glucosio nel sangue, e un valore a 8 bit che rappresenta lo stato della batteria presente nel trasmettitore G4.
Aggiunge informazioni sullo stato della batteria dell’xBridge, mostrando in percentuale, la capacità residua e l’identificativo ID del trasmettitore Dexcom G4, che sta filtrando/analizzando.
Questo dispositivo, il suo software e qualsiasi altro software aggiuntivo sviluppato per l’utilizzo dello stesso, NON DEVONO essere utilizzati per prendere decisioni terapeutiche sulla gestione del diabete. Utilizzare sempre un misuratore di glucosio capillare e le opportune decisioni di gestione. Tutto questo è solo per uso informativo e sperimentale.
Il codice originale per xDrip era basato sul lavoro di Adrien de Croy , Lorelai Lane ed altri, ma ha delle limitazioni. Il presente firmware ha le seguenti funzionalità che le risolvono:
- Non riceve alcun pacchetto dati Dexcom fino a quando non è stato inserito un identificativo ID del trasmettitore Dexcom G4 da filtrare. Ciò è importante per assicurare che sia correttamente agganciato al segnale del trasmettitore in questione e ritrasmetta solo i suoi dati univoci all’applicazione dello smartphone. IMPLEMENTATO (v2)
- Memorizza l’ID del trasmettitore nella memoria flash, in modo da ricordarlo se, per qualsiasi motivo, venisse meno l’alimentazione. L’applicazione non richiede il reset, nel caso l’evento si verificasse. IMPLEMENTATO (v1)
- Trasmette una segnalazione all’applicazione al risveglio dalla modalità di sospensione indicando l’ID del trasmettitore che sta filtrando. L’applicazione a quel punto può inviare un pacchetto TXID qualora l’ID del trasmettitore da filtrare sia errato oppure, ignorare la segnalazione. Questo è necessario per assicurare che quando un paziente cambia il trasmettitore, l’applicazione riconosce che il Wixel è operativo in modo da poter inviare un nuovo pacchetto TXID. Normalmente il Wixel si sveglierà 5 minuti dopo l’ultimo pacchetto ricevuto per rimanere in attesa fino a quando non riceve un pacchetto dal trasmettitore sul quale è configurato. IMPLEMENTATO (v2)
- Trasmette una segnalazione all’applicazione ogni 5 secondi se il codice è di nuova installazione ed il Wixel non ha ricevuto un pacchetto TXID. Continuerà a trasmettere segnalazioni ad intervalli di 5 secondi fino al ricevimento di un TXID ed il codice ID del trasmettitore non è memorizzato nella memoria flash. La segnalazione indica che l’ID è impostato a zero, e l’applicazione, una volta configurata con l’ID del trasmettitore, deve inviare un pacchetto TXID, prima che il codice cominci ad accettare I pacchetti. Il Wixel risponderà al pacchetto TXID con una segnalazione, indicando che il il TXID è stato memorizzato con successo nella memoria flash. IMPLEMENTATO (v2)
- Accetta un pacchetto ID del trasmettitore dall’applicazione del telefono e lo salva in flash. Nota, l’applicazione del telefono deve attendere un pacchetto di dati o una segnalazione prima di determinare se l’ID trasmettitore è errato ed inviare un pacchetto TXID al ponte. IMPLEMENTATO (v1)
- Invia, sotto forma di pacchetto dati, la percentuale di batteria del ponte, determinata dal voltaggio della batteria. IMPLEMENTATO (v2)
- Corregge automaticamente il pacchetto di “ascolto” per adattarsi durante il ciclo di programmazione. Questo assicura che ogni modifica al codice, non richieda anche una modifica del pacchetto di “ascolto” per un funzionamento affidabile. NON ANCORA IMPLEMENTATO
- Configura l’ID del modulo HM-10 per essere “xBridgeXX”, dove XX è il byte meno significativo del numero di serie del Wixel. Questo assicura che ogni ponte ha un, ragionevolmente, unico ID, rendendo la connessione Bluetooth con il telefono che esegue l’applicazione, più affidabile. IMPLEMENTATO (v2)
- Il Wixel non va’ in modalità di sospensione se è collegato ad una porta USB del PC. Ciò consente di sperimentare o rieseguire la scansione del dispositivo BLE da un’applicazione, se per qualunque motivo la connessione è persa o l’applicazione viene sostituita, mentre il ponte è stato programmato con un ID del trasmettitore. Permette anche la cattura di pacchetti da parte di un PC per l’analisi delle prestazioni. IMPLEMENTATO (v2.1)
Storia delle versioni passate
| 1 | Sperimentale e verifica dei concetti. Utilizzato per perfezionare il codice Packet Capture, sviluppare l’archiviazione nella flash dell’ID del trasmettitore, e il funzionamento generale del wixel come dispositivo ponte. Protocollo e comandi solo testo. |
| 2 | Versione pronta per il consumatore. Tutti i pacchetti vengono ritrasmessi come pacchetti binari. implementato:
· Wixel Power Mode 2 riposo · Wixel Power Mode 1 su USB connessa al PC. · Monitoraggio della batteria · HM-1x modulo disinserito · Protocollo livello funzionale 1 |
Protocollo
Ogni pacchetto di dati inviati o ricevuti dal ponte è descritto di seguito. Comuni a ciascun pacchetto sono i primi due byte di 8bit. Il primo byte è la lunghezza del pacchetto in byte. Il secondo è un ID per il tipo di pacchetto che viene inviato.
Si noti che i pacchetti inviati dal ponte ad un’applicazione telefonica includeranno un ultimo byte che rappresenta il livello funzionale del protocollo che viene programmato nel firmware della wixel. Questo è stato richiesto da Stephen Black, e ha senso. Se più funzionalità di protocollo saranno aggiunte in futuro, qualsiasi applicazione che utilizza il ponte dovrà sapere come gestire diverse versioni del livello firmware / protocollo nella wixel.
Pacchetto dati
Un pacchetto di dati viene inviato dal wixel all’applicazione del telefono. Esso contiene i dati rilevanti inviati dal trasmettitore Dexcom G4, oltre al voltaggio della batteria del ponte e TxID che sta analizzando.
Il pacchetto dati ha le seguenti strutture:
| Byte | Valore | Tipo di dati | Descrizione |
| 0 | 0x11 | 8 bit intero positivo | Numero di bytes nel pacchetto (17) |
| 1 | 0x00 | 8 bit Intero positivo | Codice per pacchetto Dati |
| 2:5 | Segnale Grezzo | 32 bit Intero positivo | Segnale grezzo del sensore |
| 6:9 | Segnale filtrato | Segnale del sensore filtrato | |
| 10 | Voltaggio della batteria di Dexcom TX | 8 bit Intero positivo | Voltaggio della batteria del trasmettitore. Di solito circa 214 per un nuovo trasmettitore. L’applicazione dovrebbe avvertire se questo raggiunge <= 207, che il trasmettitore richiede la sostituzione. |
| 11 | Percentuale della batteria del ponte | 8 bit Intero positivo | La percentuale della batteria del ponte (0-100). Questo è calcolato dalla tensione VIN usando un divisore di tensione resistivo 10k / 27k su P0_0. VIN di 3,2V (equivalente all’ingresso da 865mV su P0_0) è pari a 0%, poiché è la tensione di esercizio più bassa della batteria. VIN di 4V (equivalente a 1081mV in ingresso su P0_0) è 100%, in quanto questa è la tensione massima consegnata, la batteria rimane in modo stabile una volta che la corrente viene rimossa dalla batteria. |
| 12:15 | Dexcom TxID | 32 bit Intero positivo | ID del Transmettitore Dexcon codificato che il ponte sta analizzando |
| 16 | Livello di Protocollo di XBridge | 8 bit Intero positivo | Indica il livello di protocollo di xBridge. Si noti che attualmente questo sarà 0x01 |
Al ricevimento di questo pacchetto, l’applicazione del telefono deve elaborarla prendendo le parti del pacchetto che verrà utilizzato.
Se l’applicazione determina che il Dexcom TxID è diverso da quello impostato, dovrebbe inviare immediatamente un pacchetto TXID al ponte e ignorare il pacchetto. Se l’applicazione è soddisfatta del Dexcom TxID inviato, dovrebbe accettare il pacchetto e immediatamente inviare un pacchetto di riconoscimento. Il pacchetto di riconoscimento permette immediatamente alla wixel di entrare in modalità di bassa potenza.
La struttura del pacchetto di riconoscimento è la seguente:
| Byte | Valore | Tipi di dati | Descrizione |
| 0 | 0x02 | 8 bit intero positivo | Numero di bytes nel pacchetto (2) |
| 1 | 0xF0 | 8 bit intero positivo | Codice per il pacchetto Dati |
Questo pacchetto non include l’indicazione del livello funzionale del protocollo XBridge, in quanto arriva dall’applicazione al bridge.
Si noti che la wixel altrimenti entra in modalità di bassa potenza se non riceve un pacchetto di riconoscimento o TXID entro 3 secondi dalla trasmissione di un pacchetto di dati.
Sia il pacchetto di dati che il pacchetto di riconoscimento fanno parte del livello funzionale del protocollo 1 (0x01).
Pacchetto TXID
Il pacchetto TXID viene inviato dall’applicazione del telefono al ponte per impostare il ponte per filtrare su un unico ID Dexcom G4 trasmettitore. Ciò è importante per assicurare che il ponte “blocchi” correttamente il trasmettitore corretto per un paziente e anche per assicurarsi che l’applicazione riceve solo pacchetti dal trasmettitore del paziente che sta monitorando.
La struttura del pacchetto TXID è la seguente:
| Byte | Valore | Tipi di Dayi | Descrizione |
| 0 | 0x06 | 8 bit intero positivo | Numero di byte nel pacchetto (6). |
| 1 | 0x01 | 8 bit intero positivo | Codice del pacchetto dati |
| 2:5 | TxID | 32 bit intero positivo | L’intero 32 bit codificato rappresenta l’ID del trasmettitore Dexcom G4 che il ponte sta analizzando i pacchetti. |
Nota: poiché questo pacchetto viene inviato dall’applicazione al telefono, non include un byte a livello di protocollo XBridge.
Il pacchetto TXID fa parte del livello funzionale del protocollo 1, anche se l’applicazione non invia questo tag byte al dispositivo ponte.
Pacchetto Segnalazione
Il pacchetto Segnalazione viene inviato dal ponte all’applicazione telefonica per indicare quale trasmettitore ID Dexcom G4 sta analizzando. L’applicazione può utilizzare questa segnalazione per sapere quando il ponte è attivo, e se questo ha un diverso ID del trasmettitore per il quale l’applicazione è configurata, può correggere questo inviando un pacchetto TXID.
La struttura del pacchetto di segnalazione è la seguente:
| Byte | Valore | Tipi di Dati | Descrizione | |
| 0 | 0x07 | 8 bit intero positivo | Numero di byte nei pacchetti (6). | |
| 1 | 0xF1 | 8 bit intero positivo | Codice per il pacchetto Dati | |
| 2:5 | TxID | 32 bit intero positivo | L’intero 32 bit codificato rappresenta l’ID del trasmettitore Dexcom G4 da cui il ponte dovrebbe analizzare i pacchetti. | |
| 6 | Livello di protocollo XBridge | 8 bit Intero positivo | Livello di protocollo XBridge. Indica il livello di protocollo di xBridge. Si noti che attualmente questo sarà 0x01. |
Nota, questo pacchetto è anche raddoppiato come pacchetto di riconoscimento per un pacchetto TXID. Quando l’applicazione riceve questo pacchetto può essere sicura che questo sia il valore ID del trasmettitore impostato nella memoria flash wixel.
Il pacchetto di segnalazione fa parte del livello funzionale protocollo 1.
Decodifica e codifica di un trasmettitore ID Long Int
Affinché l’applicazione invii il valore corretto in un pacchetto TXID al ponte, è necessario che sia in grado di codificare il testo dell’ID trasmettitore ad un Long int. Questo viene fatto usando il seguente pseudo codice, prelevato direttamente dal codice originale xBridge. L’applicazione dovrà replicare questo processo per inviare i dati corretti.
char SrcNameTable[32] = { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'A', 'B', 'C', 'D', 'E', 'F','G', 'H', 'J', 'K', 'L', 'M', 'N', 'P','Q', 'R', 'S', 'T', 'U', 'W', 'X', 'Y' };
/* asciiToDexcomSrc - function to convert a 5 character string into a unit32 that equals a Dexcom transmitter Source address. The 5 character string is equivalent to the characters printed on the transmitter, and entered into a receiver.
Parameters:
addr-a 5 character string. eg "63GEA"
Returns:
uint32-a value equivalent to the incodeded Dexcom Transmitter address.
Uses:
getSrcValue(char)
This function returns a value equivalent to the character for encoding.
See srcNameTable[]
*/
uint32 asciiToDexcomSrc(char addr[6])
{
// prepare a uint32 variable for our return value
uint32 src = 0;
// look up the first character, and shift it 20 bits left.
src |= (getSrcValue(addr[0]) << 20);
// look up the second character, and shift it 15 bits left.
src |= (getSrcValue(addr[1]) << 15);
// look up the third character, and shift it 10 bits left.
src |= (getSrcValue(addr[2]) << 10);
// look up the fourth character, and shift it 50 bits left.
src |= (getSrcValue(addr[3]) << 5);
// look up the fifth character
src |= getSrcValue(addr[4]);
//printf("asciiToDexcomSrc: val=%u, src=%u\r\n", val, src);
return src;
}
/* getSrcValue-function to determine the encoding value of a character in a Dexcom Transmitter ID.
Parameters:
srcVal-The character to determine the value of
Returns:
uint32-The encoding value of the character.
*/
uint32 getSrcValue(char srcVal)
{
uint8 i = 0;
for(i = 0; i < 32; i++)
{
if (SrcNameTable[i]==srcVal) break;
}
//printf("getSrcVal: %c %u\r\n",srcVal, i);
return i & 0xFF;
}
La decodifica di un lungo ID del trasmettitore è molto più semplice. È possibile implementare una parte di codice simile se si memorizza l’ID come int lungo, ma si desidera visualizzare l’equivalente di testo.
// convert the passed uint32 Dexcom source address into an ascii string in the passed char addr[6] array.
void dexcom_src_to_ascii(uint32 src, char addr[6])
{
//each src value is 5 bits long, and is converted in this way.
addr[0] = SrcNameTable[(src >> 20) & 0x1F];//the last character is the src, shifted right 20 places, ANDED with 0x1F
addr[1] = SrcNameTable[(src >> 15) & 0x1F];//etc
addr[2] = SrcNameTable[(src >> 10) & 0x1F];//etc
addr[3] = SrcNameTable[(src >> 5) & 0x1F];//etc
addr[4] = SrcNameTable[(src >> 0) & 0x1F];//etc
addr[5] = 0;//end the string with a null character.
}
Nota sulla modalità Promiscua
In questo codice, se al wixel NON è stato inviato un pacchetto TXID, NON raccoglierà i pacchetti da qualsiasi trasmettitore Dexcom e li passerà all’applicazione smartphone. Questa è una caratteristica di sicurezza ed è di progettazione. Non si desidera che un’applicazione visualizzi o memorizzi dati da un trasmettitore di altri.
Tuttavia, nella parte del codice che raccoglie i pacchetti, è consentita la modalità promiscua.
Se si desidera veramente utilizzare la modalità promiscua, de-commenta nella sezione principale () Questa viene chiaramente commentata come la sezione che invia le segnalazioni fino a quando un pacchetto TXID imposta l’ID del trasmettitore. Quindi semplicemente non inviare mai un pacchetto TXID.
Operazione di base del codice
Il codice Wixel utilizza i seguenti passaggi quando si attiva o è acceso.
- Inizializza tutti i sistemi base IO e Wixel.
- Attende per 30 secondi, elaborando IO. Ciò consente di collegare un terminale seriale tramite USB, in modo da poter vedere cosa sta succedendo.
- Carica il registro dei flags interni salvati per determinare se ha impostato il modulo HM-1x. Fa questo solo la prima volta che viene eseguito dopo il caricamento del codice XBridge. Nessun punto che fa troppo spesso.
- Se il flag indica che l’HM-1x NON è configurato, lo configura.
- Carica i limiti della capacità della batteria dalla Flash. Se questi non sono impostati, li imposta sui valori predefiniti.
- Carica il valore TXID dalla Flash.
- Accende il modulo HM-1x.
- Se il valore TXID NON è impostato, entra in loop, in attesa di una connessione BLE e quindi invia pacchetti di segnalazione fino a ottenere un pacchetto TXID. Memorizza quindi tutte le impostazioni nella flash e va avanti.
- Entra in loop dove aspetta il pacchetto dal trasmettitore Dexcom.
- Se un pacchetto del trasmettitore Dexcom non viene ricevuto in 320 secondi (5 minuti e 20 secondi), invia un altro pacchetto di segnalazione e riprova. Il Wixel NON si fermerà fino a che non abbia catturato un pacchetto.
- Una volta che ha catturato un pacchetto, attende che sia stabilita una connessione BLE tra HM-1x e il telefono. Quindi invia il pacchetto di dati.
- Se un pacchetto ACK non viene ricevuto in 10 secondi, esso ri-invia il pacchetto di dati.
- Se viene ricevuto un ACK, salva tutte le impostazioni nella flash, spegne il modulo HM-1x, imposta tutto gli IO a basso consumo di energia e si spegne per circa 255 secondi.
- Alla riattivazione, rialimenta l’HM-1x, riavvia la radio e inizia ad aspettare nuovamente i pacchetti.
- In qualsiasi momento, è possibile ricevere un pacchetto dall’applicazione, o un pacchetto o comando dalla USB. Questo viene elaborato immediatamente e il programma torna al punto precedente.
Flusso di base delle comunicazioni
Dall’avvio dopo il caricamento del codice sul wixel, il codice xBridge2 inizia l’invio di pacchetti segnalazione a intervalli di 5 secondi su UART1 e USB (se è collegato). Per interrompere questo ciclo, un pacchetto TXID deve essere ricevuto su UART1 o USB (se collegato).
Una volta che la wixel ha ricevuto un pacchetto TXID e salvato le informazioni nella flash, inizia a scansionare i pacchetti Dexcom da quel trasmettitore.
Quando il wixel riceve un pacchetto di dati Dexcom, invierà un Data Packet su UART1 o USB (se collegato). L’applicazione ricevente deve elaborare il pacchetto e se il TXID inviato nel pacchetto è valido, può inviare un pacchetto ACK di dati che metterà immediatamente la wixel a riposo per un certo periodo di tempo prima del pacchetto successivo.
Se il TXID nel pacchetto di dati non è corretto, l’applicazione deve rimandare un pacchetto TXID al wixel per impostarlo sull’ID corretto.
La wixel invierà un pacchetto di segnalazione, se non ha ricevuto un pacchetto dati entro 5 minuti e 30 secondi di attiva. L’applicazione deve elaborare questo pacchetto e ignorare il pacchetto segnalazione se tutto è apposto o inviare un pacchetto TXID se la segnalazione contiene l’ID errato. Ciò assicura che quando un paziente cambia il proprio ID del trasmettitore nell’applicazione, la wixel può essere aggiornata al più presto dopo la sua attivazione e prima di ricevere un pacchetto dal nuovo trasmettitore. Se non venisse inviata una segnalazione all’attivazione della wixel, la wixel sarebbe semplicemente in loop a tempo indefinito fino a ricevere un pacchetto da un trasmettitore che non funzionava più.
La ragione per cui abbiamo dovuto inviare le segnalazioni in questo modo è per due motivi. In primo luogo, l’implementazione di BLE in Android non rileva chiaramente una connessione chiusa, e riprova la connessione ad una velocità sufficiente a garantire che si connetta immediatamente il modulo HM-1x acceso dalla Wixel. Altrimenti, avremmo inviato la segnalazione appena il Wixel si attiva e accende l’HM-10. Qualsiasi ritardo tra l’accensione e la cattura di pacchetti iniziali potrebbe impedire che un pacchetto dexcom venga perduto.
In secondo luogo, non vogliamo interrompere la cattura di pacchetti, quindi è meglio impostare un limite sulla cattura di pacchetti, fermare e inviare la segnalazione e quindi avviare nuovamente la cattura di pacchetti. Quindi, consentendo alla cattura di pacchetti di eseguire un po ‘più di quei 5 minuti previsti significa che abbiamo meno probabilità di perdere la cattura di pacchetti.
COSTRUZIONE xBRIDGE
Lista componenti
I componenti minimi richiesti per fare un circuito xBridge sono:
- 1x Pololu Wixel
- 1x Caricatore Adafruit Micro Lipo con connettore Micro USB (PRODUCT ID: 1904) o equivalente.
- 1x resistenza a film metallico da 10k 1% 1/2W.
- 1x resistenza a film metallico da 27k 1% 1/2W.
- 1x JNHuaMao HM-1X (HM-10/HM-11 con CC2541 SoC, o HM-16/HM-17) basata sul modulo BLE.
Nota: Se state ordinando un HM-10/11, assicuratevi di prendere un SoC CC2541 e non un SoC CC254. JNHuaMao non rilascia più il firmware per il SoC CC2540.
Nota: Se state ordinando un modulo HM-16/17, assicurarsi di specificare che la versione del firmware sia minimo la v119. Al momento non è possibile aggiornare il firmware sui moduli HM-16/17 da soli. - 1x Batteria ai Polimeri di Litio da 3.7V (LiPo). La capacità è una vostra scelta, ma raccomandiamo 1200mAh per un uso continuo di 5 giorni o più. Questa dovrebbe essere già dotata di un connettore JST, che si inserisce nella presa JST sulla scheda caricabatteria.
Come indicazione di quanto tempo possa durare una batteria, utilizzare la formula riportata di seguito. Nota che questo calcolo è solo teorico, non aspettatevi che questo numero sia esattamente reale. Questa formula è solo per il confronto delle capacità della batteria e si applica solo al circuito xBridge2 e al firmware wixel.
Durata in giorni = Capacità della batteria mAh/168.
Esempio del calcolo di durata della batteria.
Una batteria da 1200mAh durerà: 1200/168= 7,14 giorni.
Facoltativamente puoi includere:
- Un modulo ricevitore universale 20mm Reverse/Forward Micro USB Qi (Adafruit Product IDs 2114, or 2116. Questo si inserisce nella presa micro USB del caricatore
- Interruttore sul polo positivO della batteria per spegnere il trasmettitore.
- JST Spina con filo e Presa. Saldare la presa su GND e VIN (Assicurarsi che la polarità sia corretta, il cavo della batteria rossa va su VIN, il nero va su GND) e saldare la spina e il filo JST ai pin di uscita della scheda caricabatteria. È quindi possibile scollegare facilmente la wixel dalla batteria e dal caricabatteria quando non si utilizza il ponte
Schema circuito
Esistono 4 diversi circuiti per la costruzione del proprio xBridge.
- Modulo HM-10 o HM-16 connesso al Wixel e al circuito di carica Adafruit.
Nota: State molto attenti a non surriscaldare le piazzole di saldatura sul modulo HM-10. Sono molto delicate. Assicurarsi inoltre che i cavi non mettano pressione su queste.
2. HM-10 sulla scheda di supporto, con la scheda Wixel e Adafruit.
3. Modulo HM-11o HM-17
4. Modulo HM-11 di Chris Bothello’s (Grazie a Noah Terracalls).
Nota: a partire da v2.47.
Opzioni di Carica Batterie
Attenzione, è PERICOLOSO lasciare che la vostra batteria LiPo scenda sotto il suo voltaggio nominale anche per poco tempo. Anche se le batterie sono dotate di protezione contro lo scarico completo, continuano comunque a scaricarsi. Tenete sempre le vostre batterie LiPo cariche.
Il modo più ovvio di caricare la batteria è di connettere il modulo di carica Adafruit ad un cavo USB micro collegandolo ad una porta USB. Appena il LED Rosso si spegne e si accende quello Verde, la batteria è carica.
Questo, però, può non essere sempre comodo, specialmente se vi siete costruiti un sistema impermeabile. Avrete bisogno di aprire il contenitore per connettere i cavi.
Una soluzione usata frequentemente è la carica attraverso una base di ricarica senza fili Qi. Qi è uno standard wireless di ricarica per Smartwatch ecc. Adafruit (ed i loro rivenditori) vendono una serie di queste basi, vi consigliamo di acquistare quelle che sono dotate di presa micro. Collegate una di queste basi alla scheda di ricarica Adafruit, e mettete il ricevitore della carica, di piatto, all’interno di un lato del bridge che state usando. Poi appoggiatelo su un trasmettitore di carica Qi (disponibile ovunque per 20-50 Euro) che a sua volta è collegato via USB alla rete elettrica.
Una volta appoggiato sul trasmettitore di carica Qi, il LED di carica Rosso dovrebbe accendersi sul bridge. Probabilmente, dovrete muoverlo un pò per assicurarvi che il centro del ricevitore sia esattamente al centro del trasmettitore. Questa è l’unico problema con queste basi di ricarica wireless, è facile spostarlo accidentalmente e quindi interrompere per errore la ricarica.
A voi la scelta!
Aggiornamento firmware del modulo HM-10/11
ATTENZIONE: Seed Studio (www.seedstudio.com) ed alcuni altri fornitori distribuiscono moduli HM-11 che NON sono autentici, e quindi questa procedura non funzionerà con questi moduli. Un modulo HM-11 autentico deve rispondere ad un comando AT+NAME? con “OK+NAMEHMSoft”, ed apparirà sulla connessione BLE con il nome “HMSoft”. Se il vostro modulo NON risponde come descritto sopra, o non appare con il nome “HMSoft”, NON SARA AUTENTICO. Potrà comunque funzionare con la app wixel xBridge2, dato che la app riuscirà automaticamente a rilevare la velocità di trasmissione (Baud Rate) del modulo usandola correttamente.
Per essere certi dell’autenticità del modulo HM-11, vi suggerisco di acquistarlo da: https://www.fasttech.com/product/1740900-hm-11-bluetooth-v4-0-transceiver-ble-module.
Fornitore molto veloce ed affidabile.
Da notare anche che:
Il nuovo firmware non è presente sui moduli HM-10/11 che lavorano con il sistema CC2540 SoC. Al momento di ordinare il modulo HM-10/11 dovrete specificare il sistema CC2541 SoC.
Sui moduli HM-16/17 il firmware non può essere aggiornato. Al momento dell’ordine specificate la versione minima V119, e rispedite indietro il modulo nel caso non vi arrivi corretto.
Per assicurare un regolare funzionamento di XBridge e del modulo HM-1x, si raccomanda di aggiornare immediatamente il firmware del modulo HM-1x, una volta assemblato l’hardware.
Questo perchè i moduli sono spesso consegnati con SoC diversi (cc2540 o cc2541), e vari livelli di firmware diversi.
Per correggerli, aggiornateli almeno al livello V534. Questo è il livello con il quale è stato testato il codice wixel di XBridge. Nota: basta che il modulo risponda ad un comando AT con OK, e lavorerà correttamente con xBridge2.
Prerequisiti
Per prima cosa dovrete copiare o il file già compilato usb_serial.wxl (che può essere copiato da https://github.com/jstevensog/wixel-sdk/blob/master/apps/usb_serial/usb_serial.wxl), o compilarlo usando il wixel-sdk che trovate qui https://github.com/jstevensog/wixel-sdk. Collegate il vostro wixel ad un PC via USB, ed usate il programma di Configurazione Wixel (Wixel Configuration Utility) per caricarlo sul vostro wixel.
Secondariamente, avrete bisogno di un emulatore di terminale. In questo caso ci sono due opzioni; usare un programma standard (PuTTY, Hyperterminal, etc) o un emulatore di terminale Arduino. L’Arduino è probabilmente l’opzione da preferire, anche se si può usare un programma standard, quest’ultimo è solo piu’ pratico. Provate l’assistente (PC Comm Assistant) di JNHuaMao che trovate qui https://www.jnhuamao.com/HMPCComAssistant_en.rar, o se lavorate con Windows 10, sia qui https://www.jnhuamao.com/HMBLEComAssistant_x86.zip che qui https://www.jnhuamao.com/HMBLEComAssistant_x64.zip (dipende se state usando Windows a 32 o a 64 Bit).
Se usate un programma standard tipo per es. PuTTY, dovrete fare COPIA/INCOLLA del comando nella finestra del terminale. Questo perché il modulo HM-1x NON accetta caratteri CR o LF. Il modulo sente solo un ritardo alla fine della stringa del comando e cerca di eseguirlo. Se provate ad inserire il comando nel programma, questo vi ignorerà dato che non potrete scriverlo abbastanza velocemente da inserirlo completamente.
Nota: Settate i parametri di connessione a 9600 baud, 8 bits, 1 stop bit, no parity
Alcune persone mi hanno riportato di aver ricevuto moduli HM-1x che usano una velocità diversa (baud rate 115200). La documentazione del fornitore JNHuaMao dichiara che il baud rate di fabbrica dei moduli HM-10 e HM-11 è 9600 baud. Come ho fatto notare precedentemente, il modulo che avete ricevuto potrebbe non avere l’ultimo firmware, o potrebbe non essere stato resettato al test di Controllo Qualità e quindi consegnato non aggiornato. Al momento in cui caricate la versione del firmware aggiornata, il modulo DOVREBBE comunicare a 9600 baud. Se ancora non comunica alla velocità indicata, avrete bisogno di emettere il comando “AT+BAUD0” seguito da “AT+RESET”, in modo da confermare che il modulo sta ora comunicando alla velocità di 9600 baud, prima di caricare la app xBridge2 sul wixel.
Infine, andate all’indirizzo https://www.jnhuamao.cn/download_rom_en.asp?id=# e scaricate file zip contenente il firmware V534 che è quello corretto per il SoC sul vostro HM-1×0. Usate una lente d’ingrandimento per leggere in numero del modello sul vostro modulo. Dovrebbe essere sia CC2540 o CC2541. Se avete l’intenzione di farne alcuni, scaricateli tutti e due. Non potete sapere quale dei due otterrete. Aprite il file zippato in una nuova cartella. Vedrete un file readme.txt, un file HMSoft.bin (il firmware), ed un file HMSoft.exe (L’utility di aggiornamento del firmware).
Fasi dell’aggiornamento.
- Assicuratevi che il vostro wixel sia collegato al PC via USB.
- Assicuratevi di sapere qual è la porta COM usata. Potete servirvi del Wixel Configuration Utility per trovarla.
- Assicuratevi di aver installato il programma usb_serial.wxl sul wixel.
- Aprite il vostro programma emulatore (terminal program).
- Inviate “AT” al wixel. La risposta dovrebbe essere “OK”.
- Inviate “AT+SBLUP” al wixel. Risponderà con “OK+SBLUP”. Da questo momento è pronto ed in attesa di trasferimento del firmware aggiornato.
- CHIUDETE ORA IL PROGRAMMA EMULATORE (TERMINAL PROGRAM) !!!!!
- Aprite il file HMSoft.exe. Si aprirà una finestra come questa
- Cliccate sul bottone alla destra della stringa di testo “Image File:” e cercate il file image file. Esempio sotto.
- Inserite in numero della porta COM. Per es. in questo caso il mio wixel è sulla porta 10, quindi la mia schermata sarà come quella sotto:
- Cliccate su “Load Image”. La stringa mostrerà il processo. Il processo ha bisogno di alcuni minuti per completarsi. Una volta finito. il modulo HM-1x sarà aggiornato al livello richiesto. Chiudete la finestra di aggiornamento firmware (HMSoft Serial Bootloader).
- Per verificare il livello del Firmware del modulo, aprite l’emulatore (terminal program) ancora una volta. Inviate il comando “AT+VERR?”. Dovreste vedere la risposta “OK:HMSoft v534”
- Ora potete caricare il file xBridge2.wxl usando il Wixel Configuration Utility, ed il sistema e pronto per l’uso.
Modifiche per l’utilizzo dell’ app xBridge con il circuito xDrip-wixel.
Il firmware xBridge2 adesso rileva automaticamente se il circuito è collegato come un xDrip wixel “classico” o un xBridge, al momento dell’accensione. Si autoconfigurerà automaticamente per utilizzare l’originale commutatore di tensione di Chris Bothello nel caso venga rilevato un circuito classico, in modo da trasferire la capacità della batteria su xDrip.
Se utilizzate xBridge2 su un circuito classico. DOVETE selezionare xBridge come Metodo di Raccolta Dati (Data Collection Method) in xDrip/xDrip+, perchè in caso contrario il sistema non funzionerà.
La app xDrip può essere configurata in modo che NON mostri il livello della batteria del bridge ma che lo invii al Peeble, nel caso in cui non abbiate configurato il commutatore di tensione, o se accendete il bridge con metodi diversi (come collegandolo direttamente ad un telefono come alcuni hanno fatto).
Creare il programma xBridge wixel.
Per creare il programma xBridge wixel, utilizzate il Wixel SDK che trovate qui https://github.com/jstevensog/wixel-sdk. Questo SDK ha sia la libreria di attesa “lumos” che la libreria “slasi” radio_mac modificata. Sebbene il codice non usi la prima, usa la libreria radio_mac.
Leggete le istruzioni di Pololu per creare il programma se non avete familiarità con la creazione del programma.
Oppure, potete avere il file xBridge2.wxl dall’archivio (repository) in apps/xBridge2 (https://github.com/jstevensog/wixel-sdk/blob/master/apps/xBridge2/xBridge2.wxl), e caricarlo semplicemente sul Wixel usando la Wixel Configuration Utility.
Installazione dell’app xBridge sul Wixel
Prima di installare la app xBridge sul Wixel assicuratevi che TUTTI i telefoni o qualsiasi altro apparecchio che trasmette via BLE siano spenti (o che comunque il loro Bluetooth lo sia). Se qualche apparecchio trasmette ancora dei segnali Bluetooth, impedirà al modulo HM-1x di configurarsi correttamente SE un’altro apparecchio ha stabilito una connessione al modulo prima che la app xBridge app abbia iniziato i suoi tentativi di configurarlo.
La app xBridge adesso aspetta 30 secondi prima di iniziare, in modo che, se lo volete, potete collegarvi utilizzando un cavo USB ad un terminale per vedere il processo di avvio.
Aprite la Wixel configuration utility, poi aprite la app xBridge2. Collegate il vostro bridge al vostro computer via USB. Dovreste vederlo sulla Wixel Configuration utility come sotto:
Cliccate sul bottone Write to Wixel, e la app sarà caricata sul wixel.
Aspettate almento 30 secondi, fino a che vedrete acceso il LED Verde sul wixel, e almeno un lampeggio del LED Rosso. Eventualmente potete usare un terminale per vedere il processo di avvio.
A questo punto potete accendere il Bluetooth del vostro telefono facendo una scansione del vostro xBridge usando xDrip/xDrip+. Dovete cercare il nome tipo “xBridgeXXYY”, dove XX e YY sono caratteri alfanumerici. Una volta localizzato il nome, selezionatelo e la connessione al vostro xBridge sarà stabilita.
Se sul telefono vedete solo il nome HMSoft, per prima cosa provate a spegnere e riaccendere il wixel. Se questo non risolve, c’è un problema con la connessione seriale tra il Wixel ed il modulo HM-1x. Andate alla sezione Risoluzione dei Problemi.
Il LED Rosso lampeggiante (molto veloce e tenue, ogni 10 secondi) sta a significare che il wixel sta cercando di ottenere l’ID del Trasmettitore. L’impostazione predefinita di xDrip/xDrip+ è a “00000”. Avrete bisogno di configurare correttamente xDrip/xDrip+ per lavorare con xBridge.
Nella sezione Setting di xDrip/xDrip+, selezionate “xBridge Wixel” come fonte dati (di default è “xDrip Wixel”). Una volta fatto, si aprirà una nuova sezione chiamata “Dexcom Transmitter ID”. Selezionatela ed inserite il vostro ID del Trasmettitore Dexcom. Ricordatevi di inserire le lettere (A-Z) in MAIUSCOLO.
Apparirà anche una nuova sezione che vi permettera di visualizzare (o non visualizzare) il livello della batteria in xDrip/xDrip+. Le impostazioni predefinite lo visualizzaranno.
Dovreste ora essere in grado di far partire il vostro sensore, permettere a xDrip/xDrip+ di ottenere due misurazioni e aggiungere la doppia calibrazione per iniziare ad utilizzare il sistema.
Comandi di terminale seriale
xBridge2 supporta tre comandi da emettere su un terminale seriale collegato alla wixel tramite USB.
Nota: la wixel DEVE essere attiva per emettere questi comandi. Il modo migliore per assicurarsi cio, è quello di alimentare la tua wixel, in quanto rimarrà attiva finché non cattura un pacchetto dal trasmettitore Dexcom. In caso contrario, attendere che il LED di stato HM-1x lampeggi o si illumini, indicando che la wixel è attiva. Questo vale solo per un circuito xBridge.
Quando la wixel è alimentata, hai 10 secondi per collegare un terminale seriale prima che entri in funzione. Tentare di collegare un terminale seriale a una wixel non attiva non funziona. Provare di nuovo fino a quando non si riesce, se non è possibile accendere il wixel ciclicamente.
S – Premendo il tasto S vi verrà fornito un display di stato. Ciò è utile nella risoluzione dei problemi per far sapere come xBridge2 pensa che sia configurato.
D – Premendo il tasto D si attiverà la commutazione (accensione o disattivazione dell’uscita di debug) sulla linea seriale USB. Non dovrai farlo a meno che non si stia provando a utilizzare un xBridge2 con un programma seriale / USB o un dispositivo, che potrebbe essere confuso con l’output di debug. Naturalmente, se si segue la descrizione del protocollo, questo non dovrebbe essere necessario. Tuttavia, se si utilizza una libreria PERL Serial IO che prevede un parametro di fine linea o di ritardo di tempo, non è possibile effettivamente eseguire una acquisizione byte-by-byte del flusso e cercare i byte di identificazione per ciascun tipo di pacchetto. In questo caso, questo comando può essere utile.
B – Premendo il tasto B si accenderà e spegne “Sleeping” (spegnimento) del modulo HM-1x. Verrà visualizzato un messaggio che dice se è acceso o spento. Questo aiuterà quelli con telefoni o versioni Android che non si riconnettono in modo affidabile al dispositivo BLE una volta acceso. Se si verificano numerosi problemi di Bluetooth o perdita di pacchetti, è possibile utilizzare questo comando per impedire che il modulo HM-1x sia disattivato e quindi risolvere il problema. NOTA: questo influirà sulla durata della batteria del ponte.
P – Premendo il tasto P si ripristinano i valori di alta e bassa tensione della batteria ai valori predefiniti. Utilizzare questo solo quando l’indicazione della capacità della batteria in xDrip / xDrip+ è diventata inesatta. Questo ti eviterà di dover risanare nuovamente la wixel per correggerla. Mentre non ho mai sperimentato questo problema, con vari wixel e ponti, alcuni hanno riferito che le loro indicazioni sulla batteria diventano molto imprecise (sono semplicemente un’indicazione in ogni caso).
L – Premendo il tasto L commuterà la visualizzazione dei LED. Spegnendo i LED la durata della batteria sarà maggiore. Se ritieni che sia tutto apposto con xbridge, puoi spegnere i LED. Il più colpito è il LED Yellow BLE Connection Status sulla wixel. Altrimenti conosciuto come “Il sole ardente”. Potresti dormire meglio con questo spento.
Significato delle luci LED
I LED wixel indicano come segue:
| VERDE ACCESO | Mostra solo se il wixel è collegato ad un computer tramite la porta USB e un programma terminale è collegato ad esso.
|
| ROSSO, LAMPEGGIA TRE VOLTE, POI SI SPEGNE E RIINIZIA | Il programma xBridge2 è stato caricato ed è in attesa di un pacchetto TXID dall’applicazione (xDrip / xDrip + o qualsiasi altra cosa). |
| ROSSO SEMPRE LAMPEGGIANTE A INTERVALLI DI 1 SECONDO | xBridge2 ha ricevuto un pacchetto TXID, e sta scansionando il pacchetto dal trasmettitore Dexcom G4.. |
| GIALLO ACCESO | Il HM-1x e il telefono hanno stabilito una connessione BLE. |
Risoluzione dei Problemi
Ovviamente, la prima cosa da controllare sono le connessioni fra le varie schede. Assicuratevi che tutto sia corretto prima di continuare. Inoltre, se avete problemi con l’indicatore della capacità della batteria mostrata in xDrip/xDrip+, controllate che non ci siano saldature fredde o che non ci siano tracce di possibili cortocircuiti nel circuito di resistenza del divisore di tensione.
Problemi con l’aggiornamento del firmware del modulo HM-1x
Questi moduli sono piuttosto robusti e resistono bene. Se per caso si capita di togliere l’alimentazione dal modulo durante l’aggiornamento, dopo aver inserito il comando AT+SBLUP, non vi allarmate. Semplicemente il processo di aggiornamento non sarà stato completato. Alimentatelo nuovamente e inviate di nuovo il file del firmware. il processo verrà completato.
Il problema più comune, è stabilire la connessione con il modulo usando la seriale USB e l’app sul wixel. Mi è stato riportato (sebbene non l’abbia visto personalmente) che alcuni moduli sono stati consegnati con una velocità (baud rate) diversa da quella specificata dal produttore. Potete determinare la velocità settando il vostro programma a velocità diverse rilasciando poi un “AT” su ognuna della velocità fino a quando non riceverete “OK” in risposta. Al momento di caricare il nuovo firmware, la velocità (baud rate) dovrà essere di 9600 baud, che è anche quella usata da xBridge.
Appare il nome HMSoft, invece di xBridgeXXYY.
Se, quando collegate il vostro xBridge con xDrip/xDrip+ (o qualsiasi scan BLE) vedete il nome HMSoft, questo normalmente significa che:
- Quando avete caricato la App sul wixel, avevate una connessione Ble aperta in scan.
Scollegate il modulo BLE (meglio, chiudete e spegnete il Bluetooth da tutti i telefoni o altri apparecchi vicini), e ricaricate il codice wixel. - Non avete verificato che il vostro modulo HM-1x stesse comunicando alla velocità corretta di 9600 baud.
In questo caso o non avete aggiornato il firrmware, o semplicemente non avete controllato la velocità del modulo. Caricate nuovamente la app sul wixel, e controllate la velocità iniziando il ciclo da 115200 baud a scendere. Una volta determinata la velocità, caricate nuovamente il nuovo firmware sul modulo o all’ultimo inviate il comando “AT+BAUD0”, seguito da “AT+RESET”.
Come posso sapere se sta funzionando?
Prima di connettersi a xDrip/xDrip+ o ad una qualiasi altra app, il wixel dovrà attivarsi. Se non siete connessi con un cavo USB, attraverso un programma emulatore (terminal program) per almeno 30 secondi, all’ inizio, non noterete niente.
Se, invece, siete connessi, dopo 30 secondi, dovreste vedere il LED VERDE accendersi.
dato che il codice accende solamente il LED Giallo, quando la connessione BLE è effettuata con la normale operazione, potrebbe essere difficile capire cosa sta succedendo. Di seguito alcune istruzioni che potete seguire passo passo:
- Al momento in cui caricate il file xBridge2.wxl sul wixel e siete connessi via USB, il LED VERDE si accenderà dopo 30 secondi ed il LED ROSSO si accenderà brevemente. Il LED VERDE sta ad indicare la connessione stabilita attraverso la porta USB, il LED ROSSO che ha letto i suoi parametri dalla memoria FLASH.
- Usate un programma di scansione BLE o xDrip/xDrip+, per controllare la lista degli apparecchi BT. Dovreste trovare una connessione sotto il nome di XBridgeXX. Se la vedete, il wixel è attivo e ha configurato correttamente il modulo HM-10, e dovrebbe essere pronto a partire.
- Se, al contrario, vedete solo una connessione con il nome di HMSoft, il wixel non è stato capace di comunicare correttamente con il modulo HM-10. Controllate tutte le connessioni e collegamenti oltre a controllare che abbiate caricato il file xBridge2.wxl sul wixel.
- Se stabilite una connessione BLE al sistema, il LED Verde sul modulo HM-1x si accenderà ed anche il LED Giallo sul wixel si accenderà brevemente subito dopo. Questo indica che il wixel riconosce la connessione.
- Se non avete ancora inserito il vostro ID del Trasmettitore in xDrip/xDrip+, noterete che il LED ROSSO lampeggerà 4 volte ogni 10 secondi. Questo significa che il wixel sta indicando a xDrip/xDrip+ che non ha il codice ID del Trasmettitore.
- Se, al contrario, avete inserito il vostro codice ID del Trasmettitore on xDrip/xDrip+, ed il sistema l’ha ricevuto, il LED ROSSO lampeggerà (mezzo secondo acceso/spento) mentre attende il pacchetto dati dal trasmettitore.
NOTA: Se avete usato il comando L che indica il settaggio con LED OFF, nessun LED si accenderà.
- Se volete vedere più in dettaglio cosa sta succedendo, collegate il wixel con un cavo Mini USB ad un PC o un portatile. Dopo un certo periodo di tempo (fino a 5 minuti se era in modalita’ riposo quando lo hai connesso) il LED VERDE si accenderà. Collegate un programma emulatore (terminal program) al dispositivo. Il wixel sarà in modalità riposo (SLEEP) mentre è collegato al programma Terminale, ma è il solo modo che permetta alla USB di rimanere attiva, se ha ricevuto un pacchetto dal trasmettitore Dexcom, lo ha inviato e ha ricevuto un pacchetto ACK dall’applicazione.
- Se volete vedere il flusso di comunicazioni, potete aprire un terminal seriale e collegarlo al wixel. Usate 9600, 8, 1, no parity come settaggio del terminale. Vedrete che XBridge può inviare segnali di output che NON sono di testo, quindi potrete vedere occasionalmente lettere incomprensibili. Vedrete, però, molti messaggi di diagnostica che vi mostreranno cosa sta succedendo. Potete inviare un comando “s” o “S” dal terminale e riceverete un messaggio di stato, che vi dettaglierà i contenuti delle variabili di memorizzazione della Flash e le variabili che contengono questi valori nel programma. Vedete sotto per i dettagli sul tipo di messaggi che potete vedere.
Esempio di uscita su porta seriale USB
Lo schermo sopra indicato mostra un avvio dopo il caricamento del firmware. Notare che questa wixel era già stata connessa ad un’app xDrip / xDrip +. Come potete vedere, quando è stato avviato per la prima volta tutti i xBridge_flags sono stati impostati su 1 (ffff). Dopo l’impostazione e la configurazione dell’HM-1x, le flag sono ora impostate su fffe. Inoltre, le impostazioni battery_minimum e battery_maximum non sono ancora impostate (mostrando 65535).
Dopo aver configurato l’HM-1x, esso invia un pacchetto di beacon fino a ottenere un pacchetto TXID in risposta. Una volta ricevuto il TXID, salva tutte le impostazioni nella flash e inizia la scansione dei canali radio per un pacchetto.
In questa schermata successiva, puoi vedere che ha preso un pacchetto dal trasmettitore Dexcom. La wixel attende fino a che non ha una connessione BLE con il telefono, quindi invia una segnalazione (BEACON), quindi il pacchetto DATA, e attende un pacchetto ACK.
Una volta che lo riceve, salva le impostazioni nella flash (il messaggio di sopra) e va a riposo.
È relativamente frequente per l’attuale xDrip / xDrip +che l’app per impieghi un po ‘per stabilire una connessione. Da qui potete vedere tutti i messaggi “in attesa di pacchetti”. La wixel rimane in attesa per due minuti dopo la ricezione di pacchetti, di una connessione BLE. In alcune occasioni, questo non accadrà, e la wixel tornerà a riposo, questo verrà visualizzato come un pacchetto perso in xDrip / xDrip+.
In qualsiasi momento quando la wixel è attiva, è possibile premere il tasto “S” sulla tastiera per ottenere un display di stato. Vedi sotto.
Qui si può vedere che la wixel si è attivata e ha acceso l’HM-1x (ble on). Ha ricevuto un comando (ho premuto il tasto S) e lo sta elaborando. È possibile vedere i valori di default della batteria minima e massima e la capacità della batteria che è stata calcolata al 70%.
Test di funzionalità
I seguenti test vengono eseguiti su ogni iterazione del codice XBridge2 per assicurarsi che funzioni come previsto. Se state modificando questo codice, eseguite questi test per assicurarvi che il codice soddisfi queste funzioni minime.
Questa sezione sul test presuppone che tu abbia familiarità con Android Studio e l’utilizzo dei registri di Debug Android (ADB).
Prerequisiti per i Test
Per effettuare questi test avrete bisogno di:
- Telefono Android con debug USB abilitato.
- Android Studio
- Una copia dell’archivio app XDrip/xDrip+, che contiene il supporto XBridge.
- Una unità XBridge costruita seguendo i diagrammi di questo documento.
Test 1 – Trasmissione del pacchetto Beacon e settaggio del TXID.
- Assicuratevi che XDrip/xDrip+ stia funzionando che vediate i log ADB.
- Caricate di nuovo il file xBridge2.wxl nel modulo wixel. NOTA: NON fate partire e fermate semplicemente il programma wixel, riprogrammate la wixel con il programma in modo da cancellare la memoria Flash usata da XBridge2.
- Osservate il log ADB. Dovreste vedere questa sequenza di eventi:
- Serie di messaggi di connessione BLE GATT.
- Messaggi che indicano la ricezione del Pacchetto Segnalazione (Beacon).
- Messaggio che dice che il Pacchetto Segnalazione (Beacon) è sbagliato.
- Messaggio “sending message”.
- Ricezione di un altro Pacchetto Segnalazione (Beacon), che è la conferma del precedente.
- Il wixel rimarrà ora in ascolto e in attesa pronto per un Pacchetto Dati. Non ci sono messaggi che mostrano questa fase di ascolto/attesa, ma ci saranno messaggi al momento in cui sarà ricevuto un Pacchetto dati.
Test 2 – Ricezione dei dati Dexcom, ed avvio modalità di attesa (sleep).
- Osservate i log dell’ADB fino all’arrivo di un messaggio che vi confermi la ricezione del Pacchetto Dati. Nota, se utilizzate Android Studio, potete filtrarlo attraverso il DexCollectionService in modo da trovarli più facilmente.
- Una volta ricevuto, il mesaggio sarà seguito da una dicitura “invio messaggio” (“sending message”). Questo è il messaggio ACK del Pacchetto Dati, e metterà il wixel in attesa (sleep).
- Seguiranno una serie di messaggi che mostrano la disconnessione del BLE GATT, e la successiva connessione al BLE del sistema. Questo avverrà anche se il modulo HM-1x non è attivo.
Test 3 – Attivazione del wixel e ricezione dei dati Dexcom.
- Osservate il log dell’ADB fino che compaiano una serie di messaggi che confermano che la connessione al BLE GATT è in corso. Nota, anche se pensate che questo accada con intervalli molto regolari, non sempre succede. Questo non vuol dire che il wixel non si è attivato come programmato, né che abbia perduto un pacchetto di dati. L’esecuzione del BLE non rileva automaticamente quando un sistema accoppiato sia nuovamente disponibile.
- Ad un certo punto, dopo che la connessione BLE è stata stabilita, il log ADB mostrerà la ricezione di un Pacchetto Dati come dal Test 2 sopra descritto. In funzione dei tempi, potrebbe anche mostrare la ricezione di un Pacchetto Beacon, che sarà preso in considerazione solo se il TXID non è ciò che la app si aspetta.
- Il wixel ritornerà in modalità di attesa (sleep) come descritto nel Test 2 sopra.
Note di Utilizzo
Usando il codice xBridge ci sono alcune cose da ricordarsi, e molte di queste serviranno anche per usare il codice xDrip-wixel.
- Cambiate la batteria quando la carica scende sotto il 40%. Dato che misuriamo in modo molto semplice il voltaggio per determinare la capacità, e le batterie LiPo si scaricano in modo più veloce man mano che arrivano al loro voltaggio minimo, consigliamo di ricaricarle a questo livello di carica e non aspettare oltre. Anche se la batteria potrebbe lavorare ancora alcune ore a questo livello, certamente non durerebbe molto.
- Tenete il bridge vicino a voi. Anche se il modulo BLE avrebbe una portata maggiore ed una affidabilità maggiore del protocollo originale a 2.4 GHz usato dal trasmettitore Dexcom, è comunque consigliato tenerlo ad una distanza di 20pollici / 6 mt di raggio.
- Allo stato delle cose, il bridge può perdere occasionalmente delle misurazioni. Stiamo ancora ricercando le cause di questo comportamento. Se usate un caricatore wireless Qi, questa perdita potrebbe essere più frequente probabilmente a causa del campo elettromagnetico che interferisce con il ricevitore Wixel.
- Se avete problemi con la versione di Android del vostro telefono e con il Bluetooth, per la connessione e la disconnessione che xBridge2 utilizza per risparmiare la carica della batteria, potete provare a mantenere il BLE sempre attivo. Usate il comando “B” in una finestra di Terminale per attivare o disattivare questa funzione. Se decidete di avere il BLE sempre attivo, questo consumerà maggiormente la batteria. La connessione al telefono, però, rimarrà stabile fino a che il bridge rimane nel range di portata del telefono.
NOTA: il modulo HM-1x NON mostrerà il LED DI STATO Verde quando il wixel è disattivato. Questa è una caratteristica non documentata di questi moduli quando le linee seriali sono inviate in LOW, che è ciò che fa il wixel quando entra in modalità di sospensione per risparmiare la carica della batteria. - Le indicazioni del livello della batteria in xDrip/xDrip+, come vengono calcolate e trasmesse dal xBridge2, NON sono precise. Questa è solo in indicazione di massima. Questo perchè viene misurato il voltaggio della batteria e non il livello di corrente che entra ed esce dalla batteria.
Di seguito alcune annotazioni da seguire:
- Anche se l’indicazione è al 100% della carica della batteria, questa potrebbe NON essere caricata completamente. Caricate sempre la batteria fino a che il LED Verde sul caricatore vi indica che la batteria è al massimo della carica.
- Quando interrompete la carica, la capacità della batteria scenderà rapidamente. Questo perchè il voltaggio usato per caricare la batteria è molto maggiore di quello nominale della batteria stessa. Quanto potrebbe calare dipende da come la batteria viene caricata. Se completamente carica, il livello scenderà intorno al 90% in poche ore, secondo il tipo di capacità (mAh) della vostra batteria
- Al momento in cui la carica della batteria raggiunge il 30%, la batteria si scaricherà rapidamente. Cambiate la batteria prima possibile al raggiungimento del 30% di carica.
 Da Padre a padre, dico grazie all'autore per aver fatto sorridere la mia bambina. Ci ha relagato uno sprazzo di magia Ho pianto nel vedere la mia bimba felice di leggere di una bimba come lei |
Vuoi parlare con le migliaia di amici che hanno già sperimentato le soluzioni proposte su DeeBee.it? Vuoi fare qualche domanda su un argomento specifico per conoscere le opinioni ed i suggerimenti di chi ci è già passato? Vuoi suggerire tu qualcosa dicendo la tua?
Non devi fare altro che iscriverti nel gruppo Nightscout Italia ed otterrai risposta ad ogni tua domanda! Nel nostro gruppo affrontiamo ogni tematica inerente il diabete (non solo tecnologia ma anche leggi, sport, alimentazione, accettazione, gestione quotidiana, L104, ecc., sia per adulti che per bambini).
Enjoy!
Ti potrebbero interessare anche...
