Accelerare la progettazione della connettività wireless a lungo raggio con un System-in-Package LoRaWAN

Nelle applicazioni di telerilevamento che richiedono connettività wireless a basso costo, a lungo raggio e a basso consumo, la tecnologia LoRa ha prevalso su alternative come Bluetooth e Wi-Fi. Gli sviluppatori continuano tuttavia ad aver difficoltà con le minuzie della progettazione RF per implementare in modo economico e rapido progetti LoRa che massimizzino la portata e la velocità dei dati senza superare la limitata potenza disponibile normalmente ai tipici sistemi IoT.

Per accelerare la progettazione basata su LoRa, i fornitori di chip hanno sviluppato moduli System-in-Package (SiP) completi, corredati dai relativi stack software LoRaWAN, come soluzioni quasi drop-in per la connettività a lungo raggio.

Questo articolo illustrerà brevemente l'approccio LoRa prima di presentare soluzioni hardware e software idonee e spiegare quindi come i progettisti possano utilizzarle per approntare rapidamente un progetto.

Reti IoT a lungo raggio

LoRa, acronimo di "long-range", ovvero lungo raggio, è un protocollo di comunicazione radio a divisione di spettro proprietario ultra-efficiente, a basso costo e a basso consumo. La sua capacità di supportare sensori alimentati a batteria e altre applicazioni a basso consumo lo rende particolarmente idoneo per le applicazioni IoT che operano a distanze superiori ai raggi di copertura Wi-Fi o Bluetooth. I progetti basati su LoRa possono funzionare per anni con una piccola batteria, fornendo comunque una connettività sicura a reti molto grandi che si estendono per chilometri.

LoRaWAN è un layer Media Access Control (MAC) posto sopra l'interfaccia radio LoRa che definisce come funziona la rete e stabilisce le velocità dei dati (in genere fino a 50 kbit/s) (vedere LoRaWAN Parte 1: Come ottenere una portata wireless di 15 km e una durata della batteria di 10 anni per IoT). L'architettura di rete WAN LoRaWAN opera in una topologia di rete a stella e utilizza i gateway per trasmettere i messaggi tra più dispositivi finali come i sensori IoT e un server host (Figura 1). Anche se è possibile utilizzare un modulo radio LoRa separato, con un layer MAC alternativo a LoRaWAN, l'interfaccia che ne deriverà non sarà conforme alla specifica LoRaWAN.

Figura 1: La specifica LoRaWAN assicura comunicazioni autenticate e crittografate tra dispositivi finali e server di rete, utilizzando la connettività a lungo raggio fra gateway e bridge con dispositivi finali e la connettività WAN con gli host di rete nel cloud o in ambienti dedicati. (Immagine per gentile concessione di LoRa Alliance)

In questa architettura, i dispositivi finali e i server host comunicano attraverso dispositivi gateway che possono essere configurati per fungere semplicemente da ponti di comunicazione. Per comunicare con i server host, il gateway utilizza opzioni di connettività convenzionali come Wi-Fi, Ethernet o cellulare. Per comunicare con i dispositivi finali, il gateway si affida alla capacità del layer fisico (PHY) LoRa proprietario di Semtech per ottenere una connettività a lungo raggio affidabile utilizzando bande inferiori a 1 GHz. In entrambi i casi, LoRaWAN protegge le comunicazioni end-to-end con la crittografia AES utilizzando le chiavi della sessione di rete o dell'applicazione che possono essere create durante la produzione, durante la messa in servizio o tramite l'attivazione via etere (OTA).

In una rete LoRaWAN, tutte le comunicazioni con i dispositivi finali sono bidirezionali, ma le specifiche del protocollo LoRaWAN forniscono tre diverse classi di dispositivi finali che consentono agli sviluppatori di bilanciare sostanzialmente il consumo energetico con la latenza della risposta. I dispositivi di classe A possono ricevere solo durante due brevi finestre di ricezione downlink successive a ogni loro trasmissione. Limitando i periodi attivi del ricevitore, i dispositivi di Classe A sono idonei in presenza di vincoli di potenza, come nel caso dei sensori IoT. La Classe B corrisponde alla Classe A ma con ulteriori finestre di ricezione. È pertanto appropriata per i dispositivi attuatori IoT che devono rispondere con una minore latenza alle richieste dell'host anche a costo di un maggiore consumo energetico in ricezione. Infine, i dispositivi di Classe C offrono finestre di ricezione aperte in modo quasi continuo e sono adatti per l'uso nei gateway LoRaWAN.

Il lavoro degli sviluppatori che tentano di ottimizzare la sicurezza, i consumi e la connettività a lungo raggio LoRaWAN può essere ritardato dalla miriade di dettagli richiesti per configurare la piattaforma hardware e i sistemi software. L'hardware e il software di Microchip Technology vengono in soccorso, semplificando l'implementazione delle reti LoRaWAN e fornendo una soluzione quasi drop-in per l'implementazione della tecnologia LoRa.

Soluzione integrata a basso consumo

I moduli System-in-Package (SiP) SAM R34/35 di Microchip combinano un Arm^® Cortex^®-M0+ a basso consumo, un transceiver SX1276 di Semtech, memoria flash, RAM, RAM a basso consumo (LP) speciale e una serie completa di tutti i tipi di periferiche solitamente richiesti nei sistemi di sensori (Figura 2). Oltre a moduli logici configurabili in modo personalizzato, SAM 34/35 include un convertitore analogico/digitale (ADC) multicanale a 12 bit, comparatori analogici e più moduli di comunicazione seriale che possono essere programmati per supportare I²C, SPI e altre interfacce seriali. I SiP SAM R34 e R35 differiscono per un solo aspetto: R35 non fornisce l'interfaccia USB inclusa con il modello R34. A parte questa differenza, i moduli SAM R34/35 di 6x6 mm sono identici nelle tre diverse configurazioni di memoria:

• ATSAMR3xJ16BT-I/7JX con 64 kbyte di flash, 8 kbit di SRAM, 4 kbyte di SRAM a basso consumo
• ATSAMR3xJ17BT-I/7JX con 128 kbyte di flash, 16 kbit di SRAM, 8 kbyte di SRAM a basso consumo
• ATSAMR3xJ18BT-I/7JX con 256 kbyte di flash, 32 kbit di SRAM, 4 kbyte di SRAM a basso consumo

Figura 2: Il modulo System-in-Package (SiP) SAM R34/R35 di Microchip Technology combina un processore Arm Cortex-M0+ a basso consumo, un transceiver SX1276 di Semtech, memoria e diverse periferiche, esclusa l'interfaccia USB in SAM R35. (Immagine per gentile concessione di Microchip Technology)

Studiati espressamente per applicazioni a basso consumo, i moduli SiP offrono diverse opzioni software selezionabili per ridurre la potenza durante i periodi di minore attività. Gli sviluppatori possono impostare SAM R34/R35 per operare a due diversi livelli di prestazioni. Al livello superiore, PL2, il core del dispositivo opera alla massima tensione, consentendogli di funzionare a velocità di clock elevate. Al livello inferiore, PL0, il livello di tensione del core viene scalato in base alla minore frequenza operativa, riducendo il consumo energetico complessivo.

A un determinato livello di prestazioni, gli sviluppatori possono anche cambiare a livello di codice il dispositivo affinché operi in diverse modalità di alimentazione. In modalità di inattività, il modulo consuma solo 4,5 mA con brevi periodi di domanda di picco che arrivano a 28 mA in Tx e a 10,3 mA in Rx. Gli sviluppatori possono abbassare il consumo energetico del modulo a 1,4 μA portandolo in modalità standby, che spegne tutti i clock e le funzioni tranne quelli espressamente programmati per rimanere attivi. Inoltre, i moduli supportano il funzionamento SleepWalking che consente alle periferiche selezionate di rispondere agli eventi indipendentemente dal processore, eseguire operazioni periferiche e attivare il processore solo se è necessario. Per ridurre la potenza durante periodi prolungati di inattività, gli sviluppatori possono portare il modulo in modalità di sospensione, che consuma solo 790 nA. Microchip sconsiglia di portare il dispositivo in stato Off a causa delle condizioni di metastabilità prodotte dall'alta impedenza sul bus SPI interno.

Implementazione del progetto

Grazie alla funzionalità di integrazione dei moduli, i requisiti dell'interfaccia hardware sono semplici. A parte i condensatori di disaccoppiamento per il SiP SAM R34/R35, è sufficiente aggiungere solo un commutatore di segnale come SKY13373 di Skyworks Solutions e i componenti passivi richiesti per completare i percorsi del segnale RF di trasmissione e ricezione (Figura 3).

Figura 3: Con un modulo SAM R34/R35 di Microchip Technology, agli sviluppatori servono solo pochi componenti in più oltre a quelli richiesti per il percorso del segnale RF e al relativo interruttore RF, come SKY13373 di Skyworks Solutions. (Immagine per gentile concessione di Microchip Technology)

Gli sviluppatori possono evitare anche questi semplici requisiti hardware supplementari utilizzando il kit di valutazione SAM R34 Xplained Pro DM320111 di Microchip Technology. Il kit può essere utilizzato per iniziare immediatamente a valutare SAM R34 o estendere il progetto di riferimento hardware per i propri dispositivi personalizzati.

Microchip aiuta anche ad accelerare lo sviluppo del software attraverso una combinazione di firmware del modulo SAM R34/R35 e di software di esempio disponibile con l'ambiente di sviluppo integrato Atmel Studio 7. Basati sul transceiver LoRa SX1276 integrato di Semtech e sul PHY, i SiP SAM R34/R35 forniscono un'implementazione LoRaWAN certificata tramite il loro Microchip LoRaWAN Stack (MLS) incorporato (Figura 4).

Figura 4: Grazie a una serie di API, Microchip LoRaWAN Stack (MLS) offre agli sviluppatori servizi firmware per MAC, PHY, storage persistente, gestione dell'alimentazione e altro ancora. (Immagine per gentile concessione di Microchip Technology)

Basato sull'Advanced Software Framework (ASF) di Microchip di driver dei dispositivi e dei moduli core, il firmware MLS fornisce interfacce di programmazione delle applicazioni (API) per ognuno dei suoi servizi, tra cui:

• LoRaWAN MAC, che fornisce la funzionalità del layer MAC LoRaWAN
• LoRaWAN Radio Layer (TAL), che fornisce l'accesso al transceiver LoRa
• Persistent Data Server (PDS), che fornisce un layer di servizio alla memoria Flash, riducendo i tempi e i cicli di accesso per recuperare i parametri MLS
• Power Manager Module (PMM), che mette il processore in modalità di sospensione durante i periodi di inattività
• Hardware Abstraction Layer (HAL), che protegge il codice indipendentemente dalle reali specifiche dell'hardware
• Librerie di timer
• Scheduler, che alloca le risorse del processore ai vari moduli

Utilizzando le funzioni API, gli sviluppatori possono controllare con precisione ogni aspetto della funzionalità del modulo. Ad esempio, per mettere il modulo in modalità di sospensione, richiamano la funzione API PMM, PMM_Sleep(), che assume la struttura di una richiesta di sospensione contenente il tempo di sospensione, la modalità di sospensione (inattivo, standby, sospensione o off) e una funzione di callback di completamento (Listato 1). All'interno di un'applicazione, gli sviluppatori richiamerebbero in genere questa funzione dopo ogni attività. Ad esempio, la distribuzione ASF di Microchip include un'applicazione dispositivo finale di esempio che utilizza questo approccio all'interno di un anello infinito (Listato 2). Ogni API MLS fornisce punti di accesso simili ai servizi firmware MLS.

Copy
/* Structure of sleep request */
typedef struct _PMM_SleepReq_t
{
       /* Sleep time requested to PMM. Unit is milliseconds */
       uint32_t sleepTimeMs;
    /*  Sleep Modes */
       HAL_SleepMode_t sleep_mode;
       /* Callback from sleep request */
       void (*pmmWakeupCallback)(uint32_t sleptDuration);
} PMM_Sleep

Listato 1: La distribuzione Advanced Software Framework (ASF) di Microchip fornisce un software di esempio che dimostra schemi di progettazione chiave e strutture dati come questa utilizzata per mettere in stato di sospensione il modulo SAM R34/R35 di Microchip Technology. (Fonte del codice: Microchip Technology)

Copy
  .
.
.
while (1)
    {
              serial_data_handler();
        SYSTEM_RunTasks();
#ifdef CONF_PMM_ENABLE
        if (false == certAppEnabled)
        {
            if(bandSelected == true)
            {
                PMM_SleepReq_t sleepReq;
                /* Put the application to sleep */
                sleepReq.sleepTimeMs = DEMO_CONF_DEFAULT_APP_SLEEP_TIME_MS;
                sleepReq.pmmWakeupCallback = appWakeup;
                sleepReq.sleep_mode = CONF_PMM_SLEEPMODE_WHEN_IDLE;
                if (CONF_PMM_SLEEPMODE_WHEN_IDLE == SLEEP_MODE_STANDBY)
                {
                    deviceResetsForWakeup = false;
                }
                if (true == LORAWAN_ReadyToSleep(deviceResetsForWakeup))
                {
                    app_resources_uninit();
                    if (PMM_SLEEP_REQ_DENIED == PMM_Sleep(&sleepReq))
                    {
                        HAL_Radio_resources_init();
                        sio2host_init();
                        /*printf("\r\nsleep_not_ok\r\n");*/
                    }
                }
            }
        }
#endif
    }
  .
.
.

Listato 2: Il software di esempio di Microchip illustra come gli sviluppatori possono utilizzare alcune chiamate API per riportare un modulo SAM R34/R35 di Microchip Technology a uno stato di basso consumo durante i periodi di inattività. (Fonte del codice: Microchip Technology)

Il codice di esempio, disponibile tramite Studio 7 o separatamente tramite la distribuzione ASF, fornisce una dimostrazione completa dell'utilizzo delle chiamate API MLS nell'implementazione di un'applicazione LoRaWAN. Una dimostrazione dell'implementazione del dispositivo finale illustra operazioni di alto livello importanti, compresa l'inizializzazione di un dispositivo, recuperando parametri e attributi MLS archiviati precedentemente dal servizio PDS (Persistent Data Server) (Listato 3). Altro software di esempio fornisce una suite di routine di test che consente agli sviluppatori di esaminare le caratteristiche dettagliate delle prestazioni LoRaWAN e le chiamate API MLS utilizzate per estrarre questi valori. Utilizzando gli esempi di software di Microchip in combinazione con il kit di valutazione SAM R34 Xplained Pro, gli sviluppatori possono maturare rapidamente un'esperienza sulle operazioni LoRaWAN in generale e sul servizio del firmware Microchip in particolare.

Copy
/*********************************************************************//**
\brief    Initialization the Demo application
*************************************************************************/
void mote_demo_init(void)
{
    bool status = false;
    /* Initialize the resources */
    resource_init();
       /* Read DEV EUI from EDBG */
       dev_eui_read();
       startReceiving = false;
    /* Initialize the LORAWAN Stack */
    LORAWAN_Init(demo_appdata_callback, demo_joindata_callback);
    printf("\n\n\r*******************************************************\n\r");
    printf("\n\rMicrochip LoRaWAN Stack %s\r\n",STACK_VER);
    printf("\r\nInit - Successful\r\n");
 
    status = PDS_IsRestorable();
    if(status)
    {
        static uint8_t prevBand = 0xFF;
        uint8_t prevChoice = 0xFF;
        PDS_RestoreAll();
        LORAWAN_GetAttr(ISMBAND,NULL,&prevBand);
        for (uint32_t i = 0; i < sizeof(bandTable) -1; i++)
        {
            if(bandTable[i] == prevBand)
            {
                prevChoice = i;
                break;
            }
        }
        memset(rxchar,0,sizeof(rxchar));
        sio2host_rx(rxchar,10);
        printf ("Last configured Regional band %s\r\n",bandStrings[prevChoice]);
        printf("Press any key to change band\r\n Continuing in %s in ", bandStrings[prevChoice]);
 
        SwTimerStart(demoTimerId,MS_TO_US(1000),SW_TIMEOUT_RELATIVE,(void *)demoTimerCb,NULL);
    }
    else
    {
              appTaskState = DEMO_CERT_APP_STATE;
        appPostTask(DISPLAY_TASK_HANDLER);
    }
}

Listato 3: Questo frammento tratto da un'applicazione di esempio di dispositivo finale di Microchip illustra lo schema di progettazione di base associato all'inizializzazione di un dispositivo, incluso il ripristino degli attributi LoRaWAN se disponibili (PDS_IsRestorable()) da PDS (Persistent Data Server). (Fonte del codice: Microchip Technology)

Conclusione

La tecnologia LoRa è particolarmente idonea per rispondere all'esigenza emergente di connettività a lungo raggio per i sensori IoT alimentati a batteria. In passato, invece, erano gli sviluppatori a dover sviluppare parti significative dei sottosistemi hardware e software. Con i loro hardware e firmware integrati, i moduli SiP SAM R34/R35 di Microchip eliminano efficacemente molti dei requisiti specifici di progettazione associati agli approcci precedenti. Utilizzandoli assieme all'hardware e al software basati su LoRaWAN di Microchip, gli sviluppatori possono implementare rapidamente dispositivi IoT alimentati a batteria e gateway a basso consumo in grado di garantire comunicazioni sicure a lungo raggio con server host nel cloud o in ambienti dedicati.