Sensors FAQ - Revision history

Lcs at 12:34, 7 June 2018

2018-06-07T12:34:53Z

Lcs: /* Link quality */

2018-06-07T10:22:24Z

‎Link quality

Lcs at 09:19, 7 June 2018

2018-06-07T09:19:51Z

Arl at 11:08, 28 November 2017

2017-11-28T11:08:06Z

Lcs: Created page with "Category:Sensors === Sensors stuck on SF12 datarate since the join procedure === The first data transmitted is always with SF12. This is to comply with most kind of..."

2017-10-27T15:01:36Z

Created page with "Category:Sensors === Sensors stuck on SF12 datarate since the join procedure === The first data transmitted is always with SF12. This is to comply with most kind of..."

New page

[[Category:Sensors]]

=== Sensors stuck on SF12 datarate since the join procedure ===

The first data transmitted is always with SF12. This is to comply with most kind of network architecture.
For example you can perform a join with SF10 but it's not guarantee that you could communicate with same SF.

The Network Server should use ADR mechanism to lower the SF.

If the device is stuck at SF12 with good radio condition it means that the NS do not manage ADR

← Older revision		Revision as of 12:34, 7 June 2018
Line 1:		Line 1:
	[[Category:Sensors]]		[[Category:Sensors]]
		+


Line 38:		Line 39:

	Feel free to reach out to your local operator or devrelations@sigfox.com if you need detailed information.		Feel free to reach out to your local operator or devrelations@sigfox.com if you need detailed information.
		+
		+
		+
		+	== RSSI ==
		+
		+	RSSI reading can vary over time. A particular reading represents only one moment, and the values may change dramatically depending on surrounding condition. It is advised to do several measures to check the connection stability.

@@ Line 27: / Line 27: @@
 A device can toggle between two level quality depending on RSSI and number of stations reached which are two parameters that can fluctuate in time.
 For example:
- - a device around -122dBm will likely fluctuate between GOOD and EXCELLENT.
+* a device around -122dBm will likely fluctuate between GOOD and EXCELLENT.
- - a device around -135dBm will likely fluctuate between AVERAGE and LIMIT. PLease Note also that with this quality Link LIMIT trames might be lost. The floor level detection of Sigfox is around -138 dBm
+* a device around -135dBm will likely fluctuate between AVERAGE and LIMIT. PLease Note also that with this quality Link LIMIT frames might be lost.

← Older revision		Revision as of 09:19, 7 June 2018
Line 2:		Line 2:


−		+	== LoRaWan Mode ==


Line 14:		Line 14:

	If the device is stuck in SF12 despite good radio conditions (for example, in line of sight) it means that the Network Server does not manage ADR.		If the device is stuck in SF12 despite good radio conditions (for example, in line of sight) it means that the Network Server does not manage ADR.
		+
		+
		+
		+
		+
		+	== Sigfox Mode ==
		+
		+	=== Link quality ===
		+
		+	Sigofx deliver Link Quality information as explained in [https://resources.sigfox.com/document/link-quality:-general-knowledge link-quality:-general-knowledge] page.
		+
		+	A device can toggle between two level quality depending on RSSI and number of stations reached which are two parameters that can fluctuate in time.
		+	For example:
		+	- a device around -122dBm will likely fluctuate between GOOD and EXCELLENT.
		+	- a device around -135dBm will likely fluctuate between AVERAGE and LIMIT. PLease Note also that with this quality Link LIMIT trames might be lost. The floor level detection of Sigfox is around -138 dBm

@@ Line 8: / Line 8: @@
 === Sensors stuck on SF12 datarate since the join procedure ===
-The first data transmitted is always with SF12. This is to comply with most kind of network architecture.
+The first data transmitted is always with SF12. This is to be compatible with most network architectures.
-For example you can perform a join with SF10 but it's not guarantee that you could communicate with same SF.
+For example, you can perform a join in SF10 but there is no guarantee that you will be able to communicate with the same SF.
-The Network Server should use ADR mechanism to lower the SF.
+The Network Server should use Adaptive Data Rate (ADR) mechanism to lower the SF.
-If the device is stuck at SF12 with good radio condition it means that the NS do not manage ADR
+If the device is stuck in SF12 despite good radio conditions (for example, in line of sight) it means that the Network Server does not manage ADR.