LTE Connectivity (in the 945)

I am hoping that the FR945 LTE will work similarly to how the VA3M LTE did.  If LTE was active and the device was not connected to the phone, then LTE was available to widgets and apps for doing web requests, either JSON data or an image request.

To utilize the LTE you do need to use the System.DeviceSettiungs.ConnectionAvailable instead of the phoneConnected check.  You can also use the ConnectionInfo status to check the state of each of the available connection types.  It looks like this is the first device that has the potential to have all three, BT, LTE, and WiFi.

I have used the VA3MLTE to push data to and from a webservice over the LTE connection without a phone.  I am hopeful the FR945LTE will work similarly, but the key thing to understand is using the LTE can be a big hit on battery if used frequently.

I talked to Garmin support, and they said it wouldn't. So only Garmin features have access to the LTE feature. Which is sad, I'd say that this watch doesn't deserve the "LTE" name if only a small part of the watch can use LTE. I'm fine with no text and no calls support, but no internet at all except for incidents is sad

No offense, but I am not convinced support is the best source for what CIQ features are available.  They are great at product use but not the best source for developers.  If their statements are true, then the simulator is broken.  According the the simulator the FR945LTE is able to use LTE when BT and WiFi are set to "Not Connected".  If LTE is not available the simulator will grey out the option.  I will be interested to hear what one of the .connectiq team members have to say.  Travis.ConnectIQ is usually very accurate about confirming device capabilities.

Oh ok thank you, that gives me a bit of hope!

I haven't had access to an actual fr945lte device, but it should behave just like the existing LTE devices.

Thanks Travis!  That is what the simulator hints at.

What you may want to do is check your code where you may decide things based on "phoneConnected"

and do something like

var c=(Sys.getDeviceSettings() has :connectionAvailable) ? Sys.getDeviceSettings().connectionAvailable : Sys.getDeviceSettings().phoneConnected;

to check the state of all possible connections.

You can also skip checking for a connection and just do the makeWebRequest() and look for an error in it's callback

Also note that this is a "System 4" device, and but per the sim, it's at the 3.2 API level

Jim, I like how concise that code is, however it has a problem with a FW bug in the Edge 1000/explore. See the link.

https://forums.garmin.com/developer/connect-iq/i/bug-reports/edge-explorer-1000-fw-9-30-reporting-it-has-connectionavailable-on-device-only

I ended up using Travis's solution in the bug report to check the phoneConnected first, if false see if device has connection available and use it, else we know we don't have a connection.  I put it in a function that I call every time I want to confirm the device has a connection.

I need to check if the following might work instead.

var c=(Sys.getDeviceSettings().phoneConnected) ? Sys.getDeviceSettings().phoneConnected: (Sys.getDeviceSettings() has :connectionAvailable) ? Sys.getDeviceSettings().connectionAvailable : false;

Edit: it does work, even on the edge 1000/explore

I use the above check mainly in watch faces to show an icon.

For things that do a makeWebRequest, I just do the request and check the return code.  That way the FW decides  what it can or cannot use.

Travis.ConnectIQ said:

I haven't had access to an actual fr945lte device, but it should behave just like the existing LTE devices

Sorry to pull up an old thread, but I just got a chance to play with a FR954LTE.  CIQ apps do not have any access to the LTE on the device and apparently have no way to wake up the LTE connection to take advantage of the LTE connection as when you query the Connection info, it does not even acknowledge that the device has LTE.

So the LTE is only available to the built-in Garmin Functions.  So in this case the simulator is wrong and does not match the on device behavior.