MultiTech Developer Resources » Topic: OTAA Join Issue Using Semtech SX1272RF1 Development Board and Conduit

OTAA Join Issue Using Semtech SX1272RF1 Development Board and Conduit

This topic has 22 replies, 4 voices, and was last updated 8 years, 9 months ago by yousra mkhakh.

Viewing 23 posts - 1 through 23 (of 23 total)

Author

Posts
February 17, 2016 at 11:00 am #11686

James Coleman
Participant

Hello,

We have a platform that we have developed for evaluating the Semtech SX1272 radio module with the Freescale K22F microprocessor as the host processor. We designed an adapter card to connect the SX1272 radio to the Freescale FRDM K22F development platform.

We currently have verified that we are able to execute the LoRa PING-PONG test between two SX1272 modules on our system.

We are now trying to use the semtech lmic_NAmote_GPS program on our development platform to verify that we can complete a LoRa JOIN with the Conduit Gateway.

We revised the following lines of code to make sure the APPEUI and DEVKEY settings match the settings in the Conduit Gateway lora-network-server.conf file. One question we have is what should the DEVEUI value be? Currently it is a random value that we chose.

The reference code for our settings is provided below:

#ifdef LORA_IT
// application router ID (LSBF)
//static const u1_t APPEUI[8] = { 0x01, 0x00, 0x01, 0x00, 0x00, 0x0c, 0x25, 0x00 };
static const u1_t reverse_APPEUI[8] = { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77 };

// unique device ID (LSBF)
//static const u1_t DEVEUI[8] = { 0x0f, 0x00, 0x00, 0x00, 0x01, 0x0c, 0x25, 0x00 };
static const u1_t reverse_DEVEUI[8] = { 0x02, 0x00, 0x00, 0x00, 0x00, 0xee, 0xff, 0xc0 };

// device-specific AES key (derived from device EUI)
static const u1_t DEVKEY[16] = { 0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF, };
// E4 -72 -71 -C5 -F5 -30 -A9 -9F -CF -C4 -0E -AB -EA -D7 -19 -42
#endif /* LORA_IT */

Also the Conduit Gateway lora-network-server.conf file settings are provided.

{
“lora”: {
“netID”: “010203”, /* netID for beacon packets */
“frequencyBand”: “915”, /* US=”915″, EU=”868″ */
“frequencySubBand”: 7, /* Sub-band for US operation, 1-8 */
“rx1DatarateOffset”: 0, /* Datarate offset for mote rx window 1 sent in join response (0-3) */
“rx2Datarate”: 12, /* Datarate for mote rx window 2 sent in join response (7-12) */
“maxTxPower”: 26, /* Max Tx power (dBm), -6 to 26 */
“frequencyEU”: 867500000 /* center freq for extra EU channels (Hz) */
},
“udp”: {
“appPortUp”: 1784, /* port for user-developed application use */
“appPortDown”: 1786 /* port for user-developed application use */
},
“addressRange”: {
“start”: “00:00:00:01”, /* address range used for mDots */
“end”: “FF:FF:FF:FE”
},
“network”: {
“public”: true , /* set to false for private LoRa network with mDots + Conduit */
“leasetime”: 1440, /* time until mDot join expires (minutes) */
“eui”: “00:11:22:33:44:55:66:77”, /* configure network security */
“key”: “00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff”
},
“log” : {
“console” : true,
“syslog” : false,
“level” : 30, /* error=10, warn=20, info=30, debug=50, trace=60, max=100 */
“path”: “/var/log/lora-network-server.log”
},
“mqtt”: {
“enabled”: true
}
}

Another question that we have has to do with the frequencySubband setting of 7. Exactly what frequency does this correspond to? Should we configure the lmic_NAmote_GPS software that we are using to transmit only on frequencySubband 7?

Are there any other parameters in the Conduit Gateway that we should be changing? Should we be using a different packet forwarder on the Gateway?

Any and all help would be greatly appreciated.

PS. It was a lot easier when we used the mDot boards with the Conduit Gateway.

Thanks,

James

February 17, 2016 at 11:11 am #11687

Jason Reiss
Keymaster

Each Dev EUI has an OUI prefix.
The OUI prefix can be registered with IEEE to ensure global uniqueness of each assigned EUI.
https://en.wikipedia.org/wiki/IEEE_Registration_Authority

mDot are assigned an EUI using the Multitech OUI

The frequencySubBand configures the radio for eight 125k and a one 500k upstream channels. In private mode one downstream channel will be used for each subband.

Issuing AT+TXCH on an mDot will list the channels

at+fsb=7

OK

at+txch
0: 911900000 125k
1: 912100000 125k
2: 912300000 125k
3: 912500000 125k
4: 912700000 125k
5: 912900000 125k
6: 913100000 125k
7: 913300000 125k
U: 912600000 500k
D: 926900000 500k

OK

February 18, 2016 at 8:08 am #11695

James Coleman
Participant

Jason,

Thanks for the reply and the information provided above. In regards to the DEV EUI that I show in the LoRa file above. Is this the DEV EUI that I should be using or does it really matter in regards to joining a public network?

Thanks,

James

February 18, 2016 at 8:19 am #11696

Jason Reiss
Keymaster

If you are using the network server on the Conduit then it is fine to be a random value and ensure uniqueness locally.
A device will only be able to join if it has the app-eui and app-key corresponding to that Conduit.

If you were joining a public network, yes then it would be important to ensure global uniqueness.

February 23, 2016 at 10:48 am #11736

James Coleman
Participant

Jason,

We are very close to getting our LoRa module to complete a JOIN Request with the Conduit Gateway. Below is the response that we receive back from the Conduit when we send a JOIN request from our LoRa module. Appears that we have a channel error. Is this due to the fact that our channel frequency is not matching the Conduit channel frequency which should be set to channel 7.

16:28:26:899|INFO| Device not found in DB
16:28:26:899|INFO| assigning address: 1
16:28:26:913|INFO| Queue join response 17 bytes
16:28:26:926|INFO| Send Join Accept – EUI: c0:ff:ee:00:00:00:00:02 ADDR: 00000001
16:28:26:926|INFO| Schedule TX Time on air: 150 ms
16:28:31:792|INFO| Frame transmitted to 00:00:00:01 via GW (00:80:00:00:00:00:9b:cb Chan ERR 127.0.0.1:59147) Seq# 0
16:28:31:797|INFO| Transmit message 186 bytes

February 23, 2016 at 11:12 am #11737

Jason Reiss
Keymaster

If you increase the logging level to debug you should see the frequencies received and attempting to transmit on.

What frequencies are you expecting?

February 23, 2016 at 11:36 am #11738

James Coleman
Participant

Jason,

Additional debug information from our JOIN request session. We see that we receive information from the Conduit at the uplink frequency of 912600000. This is when we get a response from Conduit. I thought we should be receiving a response back at the 902300000 frequency for channel 7. We set our code to transmit at 902300000 for channel 7 but do not receive a response from Conduit at this frequency. What are we doing wrong?

LoRaWan Demo Application TJM
JOINING
chnl56 923100000 (125khz)
njs blk7, dr4, txChnl71 chnl71 914200000 (500k)
njs blk0, dr0, txChnl1 chnl1 912100000 (125khz)
njs blk0, dr4, txChnl64 chnl64 903000000 (500k)
njs blk1, dr0, txChnl9 chnl9 913700000 (125khz)
njs blk1, dr4, txChnl65 chnl65 904600000 (500k)
njs blk2, dr0, txChnl17 chnl17 915300000 (125khz)
njs blk2, dr4, txChnl66 chnl66 906200000 (500k)
njs blk3, dr0, txChnl25 chnl25 916900000 (125khz)
njs blk3, dr4, txChnl67 chnl67 907800000 (500k)
njs blk4, dr0, txChnl33 chnl33 918500000 (125khz)
njs blk4, dr4, txChnl68 chnl68 909400000 (500k)
njs blk5, dr0, txChnl41 chnl41 920100000 (125khz)
njs blk5, dr4, txChnl69 chnl69 911000000 (500k)
njs blk6, dr0, txChnl49 chnl49 921700000 (125khz)
njs blk6, dr4, txChnl70 chnl70 912600000 (500k)
njs blk7, dr0, txChnl57 chnl57 923300000 (125khz)

17:39:34:586|INFO| ——————————————-
17:39:34:592|INFO| DB loading…
17:39:34:613|INFO| Database version: 5
17:39:34:613|INFO| Latest version: 5
17:39:34:681|INFO| Beacon is disabled
17:41:9:73|INFO| Parsing 1 rx packets
17:41:9:73|WARNING| Recv’d frame failed CRC check
17:43:17:106|INFO| Parsing 1 rx packets
17:43:17:107|INFO| Received join request
17:43:17:109|INFO| Device found in DB, assigning address: 1
17:43:17:113|INFO| Queue join response 17 bytes
17:43:17:127|INFO| Send Join Accept – EUI: c0:ff:ee:00:00:00:00:02 ADDR: 00000001
17:43:17:127|INFO| Schedule TX Time on air: 150 ms
17:43:21:959|INFO| Frame transmitted to 00:00:00:01 via GW (00:80:00:00:00:00:9b:cb Chan ERR 127.0.0.1:40141) Seq# 9
17:43:21:967|INFO| Transmit message 186 bytes

February 23, 2016 at 11:44 am #11739
Jason Reiss
Keymaster
James,

Can you set the log level to 50 or 60 as shown below to get more info in the lora-network-server.log
```
“log” : {
“level” : 60, /* error=10, warn=20, info=30, debug=50, trace=60, max=100 */
},
```
Just to confirm you still have these settings on conduit.
"network" : { "public" : true }
and
"lora" : { "frequencySubBand": 7 }
February 23, 2016 at 1:50 pm #11741

James Coleman
Participant

Jason,

We will set the log levels and get back to you.

Yes we do have the network set to public and frequencySubBand set to 7.

Thanks,

James

February 23, 2016 at 3:01 pm #11742

James Coleman
Participant

Jason,

Information below on what we see with the revised log settings on our platform and on Conduit. Hopefully this provides additional information on what is going on.

Thanks,

James

LoRaWan Demo Application TJM
JOINING
chnl56 923100000 (125khz)
njs blk7, dr4, txChnl71 chnl71 914200000 (500k)
njs blk0, dr0, txChnl1 chnl1 912100000 (125khz)
njs blk0, dr4, txChnl64 chnl64 903000000 (500k)
njs blk1, dr0, txChnl9 chnl9 913700000 (125khz)
njs blk1, dr4, txChnl65 chnl65 904600000 (500k)
njs blk2, dr0, txChnl17 chnl17 915300000 (125khz)
njs blk2, dr4, txChnl66 chnl66 906200000 (500k)
njs blk3, dr0, txChnl25 chnl25 916900000 (125khz)
njs blk3, dr4, txChnl67 chnl67 907800000 (500k)
njs blk4, dr0, txChnl33 chnl33 918500000 (125khz)
njs blk4, dr4, txChnl68 chnl68 909400000 (500k)
njs blk5, dr0, txChnl41 chnl41 920100000 (125khz)
njs blk5, dr4, txChnl69 chnl69 911000000 (500k)
njs blk6, dr0, txChnl49 chnl49 921700000 (125khz)
njs blk6, dr4, txChnl70 chnl70 912600000 (500k) <– triggers join message

———————————————————————————————–

root@mtcdt:/var/config/lora# /etc/init.d/lora-network-server restart
Stopping lora-network-server: OK
Found lora card MTAC-LORA-915
Starting lora-network-server: OK
root@mtcdt:/var/config/lora# tail -f /var/log/lora-network-server.log
21:11:2:309|TRACE| Start Command Receive thread
21:11:2:309|TRACE| Start Time thread
21:11:2:311|TRACE| Start Db Backup thread
21:11:2:311|TRACE| Start Mqtt thread
21:11:2:312|TRACE| Start Beacon thread
21:11:2:313|TRACE| Start appData thread
21:11:2:313|TRACE| Start GatewayDownstreamReceive thread
21:11:2:314|TRACE| Start GatewayReceive thread
21:11:2:315|DEBUG| AppData thread started
21:11:2:316|INFO| Beacon is disabled
21:11:7:750|TRACE| Parse downstream message 12 bytes
21:11:7:751|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:11:19:950|TRACE| Parse downstream message 12 bytes
21:11:19:951|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:11:32:150|TRACE| Parse downstream message 12 bytes
21:11:32:151|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:11:44:350|TRACE| Parse downstream message 12 bytes
21:11:44:351|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:11:56:550|TRACE| Parse downstream message 12 bytes
21:11:56:551|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:12:8:750|TRACE| Parse downstream message 12 bytes
21:12:8:751|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:12:20:950|TRACE| Parse downstream message 12 bytes
21:12:20:951|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:12:33:150|TRACE| Parse downstream message 12 bytes
21:12:33:151|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:12:34:646|TRACE| Parse upstream message 362 bytes
21:12:34:646|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen
21:12:34:648|INFO| Parsing 1 rx packets
21:12:34:648|WARNING| Recv’d frame failed CRC check
21:12:45:350|TRACE| Parse downstream message 12 bytes
21:12:45:351|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:12:54:592|TRACE| Parse upstream message 371 bytes
21:12:54:592|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen
21:12:54:593|INFO| Parsing 1 rx packets
21:12:54:594|WARNING| Recv’d frame failed CRC check
21:12:57:550|TRACE| Parse downstream message 12 bytes
21:12:57:551|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:13:9:750|TRACE| Parse downstream message 12 bytes
21:13:9:751|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:13:21:950|TRACE| Parse downstream message 12 bytes
21:13:21:951|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:13:34:150|TRACE| Parse downstream message 12 bytes
21:13:34:151|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:13:46:350|TRACE| Parse downstream message 12 bytes
21:13:46:351|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:13:58:550|TRACE| Parse downstream message 12 bytes
21:13:58:551|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:14:10:750|TRACE| Parse downstream message 12 bytes
21:14:10:751|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:14:22:950|TRACE| Parse downstream message 12 bytes
21:14:22:951|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:14:35:150|TRACE| Parse downstream message 12 bytes
21:14:35:151|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:14:38:966|TRACE| Parse upstream message 242 bytes
21:14:38:967|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen
21:14:38:968|INFO| Parsing 1 rx packets
21:14:38:969|DEBUG| Received packet
================================
000 00 77 66 55 44 33 22 11
008 00 02 00 00 00 00 ee ff
010 c0 ba 5a fe 37 d2 6d

February 23, 2016 at 3:34 pm #11743

Jason Reiss
Keymaster

James,

The log cut off just before it got interesting. Can you open a support case to exchange files more easily?

Have you tried to enable the hybrid mode in LMIC and use frequencySubBand 1 on the Conduit?

February 23, 2016 at 3:40 pm #11744

James Coleman
Participant

Jason,

Have not tried this. But we will. I will also open a support case.

Thanks,

James

February 23, 2016 at 6:52 pm #11745

James Coleman
Participant

Jason,

Sorry I did not send you the entire log file in the previous post.
Here is the entire log file. Hopefully this helps. I will also open up a support case and put this information in the support case.

LoRaWan Demo Application TJM
JOINING
chnl56 923100000 (125khz)
njs blk7, dr4, txChnl71 chnl71 914200000 (500k)
njs blk0, dr0, txChnl1 chnl1 912100000 (125khz)
njs blk0, dr4, txChnl64 chnl64 903000000 (500k)
njs blk1, dr0, txChnl9 chnl9 913700000 (125khz)
njs blk1, dr4, txChnl65 chnl65 904600000 (500k)
njs blk2, dr0, txChnl17 chnl17 915300000 (125khz)
njs blk2, dr4, txChnl66 chnl66 906200000 (500k)
njs blk3, dr0, txChnl25 chnl25 916900000 (125khz)
njs blk3, dr4, txChnl67 chnl67 907800000 (500k)
njs blk4, dr0, txChnl33 chnl33 918500000 (125khz)
njs blk4, dr4, txChnl68 chnl68 909400000 (500k)
njs blk5, dr0, txChnl41 chnl41 920100000 (125khz)
njs blk5, dr4, txChnl69 chnl69 911000000 (500k)
njs blk6, dr0, txChnl49 chnl49 921700000 (125khz)
njs blk6, dr4, txChnl70 chnl70 912600000 (500k) <– triggers join message

———————————————————————————————–

root@mtcdt:/var/config/lora# /etc/init.d/lora-network-server restart
Stopping lora-network-server: OK
Found lora card MTAC-LORA-915
Starting lora-network-server: OK
root@mtcdt:/var/config/lora# tail -f /var/log/lora-network-server.log
21:11:2:309|TRACE| Start Command Receive thread
21:11:2:309|TRACE| Start Time thread
21:11:2:311|TRACE| Start Db Backup thread
21:11:2:311|TRACE| Start Mqtt thread
21:11:2:312|TRACE| Start Beacon thread
21:11:2:313|TRACE| Start appData thread
21:11:2:313|TRACE| Start GatewayDownstreamReceive thread
21:11:2:314|TRACE| Start GatewayReceive thread
21:11:2:315|DEBUG| AppData thread started
21:11:2:316|INFO| Beacon is disabled
21:11:7:750|TRACE| Parse downstream message 12 bytes
21:11:7:751|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:11:19:950|TRACE| Parse downstream message 12 bytes
21:11:19:951|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:11:32:150|TRACE| Parse downstream message 12 bytes
21:11:32:151|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:11:44:350|TRACE| Parse downstream message 12 bytes
21:11:44:351|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:11:56:550|TRACE| Parse downstream message 12 bytes
21:11:56:551|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:12:8:750|TRACE| Parse downstream message 12 bytes
21:12:8:751|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:12:20:950|TRACE| Parse downstream message 12 bytes
21:12:20:951|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:12:33:150|TRACE| Parse downstream message 12 bytes
21:12:33:151|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:12:34:646|TRACE| Parse upstream message 362 bytes
21:12:34:646|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen
21:12:34:648|INFO| Parsing 1 rx packets
21:12:34:648|WARNING| Recv’d frame failed CRC check
21:12:45:350|TRACE| Parse downstream message 12 bytes
21:12:45:351|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:12:54:592|TRACE| Parse upstream message 371 bytes
21:12:54:592|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen
21:12:54:593|INFO| Parsing 1 rx packets
21:12:54:594|WARNING| Recv’d frame failed CRC check
21:12:57:550|TRACE| Parse downstream message 12 bytes
21:12:57:551|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:13:9:750|TRACE| Parse downstream message 12 bytes
21:13:9:751|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:13:21:950|TRACE| Parse downstream message 12 bytes
21:13:21:951|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:13:34:150|TRACE| Parse downstream message 12 bytes
21:13:34:151|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:13:46:350|TRACE| Parse downstream message 12 bytes
21:13:46:351|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:13:58:550|TRACE| Parse downstream message 12 bytes
21:13:58:551|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:14:10:750|TRACE| Parse downstream message 12 bytes
21:14:10:751|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:14:22:950|TRACE| Parse downstream message 12 bytes
21:14:22:951|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:14:35:150|TRACE| Parse downstream message 12 bytes
21:14:35:151|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:14:38:966|TRACE| Parse upstream message 242 bytes
21:14:38:967|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen
21:14:38:968|INFO| Parsing 1 rx packets
21:14:38:969|DEBUG| Received packet
================================
000 00 77 66 55 44 33 22 11
008 00 02 00 00 00 00 ee ff
010 c0 ba 5a fe 37 d2 6d

21:14:38:969|DEBUG| Rx on 912600000, rssi: -93 snr: 80
21:14:38:970|DEBUG| Received frame: type: Join Request
21:14:38:970|INFO| Received join request
21:14:38:971|DEBUG| BUFFER: 0077665544332211000200000000eeffc0ba5a
21:14:38:971|DEBUG| App EUI: 00.11.22.33.44.55.66.77
21:14:38:971|DEBUG| Dev EUI: c0.ff.ee.00.00.00.00.02
21:14:38:971|DEBUG| Nonce: 00005aba
21:14:38:972|DEBUG| MIC is valid
21:14:38:973|DEBUG| Got appkey: 00.11.22.33.44.55.66.77.88.99.aa.bb.cc.dd.ee.ff
21:14:38:973|DEBUG| DEV NONCE: 5aba
21:14:38:973|DEBUG| APP NONCE: 512fc4
21:14:38:974|DEBUG| session keys: d08c57d23d8ed493fb2747c614970cca 62b2ce77400590345cbce23202a1139c
21:14:38:974|TRACE| SQL query = SELECT address FROM nodes WHERE deveui = “c0ffee0000000002”
21:14:38:976|INFO| Device found in DB, assigning address: 1
21:14:38:976|DEBUG| Update session keys
21:14:38:976|TRACE| SQL query = UPDATE nodes SET authenticationkey = “d08c57d23d8ed493fb2747c614970cca”, encryptionkey = “62b2ce77400590345cbce23202a1139c” WHERE address = “00000001”
21:14:38:980|DEBUG| Set node active: 1
21:14:38:980|INFO| Queue join response 17 bytes
21:14:38:981|DEBUG| Set node active: 1
21:14:38:981|DEBUG| update bestGateway
21:14:38:981|DEBUG| Time: 215166376
21:14:38:981|DEBUG| App Queue Length: 1
21:14:38:982|DEBUG| Rx Frame seq 4386 snr 80
21:14:38:982|DEBUG| SpreadingFactorStore::Add
21:14:38:982|DEBUG| FindSF : snr : 80 100 -20
21:14:38:983|DEBUG| ReceiveOption : 00
21:14:38:984|TRACE| SQL query = UPDATE nodes SET jointime = “2016-02-23T21:14:38Z” WHERE address = “00000001”
21:14:38:987|TRACE| SQL query = UPDATE packets SET port = 0, seqno = 0, gateway = “0080000000009bcb”, time = “2016-02-23T21:14:38Z”, microseconds = 965865000, rssi = -93, channel = 8, lsnr_cB = 80, spread = 8, modulationbandwidth = 500, data = “0000eeffc0ba5a” WHERE node = “00000001”
21:14:38:991|TRACE| SQL query = UPDATE nodes SET lastuppacketid = 1, lastmessagems = 14279662 WHERE address = “00000001”
21:14:38:993|TRACE| SQL query = UPDATE gateways SET lastuppacketid = 1 WHERE address = “0080000000009bcb”
21:14:38:996|DEBUG| getTimeOnAirMs dr: 8 bw: 2 pl: 8 sz: 16 toa: 23
21:14:38:997|INFO| Send Join Accept – EUI: c0:ff:ee:00:00:00:00:02 ADDR: 00000001
21:14:38:997|INFO| Schedule TX Time on air: 150 ms
21:14:39:3|DEBUG| Send MQTT message
21:14:39:3|DEBUG| UDP message: lora/c0:ff:ee:00:00:00:00:02/joined
21:14:39:4|DEBUG| UDP port: 1786
21:14:39:6|TRACE| Published message: 2
21:14:43:836|DEBUG| is frame ready?
21:14:43:836|DEBUG| App Queue Length: 1
21:14:43:836|DEBUG| BestGateway: 80000000009bcb
21:14:43:837|DEBUG| Start
21:14:43:837|INFO| Frame transmitted to 00:00:00:01 via GW (00:80:00:00:00:00:9b:cb Chan ERR 127.0.0.1:42391) Seq# 3b
21:14:43:838|TRACE| SQL query = UPDATE nodes SET lastdownmsgseqno = 59 WHERE address = “00000001”
21:14:43:841|DEBUG| App Data Queue: 1 front size: 17 available: 242
21:14:43:842|DEBUG| check if front is join request 17 bytes
21:14:43:842|DEBUG| Start
21:14:43:842|TRACE| App Data Queue – Join Popped
21:14:43:843|DEBUG| Transmitted Frame data
================================
000 20 ec 72 f0 bb 82 16 ba
008 85 ff f8 cb cc 2f 73 6b
010 2c

21:14:43:843|DEBUG| rx1Offset: 0 rx1Datarate: 7
21:14:43:844|DEBUG| Use JoinResponse Window Time
21:14:43:845|DEBUG| JSON tx: {
“txpk” : {
“codr” : “4/6”,
“data” : “IOxy8LuCFrqF//jLzC9zayw”,
“datr” : “SF7BW500”,
“freq” : 925.10000000000002,
“ipol” : true,
“modu” : “LORA”,
“ncrc” : false,
“powe” : 14,
“rfch” : 0,
“size” : 17,
“tmst” : 220166376
}
}

21:14:43:847|INFO| Transmit message 186 bytes
21:14:43:847|DEBUG| Send on socket 190 bytes, payload len: 186
21:14:43:850|DEBUG| Set node active: 0
21:14:47:260|TRACE| Parse downstream message 12 bytes
21:14:47:261|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:14:57:372|TRACE| Parse upstream message 539 bytes
21:14:57:373|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen
21:14:57:374|INFO| Parsing 1 rx packets
21:14:57:375|WARNING| Recv’d frame failed CRC check
21:14:59:460|TRACE| Parse downstream message 12 bytes
21:14:59:461|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:15:11:660|TRACE| Parse downstream message 12 bytes
21:15:11:661|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391
21:15:23:860|TRACE| Parse downstream message 12 bytes
21:15:23:861|TRACE| Gateway 00:80:00:00:00:00:9b:cb seen IP address 127.0.0.1:42391

February 24, 2016 at 6:48 am #11748
Jason Reiss
Keymaster
Here are the downlink parameters the mote should be listening with.
“codr” : “4/6″,
“datr” : “SF7BW500″,
“freq” : 925.10000000000002,

In the LMIC code they attempt to open the rx window 1.5 symbols into the preamble. Others have been able to get this working by removing the offset.
```
// Called by HAL once TX complete and delivers exact end of TX time stamp in LMIC.rxtime
static void txDone (ostime_t delay, osjobcb_t func) {
...
    // Setup receive - LMIC.rxtime is preloaded with 1.5 symbols offset to tune
    // into the middle of the 8 symbols preamble.
...
        LMIC.rxtime = LMIC.txend + delay + (PAMBL_SYMS-MINRX_SYMS)*dr2hsym(LMIC.dndr);
        LMIC.rxsyms = MINRX_SYMS;
    }
    os_setTimedCallback(&LMIC.osjob, LMIC.rxtime - RX_RAMPUP, func);
}
```
```
static void schedRx2 (ostime_t delay, osjobcb_t func) {
    // Add 1.5 symbols we need 5 out of 8. Try to sync 1.5 symbols into the preamble.
    LMIC.rxtime = LMIC.txend + delay + (PAMBL_SYMS-MINRX_SYMS)*dr2hsym(LMIC.dn2Dr);
    os_setTimedCallback(&LMIC.osjob, LMIC.rxtime - RX_RAMPUP, func);
}
```
Remove this offset in both functions
```
+ (PAMBL_SYMS-MINRX_SYMS)*dr2hsym(LMIC.dndr)
```
- This reply was modified 9 years, 1 month ago by Jason Reiss.
- This reply was modified 9 years, 1 month ago by Jason Reiss.
- This reply was modified 9 years, 1 month ago by Jason Reiss.
February 24, 2016 at 7:54 am #11753

James Coleman
Participant

Jason,

We will verify our settings and make this revision.

Thanks,

James

February 25, 2016 at 7:24 am #11760

James Coleman
Participant

Jason,
We are still having issues Joining The Conduit. I just opened a CASE on the Multitech Support Site and provided the latest log information on that site.

Thanks,

James

July 6, 2016 at 10:02 am #13705
yousra mkhakh
Participant
Hello,

I was reading your discussion because i have a problem configuring my device from the conduit. That is why i wanted to create a logfile so i could see information that could explain what’s wrong. However i didn’t succeed in creating the log file.
Here is what i put to create the file: curl 192.168.4.19/api/loraNetwork -x PUT -d ‘{“log”: {“syslog”: false, “path”: “/var/log/lora-network-server.log”}}‘
Then i added: /etc/init.d/ssh restart
I didn’t receive any error, however when i search for lora-network-server.log, i can’t find it which means that it wasn’t created at all.
Can you please tell me what to do exactly to create the logfile?
Thank you,
- This reply was modified 8 years, 9 months ago by yousra mkhakh.
- This reply was modified 8 years, 9 months ago by yousra mkhakh.
July 6, 2016 at 10:12 am #13709

Bryan Tran
Moderator

Hi yousra mkhakh,

Try /etc/init.d/lora-network-server restart

Thanks,

BT

July 6, 2016 at 10:19 am #13710

yousra mkhakh
Participant

Thank you for your response, i tried it, actually that’s what i already did, i just made a mistake writing ssh. No log file was created.
Thanks,
Yousra

July 6, 2016 at 10:23 am #13711

Bryan Tran
Moderator

yousra mkhakh,

BTW, if it still does not work, I am assuming that you have an AEP version, you can also bring up your web browser and do a copy and paste the 3 commands below:

https://192.168.2.3/api/loraNetwork?method=PUT&data={“log”:{“syslog”:false,”path”:”/var/log/lora-network-server.log”}}

https://192.168.2.3/api/command/save?method=POST

https://192.168.2.3/api/command/restart?method=POST

Notes: Replace the IP address with your IP address

Thanks,

BT

July 6, 2016 at 10:33 am #13712

yousra mkhakh
Participant

Bryan,

when i copy the first command (with the IP address changed) i receive this:

{
“code” : 400,
“error” : “Error parsing URL JSON data [* Line 1, Column 2\n Missing ‘}’ or object member name\n]”,
“status” : “fail”
}

Yousra

July 6, 2016 at 10:39 am #13713

Bryan Tran
Moderator

Sorry. Could you please try to copy them and put them in the notepad program or something. Then change all the double quotes to a normal double quotes. I think the web page is changing it to a weird double quotes.

Then copy the command from your notepad program and paste it into your web browser.

July 6, 2016 at 10:44 am #13714

yousra mkhakh
Participant

It worked, thank you very much,
Yousra
Author

Posts

Viewing 23 posts - 1 through 23 (of 23 total)

You must be logged in to reply to this topic.

OTAA Join Issue Using Semtech SX1272RF1 Development Board and Conduit

User

Sitemap

Pages

Forums