Jumping Jack Flash weblog

COVID-19 – Misurare temperatura corporea con accuratezza di +/-0.1°C – puntata 2

Posted in hardware by jumpjack on 22 maggio 2020

— IN AGGIORNAMENTO — PROGETTO IN CORSO —

E’ arrivato l’ultimo componente hardware necessario per il progetto: il ClosedCube breakout SHT35-D. Datasheet.

 

Quello che serve adesso per realizzare il progetto completo è:

Hardware

  • nuovo supporto stampato in 3d per il cinturino
    • ne ho stampato uno provvisorio tanto per provare, e funziona, ma non avendo tra  le mani la schedina SHT35 non potevo progettare quello definitivo, che contiene sia l’m5stickC che il sensore
    • FATTO; da mettere online il file 3d –>è sbagliato perchè l’ho predisposto per avere i pin dell’SHT sul lato dell’m5stickC col connettore lungo, ma i pin SDA/SCL sono sul connettore GROVE!
    • testare fissaggio del cinturino con perni in fil di ferro
  • connessione hardware tra sensore e m5stickC

M5stickC pinout

24/5/2020: FATTO. Connessione effettuata, sketch di prova funziona: vedo valori di temperatura e umidità sulla seriale; però ho dovuto cambiare da 0x44 a 0x45 l’indirizzo I2C del sorgente di esempio.

In compenso non vengono mostrati correttamente i valori float sul display, nonostante la copiatura dall’esempio “TFT_Float_Test.ino”

    • Esiste comunuque una libreria che permette di usare come pin I2C qualunque coppia di pin
    • L’alimentazione dell’SHT35 può essere sia 3.3V che  5V (max 5.5V), e la Vout della porta GROVE è 5V.
  • Altri pin utili:
    ESP32 GPIO10 GPIO9 GPIO37 GPIO39
    RED LED LED pin
    IR transmitter Transmitter pin
    BUTTON A Button pin
    BUTTON B Button pin
  • isolamento elettrico dei contatti del sensore dal sudore della pelle
  • verificare presenza di cicalino a bordo per allarme acustico in caso di temperatura pericolosa –> no, serve esterno

Software

Il software dovrà avere una serie di componenti, alcuni accessori, altri indispensabili; ovviamente non reinventerò la ruota ma andrò scopiazzando di qua e di là cosa c’è di disponibile. Chiaramente la prima cosa da fare è visualizzare la temperatura, anche senza ora attuale; il resto verrà dopo.

  • scansione dispositivi I2C (anche le periferiche di bordo sono su I2C, su pin vari) LINK
  • lettura e visualizzazione dati sensore SHT35
    • c’è una libreria specifica ClosedCube e una Adafruit, verificare
    • pare che nella libresria ClosedCube esista un modo per leggere la temperatura “periodicamente”, verificare se consuma di meno –> è una caratteristica del sensore, ma consuma 30 volte più corrente della lettura singola (70 uA invece che 2 uA)
    • Nella libreria ClosedCube il risultato della lettura del sensore tramite le varie funzioni possibili è di questo tipo:
      struct SHT31D {
      float t;
      float rh;
      SHT31D_ErrorCode error;
      };
      Quindi bisogna:

      • Definire la variabile:
        • SHT31D   risultato;
      • Assegnare alla variabile il valore della lettura effettuato tramite una delle 3 funzioni:
        1. readTempAndHumidity(repeatability, mode, timeout);
          • E’ la più generica: permette di scegliere una delle altre due in base al parametro “mode”.
        2. readTempAndHumidityClockStretch(repeatability);
        3. readTempAndHumidityPolling(repeatability, timeout);
      • Non sono riuscito a trovare nessuna info in merito alla differenza dei due metodi, quindi userei quello più semplice, con singolo parametro, tenendo in considerazione l’unica cosa che ho capito: più è basso il valore di repeatability, minori son i consumi; e noi dobbiamo tenere i consumi al minimo per prolungare la durata della batteria. Useremo quindi la funzione 2, con parametro pari alla costante SHT3XD_REPEATABILITY_LOW.
      • Utilizzare di temperatura contenuto nella variabile-risultato:
        • risultato.t
  • impostazione ora attuale
    • ho scoperto che è possibile impostare l’ora del PC sull’ESP32 al momento del caricamento dello sketch; questa riga memorizza in una variabile data e ora attuale:
      const char compile_date[] = __DATE__ ” ” __TIME__;
      risultato: May 22 2020 16:55:46  –> verificare configurabilità formato
    • l’orario andrà in qualche modo memorizzato nell’RTC di bordo
    • l’istruzione setTime(8,29,0,1,1,11) è valida solo per Arduino/AVR o anche per ESP32/M5stickC?
    • ho trovato diversi sorgenti, sia per orologi digitali che analogici; molti si basano su millis(), ma sarebbe meglio basarsi sull’RTC incorporato; pare che abbia una pessima precisione (5%, quindi un minuto perso ogni 3 ore!) se basato su riferimento interno, ma ottima se basato su un cristallo “esterno”: da verificare quanto/come “esterno. Discussione, discussione
    • esempio ufficiale RTC su M5stickC
    • si può usare server NTP er impostare l’ora; ci sono vari sorgenti, ma bisogna prima riuscire a collegarsi al WiFi! E al momento il mio m5stickC non si collega… Impostare oratio NTP con una riga singola: configTime(0, 0, “pool.ntp.org“);
  • visualizzazione ora/data: FATTO
  • visualizzazione livello batteria
  • impostazione deepsleep: la batteria deve durare almeno 24 ore, chissà se è possibile.
    • verificare i consumi in deepsleep dell’m5stickC –> 10uA (solo RTC e RTC memory); è presente anche un ULP (Ultra Low Power) processor, che consuma appena 100 uA o 150 uA durante il deepsleep, secondo come viene impostato, ma va programmato separatamente dallo sketch principale.
    • verificare i consumi in deepsleep dell’SHT35 –> 2 uA in attesa, 1500uA in misurazione, durata da 4ms a 15ms a seconda della ripetibilità impostata
    • Considerando i dati sopra, con un consumo di 12uA e una batteria da 80.000 uAh si avrebbe un’autonomia teorica di 6666 ore. Ovviamente però ogni tanto il dispositivo si accende, vuoi per leggere i valori e salvarli, vuoi perchè consultato dall’utente, quindi i consumi reali sono da valutare. Poichè l’M5stickC è dotato di appositi comandi per leggere la quantità di corrente assorbita in un dato momento grazie al power manager di bordo AXP192, volendo è possibile salvare questi dati durante l’utilizzo e fare una stima dell’autonomia reale possibile.
  • logging dei dati in memoria FLASH tramite SPIFFS; esempio1
  • visualizzazione grafico temperatura delle ultime X ore direttamente sul display; bisogna tracciare gli ultimi “n” valori; il display è 80×160. la temperatura può oscillare tra 36.0 e 38.0, quindi basterebbe una striscia alta 20 pixel. drawPixel(int16_t x, int16_t y, [uint16_t color]);
  • visualizzazione alert visivo in caso di temperatura pericolosa: usare immagini in formato XBM (BMP monocromatiche in formato testuale/esadecimale)
Tagged with: , , ,

leave a comment

COVID-19 – Misurare temperatura corporea con accuratezza di +/-0.1°C

Posted in hardware by jumpjack on 15 maggio 2020

Ai tempi del COVID-19, per molte settimane – e speriamo non mesi – ci verrà misurata la temperatura in continuazione: andando a lavoro, entrando nei locali, andando dal barbiere; per ora infatti è l’unico modo istantaneo per verificare, anche se molto a grandi linee, se si è infetti o no.

Potrebbe allora essere comodo potersi misurare da sè la temperatura corporea, senza dover stare ogni volta 5 minuti col termometro sotto l’ascella, o senza spendere 50 euro per un termometro a infrarossi; senza contare che sarebbe molto utile poter avere un grafico dell’andamento della temperatura nella giornata.

Stanno iniziando a comparire sul mercato i primi braccialetti fitness o smartwatch con termometro incorporato, ma per ora solo in spedizione dalla Cina, e comunque nessuno fornisce il grado di accuratezza della misurazione (tranne questo, che dichiara 0.1°C); e considerando, ad esempio, che per esempio che il termometro di una tipica stazione meteo ha un’accuratezza dichiarata di +/-2°C, significa che se usassimo quel termometro per misurarci la febbre, e avessimo 37.5°, quel termometro potrebbe dire un qualunque valore fra 35.5° (in ipotermia) o 39.5° (con le pezze in fronte)…

Serve quindi una misurazione molto più precisa, con uno scarto di pochi decimi di grado.

Ecco allora un elenco di alcuni sensori di temperatura ad alta accuratezza: anche se, usandoli per il fai-da-te, non possono essere usati come presidio medico per decidere se e come curarsi, possono comunque dare un valido indizio per decidere se poi farsi una misurazione seria con uno strumento certificato.

Ecco dunque la lista:

  1. SHT35: +/-0.1°C (Sensirion) (temperatura/umidità)
  2. STS35: +/-0.1°C (Sensirion) (solo temperatura)
  3. SHT85: +/-0.1°C (Sensirion) (temperatura/umidità)
  4. Si7051: +/-0.1°C (Silicon Labs)
  5. MAX30205: +/-0.1°C (Maxim Integrated)
  6. MAX30208: +/-0.1°C (Maxim Integrated)
  7. MCP9808: +/-0.1°C  (Microchip) (solo temperatura)

 

Altri  meno accurati:

 

Sono tutti sensori davvero minuscoli, grandi quanto l’unghia del mignolo, quindi impossibili da gestire con un saldatore classico: servirebbe un fornetto per saldature SMD. Per fortuna però per molti esistono delle versioni già saldate su breadboard; alcune sono molto rare e disponibili solo in ordine dalla cina, ma altre sono piuttosto diffuse e si trovano su ebay Italia o addirittura su Amazon, alcuni persino con spedizione gratuita con Prime da un giorno all’altro.

E’ importante quindi saper distinguere quale è il migliore. I dati di accuratezza  sono espressi come un singolo numero, ma un modo più preciso per definire l’accuratezza è un grafico; nei datasheet di questi oggetti sono presenti grafici come questo, che indicano quant’è il massimo possibile errore di misurazione (asse Y, a sinistra) alle varie temperature (asse X, in basso):

Questo grafico dice ad esempio che per questo specifico componenbte “tipicamente”, per misurazioni tra +20°C e +60°C, lo scarto tra temperatura misurata e reale è di 0.1°C, mentre quello “massimo” è di 0.3°C.

Prendendo i grafici di tutti i vari sensori e raggruppandoli tutti in un’unica figura, ho ottenuto quanto segue:

Si nota chiaramente come tutti i sensori siano più accurati nella zona di interesse, che è quella della temperatura del corpo umano, la quale può variare fra 35 e 43 gradi, dove ovviamente i valori estremi si hanno solo in caso di gravissima malattia: la temperatura tipica di un essere umano in salute è infatti di circa 37°C. “Circa” perchè la temperatura può variare per vari motivi:

In base al punto di misurazione:

In base al momento della misurazione:

Persino in base all’umore:

 

Questa tabella indica alcune temperature di riferimento, da cui si evince perchè bisogna allertarsi, in tempi di pandemia mondiale da coronavirus, se la temperatura sale sopra i 37.5°C:

Scelta del sensore

Qual è il sensore migliore tra quelli elencati prima?

Ovviamente quello che ha deviazione/errore più basso in prossimità dei 37 gradi, quindi quelli della prima lista, con accuratezza di 0.1°C; poi però bisogna trovare:

  1. quello più facilmente reperibile in Italia
  2. il meno costoso
  3. quello più pratico

Per il punto 1: scartiamo quindi quelli su Aliexpress e simili, che probabilmente, ordinati a maggio 2020, arriverebbero dopo che sarà stato inventato il vaccino… Orientiamoci quindi su siti italiani, su Ebay con spedizione dall’Europa, e su Amazon.

Per il punto 2: se c’è su Amazon, vediamo se è disponibile con spedizione gratuita.

Per il punto 3: verifichiamo se ci sono già librerie disponibili per Arduino, o addirittura kit di test già pronti.

 

Per quanto riguarda Amazon Prime, la scelta è molto limitata: ci sono solo SHT35 e Si7051. Su Ebay la scelta è un po’ più ampia: SHT35, SHT85, Si7051,  MAX30205.

Per quanto riguarda le librerie Arduino, ce ne sono per i Sensirion SHT3x e per i Silicon Labs Si7051 dalla Adafruit (o anche per i Silicon Labs Si7013, Si7020 e Si7021, che però hanno accuratezza troppo bassa (+/-0.5°C)).

Schede preassemblate

SHT31 Smart Gadget

Il Sensirion SHT35 ha un punto a suo favore in più: esiste un modulo già assemblato dotato di batteria tampone, circuito di lettura del sensore e schermo LCD, cose che altrimenti dovremmo aggiungere noi a mano, assemblare e testare: si chiama SHT31 Smart Gadget:

Clicca qui per una foto a risoluzione esagerata: link

Lo Smart Gadget è disponibile su:

Come è facile intuire dal nome, non è basato sull’SHT35 da +/-0.1°C ma sull’SHT31 da +/-0.2°C: ci si può accontentare di 0.2, oppure si può pensare di sostituire il sensore SHT31 con un altro: la scheda infatti espone i 4 pin a cui è collegato il sensore tramite protocollo I2C (Vcc, GND, SDA, SCL), che quindi può essere staccato e facilmente sostituito, a livello di hardware; per quanto riguarda la compatibilità SW, dal momento che le librerie arduino sono dichiarate come compatibili per tutti i modelli SHT3x, è ipotizzabile che anche questa scheda già pronta sia compatibile con tutti gli SHT3x. Naturalmente per esserne sicuri al 100%, anche qui bisognerebbe leggere in dettaglio nel datasheet i registri e i protocolli.

Importante anche l’indirizzo I2C assegnato: per certe board che montano SHT31 può essere impostato su 0x44 (default) o 0x45 a seconda di come è connesso il pin ADR (ADDRESS). Altre board hanno indirizzo fisso non modificabile, quindi non sono adatte:

Sullo smart gadget l’SHT31 ha il pin ADDR collegato all’alimentazione, quindi, da datasheet, l‘indirizzo è impostato su 0x45.

Lo Smart gadget è dotato di memoria onboard e capacità di logging, e sono disponibili due app della Sensirion stessa per scaricare i dati e mostrarli sul cellulare Android o iOS (qui l’app Android precedente e ormai abbandonata).

Il sensore esterno SHT35 si trova già montato su basetta con connettore GROVE, preimpostata su indirizzo 0x45, quindi direttamente collegabile al gadget.

L’immagine che segue mostra il retro di una schedaGrove SHT35, evidenziando le piazzole utilizzabili per modificare l’indirizzo dal default 0x45 a 0x44:

Affinchè una scheda SHT35 funzioni su uno Smart Gadget SHT31, deve essere impostata sullo stesso indirizzo che l’SHT31 ha sulla scheda (0x45); in caso di errore non si rompe niente, ma il sensore non verrà visto dalla scheda.

E’ disponibile, tra parentesi, anche una libreria Arduino per il sensore STS35, sempre della Sensirion, sempre da +/-0.1°C, ma solo sensore di temperatura (mentre l’SHT35 contiene anche un sensore di umidità ambientale, in realtà inutile per la nostra applicazione).

Sempre su RS è disponibile anche una board in formato “Grove” contenente il sensore SHT35 (disponibile da giugno) a 15,00 euro o su robot-domestici a 26,00 euro.

Questo è il manuale dello Smart Gadget, questa la pagina ufficiale

Esaminando i file gerber dello SmartGadget, è spossibile individuare come e a cosa sono connessi i vari pin, e scoprire che dal lato opposto della batteria c’è proprio una predisposizione per collegare un sensore esterno:

 

Basta quindi tagliare le piste di rame vicino al sensore, saldare il nuovo sensore alle piazzole libere, e ottenere quindi (in teoria) uno Smart gadget con accuratezza di +/-0.1°C anzichè 0.3°C; la rimozione dell’SHT31 è in ogni caso necessaria perchè è montato dalla parte del display, mentre è necessario che sia attaccato al polso per leggere correttamente la temperatura, ma una volta rimosso potrebbe risultare difficile, se non impossibile, risaldare i fili ai vicinissimi terminali del sensore, o ai forellini sul PCB per cui passano le piste di rame.

Scheda M5stickC

Una possibile alternativa quasi-già-pronta, essendo disponibili le librerie arduino, è l’utilizzo di una board M5StickC (da non confondere con M5Stack):

Anche se non dispone di un sensore di temperatura integrato, questo dispositivo è dotato di:

  • Microcontrollore ESP32 dualcore a 240 MHz con 4 Mbyte di RAM
  • Bluetooth
  • Wifi
  • Schermo OLED
  • Connettore GROVE (adatto per sensore esterno Grove SHT35)
  • Pulsanti
  • Accelerometro
  • Giroscopio
  • Trasmettitore IR
  • Segnalatore acustico
  • Predisposizione per attacco a cinturino
  • Batteria da 95 mAh
  • Connettore USB

La quantità di progetti realizzabili con un simile dispositivo è enorme, per cui, una volta terminata la necessità di misurarsi la temperatura tutto il giorno, può essere riciclato per altri usi.

E’ disponibile su Amazon Prime (B07QRQ4MP8) a 25 euro inclusivo di cinturino:

Naturalmente in questo caso il SW sarà tutto da scrivere, ma essendo l’ESP32 programmabile tramite Arduino, si tratta solo di usare le già citate librerie Arduino adatte per il proprio sensore e trovare un sorgente di esempio da cui partire.

Per quanto riguarda il cinturino, se si possiede già un M5tickC senza cinturino, o si vuole comprarlo senza per risparmare, usando un vecchio cinturino, qui c’è il modello 3d dell’involucro dell’M5stickC, su cui lavorare per crearsi manualmente l’aggancio in plastica per il cinturino:

 

Fai da te: Arduino/ESP8266/ESP32

Librerie

Sorgenti di esempio:

Questo sorgente di esempio si limita a stampare la temperatura sul monitor seriale; chiaramente l’applicativo finale dovrà invece stamparlo su un display:

#include <Arduino.h>
#include <Wire.h>
#include "Adafruit_SHT31.h"

Adafruit_SHT31 sht31 = Adafruit_SHT31();

void setup() {
  Serial.begin(9600);
  if (! sht31.begin(0x44)) { // Qui c'è l'indirizzo I2C del sensore; per alcuni è fisso a 0x40, per altri si può modificare tra 0x44 e 0x45
    Serial.println("*ERR01* Sensore non presente a indirizzo 0x44");
    while (1) delay(1);
  }
}

void loop() {
  float t = sht31.readTemperature();

  if (! isnan(t)) {
    Serial.print("Temp *C = "); Serial.println(t);
  } else {
     Serial.println("*ERR02* Lettura errata");
  }

  Serial.println();
  delay(1000);
}

 

 

Sensori su breadboard

Per SmartGadget (serve indirizzo 0x45):

 

Tagged with: , , , , , , , , , , , , , , , , , ,

2 comments

Appunti su programmazione ATTINY85 su piattaforma Digistump Digispark

Posted in arduino, hardware by jumpjack on 25 ottobre 2019

L’attiny85 è un minuscolo microcontrollore con soli 6 pin con una minuscola memoria di 8 KB e una frequenza di lavoro di 16MHz, ma per alcuni progetti può benissimo sostituire una ben più costosa e ingombrante Arduino o Raspberry; per esempio per leggere semplicemente i valori di un dispositivo con interfaccia I2C.

L’unico problema è superare alcuni “scogli” per riuscire a programmarla tramite il normale IDE di Arduino; in giro c’è una moltpelicità di guide che spiegano trucchi e schemi elettrici vari per riuscire a programmare il modulo Digispark con l’arduino IDE usando una Arduino Uno come “ponte”…. ma sono obsoleti, non ce n’è più bisogno, ora si può semplicemente collegare il dispositivo al PC e caricarci direttamente lo sketch. Però bisogna seguire alcuni accorgimenti:

  1. Il problema dei driver
  2. Il problema del LED
  3. Il problema del mancato riconoscimento USB (suono continuo di connessione/disconnessione)
  4. Il problema della porta seriale

I driver

Servono dei driver specifici, che potrebbero non venire installati automaticamente quando si installa Arduino IDE, quindi ecco il link per scaricarli

Il LED

Esistono diverse varianti della board (rev2, rev3, rev4,…); sono identiche tranne per il pin a cui è collegato il LED: a volte 0, a volte 1; se è collegato al pin 0, non è possibile comunicare con dispositivi I2C, quindi va scollegato.

Mancato riconoscimento USB (suono continuo di connessione/disconnessione)

Connettendo il dispositivo a una porta USB, si sente inizialmente il classico suono di disconnessione, ma dopo 5 secondi si sente quello di disconnessione, poi di nuovo quello di connessione, e così via all’infinito.

Il problema è che… va bene così, è così che deve funzionare, non è rotto. E’ solo che va programmato in modo diverso da Arduino: prima di connettere il Digispark, bisogna avviare l’upload dello sketch, e solo dopo, quando è l’IDE stesso a chiederlo, bisogna collegare il dispositivo, e lo sketch verrà caricato. E una volta caricato il primo sketch, non ci sarà più il problema di connessione/disconnessione continua.

Dal manuale ufficiale:

You do not need to plug in your Digispark before invoking upload. Hit the upload button. The bottom status box will now ask you to plug in your Digispark – at this point you need to plug it in – or unplug and replug it. You’ll see the upload progress and then it will immediately run your code on the Digispark. If you unplug the Digispark and plug it back in or attach it to another power source there will be a delay of 5 seconds before the code you programmed will run. This 5 second delay is the Digispark Pro checking to see if you are trying to program it.

La porta seriale

Il problema della porta seriale… è che non c’è porta seriale, quindi il comando Serial.print() non è implementato e il Serial Monitor dell’IDE non si può usare.

Si può ovviare al problema installando una libreria a parte:

Altri metodi di debugging: link

Sensori I2C

Il digispark può leggere dati da sensori digitali tramite protocollo I2C (pin SDA e SLK):

  • SDA: pin 0
  • SCL: pin 2

Installando la scheda nell’IDE Arduino si rende disponibile uno sketch per la scansione di tutti i dispositivi I2C collegati (i2cscanner.ino)

Emulazione tastiera

Fortunatamente il Digispark non ha solo problemi, ma anche vantaggi; per esempio, nonostante le minuscole dimensioni, poichè gira a 16MHz e va a 5V, a differenza di altre board è in grado di emulare dispositivi HID (joystick, tastiere, mouse,…)

Connessione Android USB

Essendo in grado di emulare una tastiera, il Digispark può essere anche connesso via USB a uno smartphone che supporti l’OTG; il che significa che in sostanza si può usare per collegare a un dispositivo Android un qualunque sensore dotato di interfaccia I2C. Sorgenti di esempio.

 

Tagged with: , , , , , , , ,

leave a comment

Hacking Icaro – centralina GSM – il logger seriale

Posted in minicar elettriche by jumpjack on 13 giugno 2019

Questo primo sketch di prova utilizza una board ESP32 per leggere i dati scambiati tra il microcontrollore e il modem della scheda GSM/GPS della Icaro: vengono letti contemporaneamente i due canali in modo da mantenere la sincronia tra messaggi inviati e ricevuti, e poter meglio ricostruire il dialogo.

Al momento la “registrazione” viene effettuata solo inviando l’output al serial monitor dell’Arduino IDE; una successiva versione memorizzerà i dati o in una SD card, o su un server remoto, in modo che il logger possa essere montato direttamente sul veicolo senza necessità di un PC.

Trattandosi di un generico logger seriale a due canali, può in realtà essere usato per “sniffare” qualunque altra comunicazione seriale tra due dispositivi, o anche per loggare un singolo dispositivo.

Il numero a inizio linea identifica il canale cui si riferisce la linea stessa.


// Greengo/Zhidou/Xindayang GSM logger
// Read data from GSM/GPS logger, from both MCU and MODEM outputs and same time
// using ESP32 board.
// V. 0.1.0 - First working version; logs only to USB/serial port (PC needed).
String tempVal = "";
String row0 = "";
String row1 = "";
int MAXLEN = 50;
void setup() {
// initialize serial:
// Recommendation: use Serial0 and 1 for your duplex devices and serial2 for your debug messages.
// https://github.com/espressif/arduino-esp32/issues/1314
//
// Standard serial pinouts:
// https://circuits4you.com/2018/12/31/esp32-hardware-serial2-example/
// UART RX TX CTS RTS
// UART0 GPIO3 GPIO1 N/A N/A
// UART1 GPIO9 GPIO10 GPIO6 GPIO11
// UART2 GPIO16 GPIO17 GPIO8 GPIO7
// But all 3 HW UARTs can be remapped to any pin.

Serial.begin(9600,SERIAL_8N1, 16, 17); // Input 1 (16 = RX)
Serial1.begin(9600,SERIAL_8N1, 4, 2); // Input 2 (4 = RX)
Serial2.begin(9600,SERIAL_8N1, 3,1); // Standard USB-serial port

Serial2.println("Free heap:");
Serial.println(ESP.getFreeHeap());
Serial2.println("--------------------");

}
void loop() {
// read from port 0, send to port 2:
if (Serial.available()) {
int inByte = Serial.read();
/*
Serial2.print("\t0\t0x");
Serial2.print(inByte,HEX);
Serial2.print("\t");
Serial2.print(inByte,DEC);
if (inByte>31) {
Serial2.print("\t");
Serial2.write(inByte);
}
Serial2.println();
*/
tempVal = String(inByte);
row0 += "\t" + tempVal;
if (row0.length() > MAXLEN) {
Serial2.print("0\t");
Serial2.println(row0);
row0="";
}
}
// read from port 1, send to port 2:
if (Serial1.available()) {
int inByte = Serial1.read();
/*
Serial2.print("\t1\t0x");
Serial2.print(inByte,HEX);
Serial2.print("\t");
Serial2.print(inByte,DEC);
if (inByte>31) {
Serial2.print("\t");
Serial2.write(inByte);
}
Serial2.println();
*/
tempVal = String(inByte);
row1 += "\t" + tempVal;
if (row1.length() > MAXLEN) {
Serial2.print("1\t");
Serial2.println(row1);
row1="";
}
}

}
Tagged with: , , , , , ,

leave a comment

Diario elettrico GreenGo Icaro: il CAN-BUS

Posted in Diario elettrico GreenGo Icaro, minicar elettriche by jumpjack on 16 marzo 2018

La centralina della mia Icaro ha il CAN-BUS abilitato (notare che l’abilitazione fa lievitare il costo di 80 euro su 800 al momento dell’ordine), il che significa che è possibile collegarsi con un paio di fili alla centralina per leggere molti dati interessanti.

Pare che dalla KHB72701 sia possibile leggere questi dati:

1) Voltages: Batteries, controller supply, accelerator sensor
2) Motor Specs: RPM, Motor current and Phase Width Modulator (PWM) value
3) Temperatures: Controller and Motor
4) Switch Settings: Reverse & accelerator micro-switch

 

Pin del connettore J1:

  • 5, 7, 13: GND/RTN
  • 10: CAN bus high
  • 11: CAN bus low

Per leggere i dati tramite una Arduino o simili è sufficiente un apposito shield:

 

  • Sketch di esempio in forum italiano: link
  • Post su blog inglese: link

 

In realtà è anche possibile che da qualche parte sia nascosto un connettore standard OBD, devo cercare bene sotto il  cruscotto prima di avventurarmi nell’impresa.

 

 

 

 

Tagged with: , ,

leave a comment

Appunti ESP8266 – Come risolvere problemi di stabilità

Posted in esp8266, hardware by jumpjack on 10 giugno 2017

Sembra che l’ESP8266 sia famoso per la sua instabilità, cioè la facilità con cui perde la connessione WiFi si resetta; queste ottime pagine spiegano come ovviare al problema: link1, link2.

Riassumendo:

  • Il comando “delay()” resetta il WatchDog Timer (WD o WT); si tratta di un contatore che, se raggiunge un valore troppo alto (maggiore di 5 secondi e non modificabile), fa riavviare il dispositivo; è un sistema di sicurezza per evitare che il sistema, se si blocca, resti bloccato indefinitamente: in “sottofondo” è infatti sempre attivo un controllo hardware sul watchdog, anche quando uno sketch si blocca; se rimane bloccato per troppo tempo, il processore va in autoreset e quindi lo sketch si riavvia; quindi lo sketch deve essere predisposto per potersi riavviare da solo senza l’intervento dell’utente.
  • Forse anche il comando wdt_feed()  resetta il watchdog, ma probabilmente è un comando dell’SDK di ESP, quindi per utenti evoluti.
  • Utilizzando l’ESP8266 come access point (ossia come router o come sever), bisogna evitare di gestire l’attesa dei comandi web durante alla funzione standard loop(), perchè sembra che la loop() interferisca con i meccanismi del wifi; bisogna invece implementare una funzione di callback che viene chiamata quando il client connesso all’ESP gli invia un comando (sketch di esempio: link).
  • La connessione WiFi può spesso cadere senza motivo, quindi uno sketch deve sempre prevedere nella funzione loop() un monitoraggio della connessione, per ristabilirla se cade.
    Queste righe servono a verificare se è attiva la connessione tra l’ESP e un router, non tra un dispositivo e l’ESP:
    while (WiFi.status() != WL_CONNECTED) {
      Serial.print(“.”);
      delay(500);
    }
    Quindi vanno dopo la riga:
    WiFi.begin(ssid, password);
    Dove “ssid” è il nome del router.
    Invece, per rilevare la connessione di un dispositivo bisogna usare questo codice:
    #include <ESP8266WiFi.h>
    WiFi.disconnect(true); // Più che disconnettere, cancella dalla PROM i parametri di connessione usati finora;
    WiFi.persistent(false); // Evita che tali parametri vengano poi memorizzati
    WiFi.mode(WIFI_AP); // Imposta la modalità di connessione su Access Point
    WiFi.softAP(ssid); // Imposta il nome della rete e accende l’access point (senza password)
    delay(1000); // Ritardo per azzerare il watchdog
    WiFi.onEvent(WiFiEvent); // Rileva tutti gli eventi WiFi nella funzione “WiFiEvent(WiFiEvent_t event);
  • Quando usa il WiFi, l’ESP8266 ha bisogno di molta più corrente dei 500 mA che può fornire la porta USB di un PC, quindi va alimentato con un trasformatore.
  • Anche utilizzare un adattatore USB/seriale può causare interferenze nel WiFi e perdita di connessione, quindi una volta terminate le prove, usare sempre un alimentatore per alimentare l’ESP.
  • Ad ogni richiesta http GET proveniente da un client, l’ESP “perde un po’ di memoria (heap)”, per liberarla solo “dopo un po’ “, quindi non si può inondare l’ESP di richieste http GET, bisogna aspettare almeno due minuti tra l’una e l’altra (fonte).
  • Un “bug noto” impedisce a SoftAP() di funzionare (cioè di impostare l’ESP come accesspoint)  se l’ESP non è anche connesso a un router.

Esiste anche una libreria WiFi specifica che effettua la riconnessione automatica in caso di disconnessione, ma è per una Arduino collegata a un ESP:

https://github.com/ekstrand/ESP8266wifi

 

Tagged with: , , , , , ,

6 comments

Programmare l’ESP8266 con Arduino IDE

Posted in arduino, hardware, Uncategorized by jumpjack on 15 gennaio 2017

Brevissimo tutorial su come rendere il NodeMCU Amica con ESP8266 ESP12 a bordo programmabile tramite IDE Arduino.

  1. Scaricare esp8266_flasher.exe.
  2. Scaricare i file del firmware ESP_Easy (*).
  3. Collegare il NodeMCU (ad esempio Amica o Lolin) al PC tramite USB
  4. Avviare l’IDE arduino per verificare quale porta sia stata associata al dispositivo (menu Strumenti –> Porta)
  5. Aprire il monitor seriale di Arduino
  6. Premere e rilasciare il tasto reset sul NodeMCU per verificare se effettivamente il dispositivo comunica con l’IDE attraverso quella porta
  7. Chiudere l’IDE
  8. Avviare esp8266_flasher.exe
  9. Impostare il numero di porta
  10. Caricare il file .bin corretto, che dipende dalle dimensioni della flash a bordo del dispositivo (4MB o 4096 kbyte sull’ESP12, montato su Huzzah Adafruit, NodeMCU Lolin, NodeMCU Amica)
  11. Tenere premuto il tasto FLASH sul dispositivo, premere il tasto reset, rilasciare reset e rilasciare il tasto FLASH: in questo modo il dispositivo si predispone per la riprogrammazione (re-flashing)
  12. Cliccare DOWNLOAD: in realtà non verrà scaricato un file DA internet, ma inviato il firmware al dispositivo
  13. Attendere il completamento dell’operazione.
  14. Riaprire l’IDE di Arduino
  15. Ripetere il punto 11
  16. Caricare sul dispositivo uno sketch di esempio che stampi qualcosa sul monitor seriale

 

Metodo alternativo:

Per flashare il firmware è possibile usare direttamente anche il file eseguibile presente nel pacchetto ESP_Easy (*), che però è un po’ meno intuitivo. Una volta nota la porta a cui è collegato il dispositivo (v. punto 4 sopra) e la memoria disponibile (v. punto 10 sopra), mettere il dispositivo in modalità FLASH (punto 11 sopra), avviare esptool e indicare in sequenza il numero di porta, la dimensione della flash e la versione del fimware, cioè il numero dopo la “R” nel nome del file; ad esempio, ESPEasy_R108_4096.bin è la versione 108 per l’ESP da 4096 kbyte.

Nota: per scoprire quant’è grande la Flash RAM sul dispositivo si potrebbe usare questo comando:

esptool.py flash_id

Ma la cosa richiede di preinstallare e configurare un interprete python, che è una noia e una rogna, sto cercando un modo più semplice e alla portata di tutti.

 

(*) Il file .zip contiene vari file .bin, che sono firmware adatti a moduli ESP con Flash RAM di dimensioni diverse: 512 kbyte, 1924 kbyte, 4096 kbyte; ad esempio, il file ESPEasy_R108_1024.bin è per un ESP da 1024 kbyte (1Mbit); R108 è il numero di “build”, cioè di versione.

 

 

Tagged with: , , , , , , , ,

leave a comment

Collegamento di un CellLog8S/8m ad Arduino o a ESP8266

Posted in auto elettriche, batterie, hardware, scooter elettrici by jumpjack on 2 gennaio 2017

L’utente pa.hioficr sul forum https://endless-sphere.com/forums/viewtopic.php?f=14&t=20142 ha scoperto che è possibile leggere in tempo reale i dati di log di un CellLog (sia 8S con memoria che 8S senza memoria) semplicemente “agganciandosi” al pin TX dell’Atmel montato sul CellLog.

Questo significa che invece di spendere 40-50 euro per comprare un CellLog8S con memoria e infilarlo nel sottosella per poi aspettare di arrivare a casa per scaricare i dati letti, è in linea di principio possibile collegare al CellLog8M da 15 euro un ESP8266 da 8 euro che tramite Wifi invia dati a uno smartphone che li mostra in tempo reale sullo schermo durante la marcia; probabilmente è anche possibile scrivere un SW che legge i dati da più di un celllog contemporaneamente, sfruttando l’emulatore di porte seriali.

Questo è lo schema elettrico originale dell’autore:

celllog-000

 

Questa è una sua successiva modifica per implementare anche avvio del logging e reset del CellLog:

celllog-001

Di seguito la spiegazione del funzionamento che ho dedotto io dallo schema, inserita anche nella seconda edizione del mio libro “Guida alla costruzione di una batteria al litio per mezzi elettrici”, di imminente pubblicazione:

 

8.1.2. Materiale occorrente
Q1 = 2n3906 o altro PNP
R1 = R4 = R6 = R7 = 220 ohm
R2 = R5 = 330 ohm
R3 = 4700 ohm
U1 = U2 = optocoupler/fotoaccoppiatore a 2 canali, 5V, 8 pin, uscita a fototransistor di tipo NPN (es. Vishay ILD615, Fairchild MCT61, Isocom ISP827,… )
8.1.3. Spiegazione del funzionamento
Il circuito può essere suddiviso in 4 parti: le prime due ricevono dati dal CellLog tramite il primo fotoaccoppiatore e li inviano al microcontrollore esterno; le altre due ricevono invece dati dal microcontrollore e li inviano al CellLog tramite il secondo fotoaccoppiatore.
8.1.3.1. Rilevamento accensione
In Figura 127 è riportata la parte dedicata al rilevamento dell’accensione; notare che nella figura il transistor è stato capovolto rispetto allo schema originale reperito su internet, per renderlo coerente con la notazione standard di avere la corrente che scorre dall’alto verso il basso; inoltre lo schema è stato semplificato e ripulito, per facilitarne la comprensione, lasciando però inalterati i collegamenti e i componenti.
Il microcontrollore (MCU) è programmato per leggere sul pin MCU_CL8.1_DETECT lo stato del CellLog: quando il pin è “basso” (0V), vuol dire che il CellLog è acceso; normalmente questo pin è invece a 5V perché connesso all’alimentazione dell’MCU tramite R5 (che serve a limitare a 15mA la corrente Collettore-Emettitore quando il transistor è in conduzione); quando però il CellLog viene acceso, i suoi 5V arrivano, tramite la resistenza R4 (che limita la corrente a 23 mA) sul pin 4, e mettono in conduzione il fotodiodo 3-4, che mette a sua volta in conduzione il fototransistor 5-6, che mette a massa il pin MCU_CL8.1_DETECT.
celllog-002
Figura 127 – Rilevamento accensione
8.1.3.2. Lettura dati
Dobbiamo far “riflettere” sul piedino RX del microcontrollore esterno lo stato del pin TX del CellLog, tramite il fotoaccoppiatore; per farlo, usiamo il pin TX del CellLog per controllare la base di un transistor collegato all’ingresso del fotoaccoppiatore; il transistor serve a far sì che basti prelevare dal CellLog una piccolissima corrente (1 mA grazie a R3 da 4300 ohm) per attivare il fotodiodo, che richiede invece alcune decine di mA; in pratica è un transistor di disaccoppiamento, che cioè rende indipendenti gli assorbimenti di corrente di CellLog e fotoaccoppiatore.
celllog-003
Figura 128 – Circuito TX-RX con transistor PNP o NPN
Il progettista ha scelto di usare un transistor di tipo PNP, che viene acceso da una tensione di base negativa rispetto all’emettitore; l’emettitore va quindi collegato stabilmente alla tensione di alimentazione 5V, in modo che il transistor entri in conduzione quando TX va a 0V. Quando questo accade, succederà quanto segue, in sequenza:
1. Q1 si accenderà
2. Passerà una corrente nel fotodiodo 1-2
3. Si accenderà il fototransistor 7-8
Dobbiamo ora fare in modo che tutto ciò risulti in una tensione di 0V sul piedino RX del microcontrollore esterno, corrispondente al piedino 8 del primo fotoaccoppiatore, che è il collettore del fototransistor di uscita; per farlo, dobbiamo fare in modo che il piedino 8 si trovi normalmente a 5V, e venga portato a 0V solo quando si accende il fototransistor 7-8; bisogna quindi tenere il pin 8 costantemente collegato ai 5V del microcontrollore esterno, e il pin 7 alla sua massa; in questo modo, l’accensione del fototransistor 7-8, che avviene quando TX del CellLog va a 0, collegherà il pin 8 a massa tramite il 7, cioè metterà RX del microcontrollore esrerno a 0, riflettendo così esattamente lo stato del pin TX del CellLog.
Se non dovessimo avere disponibile un transistor PNP ma solo un NPN, occorrerà invertire la logica del circuito.
8.1.3.3. Reset
Il “cervello” del CellLog, un microcontrollore ATMEL, è dotato di un piedino di reset, che possiamo controllare tramite il nostro microcontrollore esterno; per farlo, al pin di reset colleghiamo il collettore del fototransistor 5-6 del secondo fotoaccoppiatore (pin 5); controlliamo questo fototransistor tramite il rispettivo fotodiodo 3-4, collegato al pin MCU_CL8.1_RESET del nostro microcontrollore esterno; basterà quindi mettere alto questo pin per mettere in conduzione il fotodiodo e il fototransistor e quindi resettare il CellLog.
celllog-005
8.1.3.4. Avvio log
Per far partire il logging è necessario premere per 3 secondi il pulsante 2 del CellLog (SW2); possiamo farlo fare al nostro microcontrollore esterno collegando l’interruttore in parallelo a un’uscita del secondo fotoaccoppiatore: quando sull’ingresso ci sarà una tensione di 5V (impostata via software), il fototransistor di uscita entrerà in conduzione chiudendo l’interruttore e avviando così il logging.

celllog-004

Tagged with: , , , , , , , , , , , , , , , ,

leave a comment

Datalogger per regolatori di carica EPSolar Tracer MPPT

Posted in fotovoltaico by jumpjack on 4 maggio 2014

Mi appunto un paio di link interessanti su come costruire o dove comprare cavi/interfacce per collegare un regolatore di carica EPSolar a un PC o a un logger standalone, invece che semplicemente al display “istantaneo” fornito di serie, che non memorizza niente:

monitoraggio mppt ep solar 40A 

Datalogger Arduino per regolatore EP Solar

Questo sarebbe interessante se vendessero anche la sola interfaccia seriale:

GWL/Power Solar Controller Monitor for Tracer series (RS-232/USB)

Così si potrebbe collegare alla nuovissima versione (marzo 2014) di Ardulog, che ora oltre ad avere la SD Card incorporata ha anche l’RTC incorporato:

http://www.hobbytronics.co.uk/ardulog-rtc

 

Da notare che, nonostante serva un cavo di rete per collegare display e regolatore, NON è un interfaccia di rete ma un’interfaccia seriale a 12V, e collegare il cavo al regolatore e al PC significherebbe probabilmente bruciare la scheda di rete, che lavora a 3 o 5 V e con tutt’altro protocollo!

 

Tagged with: , , , , , , , , , , , , , ,

leave a comment

Ecco “Displog”, il DISPlay che LOGga!

Posted in arduino, hardware by jumpjack on 8 aprile 2013

Una volta domato il bastardo Ardulog, crearci nuove applicazioni è solo questione di fantasia!

Ecco quindi nascere DISPLOG, il primo display con logger incorporato, o logger con display incorporato, fate vobis:

DISPLOG - DISPLAY + LOGGER on SD card

DISPLOG – DISPLAY + LOGGER on SD card

La faccenda è molto semplice: il display grafico/alfanumerico 3110/5110 (aka Philips PCD8544) può essere pilotato tramite 5 soli pin (addirittura 4 in casi particolari), e su Ardulog ci sono 4 pin analogici disponibili (A1, A3, A4 e A5), più RX e TX (D0 e D1); quindi si tratta solo di giocherellare un po’ con le impostazioni di un banale sorgente di esempio sul playground, fare 5 saldature, ed ecco ottenuto un display che supporta le micro SD card!

Tutto quello che cè da fare è modificare le prime linee di codice in questo modo:

#define PIN_SCE   0
#define PIN_RESET 1
#define PIN_DC    A3
#define PIN_SDIN  A4
#define PIN_SCLK  A5

Manca un PIN libero per accendere la retroilluminazione, ma Hobbytronics ha previdentemente predisposto due piazzole libere vicino ai due LED, quindi si può facilmente utilizzare il pin 5 o 13 per comandare la retroilluminazione.

Il pin analogico A1 rimane disponibile per collegare un qualunque sensore analogico.

Tagged with: , , , , , , , , ,

leave a comment