GenericChannel.open() problems on VAHR

I am using GenericChannel to connect to a Garmin Alpha and receive dog tracking data. I have based my code on the MO2Display sample. On a Vivoactive HR, I occasionally have issues where the GenericChannel.open() returns true, but I never get any ant messages to my message handler. Even if the Alpha isn't turned on, I should get the basic setup messages. If I stop the app and re-start it, or even just delete and recreate my sensor object without restarting the app, it works every time. If I let the watch sit at the standard watch face for awhile (about 15 minutes) and then relaunch my app, it usually (possibly always, I'm verifying) seems to fail again.

This doesn't happen on my FR630.

So it seems like there is some timing issue with the GenericChannel.open() call on the VAHR where something isn't setup yet in the GenericChannel code or hardware.

Again, this works fine in the simulator, on my 630, and on the VAHR (after the first attempt).

Here is my code.

in the App.onStart I have {mSensor=new TrackerSensor(); mSensor.open();}


function initialize()
{
// Get the channel
chanAssign = new Ant.ChannelAssignment(
0,//Ant.CHANNEL_TYPE_RX_NOT_TX,
Ant.NETWORK_PLUS);
GenericChannel.initialize(method(:onMessage), chanAssign);

// Set the configuration
deviceCfg = new Ant.DeviceConfig( {
:deviceNumber => 0, //47052 //Wildcard our search
:deviceType => 41,
:transmissionType => 0,
:messagePeriod => 2048,
:radioFrequency => 57, //Ant+ Frequency
:searchTimeoutLowPriority => 25, //Timeout in 25s
:searchThreshold => 0} ); //Pair to all transmitting sensors

GenericChannel.setDeviceConfig(deviceCfg);

searching = true;
}
function open()
{
isOpen = GenericChannel.open();
//Sys.println("isOpen="+isOpen);
searching = true;
}
function onMessage(msg)
{
//this function never gets called when this doesn't work
}
  • A couple things you might try.

    1) Set the low priority timeout to 10. This is in units of 2.5 seconds so this would actually make it 25 seconds. Even if you set it longer, I don't think it actually makes it longer. Maybe this causes some grief on the VAHR.
    2) Set the high priority timeout to 0. This disables high priority searching which interferes with native stuff on the watch. This might default to 0 so might not be a big deal or it might have a different default on different devices (I don't recall if this is the case or not). I don't think this is your problem but you might want to set it to 0 anyway so you don't have a new problem later. Here's the thread on this one.https://forums.garmin.com/showthread.php?346838-ANT-Problem-on-Edge-520

    :searchTimeoutLowPriority => 10,
    :searchTimeoutHighPriority => 0,


    3) I don't know anything about the tracker profile you are using. I see that you set the period to 2092 which would be 16 Hz. In my experience 4 Hz (8192) is more typical for other ANT+ profiles. You might want to test 8192 and see if that is related to the issue.

    Roger
  • Thanks for the suggestions. I had :searchTimeoutLowPriority => 10 but changed it during debugging to try and and speed up the retry, until I realized it never got the timeout message anyway.

    I didn't know about :searchTimeoutHighPriority => 0 but now tried that as well.

    Making these two changes didn't help.

    I believe I'm using the latest version of the SDK and the VAHR fw are up to date. Don't have the watch on me right now as my wife got tired of not getting her steps while I'm debugging this.

    In fact, I tried running the stock MO2Display sample on the VAHR and it has the exact same problem. I only modified it so that it would display the number of messages received in onMessage (as well as Sys.println(cmsg) to the log file). If I haven't run any app using sensors for at least approximately 15 minutes, the onMessage function never gets called. If I have run an app such as my tracker or the MO2DIsplay app, even one that fails, within the last 15 minutes, it immediately (within a second) shows that it has been called 8 or more times.

    I am building both apps in debug mode, although I'm pretty sure when I first noticed the connection problems on mine, it wasn't. Doesn't seem to matter if I have a app.txt log file created for the app.

    Could someone else please verify this. Only modifications needed to the MO2Display sample are as follows. If it works (always does in the simulator and my 630), the screen will quickly count to 8. If it doesn't, the display will stay as 0.

    I'd also recommend building for debug and creating the \Garmin\apps\logs\MO2Display.txt file. It will show numbers 1-8 if it properly handles the sensor open.

    in MO2Sensor.mc
    using Toybox.System as Sys;

    in MO2Sensor class.
    var cMsg=0;

    begining of MO2Sensor.onMessage()
    cMsg++;
    Ui.requestUpdate();
    Sys.println(cMsg);


    in MainView.mc
    using Toybox.System as Sys;

    replace onUpdate function with:
    function onUpdate(dc) {
    dc.setColor(Gfx.COLOR_TRANSPARENT, Gfx.COLOR_BLACK);
    dc.clear();

    var width = dc.getWidth();
    var height = dc.getHeight();
    var margin = 20;
    var font = Gfx.FONT_SMALL;

    dc.setColor(Gfx.COLOR_WHITE,Gfx.COLOR_TRANSPARENT);
    dc.drawText(width/2,height/2,4, mSensor.cMsg, 5);
    }
  • note that none of this actually requires a sensor to see this problem. all happens just initiating the sensor search.

    as for the tracker profile, I'm just following the spec out on thisisant. given that you can have upto 20 assets/dogs, each requiring two messages for the location, the frequency seems reasonable. But I don't get far enough for that to matter. It works great other than this set up issue on the vahr
  • I haven't thought this through far enough to know if it's related but it should be quick to test.

    The Generic ANT Channels in CIQ Apps have problems if you have a lot of sensors paired natively to the watch. Going off memory here, but having 1 HR sensor in the paired sensor list is just fine. Having 9 on the paired sensor list will make it never work and numbers in between are shades of gray of working or not.

    This problem occurs just because they are on the paired sensor list in the native section of the watch. None of them need to actually be connected to cause the problem.

    https://forums.garmin.com/showthread.php?358216-Connect-IQ-2-1-2-SDK-Available!&p=903803#post903803
  • This wouldn't be it. She doesn't have any other sensors registered. Not even a hr sensor.
  • Good news is there is a relatively easy workaround. Just not pretty. Basically after 1 or 2 seconds, check to see if any messages have been received in onMessage. If not, release the sensor object and create a new one. So far, this has worked for me 100%. Just kind of an annoying hack.

    Could someone from Garmin Chime in here? Given that I can also reproduce it with the sample MO2 app, I suspect this might be an actual fw bug. I'd be interested in seeing if anybody else can reproduce it.

    I'll also try adding an HR sensor once my wife lets me have the device for a bit. Maybe the lack of other paired sensor devices is causing the problem.
  • Former Member
    Former Member over 5 years ago in reply to ekutter-dnu

    Same exact behavior on a Vivoactive 3 fw 7.20, with a data field created with SDK3.1.6 or 3.1.7. To get the connection working, after a couple of seconds I have to release and reopen the channel.

    I've seen the datafield working without this trick only when I (re)select the datafield in [any activity]/settings/data field/.
    In that case, it seems to make a "clean restart " (note, I'm still in the settings page). Then, if I try to start that activity, the datafield doesn't work (without the trick).

    Strange that nobody else found this same issue in over three years.