Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -28,6 +28,7 @@
28	28	Console Output from End device to see the transmit frequency
29	29
30	30
	31	+
31	31	(% style="color:blue" %)**2. Gateway packet traffic in gateway web or ssh. we can check:**
32	32
33	33	* If the gateway receive the Join request packet from sensor? (If this fail, check if the gateway and sensor works on the match frequency)
...	...	@@ -62,6 +62,7 @@
62	62	Check if OTAA Keys match the keys in device
63	63
64	64
	66	+
65	65	= 2. Notice of US915/CN470/AU915 Frequency band =
66	66
67	67
...	...	@@ -133,6 +133,7 @@
133	133	)))
134	134
135	135
	138	+
136	136	= 3. Why i see data lost/unperiocially uplink data? Even the signal strength is good =
137	137
138	138
...	...	@@ -155,6 +155,7 @@
155	155	)))
156	156
157	157
	161	+
158	158	= 4. Transmision on ABP Mode =
159	159
160	160
...	...	@@ -183,6 +183,7 @@
183	183	Disable Frame Counter Check in ABP Mode
184	184
185	185
	190	+
186	186	= 5. Downstream Debug =
187	187
188	188	== 5.1 How it work ==
...	...	@@ -207,6 +207,9 @@
207	207	* This packet must match the frequency of the RX1 or RX2 window.
208	208	* This packet must match the DataRate of RX1(RX1DR) or RX2 (RX2DR). (% style="color:red" %)**This is the common fail point, because different lorawan server might use different RX2DR and they don't info End Node via ADR message so cause the mismatch. If this happen, user need to change the RX2DR to the right value in end node. In OTAA, LoRaWAN Server will send the RX2DR setting in Join Accept message so the end node will auto adjust. but ABP uplink doesn't support this auto change.**
209	209
	215	+
	216	+
	217	+
210	210	== 5.2 See Debug Info ==
211	211
212	212
...	...	@@ -240,6 +240,7 @@
240	240	)))
241	241
242	242
	251	+
243	243	(((
244	244	(% style="color:blue" %)**For LoRaWAN Gateway**
245	245	)))
...	...	@@ -255,6 +255,7 @@
255	255	)))
256	256
257	257
	267	+
258	258	(((
259	259	(% style="color:blue" %)**For End Node**
260	260	)))
...	...	@@ -269,6 +269,7 @@
269	269	(% style="color:#037691" %)**AT+RX1DL=1000**       (%%) ** ~-~-->**  Receive Delay 1
270	270	(% style="color:#037691" %)**AT+RX2DL=2000**       (%%) **~-~--> ** Receive Delay 2
271	271
	282	+
272	272
273	273	)))
274	274
...	...	@@ -286,6 +286,8 @@
286	286
287	287	(((
288	288
	300	+
	301	+
289	289	)))
290	290
291	291	(((
...	...	@@ -304,6 +304,7 @@
304	304	1:0012345678}}}
305	305
306	306
	320	+
307	307	== 5.3 If problem doesn't solve ==
308	308
309	309
...	...	@@ -316,6 +316,7 @@
316	316
317	317
318	318
	333	+
319	319	= 6. Downlink Issue ~-~- Packet REJECTED, unsupported frequency =
320	320
321	321
...	...	@@ -342,6 +342,7 @@
342	342	)))
343	343
344	344
	360	+
345	345	= 7. Decrypt a LoRaWAN Packet =
346	346
347	347
...	...	@@ -355,6 +355,7 @@
355	355	[[image:image-20220526165525-16.png]]
356	356
357	357
	374	+
358	358	(% style="color:blue" %)**2. In LG02 , configure to receive above message**
359	359
360	360	[[image:image-20220526165612-17.png]]
...	...	@@ -365,6 +365,7 @@
365	365	[[image:image-20220526171112-21.png]]
366	366
367	367
	385	+
368	368	(% style="color:blue" %)**3. Decode the info in web**
369	369
370	370	[[https:~~/~~/lorawan-packet-decoder-0ta6puiniaut.runkit.sh>>url:https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/]]
...	...	@@ -387,6 +387,7 @@
387	387	)))
388	388
389	389
	408	+
390	390	= 8. Why i see uplink 0x00 periodcally on the LHT65 v1.8 firmware =
391	391
392	392
...	...	@@ -393,6 +393,7 @@
393	393	Since firmware v1.8, LHT65 will send MAC command to request time, in the case if DR only support max 11 bytes, this MAC command will be bundled to a separate uplink payload with 0x00.
394	394
395	395
	415	+
396	396	= 9. Why do I see a "MIC Mismatch" error message from the server? =
397	397
398	398
...	...	@@ -509,6 +509,7 @@
509	509	(Any combination of 16 bit codes can be used）
510	510
511	511
	532	+
512	512	= 12. I set my device is LoRaWAN Class C mode, why i still see Class A after boot? =
513	513	)))
514	514