As explained in my previous post, the latest version of the Dynastream ANT+ Radio Service is breaking my apps. Curiously enough, it seems like it's only breaking the apps when used in combination with the Dynastream ANT+ USB Service. I've suggested a simple procedure to work around the problem, but it does not work for everyone, and generally speaking is not 100% reliable: all my devices worked when I applied the procedure, but some stopped working again a couple of days later.

Now, for reasons that I'll explain below (if you're interested) patching this error is complicated. Still, I've released a new version of my apps (Sportablet 7.0, Uploader for Garmin 6.1) which contains what seems to be a robust and consistent fix, at least in all the cases I've tested. However, since the app is working as it is for quite a few of you, at this stage the fix is initially disabled and you have to enable it manually. It's likely that the next version of the apps will activate this as a default, also depending on your feedback.

To enable the patch, open the options, scroll down to ANT+ and then to the last option, which should read "Force Claim Interface". Turn that on. That's it. The purpose of this option is to force the dynastream driver to proceed with the initialization as before. It has no effect on the data transfer, because that part was not impacted. However, remember: if you have reinstalled the app, messed around with the options, etc, you have to bring the options back to what was working for you (file chunk size, delay ack, etc).

Recommendations: I've said this in my previous post, but it's worth saying it again:
- I would suggest that you disable automatic updates for the TWO dynastream services, unless you have strong reasons not to.
- Follow Sportablet on facebook or twitter. If you don't, please, next time you have a problem check the blog first.


Let me know if this patch works for you, thanks.

Details for the technically minded: Dynastream (which is a property of Garmin, by the way) provides developers with a so-called SDK to interface with their services. I was one of the early adopters of their SDK, and over time I've not only written a lot of code around it to support all the ANT+ Garmin devices, but also to work around various problems and issues. I now have a few thousand lines of code built around their SDK. Now, when they released the new service, they also released a new SDK, which is completely incompatible with the one I used. The classes I used are no longer there, the hierarchy is completely different, methods are gone. As usual, it's not just that I have to adapt my code. It's also that I've tuned the existing code over a couple of years, and if I move it to the new SDK, most of that tuning is gone. Also, a couple of things I'm doing to speed up the transfer (which Garmin is also doing on Windows) does not seem to be possible anymore with the new SDK. That said, the old SDK is still working, sort of. Most of the functions work, probably because the underlying functions in the service are still the same. However, the new driver won't start up correctly, and if you force (like it was necessary with their very first version) a reset or an enable/disable cycle, you get an interface error. So, it's a bit of a mess. Still, the patch I've come up with seems quite robust (I'll know more once you guys start using it). The future is a bit less certain. I currently lack the time to rewrite the entire ANT+ code using their new SDK, test it on a number of devices (android + garmin), tune it, etc. The apps are nowhere near the profitability required to allocate this kind of effort. It's also pretty obvious that Dynastream is moving in a direction where apps have less and less control, which is exactly the opposite of what I need. We'll see. Meanwhile, as I said, it would be better to turn of automatic update of their services.

A couple of days ago, a new version of the Dynastream ANT+ Radio Service was released. After that, I've received a couple of emails from users telling me the app wasn't working anymore. I was traveling and I couldn't test it, so I warned you guys on twitter / facebook (I suggest that you follow the Sportablet account on one of those).

I now had the time to perform some testing on my own. This is what I've found:

- if you are using a device with a built-in ANT+ chip, there seems to be no problems.

- if you are using the ANT+ USB dongle, you may have problems. In quite a few cases, the app wasn't working after update. However, it does not seem to be a problem with the app. Just uninstall the ANT+ USB service (not the radio service) and install it again. This procedure has fixed the issue in all of my tests.
Update / 1 : in one case, a user had to uninstall the usb service, reboot, reinstall. It didn't work without a reboot.

Generally speaking, I would suggest that you disable automatic updates for the dynastream service, unless you have strong reasons not to. Their roadmap is taking them in a direction where apps have even less control than they used to have. I spent quite some time squeezing as much reliability as I could out of their services, in the most difficult scenario (there are dozens of apps talking to HR straps, but no others talking to Garmin watches). I would suggest that you stay with a version that works, as long as you can.

As usual, when something external to my apps breaks, I get dozens of angry emails (thanks guys). Unfortunately, like many of you I have a real job: that's why I can spend some time on unprofitable hobbies like this app. Therefore, I cannot always respond immediately, which seems to upset some people even more. If you don't want to follow sportablet on facebook / twiter, at least when you have a problem check the recents posts in the blog. There is a good chance that you'll find the answer here.


UPDATE / 2 : for some of you, the fix above is not [reliably] working. I have experienced this myself on some devices: it works, but not all the times. I'm now testing a new version of the apps which should reliably work around the problem, which is only about establishing the initial link. Please stay tuned for another post / app update in a few hours.

I've just pushed to google play a new version of my apps (Sportablet 6.9 / Uploader for Garmin 6.1). These versions contain fixes for recent garmin connect and endomondo issues (see my previous two posts). As usual, it may take a few hours before it's made available to you guys.

If you still have troubles after the update, please get in touch using the contact form. I'll have to see your transfer logs.

[update: new version pushed on google play]

In the past few weeks I've got occasional reports of failures while uploading to garmin connect. Some were due to maintenance activity on their website, but in a few cases it was different. Looking at the transfer log, it seemed like the server was responding in a different way than usual. The problem tended to "fix" itself, meaning the guys at GC are probably A/B testing some changes, and you get a failure only if you end up being randomly chosen for the test.

Anyway, looking at the logs I've devised a potential fix. I have to say potential, because right now I cannot replicate the original failure anymore (that's the problem when the server is doing random testing). It will be part of the next release (Sportablet 6.9 / Uploader for Garmin 6.1).


If, after I release that version, you find that you still have problems, please get in touch using the contact page, I'll need to see your transfer logs.

Meanwhile: if you want updates on this issue, please follow the sportablet account on twitter or facebook.

[update: new version pushed on google play]

If you try uploading to Endomondo from my apps, you will probably experience a failure. This is due to an update on the endomondo side, which involves various changes (remember: Endomondo support is in permanent beta). Most of those changes are trivial (some endpoints previously on http have been moved to https). 

[nerd part]
One of those change is big and breaking, as they have configured their servers so that SNI (server name indication) is required during the HTTP negotiation (this is unusual for a big company, as it's mostly the case for shared hosting; might be a configuration problem on their side). Unfortunately, the android library classes that I need to use to send data to endomondo do not support SNI (in case you're wondering: browsers like chrome under android don't use the library classes :-).

I already have a workaround , and I'm currently testing it. I may have a release ready later today or maybe tomorrow. Still, the patch requires that I reach down to some hidden parts of the system to enable SNI. It may or may not work on your android device, that is, if the manufacturer has messed too much with the standard distribution, it may still fail. 

If, after I release a new version (Sportablet 6.9 / Uploader for Garmin 6.1), you find that you still have problems, please get in touch using the contact page, I'll need to see your transfer logs.

Meanwhile: if you want updates on this issue, please follow the sportablet account on twitter or facebook.