Modulo LoRa Ebyte E220 - Fixed mode bloccante

International Italiano Generale
1

Salve a tutti.
Sto utilizzando, come da titolo, questi moduli LoRa, precisamente Ebyte E220-900T22D.
Sto utilizzando la modalità Fixed, dove un modulo trasmette e uno riceve con l'ausilio della libreria di Mischianti LoRa_E220.h .
I due moduli comunicano e tutto funziona ma ho un problema: ho simulato che il modulo trasmettitore ogni mezzo secondo invia "on" o "off", e il ricevitore a seconda che riceva l'una o l'altra stringa spegne o accende il led di bordo.
Ma ciò non accade ogni mezzo secondo; infatti il trasmettitore invia il comando una volta ogni 5 secondi, a prescindere dal delay di mezzo secondo che ho impostato (ho utilizzato il delay seppur bloccante ma solo per prova).

Ho pensato che forse nella libreria sia presente qualcosa di bloccante, ma nello specifico non saprei cosa.
Di seguito riporto gli sketch del ricevitore e del trasmettitore.
Per i collegamenti mi sono attenuto al video del buon Aliverti

Aggiungo che ho settato ADDH = 0 e ADDL = 2 con CH = 6 per il ricevitore; per il trasmettitore invece ADDH = 0 e ADDL = 1 con CH = 6 . Il resto invariato.

RICEVITORE

#include "Arduino.h"
#include "LoRa_E220.h"

LoRa_E220 e220ttl(3, 2); 
 
void setup() {
  pinMode(13, OUTPUT);
  Serial.begin(9600);
  delay(500);  
  e220ttl.begin();
  
}

void loop() {
  if (e220ttl.available() > 1) {
    ResponseContainer rs = e220ttl.receiveMessage();
    if (rs.data == "on") digitalWrite(13, HIGH);
    else digitalWrite(13, LOW);
    Serial.println(rs.data);
    Serial.println(rs.status.getResponseDescription());    
  }
}

TRASMETTITORE

#include "Arduino.h"
#include "LoRa_E220.h"
LoRa_E220 e220ttl(3, 2); 
 
void setup() {
  Serial.begin(9600);
  delay(500);  
  e220ttl.begin();
}

String msg;

void loop() {  

  
     msg = "on";
     e220ttl.sendFixedMessage(0, 2, 6, msg);
     Serial.println(msg);
     delay(500);
 
     msg = "off";
     e220ttl.sendFixedMessage(0, 2, 6, msg);
     Serial.println(msg);
     delay(500);
2

Sicuro che non dipenda dalle specifiche di protocollo? Ricordo che LoRa imponeva regole ben precise sulla frequenza dei messaggi ... :roll_eyes:

Prova a documentarti sul funzionamento del protocollo e verifica ...

Guglielmo

3

Mi devo documentare perchè questa cosa forse l'ho già letta in passato... non ricordo però con esattezza. Comunque sia guardando alcuni video sul tubo come quello di Aliverti che parla di comunicazione Fixed (lui ha utilizzato il modulo E32) o quest'altro dove fa qualche esempio con trasmissione di dati con altro tipo di modulo ma sempre con comunicazione LoRa (presumo "trasparent" però in questo caso), ciò che deve accadere non ha questa "latenza" di 5 secondi, o meglio il trasmettitore non invia la stringa una volta ogni 5 secondi.

4

Velocemente un indicazione ho trovato ...

LoRa, in Europa, usa la banda libera di 868 MHz a patto di non occuparla per più del 1% del tempo.

... come vedi c'è una limitazione imposta dal protocolo LoRa ... non puoi trasmette quando e quanto ti pare a te, ma devi rispettare delle regole che, altrimenti, ti fa rispettare di forza l'hardware.

Guglielmo

5
1 Like
6

OK, tutto chiaro per quanto concerne le regolamentazioni. La domanda adesso è un'altra: perchè in questo video, il buon Aliverti, riesce a trasmettere ad 1 secondo (ossia quello impostato da lui stesso con un delay) ? Si tratta di un modulo sempre a 868Mhz sempre della Ebyte. Cioè se l'hardware con protocollo LoRa dovrebbe avere di default già impostate le limitazioni come mai nel suo video riesce a trasmettere a quanto lui stesso ha impostato? Eppure il pacchetto di dati inviato è lo stesso, ossia "on" e "off".

7

Non era nell'hardware il "problema" ma come ipotizzato nella libreria.
Nel file .cpp infatti troviamo questo:

if (result != E220_SUCCESS) return result;

		result = this->waitCompleteResponse(5000, 5000);
		if (result != E220_SUCCESS) return result;
        DEBUG_PRINT(F("Clear buffer..."))
        this->cleanUARTBuffer();

		DEBUG_PRINTLN(F("ok!"))

		return result;

Grazie mille comunque!

8

Ripeto che NON è un problema, è il giusto modo di comportarsi per evitare di violare le regolamentazioni.

LoRa NON è pensato per invii continui, LoRa è fatto per sensori IoT a bassissimo consumo che fanno invi in tempi di "minuti" e NON di "secondi" ... :roll_eyes:

Guglielmo

9

Questo lo abbiamo capito:

E' il giusto modo di comportarsi per evitare di violare le regolamentazioni.

Penso che qui abbiamo una certa capacità di discernimento che ci faccia capire che se ci sono delle regole vanno rispettate. Resta che comunque non è un fatto hardware impostato, ma della libreria. Grazie mille. Saluti

10

Se leggi le specifiche del chipset Semtech dovresti trovare le indicazioni ...

Guglielmo

11

Per chi volesse informarsi sulle regolamentazioni ho trovato ben spiegato tutto su QUESTO SITO

In particolare:

Il ciclo di servizio (duty cycle) – è definito come il massimo tempo di trasmissione per ogni ora di servizio. Ad esempio, un duty cycle dell’1% sta ad indicare che si può trasmettere per 36 secondi complessivi ogni ora, non di più.

E inoltre sullo stesso sito vi è una tabella che illustra bene la relazione tra duty cycle, frequenza e potenza. Tutto ben spiegato, e ricavato dalle tante pagine del ERC-REC-70-3E.

1 Like
12

Vedi post #5... :slight_smile:

13

Hai ragione chiedo scusa, mi era sfuggito il primo link.
Avevo visto solo il secondo, un salutone.

14

.:slight_smile:.

15

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.