Beantwoord

LoRa, Dragino/SX1276 Shield. Wil niet verbinden met netwerk.

  • 4 februari 2019
  • 7 reacties
  • 1633 keer bekeken

Hi Kpn,

Ik ben een student (elektrotechniek), die een opdracht heeft gekregen om een LoRa set aan de praat te krijgen. (http://www.dragino.com/products/lora/item/120-lora-iot-kit.html)

Het plan is om OTAA te gebruiken, maar de module wil geen verbinding maken met het netwerk. Ik heb ABP ook al geprobeerd, en dat lukt ook niet.

De arduino firmware, is op dit moment het OTAA voorbeeld van de arduino LMIC library
(https://github.com/matthijskooijman/arduino-lmic/blob/master/examples/ttn-otaa/ttn-otaa.ino)

Dit is wat de arduino + module, geeft;
Starting
Packet queued
177: EV_JOINING
422: Unknown event
404274: Unknown event
1260104: Unknown event
1662096: Unknown event
2537665: Unknown event
2963719: Unknown event
3693168: Unknown event
4094995: Unknown event
4918364: Unknown event
5348821: Unknown event
6018820: Unknown event
6482061: Unknown event
7812938: Unknown event
8241497: Unknown event
9489624: Unknown event
9937899: Unknown event
10318112: EV_JOIN_FAILED


Alles heb ik gedubbelcheckt maar ik kom er niet uit.

"Werkende" voorbeeldcode? Tips? anders?

Mvg Jesse
icon

Beste antwoord door Rick S. 6 februari 2019, 14:45

Goedemiddag @Jesse ,

Welkom bij de IoT Community!
Wat tof om te lezen dat u met LoRa aan de slag bent gegaan. Natuurlijk help ik u graag verder.
Ik heb uw Developer Portal account bekeken en ik zie 2 devices met een fout naar voren komen. Het lijkt er haast wel op alsof de Join Requests niet helemaal doorgekomen zijn.

Ik heb de devices nu uit uw account verwijderd en wil u vragen om aan de hand van het topic Over The Air Activation of devices de devices opnieuw aan te melden. In het topic OTAA verbinding omschrijft Jelle ook precies de stappen die hij heeft genomen.

Als u het Join Request heeft gedaan ontvang ik graag een sein, zodat ik kan kijken of deze bij de Developer Portal doorkomt.
Bekijk origineel

7 reacties

Reputatie 5
Badge +5
Graag gedaan! Mocht je in de tussentijd nog vragen hebben, stel ze gerust 🙂.
Hoi Rashid,

Bedant voor het uitsluiten van het netwerk als probleem en alle moeite die jullie er in hebben gestoken.
Ik ga verder testen en zal jullie informeren als ik een oplossing vindt.
Reputatie 5
Badge +5
Hi @SanderIoT,

De specialisten zijn even op onderzoek uitgegaan in de systemen om te kijken of er incorrecte data richting het device gestuurd werd. Het lijkt er echter op dat in het netwerk alles correct ontvangen wordt vanuit het device en dat er, zoals je al aangeeft, op basis van de join request een join accept richting het device gaat. Het issue lijkt dus inderdaad te zitten aan de device zijde. Het kan twee oorzaken hebben:

1. De firmware van het device weet niet goed om te gaan met de ontvangen join accept informatie, waardoor de joinprocedure niet goed kan worden afgerond. Of wellicht dat het niet luistert naar receive window 2 (RX2)?

2. De antenne ontvangt het signaal niet sterk genoeg (downlink). Gezien het goede signaal bij de uplink (geschikt voor SF7) zou niet per se de kwaliteit van de antenne een te checken punt zijn (ook al bevelen we dit wel altijd aan, conform LoRa Alliance standaard). De join accept wordt verstuurd op SF12, RX2, dus het signaal zou goed binnen moeten komen, wanneer wordt vergeleken met de join request. Het kan echter zijn dat het signaal verstoord wordt doordat inkomende signalen geblokkeerd worden door bijvoorbeeld reflecterende coating op ramen of veel metaal in de omgeving (indien binnen).
Reputatie 5
Badge +5
Hi @SanderIoT,

Wilt u mijn een privé bericht sturen met uw Subscriber ID?
Reputatie 5
Badge +5
Hi @SanderIoT,

Welkom op het zakelijk forum van KPN. Ik heb uw vraag neergelegd bij de specialisten en zodra ik antwoord van hen heb gekregen kom ik bij u terug.
Beste heren van het LoRA forum,
Ik zit met een vergelijkbaar probleem en vraag mij af wat de oorzaak is.

Mijn setup is al volgt.
- Arduino Uno (R3 denk ik)
- Dragino Lora Shield V1.4
- Grove base Shield V2

Na het proberen van een paar verschillende libraries (LMIC, Radioihead, IBM-LMIC) ben ik uitgekomen bij de volgende versie van de LMIC Library: Github

Ik maak gebruik van OTAA.
In Thingpark kan ik zien dat er JoinRequests berichten binnen komen, en er JoinAccept berichten terug gestuurd worden.
Echter komt de payload niet aan bij de applicatie server, en ik neem aan dat deze ook niet door de arduino verstuurd worden.
Binnen Thingpark staat het DevAddr op: Allocated by the NAS. Deze is zover ik begrijp dus niet toegewezen wat betekent dat het Join proces niet afgerond is.
Ik zie verder geen alarmen bij het device in Thingpark.

Ik heb al een keer geprobeerd de arduino opnieuw aan te melden met andere keys, met hetzelfde resultaat.

Is dit een software/hardware probleem van de Arduino? Of is dit een netwerk probleem?

Dit is de output van de Arduino:
12:51:15.242 -> Starting
12:51:15.322 -> Packet queued
12:51:15.322 -> 225: EV_JOINING
12:51:15.362 -> Message send
12:51:15.362 -> Now waiting for 3 minutes
12:54:15.269 -> 11251389: Unknown event
12:54:15.269 -> Message send
12:54:15.309 -> Now waiting for 3 minutes
12:57:15.217 -> Message send
12:57:15.217 -> Now waiting for 3 minutes
13:00:15.185 -> Message send
13:00:15.185 -> Now waiting for 3 minutes
13:03:15.124 -> Message send
13:03:15.124 -> Now waiting for 3 minutes

Hier onder de code die ik op de Arduino heb staan.

code:
/*******************************************************************************
* Copyright (c) 2015 Thomas Telkamp and Matthijs Kooijman
*
* Permission is hereby granted, free of charge, to anyone
* obtaining a copy of this document and accompanying files,
* to do whatever they want with them without any restriction,
* including, but not limited to, copying, modification and redistribution.
* NO WARRANTY OF ANY KIND IS PROVIDED.
*
* This example sends a valid LoRaWAN packet with payload "Hello,
* world!", using frequency and encryption settings matching those of
* the The Things Network.
*
* This uses OTAA (Over-the-air activation), where where a DevEUI and
* application key is configured, which are used in an over-the-air
* activation procedure where a DevAddr and session keys are
* assigned/generated for use with all further communication.
*
* Note: LoRaWAN per sub-band duty-cycle limitation is enforced (1% in
* g1, 0.1% in g2), but not the TTN fair usage policy (which is probably
* violated by this sketch when left running for longer)!


* To use this sketch, first register your application and device with
* the things network, to set or generate an AppEUI, DevEUI and AppKey.
* Multiple devices can use the same AppEUI, but each device has its own
* DevEUI and AppKey.
*
* Do not forget to define the radio type correctly in config.h.
*
*******************************************************************************/


#include
#include
#include
//#include


// This EUI must be in little-endian format, so least-significant-byte
// first. When copying an EUI from ttnctl output, this means to reverse
// the bytes. For TTN issued EUIs the last bytes should be 0xD5, 0xB3,
// 0x70.
static const u1_t PROGMEM APPEUI[8]={ 0x03, 0x01, 0x01, 0x00, 0x00, 0xAC, 0x59, 0x00 };
void os_getArtEui (u1_t* buf) { memcpy_P(buf, APPEUI, 8);}


// This should also be in little endian format, see above.
static const u1_t PROGMEM DEVEUI[8]={ 0x4E, 0xE7, 0x04, 0x83, 0x03, 0xC5, 0x55, 0xD4 };
void os_getDevEui (u1_t* buf) { memcpy_P(buf, DEVEUI, 8);}


// This key should be in big endian format (or, since it is not really a
// number but a block of memory, endianness does not really apply). In
// practice, a key taken from ttnctl can be copied as-is.
// The key shown here is the semtech default key.
static const u1_t PROGMEM APPKEY[16] = { 0x6F, 0xA7, 0x7A, 0x0F, 0x90, 0xB4, 0x0D, 0x12, 0x32, 0xFA, 0x2F, 0x24, 0x2D, 0x5B, 0x36, 0xC8 };
void os_getDevKey (u1_t* buf) { memcpy_P(buf, APPKEY, 16);}


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


// Schedule TX every this many seconds (might become longer due to duty
// cycle limitations).
const unsigned TX_INTERVAL = 60;


// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 10, //was 6
.rxtx = LMIC_UNUSED_PIN,
.rst = 9, //was 5
.dio = {2, 6, 7}, //was {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"));


// Disable link check validation (automatically enabled
// during join, but not supported by TTN at this time).
LMIC_setLinkCheckMode(0);
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;
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(9600);
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();


// Let LMIC compensate for +/- 1% clock error
LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);


// Start job (sending automatically starts OTAA too)
do_send(&sendjob);
}


void loop() {
os_runloop_once();
Serial.println("Message send");
Serial.println("Now waiting for 3 minutes");
delay(180000);
}
Reputatie 6
Badge +6
Goedemiddag @Jesse ,

Welkom bij de IoT Community!
Wat tof om te lezen dat u met LoRa aan de slag bent gegaan. Natuurlijk help ik u graag verder.
Ik heb uw Developer Portal account bekeken en ik zie 2 devices met een fout naar voren komen. Het lijkt er haast wel op alsof de Join Requests niet helemaal doorgekomen zijn.

Ik heb de devices nu uit uw account verwijderd en wil u vragen om aan de hand van het topic Over The Air Activation of devices de devices opnieuw aan te melden. In het topic OTAA verbinding omschrijft Jelle ook precies de stappen die hij heeft genomen.

Als u het Join Request heeft gedaan ontvang ik graag een sein, zodat ik kan kijken of deze bij de Developer Portal doorkomt.

Reageer