LoraWAN - EInstiegshürden

[Frank E. (Firma: Q3) (qualidat)]

Ich möchte mich mit dem Thema LoraWAN befassen, hänge aber an mind. 2 
Problemchen fest. Ein Account bei TTN besteht, ein Device im ABP-Modus 
ist eingerichtet. Wahrscheinlich sind es nur Kleinigkeiten, benötige 
diesbezüglich etwas Hilfe. Compiliert und Hochgeladen wird fehlerfrei, 
aber irgendwie macht das Board nicht, was ich möchte.

- als Board habe ich das hier gekauft, ein ESP32 mit Lora, BT und WLAN, 
jedoch ohne OLED:

https://www.amazon.de/gp/product/B07VKT4SVM

- als Testcode benutze ich (in der Arduino IDE) das Beispiel aus der 
LMIC-Lib "ttn-abp"

Erstes Problem:
Das Pin-Mapping, denn die Namen stimmen nicht überein. Im Beispielcode 
werden die Bezeichnungen nss, rxtx, rst und dio verwendet. Im 
Pinout-Bild zum Board kommen dagegen Lora-MISO, Lora-SCL (s.Bild) vor. 
Die Bedeutung der Signale ansich ist mir klar, aber nicht die Zuordnung 
zu den Bezichungen im Beispielcode

Zweites Problem:
In der TTN-Konsole wurden mir für mein Device im ABP-Mode ein Device-EUI 
und ein Application-EUI generiert, die in den Sourcecode eingetragen 
werden sollen. Auch hier stimmen die Bezeichnungen und die Anzahl der 
Bytes (je 8 bei TTN) im Sourcecode nicht damit überein: NWKSKEY[16] und 
APPSKEY[16]. Während die Vermutung nahe liegt, dass APPSKEY = 
Application-EUI ist, komme ich bei den unterschiedlichen Bytezahlen 
nicht weiter ...

Danke für Hinweise ...

[temp (Gast)]

Frank E. schrieb:
> - als Testcode benutze ich (in der Arduino IDE) das Beispiel aus der
> LMIC-Lib "ttn-abp"

Hier musst du genauer werden. Es kursieren unzählige LMIC Varianten im 
Netz und gefühlt mehr als die Hälfte haben nicht die richtigen 
Frequenzen die zu ttn passen eingetragen.
Jetzt kommt es noch drauf an ob du OTAA oder ABP verwendest. Bei OTAA 
hat das JOINen mit dieser Falschkonfiguration ewig gedauert, danach ging 
es. Mit ABP ging es nie. Das lag aber auch daran, dass beim JOIN der 
Frequenzplan von ttn nachgeladen wird. Zusätzlich kommt noch dazu, wenn 
du viel probierst wird die max. Sendezeit bei bestimmte Frequenzen 
überschritten und es werden nur noch die benutzt die längeres Senden 
ermöglichen. Blöd ist dann wenn die im Frequenzplan nicht passen, dann 
geht nichts mehr.
Also: Code posten oder verlinken

[Frank E. (Firma: Q3) (qualidat)]

Hier ist der Code "TTN-ABP" aus dem mitgelieferten LMIC-Beispiel. Die 
Keys sind die originalen Beispiel-Keys, nicht meine von TTN. Mein 
größtes Problem sind die unterschiedlichen Code-Längen für Net- und 
Appkey.  Klar kann ich das Array auf [8] setzen, aber man wird sich wohl 
dabei etwas geadcht haben, [16] zu verwenden ... ? Die LMIC-Variante ist 
die 1.5.1 von IBM, zwar eigentlich "deprecated", aber darauf beziehen 
sich alle Beispiele im Web.

#include <lmic.h>
#include <hal/hal.h>
#include <SPI.h>

uint8_t NWKSKEY[16] = { 0x2B, 0x7E, 0x15, 0x16, 0x28, 0xAE, 0xD2, 0xA6, 0xAB, 0xF7, 0x15, 0x88, 0x09, 0xCF, 0x4F, 0x3C };
uint8_t APPSKEY[16] = { 0x2B, 0x7E, 0x15, 0x16, 0x28, 0xAE, 0xD2, 0xA6, 0xAB, 0xF7, 0x15, 0x88, 0x09, 0xCF, 0x4F, 0x3C };

u4_t DEVADDR = 0x03FF0001 ; // <-- Change this address for every node!

void os_getArtEui (u1_t* buf) { } //dummy callback for OTAA only
void os_getDevEui (u1_t* buf) { }
void os_getDevKey (u1_t* buf) { }

static uint8_t mydata[] = "Hello, world!";
static osjob_t sendjob;

const unsigned TX_INTERVAL = 60;

// Pin mapping
const lmic_pinmap lmic_pins =
{
    .nss = 6,
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 5,
    .dio = {2, 3, 4},
};

void onEvent (ev_t ev) {
    Serial.print(os_getTime());
    Serial.print(": ");
    switch(ev) {
        case EV_SCAN_TIMEOUT:
            Serial.println(F("EV_SCAN_TIMEOUT"));
            break;
        case EV_BEACON_FOUND:
            Serial.println(F("EV_BEACON_FOUND"));
            break;
        case EV_BEACON_MISSED:
            Serial.println(F("EV_BEACON_MISSED"));
            break;
        case EV_BEACON_TRACKED:
            Serial.println(F("EV_BEACON_TRACKED"));
            break;
        case EV_JOINING:
            Serial.println(F("EV_JOINING"));
            break;
        case EV_JOINED:
            Serial.println(F("EV_JOINED"));
            break;
        case EV_RFU1:
            Serial.println(F("EV_RFU1"));
            break;
        case EV_JOIN_FAILED:
            Serial.println(F("EV_JOIN_FAILED"));
            break;
        case EV_REJOIN_FAILED:
            Serial.println(F("EV_REJOIN_FAILED"));
            break;
        case EV_TXCOMPLETE:
            Serial.println(F("EV_TXCOMPLETE (includes waiting for RX windows)"));
            if (LMIC.txrxFlags & TXRX_ACK)
              Serial.println(F("Received ack"));
            if (LMIC.dataLen) {
              Serial.println(F("Received "));
              Serial.println(LMIC.dataLen);
              Serial.println(F(" bytes of payload"));
            }
            // Schedule next transmission
            os_setTimedCallback(&sendjob, os_getTime()+sec2osticks(TX_INTERVAL), do_send);
            break;
        case EV_LOST_TSYNC:
            Serial.println(F("EV_LOST_TSYNC"));
            break;
        case EV_RESET:
            Serial.println(F("EV_RESET"));
            break;
        case EV_RXCOMPLETE:
            // data received in ping slot
            Serial.println(F("EV_RXCOMPLETE"));
            break;
        case EV_LINK_DEAD:
            Serial.println(F("EV_LINK_DEAD"));
            break;
        case EV_LINK_ALIVE:
            Serial.println(F("EV_LINK_ALIVE"));
            break;
         default:
            Serial.println(F("Unknown event"));
            break;
    }
}

void do_send(osjob_t* j)
{
    // Check if there is not a current TX/RX job running
    if (LMIC.opmode & OP_TXRXPEND) {
        Serial.println(F("OP_TXRXPEND, not sending"));
    } else {
        // Prepare upstream data transmission at the next possible time.
        LMIC_setTxData2(1, mydata, sizeof(mydata)-1, 0);
        Serial.println(F("Packet queued"));
    }
    // Next TX is scheduled after TX_COMPLETE event.
}

void setup()
{
    Serial.begin(115200);
    Serial.println(F("Starting"));

    #ifdef VCC_ENABLE
    // For Pinoccio Scout boards
    pinMode(VCC_ENABLE, OUTPUT);
    digitalWrite(VCC_ENABLE, HIGH);
    delay(1000);
    #endif

    // LMIC init
    os_init();
    // Reset the MAC state. Session and pending data transfers will be discarded.
    LMIC_reset();
    LMIC_setSession (0x1, DEVADDR, NWKSKEY, APPSKEY);

    LMIC_setupChannel(0, 868100000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(1, 868300000, DR_RANGE_MAP(DR_SF12, DR_SF7B), BAND_CENTI);      // g-band
    LMIC_setupChannel(2, 868500000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(3, 867100000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(4, 867300000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(5, 867500000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(6, 867700000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(7, 867900000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(8, 868800000, DR_RANGE_MAP(DR_FSK,  DR_FSK),  BAND_MILLI);      // g2-band
    
    // Disable link check validation
    LMIC_setLinkCheckMode(0);

    // TTN uses SF9 for its RX2 window.
    LMIC.dn2Dr = DR_SF9;

    // Set data rate and transmit power for uplink (note: txpow seems to be ignored by the library)
    LMIC_setDrTxpow(DR_SF7,14);

    // Start job
    do_send(&sendjob);
}

void loop()
{
    os_runloop_once();
}

[temp (Gast)]

Frank E. schrieb:
> In der TTN-Konsole wurden mir für mein Device im ABP-Mode ein Device-EUI
> und ein Application-EUI generiert, die in den Sourcecode eingetragen
> werden sollen. Auch hier stimmen die Bezeichnungen und die Anzahl der
> Bytes (je 8 bei TTN) im Sourcecode nicht damit überein: NWKSKEY[16] und
> APPSKEY[16]. Während die Vermutung nahe liegt, dass APPSKEY =
> Application-EUI ist, komme ich bei den unterschiedlichen Bytezahlen

Wenn du mit ABP arbeiten willst, musst du bei "Activation Method" auch 
ABP auswählen. Das steht normalerweise auf OTAA. Wenn du das machst, 
sollten der "Network Session Key", der "App Session Key" und die "Device 
Address" generiert werden. Das passiert bei OTAA während des JOIN.
Application-EUI ist nicht gleich APPSKEY!

Die Frequenzen werden hier richtig gesetzt wie es aussieht.

Frank E. schrieb:
> - als Testcode benutze ich (in der Arduino IDE) das Beispiel aus der
> LMIC-Lib "ttn-abp"

Stell mal den Link hier rein.

[Frank E. (Firma: Q3) (qualidat)]

Asche auf mein Haupt!

Ich habe auf der TTN-Webseite Device-EUI und App-EUI mit den darunter 
stehenden Net- und App-Keys verwechselt. Sorry, peinlich ...

[temp (Gast)]

Hier mal ein Beispiel

[Frank E. (Firma: Q3) (qualidat)]

temp schrieb:
> Hier mal ein Beispiel

Ja, danke, DAS hab ich nun gecheckt. Bleiben noch diese Probleme:

- in welcher Bytefolge ich das in der Arduino IDE brauche (LSB oder MSB)

- welches Board es genau ist, denn wenn ich als "TTGO1" hochlade, habe 
ich kontinuierliche Restarts im seriellen Monitor, so schnell kann ich 
kaum gucken

- das Pin-Mapping scheint auch bei beinahe jedem der Boards ein anderes 
zu sein

[Frank E. (Firma: Q3) (qualidat)]

tamp schrieb im Beitrag #6609668:
> Frank E. schrieb:
>> - in welcher Bytefolge ich das in der Arduino IDE brauche (LSB oder MSB)
>
> Was würdest Du denn empfehlen? Ich weis es nicht.
>
> Frank E. schrieb:
>> - das Pin-Mapping scheint auch bei beinahe jedem der Boards ein anderes
>> zu sein
>
> Warum wird das nicht vereinheitlicht?

Ich hab mich durch Probieren wohl dem Ziel genähert. Ursache für die 
Resets war ein falsches Pin-Mapping, verwende bei diesem Board jetzt 
(als "TTO1"):

const lmic_pinmap lmic_pins = {
    .nss = 18, 
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 23,
    .dio = {/*dio0*/ 26, /*dio1*/ 33, /*dio2*/ 32}
};

Und er schein auch irgendwas irgend wohin zu senden. Allerdings sehe ich 
in der Console bei TTN nix ankommen. Also werde ich die 
LSB/MSB-Orientierung für die Keys mal durch-iterieren ...

11:46:14.722 -> rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
11:46:14.722 -> configsip: 0, SPIWP:0xee
11:46:14.722 -> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
11:46:14.757 -> mode:DIO, clock div:1
11:46:14.757 -> load:0x3fff0018,len:4
11:46:14.757 -> load:0x3fff001c,len:1044
11:46:14.757 -> load:0x40078000,len:10124
11:46:14.757 -> load:0x40080400,len:5856
11:46:14.757 -> entry 0x400806a8
11:46:14.863 -> Starting
11:46:14.863 -> Packet queued
11:46:16.948 -> 131960: EV_TXCOMPLETE (includes waiting for RX windows)
11:47:16.943 -> Packet queued
11:47:19.058 -> 4012556: EV_TXCOMPLETE (includes waiting for RX windows)
11:48:19.042 -> Packet queued
11:48:21.133 -> 7893149: EV_TXCOMPLETE (includes waiting for RX windows)
11:49:21.148 -> Packet queued
11:49:23.235 -> 11773742: EV_TXCOMPLETE (includes waiting for RX windows)

[BlaBla (Gast)]

Bei mir ist Device EUI und App EUI lsb

[BlaBla (Gast)]

Diese Doku hat mir geholfen: Seite 21 ff.
http://www.dragino.com/downloads/downloads/LoRa_IoT_Kit/v2-Kit/Single%20Channel%20LoRa%20IoT%20Kit%20v2%20User%20Manual_v1.0.5.pdf

[temp (Gast)]

Das mit dem LSBF ist nur für die APPEUI und DEVEUI nötig, aber die 
benutzt du ja sowieso nicht.
Alles andere ist MSBF, also so wie bei ttn im "EXAMPLE CODE".
Hast du ein eigenes Gateway oder bist du sicher eins in Reichweite zu 
haben?

[BlaBla (Gast)]

Ich habe ein eigenes Gateway. Ist für mich aber auch alles Neuland. Habe 
Tage benötigt, um erstmal ein Modul zum Laufen zu bringen.

[BlaBla (Gast)]

tamp schrieb im Beitrag #6609718:
> Was steht in der Doku? Soll ich die jetzt etwa lesen?

Ihr habt hier im Forum alle ein Ton am Leibe... Ich habe mir die Mühe 
gemacht, die Doku im Web zu finden. Ob Du die lesen willst, ist mir 
gleichgültig. Ich bin hier raus.

[Frank E. (Firma: Q3) (qualidat)]

temp schrieb:
> Das mit dem LSBF ist nur für die APPEUI und DEVEUI nötig, aber die
> benutzt du ja sowieso nicht.
> Alles andere ist MSBF, also so wie bei ttn im "EXAMPLE CODE".
> Hast du ein eigenes Gateway oder bist du sicher eins in Reichweite zu
> haben?

im Moment hoffe ich einfach mal, eines in Reihweite zu haben. Mein 
Standort ist ca. 6km vom nächsten Gateway entfernt. Morgen hab ich eines 
"vor meiner Nase".

Wenn jetzt erstmal die Software prinzipiell läuft, gibts wohl auch noch 
mehr Möglichkeiten den Code mit weiteren Monitoring-Funktionen 
aufzupeppen, habe sowas schon gelesen ...

[temp (Gast)]

BlaBla schrieb:
> Ich habe ein eigenes Gateway. Ist für mich aber auch alles Neuland. Habe
> Tage benötigt, um erstmal ein Modul zum Laufen zu bringen.

Ein richtiges mit mehreren Kanälen, oder nur ein einfaches mit einem 
Kanal? Wenn nur einer, dann passt dein Frequenzplan nicht und dann ist 
der ganze LMIC Stack eigentlich für die Katze.

[Frank E. (Firma: Q3) (qualidat)]

tamp schrieb im Beitrag #6609718:
> BlaBla schrieb:
>> Diese Doku hat mir geholfen: Seite 21 ff.
>>
> 
http://www.dragino.com/downloads/townloads/LoRa_IoT_Kit/v2-Kit/Single%20Channel%20LoRa%20IoT%20Kit%20v2%20User%20Manual_v1.0.5.pdf
>
> Was steht in der Doku? Soll ich die jetzt etwa lesen?

Das war aber jetzt nicht von mir. Klar sind Dokus zum Lesen da ...

Die Doku bezieht sich aber auf ein Gateway, muss mal sehen, was davon 
auf den Arduino-Code passt. Trotzdem Danke.

[temp (Gast)]

tamp schrieb im Beitrag #6609718:
> Was steht in der Doku? Soll ich die jetzt etwa lesen?

Nö, ausdrucken und aufessen, hat bei so manchem Lernresisdenten schon 
geholfen...

[Frank E. (Firma: Q3) (qualidat)]

tamp schrieb im Beitrag #6609718:
> BlaBla schrieb:
>> Diese Doku hat mir geholfen: Seite 21 ff.
>>
> 
http://www.dragino.com/downloads/townloads/LoRa_IoT_Kit/v2-Kit/Single%20Channel%20LoRa%20IoT%20Kit%20v2%20User%20Manual_v1.0.5.pdf
>
> Was steht in der Doku? Soll ich die jetzt etwa lesen?

Das war aber jetzt nicht von mir. Klar sind Dokus zum Lesen da ...

Die Doku bezieht sich aber auf ein Gateway, muss mal sehen, was davon 
auf den Arduino-Code passt. Trotzdem Danke.

Ich hab an einem anderen Standort ein Dragino OLG2 (Outdoor-Version). 
Das bei TTN anzumelden war ziemlich easy - zumindest, bis es dort als 
"registriert" und "connected" erschien. Allerdings hat es - jedenfalls 
laut Loglist - bisher kein einziges Byte transportiert. Ob das daher 
kommt, dass ICH es noch nicht genutzt habe oder doch noch irgendwas 
nicht richtig eingestellt ist, vermag ich im Moment nicht zu sagen.

LoraWAN ist sicher eine faszinierende Technik, leidet aber wie beinahe 
alle OpenSource (o.ä.) Projekte daran, dass jeder irgendwas irgendwie 
macht und nichts richtig und eindeutig dokumentiert ist ... mal sehen, 
wieviel Zeit das noch kostet, bis mein erstes Byte zuhause ankommt.

[BlaBla (Gast)]

Frank E. schrieb:
> Die Doku bezieht sich aber auf ein Gateway, muss mal sehen, was davon
> auf den Arduino-Code passt. Trotzdem Danke.

Nein, nicht nur. Ab Seite 19 ff (ich habe hier noch eine ältere Ausgabe) 
werden die Arduinos aufgeführt. Für die Anmeldung beim TTN und myDevice 
reicht es doch. Ist doch wie ein Bilderbuch :-)
Die Einrichtung eines Gateways ist doch etwas anderes, dass muss in 
Reichweite sein, oder besser ein eigenes. Ich habe hier die 
low-cost-Variante mit einem Kanal zum Üben.

[temp (Gast)]

Frank E. schrieb:
> Ich hab an einem anderen Standort ein Dragino OLG2 (Outdoor-Version).

BlaBla schrieb:
> Ich habe hier die
> low-cost-Variante mit einem Kanal zum Üben.

Dann wundert es aber auch keinen das 80% der Pakete im Nirwana 
verschwinden, wenn nur mit den lmic-Examples ohne spezielle Anpassung 
gearbeitet wird.

[temp (Gast)]

tamp schrieb im Beitrag #6610085:
> Wo ist denn das Nirwana? Woher weisst Du, dass es genau 80 Prozent sind
> und nicht 78 oder 84 Prozent?
Das Nirwana ist da, wo man RF-Pakete hinschickt aber keiner da ist der 
sie empfangen kann. Musst nur die Augen aufmachen. Oder die Nase in den 
Wind halten, vorausgesetzt die nicht nicht durch Corona oder andere 
Sachen geschädigt...

Weil du im lmic wenigstens 8 oder 9 Frequenzkanäke definiert hast, und 
LMIC der Node mit einer random-Funktion sich einen aussucht. Bewertet 
zusätzlich über die max. Sendezeit. Wenn die Gegenstelle aber nur auf 
einem Kanal hört, ist es klar, dass ein großes Teil der Pakete verloren 
geht.

Ob das nun genau 80% sind hängt auch davon ab, wie oft du 
LMIC_setTxData2 innerhalb einer Zeiteinheit aufrufst. Und ja, es können 
auch 78 oder 84% oder noch viel mehr sein.