Changes for page LoRaWAN Communication Debug
Last modified by Mengting Qiu on 2024/01/29 19:33
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -195,15 +195,23 @@ 195 195 196 196 == 5.2 See Debug Info == 197 197 198 +((( 198 198 **For LoRaWAN Server** 200 +))) 199 199 202 +((( 200 200 We can check if there is downlink message for this end node, use TTN for example: 204 +))) 201 201 206 +((( 202 202 Configure a downstream to the end device 208 +))) 203 203 204 204 [[image:https://wiki.dragino.com/images/thumb/8/82/Downstream_debug_1.png/600px-Downstream_debug_1.png||height="217" width="600"]] 205 205 212 +((( 206 206 Set a downstream in TTN and see it is sent 214 +))) 207 207 208 208 209 209 ((( ... ... @@ -212,10 +212,14 @@ 212 212 213 213 [[image:https://wiki.dragino.com/images/thumb/d/dc/Downstream_debug_2.png/600px-Downstream_debug_2.png||height="245" width="600"]] 214 214 223 +((( 215 215 Gateway Traffic can see this downstream info 225 +))) 216 216 217 217 228 +((( 218 218 **For LoRaWAN Gateway** 230 +))) 219 219 220 220 ((( 221 221 When the downstream packet appear on the traffic of Gateway page. The LoRaWAN gateway can get it from LoRaWAN server and transmit it. In Dragion Gateway, this can be checked by runinng "logread -f" in the SSH console. and see below: ... ... @@ -223,10 +223,14 @@ 223 223 224 224 [[image:https://wiki.dragino.com/images/thumb/2/21/Downstream_debug_3.png/600px-Downstream_debug_3.png||height="195" width="600"]] 225 225 238 +((( 226 226 Gateway Sent out this packet 240 +))) 227 227 228 228 243 +((( 229 229 **For End Node** 245 +))) 230 230 231 231 we can use AT Command (AT+CFG) to check the RX1 configure and RX2 configure. as below: 232 232 ... ... @@ -258,16 +258,13 @@ 258 258 259 259 ))) 260 260 261 -(% class="box" %) 262 -((( 263 - [12502]~*~*~*~** UpLinkCounter= 0 ~*~*~*~** 277 +{{{ [12502]***** UpLinkCounter= 0 ***** 264 264 [12503]TX on freq 868500000 Hz at DR 0 265 265 [13992]txDone 266 - [15022]RX on freq 868500000 Hz at DR 0 ~-~-> RX1 window open at frequency: 868500000, DR0, after 15022-13992= 1030ms of txdone 267 - [15222]rxTimeOut ~-~-> no packet arrive in RX1 window. (duration: 200ms) 268 - [15987]RX on freq 869525000 Hz at DR 3 ~-~-> RX2 window open at frequency: 869525000, DR3, after 15987-13992= 1995ms of txdone 269 - [16027]rxTimeOut ~-~-> no packet arrive in RX2 window. (duration: 40 ms) 270 -))) 280 + [15022]RX on freq 868500000 Hz at DR 0 --> RX1 window open at frequency: 868500000, DR0, after 15022-13992= 1030ms of txdone 281 + [15222]rxTimeOut --> no packet arrive in RX1 window. (duration: 200ms) 282 + [15987]RX on freq 869525000 Hz at DR 3 --> RX2 window open at frequency: 869525000, DR3, after 15987-13992= 1995ms of txdone 283 + [16027]rxTimeOut --> no packet arrive in RX2 window. (duration: 40 ms)}}} 271 271 272 272 ((( 273 273 ... ... @@ -277,18 +277,17 @@ 277 277 **Another message:** 278 278 ))) 279 279 293 +{{{ [12502]***** UpLinkCounter= 0 ***** 294 + [12503]TX on freq 868100000 Hz at DR 0 295 + [13992]txDone 296 + [15022]RX on freq 868100000 Hz at DR 0 297 + [15222]rxTimeOut 298 + [15987]RX on freq 869525000 Hz at DR 3 299 + [16185]rxDone --> We have got the downstream packet. 300 + Rssi= -64 301 + Receive data 302 + 1:0012345678}}} 280 280 281 - [12502]~*~*~*~** UpLinkCounter= 0 ~*~*~*~** 282 - [12503]TX on freq 868100000 Hz at DR 0 283 - [13992]txDone 284 - [15022]RX on freq 868100000 Hz at DR 0 285 - [15222]rxTimeOut 286 - [15987]RX on freq 869525000 Hz at DR 3 287 - [16185]rxDone ~-~-> We have got the downstream packet. 288 - Rssi= -64 289 - Receive data 290 - 1:0012345678 291 - 292 292 == 5.3 If problem doesn’t solve == 293 293 294 294 **If user has checked below steps and still can't solve the problem, please send us (support @ dragino.com) the sceenshots for each step to check. They include:** ... ... @@ -312,8 +312,10 @@ 312 312 So if the LoRaWAN server is an AS923 server which ask the gateway to transmit at 923.2Mhz frequency, but the gateway is IN868 frequency band (support 865~~867Mhz to transmit). In the gateway log it will show something like below: 313 313 ))) 314 314 327 +{{{Sat Nov 21 08:04:17 2020 daemon.info lora_pkt_fwd[1680]: ERROR~ Packet REJECTED, unsupported frequency - 923200000 (min:865000000,max:867000000)}}} 328 + 315 315 ((( 316 - SatNov 21 08:04:17 2020 daemon.info lora_pkt_fwd[1680]: ERROR~~ Packet REJECTED, unsupported frequency - 923200000 (min:865000000,max:867000000)330 + 317 317 ))) 318 318 319 319 ((( ... ... @@ -362,7 +362,9 @@ 362 362 363 363 AT+APPSKEY=00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 11 (End Node App Session Key) 364 364 379 +((( 365 365 [[https:~~/~~/lorawan-packet-decoder-0ta6puiniaut.runkit.sh/?data=40c1190126800100024926272bf18bbb6341584e27e23245&nwkskey=00000000000000000000000000000111&appskey=00000000000000000000000000000111>>url:https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/?data=40c1190126800100024926272bf18bbb6341584e27e23245&nwkskey=00000000000000000000000000000111&appskey=00000000000000000000000000000111]] 381 +))) 366 366 367 367 [[image:https://wiki.dragino.com/images/7/77/Decrypt_a_LoRaWAN_Packet4.png||alt="Decrypt a LoRaWAN Packet4.png" height="390" width="558"]] 368 368 ... ... @@ -375,32 +375,58 @@ 375 375 376 376 = 9. Why do I see a "MIC Mismatch" error message from the server? = 377 377 394 +((( 378 378 1)If the user receives a "MIC Mismatch" message after registering the node on the server. 396 +))) 379 379 398 +((( 380 380 It is likely that the user filled in the wrong APPKEY when registering the node. Many users fill in "APPSKEY". 400 +))) 381 381 382 -* Please note the distinction between "APPKEY" and "APPSKEY". 402 +* ((( 403 +Please note the distinction between "APPKEY" and "APPSKEY". 404 +))) 383 383 406 +((( 384 384 2)If the node works on the server for a period of time, the device stops working and receives a "MIC Mismatch" message. 408 +))) 385 385 410 +((( 386 386 The user needs a USB-TTL adapter to connect the serial port to modify the node APPKEY. 412 +))) 387 387 388 -* If a node is registered with multiple servers, it may also cause the "mic mismatch" error. 414 +* ((( 415 +If a node is registered with multiple servers, it may also cause the "mic mismatch" error. 416 +))) 389 389 390 390 = 10. Why i got the payload only with "0x00" or "AA~=~="? = 391 391 392 -* If you are using US915, AU915 and AS923 frequencies.This is normal phenomenon. 420 +* ((( 421 +If you are using US915, AU915 and AS923 frequencies.This is normal phenomenon. 422 +))) 393 393 424 +((( 394 394 When using the frequency mentioned above, the server sometimes adjusts the rate of the node, because the node defaults to the adaptive rate. 426 +))) 395 395 428 +((( 396 396 When the server adjusts your node rate to 0, the maximum payload length is 11 bytes. The server sometimes sends an ADR packet to the node, 430 +))) 397 397 432 +((( 398 398 and the node will reply to the server after receiving the ADR packet, but the number of payload bytes exceeds the limit, 434 +))) 399 399 436 +((( 400 400 so it will send a normal uplink packet, and an additional 00 data packet. 438 +))) 401 401 402 -* Solution: Use the decoder to filter out this 00 packet. 403 -* Some node decoders may not have filtering function, or you need decoders of other servers and formats. Please send an email to david.huang@dragino.cc 440 +* ((( 441 +Solution: Use the decoder to filter out this 00 packet. 442 +))) 443 +* ((( 444 +Some node decoders may not have filtering function, or you need decoders of other servers and formats. Please send an email to david.huang@dragino.cc 445 +))) 404 404 405 405 (% class="wikigeneratedid" id="H" %) 406 406