location.startUpdates() never using callback (LTE Beacon)


Hey all,

We recently started experimenting with 2 of the new LTE Beacons, and have run into an issue. No matter what we do, we can not get location.startUpdates to work as expected / at all.

Here’s a small snippet of example code that we’ve tried testing on both of our beacons:

print('Code Running');

location.startUpdates((position) => { 
    print('lattitude=${position.lat} longitude=${position.long}') 
}, {minInterval: 5, minDistance: 0, timeout: 0 });

“Code Running” is printed in the webIDE as expected, but after that nothing seems to happen… It also may be worth noting that the last known location for both beacons in the cloud is Krakusa 11, 30-535 Kraków, Poland, despite having had multiple heartbeats near us (the most recent being today). Could there be something wrong with the GPS in both beacons??

Any thoughts?


Hi there,

Please note that the LTE Beacon must “see” sattelites on the sky in order to compute its GPS position. Typically the first fix might take up to 3-5 minutes and then you can obtain position every second or so.

So please try again, maybe outdoor and you can duplicate this app to your drafts

Just wait few minutes.

Let us know if it works?


Alright, We’ll give that a shot.

It’s also worth noting that we’ve run a modified version of the code above that sends me a text message instead of printing, then traveled around 4 miles with the beacon in my bag. This still didn’t seem to result in a ping to the estimote servers (which should have sent me a text message). We have successfully used twilio to send sms messages when the beacons button is pressed, so I don’t believe that twilio or our cloud code would be the issue…

Will send an update on the results of testing the new app.


Just got my LTE beacons and looking forward to play with the same scenario. Will report how it goes. Please update if you have any success.

1 Like

No dice. We left the beacon out for about two hours with no results…


‘startUpdates’ returns a promise, have you checked what it delivers? Is it rejected with error? You can forward its contents to cloud so you can test GPS outside without Bluetooth connection.


This is our current test application:

Micro-App Code:

var gpsPromise = location.startUpdates((pos) =>
    cloud.enqueue('gps', {gps: JSON.stringify(pos)});
}, {minInterval: 20, timeout: 300 }, () => {});

    print("THEN " + JSON.stringify(value)); 
    cloud.enqueue('gpsThen', {promiseInfo: JSON.stringify(value)});

    print("CATCH " + JSON.stringify(value));
    cloud.enqueue('gpsCatch', {promiseInfo: JSON.stringify(value)});

Cloud Code (with sensitive info replaced with #):

const accountSid = '########';
const authToken = '########';

const twilio = require('twilio')(accountSid, authToken);

module.exports = async function (event) 
  if (event.type === 'gps') 
    await twilio.messages.create({
      body: 'GPS Update: ' + event.payload.gps,
      to: '+########',
      from: '+########',
  else if (event.type === 'gpsThen') 
    await twilio.messages.create({
      body: 'GPS THEN: ' + event.payload.promiseInfo,
      to: '+########',
      from: '+########',
  else if (event.type === 'gpsCatch') 
    await twilio.messages.create({
      body: 'GPS THEN: ' + event.payload.promiseInfo,
      to: '+########',
      from: '+########',

This results ‘gpsThen’ getting called a few minutes later with a type of undefined - so presumably it’s not erroring out? Still no GPS info though.


When promise is resolved it does not return any value (that is why you have undefined). It just indicates that positioning finished after given timeout.
If promise wasn’t rejected it means that it tired to obtain fix, but with no success.
You can try increasing timeout value or even setting it to 0 (infinity). 5 minutes might be not enough for GPS to acquire fix from cold start (see https://en.wikipedia.org/wiki/Time_to_first_fix).


Hi there,

I also am testing the LTE Beacons, and have a different issue. I’ve found with the new firmware (0.0.7) it does the GPS fix properly with just line of sight from a window. My issue is that they don’t reliably continue to report position after some time, without a reset.

I have a block of code like the following:

var reportingInterval = 600;
var reportingDistance = 150;
var reportingTimeout = 0;

location.startUpdates((position) => {
    if (position.lat && position.long) {
        lastPosition = position;
        print("Handling Position Update.. " + new Date() + " at " + position);
    } else {
        print("Skipping distributing position update since GPS not found.");
}, {minInterval: reportingInterval, minDistance: reportingDistance, timeout: reportingTimeout });

This code calls a function to report, and should do it with the minInterval while stationary, so I would expect every 10 minutes / 600 seconds. What I see is that it does this reporting for a while and then stops.

At the same time, with the minDistance set, my understanding is that it should report when I’ve moved that far, so in this case 150m. Again, it seems to do this report for a little while and then stop once again.

Now in my test application, I made a long press handler that stops the location subscription (and turns off LTE) and then pressing it again will re-enable this and start the location monitoring. This seemed to kick the location back in again and started returning updates, at least for a little while.

Looking at last night, between midnight and around 7AM the beacon stopped reporting, and then started again without any intervention. This seems almost like the pausing issue on the early firmware, where the device would become unresponsive for hours at a time, and then return to service.

I also tried one thing, which was to stop the location monitoring in the location callback/promise, and then restart it. That didn’t seem to make a difference.


I have one supposition, which may not be correct, which is that the devices are still going into somewhat of a deep sleep mode periodically. With the original firmware they would become unresponsive for many hours at a time, and with the current firmware that seems to be far less frequent. However, if this behavior is still happening occasionally, that might account for the lack of GPS updates here and there, and then picking back up again arbitrarily.

Just a thought.


Status Update!

Just today I tried running our code again, this time disabling the timeout. About an hour after running it, The GPS got a fix and began sending updates!

Sadly this only happens on one of our two beacons. The other one still doesn’t return anything, which means it’s not obtaining a fix…
Will try a few more times and report back. I didn’t expect it to take so long to start returning data!


Thanks for sharing. Definitely shouldn’t take an hour to obtain a fix (: We keep working on the GPS reliability, with more fixes & improvements coming in firmware 0.0.9, which shouldn’t be too far off!