Hi,
I just got my Thingy91x up and running, and it’s been on for a few hours now, but it has already used 460/500 location requests. How often does the unit send location data? And is that what I’m running out of? Seems strange that a developer plan only works for a few hours…
OK. The default location services sampling interval is quite rapid -- once per minute. The sample uses the location library, which can initiate a switch to the next location services type and perhaps request a location update again before that 1 minute has expired, which may explain the numbers you are seeing.
Furthermore, with the Thingy91X, Wi-Fi location services will be used in addition to GNSS and cellular, which may increase the location services usage count compared to running it on devices without Wi-Fi hardware.
The documentation for the sample here:
has a note specifically about the high cellular data use; the comment applies to the location sampling rate in addition to the sensor sampling rate:
Note Decreasing the sensor sampling interval too much leads to more frequent use of the LTE connection, which can prevent GNSS from obtaining a fix. This is because GNSS can operate only when the LTE connection is not active. Every time a sensor sample is sent, it interrupts any attempted GNSS fix. The exact time required to obtain a GNSS fix will vary depending on satellite visibility, time since last fix, the type of antenna used, and other environmental factors. In good conditions, and with A-GNSS data, one minute is a reasonable interval for reliably getting a location estimate. This allows using long enough value for CONFIG_GNSS_FIX_TIMEOUT_SECONDS, while still leaving enough time for falling back to cellular positioning if needed. The default sensor sampling interval, 60 seconds, will quickly consume cellular data, and should not be used in a production environment. Instead, consider using a less frequent interval, and if necessary, combining multiple sensor samples into a single device message , or combining multiple device messages using the d2c/bulk device message topic. If you significantly increase the sampling interval, you must keep the CONFIG_MQTT_KEEPALIVE short to avoid the carrier silently closing the MQTT connection due to inactivity, which could result in dropped device messages. The exact maximum value depends on your carrier. In general, a few minutes or less should work well.
I suggest you change the sampling interval to a larger value, like 15 minutes:
CONFIG_LOCATION_TRACKING_SAMPLE_INTERVAL_SECONDS=900
Or, use the Asset Tracker v2 application, which is more optimized in both power and cellular data use than the multi service sample.
OK. The default location services sampling interval is quite rapid -- once per minute. The sample uses the location library, which can initiate a switch to the next location services type and perhaps request a location update again before that 1 minute has expired, which may explain the numbers you are seeing.
Furthermore, with the Thingy91X, Wi-Fi location services will be used in addition to GNSS and cellular, which may increase the location services usage count compared to running it on devices without Wi-Fi hardware.
The documentation for the sample here:
has a note specifically about the high cellular data use; the comment applies to the location sampling rate in addition to the sensor sampling rate:
Note Decreasing the sensor sampling interval too much leads to more frequent use of the LTE connection, which can prevent GNSS from obtaining a fix. This is because GNSS can operate only when the LTE connection is not active. Every time a sensor sample is sent, it interrupts any attempted GNSS fix. The exact time required to obtain a GNSS fix will vary depending on satellite visibility, time since last fix, the type of antenna used, and other environmental factors. In good conditions, and with A-GNSS data, one minute is a reasonable interval for reliably getting a location estimate. This allows using long enough value for CONFIG_GNSS_FIX_TIMEOUT_SECONDS, while still leaving enough time for falling back to cellular positioning if needed. The default sensor sampling interval, 60 seconds, will quickly consume cellular data, and should not be used in a production environment. Instead, consider using a less frequent interval, and if necessary, combining multiple sensor samples into a single device message , or combining multiple device messages using the d2c/bulk device message topic. If you significantly increase the sampling interval, you must keep the CONFIG_MQTT_KEEPALIVE short to avoid the carrier silently closing the MQTT connection due to inactivity, which could result in dropped device messages. The exact maximum value depends on your carrier. In general, a few minutes or less should work well.
I suggest you change the sampling interval to a larger value, like 15 minutes:
CONFIG_LOCATION_TRACKING_SAMPLE_INTERVAL_SECONDS=900
Or, use the Asset Tracker v2 application, which is more optimized in both power and cellular data use than the multi service sample.
