Summary

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

Details

Page properties

Content

...	...	@@ -106,17 +106,13 @@
106	106
107	107	CN470 Channels
108	108
109		-(((
110	110	If we look at the [[TTN network server frequency plan>>url:https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html]], we can see the US915 frequency band use the channel 8~~15.So the End Node must work at the same frequency in US915 8~~15 channels for TTN server.
111		-)))
112	112
113	113	[[image:https://wiki.dragino.com/images/thumb/9/9a/US915_FRE_BAND-2.png/600px-US915_FRE_BAND-2.png||height="288" width="600"]]
114	114
115	115	TTN FREQUENCY PLAN
116	116
117		-(((
118	118	In dragino end node, user can use AT+CHE command to set what frequencies set the end node will use. The default settings for Dragino end node are preconfigure for TTN server, so use 8~~15 channels, which is **AT+CHE=2**. (AT+CHE=1 for first 8 channels, AT+CHE=2 for second 8 channels.. etc, and AT+CHE=0 for all 72 channels. )
119		-)))
120	120
121	121
122	122	= 3. Why i see data lost/unperiocially uplink data? Even the signal strength is good =
...	...	@@ -127,40 +127,18 @@
127	127	* **Gateway** ~-~-> Use Sub-band2 (Channel 8,9,10,11,12,13,14,15) for Dragino Gateway. this is the default settings for dragino sensors.
128	128	* **LoRaWAN server** ~-~-> ChirpStack default installation and use Sub-band1, **enabled_uplink_channels=[0, 1, 2, 3, 4, 5, 6, 7]** in the file chirpstack-network-server.toml.
129	129
130		-(((
131	131	When Sensor power on, it will use sub-band2 to join the network, the frequency matches the settings in gateway so all Join Request will be passed to the server for Join. Server will ask the sensor to change to Sub-band1 in the Join Accept downlink message. Sensor will change to sub-band1 for data upload. This cause the sensor and gateway have different frequencies so user see lost of most data or even no data.
132		-)))
133	133
134		-(((
135		-
136		-)))
137		-
138		-(((
139	139	Use Subband2 as a default subband cause the sensor to have problem to work with the LoRaWAN server which use other subband, and use need to access to the end node to change the subband by console. that is not user frendily,. So since Dragino LoRaWAN Stack version DLS-005(release on end of 2020), we have changed the device to use All Subbands for OTAA join, for example, device will use the first frequency in Sub-Band1 as firt OTAA join packet, then use the first frequency in Sub-Band 2 , then first frequency in sub-band 3, and so on. LoRaWAN server will normally provide the required subband in the OTAA accept process, so end node will know what subband it use after join. If LoRaWAN server doesn't provide subband info in OTAA join, end node will use the subband which join success as the working subband. So the new method cause a longer OTAA Join time but will be compatible with all LoRaWAN server. And new method won't affect the normal uplink after Join Success.
140		-)))
141	141
142	142
143	143	= 4. Transmision on ABP Mode =
144	144
145		-(((
146	146	In ABP mode, there is a Frame Counter Checks. With this check enabled, the server will only accept the frame with a higher counter. If you reboot the device in ABP mode, the device will start from count 0, so you won't be able to see the frame update in server.
147		-)))
148	148
149		-(((
150		-
151		-)))
152		-
153		-(((
154	154	So in ABP mode, first check if the packet already arrive your gateway, if the packet arrive gatewat but didn't arrive server. Please check if this is the issue.
155		-)))
156	156
157		-(((
158		-
159		-)))
160		-
161		-(((
162	162	To solve this, disable the Frame Counter Check will solve this issue , or reset the frame counter in the device page.
163		-)))
164	164
165	165	[[~[~[image:https://wiki.dragino.com/images/thumb/1/19/ABP_Issue-1.jpg/600px-ABP_Issue-1.jpg~|~|height="340" width="600"~]~]>>url:https://wiki.dragino.com/index.php/File:ABP_Issue-1.jpg]]
166	166
...	...	@@ -173,9 +173,7 @@
173	173
174	174	LoRaWAN End node will open two receive windows to receive the downstream data. If the downstream packets arrive the end node at these receive windows, the end node will be able to get this packet and process it.
175	175
176		-(((
177	177	Depends on Class A or Class C, the receive windows will be a little difference,
178		-)))
179	179
180	180	[[image:https://wiki.dragino.com/images/thumb/1/1a/Downstream_LoRaWAN-1.png/600px-Downstream_LoRaWAN-1.png||height="590" width="600"]]
181	181
...	...	@@ -202,9 +202,7 @@
202	202	Set a downstream in TTN and see it is sent
203	203
204	204
205		-(((
206	206	This downstream info will then pass to the gateway downstream list. and include the DR which is used (SF9BW125) in EU868 is DR3
207		-)))
208	208
209	209	[[image:https://wiki.dragino.com/images/thumb/d/dc/Downstream_debug_2.png/600px-Downstream_debug_2.png||height="245" width="600"]]
210	210
...	...	@@ -213,9 +213,7 @@
213	213
214	214	**For LoRaWAN Gateway**
215	215
216		-(((
217	217	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:
218		-)))
219	219
220	220	[[image:https://wiki.dragino.com/images/thumb/2/21/Downstream_debug_3.png/600px-Downstream_debug_3.png||height="195" width="600"]]
221	221
...	...	@@ -228,41 +228,35 @@
228	228
229	229	(% class="box infomessage" %)
230	230	(((
231		- AT+RX2FQ=869525000 ~-~--> The RX2 Window frequency
	199	+AT+RX2FQ=869525000 ~-~--> The RX2 Window frequency
232	232	)))
233	233
234	234	(% class="box infomessage" %)
235	235	(((
236		- AT+RX2DR=3 ~-~--> The RX2 DataRate
	204	+AT+RX2DR=3 ~-~--> The RX2 DataRate
237	237	)))
238	238
239	239	(% class="box infomessage" %)
240	240	(((
241		- AT+RX1DL=1000 ~-~--> Receive Delay 1
	209	+AT+RX1DL=1000 ~-~--> Receive Delay 1
242	242	)))
243	243
244	244	(% class="box infomessage" %)
245	245	(((
246		- AT+RX2DL=2000 ~-~--> Receive Delay 2
	214	+AT+RX2DL=2000 ~-~--> Receive Delay 2
247	247	)))
248	248
249	249	when the device running, we can see below info:
250	250
251		-(% class="box" %)
252		-(((
253		-[12502]~*~*~*~** UpLinkCounter= 0 ~*~*~*~**
	219	+{{{[12502]***** UpLinkCounter= 0 *****
254	254	[12503]TX on freq 868500000 Hz at DR 0
255	255	[13992]txDone
256		-[15022]RX on freq 868500000 Hz at DR 0     ~-~-> RX1 window open at frequency: 868500000, DR0, after 15022-13992= 1030ms of txdone
257		-[15222]rxTimeOut                           ~-~-> no packet arrive in RX1 window. (duration: 200ms)
258		-[15987]RX on freq 869525000 Hz at DR 3     ~-~-> RX2 window open at frequency: 869525000, DR3, after 15987-13992= 1995ms of txdone
259		-[16027]rxTimeOut                           ~-~-> no packet arrive in RX2 window. (duration: 40 ms)
260		-)))
	222	+[15022]RX on freq 868500000 Hz at DR 0 --> RX1 window open at frequency: 868500000, DR0, after 15022-13992= 1030ms of txdone
	223	+[15222]rxTimeOut --> no packet arrive in RX1 window. (duration: 200ms)
	224	+[15987]RX on freq 869525000 Hz at DR 3 --> RX2 window open at frequency: 869525000, DR3, after 15987-13992= 1995ms of txdone
	225	+[16027]rxTimeOut --> no packet arrive in RX2 window. (duration: 40 ms)
	226	+}}}
261	261
262		-(((
263		-
264		-)))
265		-
266	266	{{{Another message:
267	267	[12502]***** UpLinkCounter= 0 *****
268	268	[12503]TX on freq 868100000 Hz at DR 0