Problem with Generic ANT Recovering from a Timeout

I'm having an issue with the Generic ANT Channel recovering from a timeout.

I've had this issue reported on the released version of the MoxyRun App running on a Fenix 3. I think I've reproduced the issue on a VivoActive, but I'm not certain this is the same issue as reported.

The problem only occurs once in a while, not every time. It seems like it will happen 5 times in a row and then I can't make it happen at all for many tries in a row.

To cause the problem:
1) Open the App
2) Do not turn on the Moxy sensor, but wait for the searching to time out ( > 25 seconds...I don't push a timeout message, but I should add that)
3) Turn the Moxy sensor on
4) Press the menu button and select Pair to Moxy sensor.

Most of the time it pairs just fine and continues to function properly.

Sometimes it won't find the Moxy sitting right next to the watch. If I back out of the searching view and then select pair to a Moxy sensor again, it will usually find the Moxy sensor. Sometimes this takes 2 or 3 tries. Once it finds the Moxy, I go back to the main screen and the SmO2 and THb values are frozen at a certain value. Everything else in the App works fine.

I added in some println's to capture what's going on when it fails like this.

function onMessage(msg) {

// Parse the payload
var payload = msg.getPayload();
Sys.println("Time: " + Sys.getClockTime().hour + ":" + Sys.getClockTime().min + ":" + Sys.getClockTime().sec + " msgId: " + msg.messageId.toNumber());
for (var i = 0; i < 2; i++) {
Sys.println("p" + i + " " + (payload.toNumber() & 0xFF));
}
if (Ant.MSG_ID_BROADCAST_DATA == msg.messageId) {
[/CODE]

Below is the output that I get from the printlns. I added in the text that says what each event message is afterwards.

Everything looks fine up through the "EVENT_RX_SEARCH_TIMEOUT" message. When I tried again to pair at about 7:51:17, I should have had a very similar series of messages again, but instead, I got 1 close message, then 1 broadcast message, then 1 close message.

I don't know where the close message is coming from. I don't think I'm sending it.

It showed on the screen that it actually paired to the sensor so I'm assuming that the values in the 1 broadcast message are the values that were frozen on the screen, but I didn't print the whole message, so I don't know for sure.

Any ideas on what I need to do differently to get this to function properly? Is this related to the issues that the Tempe app had with pairing? I can send the code in if needed.


Time: 7:46:15 msgId: 64
p0 110 Lib Config
p1 0
Time: 7:46:16 msgId: 64
p0 65 Unassign Channel
p1 0
Time: 7:46:17 msgId: 64
p0 66 Assign Channel
p1 0
Time: 7:46:18 msgId: 64
p0 81 Channel ID
p1 0
Time: 7:46:18 msgId: 64
p0 69 Channel RF Freq
p1 0
Time: 7:46:19 msgId: 64
p0 67 Channel Period
p1 0
Time: 7:46:20 msgId: 64
p0 99 Low Priority Search Timeout
p1 0
Time: 7:46:20 msgId: 64
p0 68 Search Timeout
p1 0
Time: 7:46:21 msgId: 64
p0 71 Transmit Power
p1 0
Time: 7:46:28 msgId: 64
p0 71 Transmit Power
p1 0
Time: 7:46:34 msgId: 64
p0 71 Transmit Power
p1 0
Time: 7:46:40 msgId: 64
p0 71 Transmit Power
p1 0
Time: 7:46:45 msgId: 64
p0 1
p1 1 EVENT_RX_SEARCH_TIMEOUT
Time: 7:51:17 msgId: 64
p0 76 Close Channel
p1 0
Time: 7:51:53 msgId: 78
p0 1 Broadcast Data
p1 221
Time: 7:51:53 msgId: 64
p0 76 Close Channel
p1 0
  • Former Member
    Former Member
    Hi Brandon,

    I was going to just set the timeout values for the High Priority and Low Priority searches longer for a temporary work around. However, the simulator printed an Unexpected Value error to the console for anything higher than the defaults. I didn't test lower. Is this a bug???

    When I tried to run with longer values on a VA watch, it didn't print an error message, but it didn't make the timeouts any longer. Not sure if this is expected behavior or not. The ANT spec allows for values up to 255. The defaults are 2 and 10 which corresponds to 5 and 25 seconds for low and high.

    So instead I made a timer that's just a little shorter than the search timeout values. I reset the timer every time new data is received. If new data isn't received by the time it times out, the timer callback closes the ANT channel and reopens it. This way, if the user doesn't get the sensor paired within 30 seconds of starting the app, the app just keeps waiting and it connects when they get around to turning the sensor on. This seems to be an effective work around.
    Nice solution. Got me thinking though, and off the top of my head... Won't MSG_CODE_EVENT_RX_FAIL_GO_TO_SEARCH get called x times (approx 4 times per second delay) before jumping to MSG_CODE_EVENT_RX_SEARCH_TIMEOUT. Might a MSG_CODE_EVENT_RX_FAIL_GO_TO_SEARCH counter be more efficient? You could call the channel reset when the counter reaches x-1
  • Nice solution. Got me thinking though, and off the top of my head... Won't MSG_CODE_EVENT_RX_FAIL_GO_TO_SEARCH get called x times (approx 4 times per second delay) before jumping to MSG_CODE_EVENT_RX_SEARCH_TIMEOUT. Might a MSG_CODE_EVENT_RX_FAIL_GO_TO_SEARCH counter be more efficient? You could call the channel reset when the counter reaches x-1


    I don't think that would work based on what I was getting back for ANT data. In the case where the user opens the App more than 30 seconds before they turn on their Moxy sensor, the very first message after the setup messages is EVENT_RX_SEARCH_TIMEOUT after which, it seemed that the ANT channel was no longer usable or recoverable. (See the ANT stream from post #1 and #2 in this thread). At that point the only thing I could think of was to put up an error message telling the user to restart the App.

    A timer is a ugly way to beat the problem, but I didn't see any opportunity for an early warning.

    This should be fixed soon on the watches so hopefully only a very short term hack.
  • I've said it before, but the Garmin intern trying to use the Ant+ interface to the Tempe sensor is having problems, and he can "walk down the hall" and talk to the Ant+ folks.

    Maybe in SDK 1.2.0 some of this Ant+ stuff will be fixed.... Seems the "Ant" conference is about the same time as the release of SDK 1.2.0!

    from http://developer.garmin.com/index.php/blog/post/looking-forward-connect-iq-release-schedule

    "hey, wait a minute, that is around the time of ANT+ Symposium!"