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
  • Hi Sharkbait,

    Thanks for the additional idea to try. I implemented your suggestion and it works as expected on the simulator. Reopening the channel after a search timeout allows the Moxy to connect after a timeout event has occurred.

    However, it doesn't work that way on the watch. It seems that once a EVENT_RX_SEARCH_TIMEOUT has occurred, I can't get the channel working again. My pairing routine already releases and recreates the channel. I tried also nulling out the channelAssignment and recreating that too, but it didn't help either. It just seems that once the watch has been through a timeout, the ANT channel won't work again until the App is exited and restarted.

    BTW - It fails every time when I allow the timeout to occur. Earlier in this thread, I said it worked most of the time and only failed some time. I don't think I was waiting long enough for the timeout.
  • Former Member
    Former Member
    Although... Would I be correct in saying that you have not implemented the Generic Ant Channel in the same was as I have, and that your main class has extended the Generic Ant Channel? As I remember it, that was how you had coded your app.
  • Former Member
    Former Member
    But then again, I was assuming my app was still working as it had. I seem to be experiencing the same problem. Not a large sample, but it worked 1 out of about 6 times. It used to work consistently.
  • Hi Sharkbait,

    The implementation was based on the MO2Display example. I don't think that the main class has extended the Generic ANT channel (I'm not a real programmer so sorry for my lack of certainty there)

    You can see this problem with just a simple modification of the MO2Display example code.

    Add in the following highlighted lines to the MO2Sensor code. Start the app and then wait until you get a timeout before turning on the sensor, and then turn it on, it will pair on the Simulator, but not on my VivoActive. It seems that the watch just isn't handling the MSG_CODE_EVENT_RX_SEARCH_TIMEOUT event very gracefully. After the timeout, the ANT Channel is messed up and I can't get it to recover without exiting the app.

    else if( Ant.MSG_ID_CHANNEL_RESPONSE_EVENT == msg.messageId )
    {
    if( Ant.MSG_ID_RF_EVENT == (payload[0] & 0xFF) )
    {
    if( Ant.MSG_CODE_EVENT_CHANNEL_CLOSED == (payload[1] & 0xFF) )
    {
    // Channel closed, re-open
    open();
    }
    else if( Ant.MSG_CODE_EVENT_RX_FAIL_GO_TO_SEARCH == (payload[1] & 0xFF) )
    {
    searching = true;
    Ui.requestUpdate();
    }
    else if (Ant.MSG_CODE_EVENT_RX_SEARCH_TIMEOUT == (payload[1] & 0xFF) ) {
    System.println("Timeout");
    closeSensor();
    GenericChannel.release();
    GenericChannel.initialize(method(:onMessage), chanAssign);
    GenericChannel.setDeviceConfig(deviceCfg);
    open();

    }

    }
    else
    {
    //It is a channel response.
    }
    }
  • We were able to reproduce this issue with the currently released SDK. We also confirmed that a fix had already been made to address this problem (as part of some larger ANT+ changes and additions), and will be available in the 1.2.0 release.
  • 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.
  • I'm glad you were able to find a work-around. I'm not certain about the error you were seeing for the high and low priority search timeout values, so I'll have to get that investigated and see what I can find out.
  • Former Member
    Former Member
    I'm glad you were able to find a work-around. I'm not certain about the error you were seeing for the high and low priority search timeout values, so I'll have to get that investigated and see what I can find out.
    Some info, with what appears to be a Garmin rep response.
    https://forums.garmin.com/showthread.php?176796-Ant-DeviceConfig-searchTimeoutLowPriority-error-if-gt-10-Should-handle-lt-12
  • It would be great if intended deviations from the typical ANT standard limits like this could get documented.

    ..../connectiq-sdk-win-1.1.4/doc/Toybox/Ant/DeviceConfig.html is where I looked for more information.
  • Ah-ha... glad you were able to find those in the docs. The Ant module in general is still a bit of a grey area for me personally, so I'm not always ready with a good answer. I'll create a ticket to have these documented a little better and somehow highlight that this deviates from the ANT+ spec. Apologies for the confusion!