Welcome Guest,Register Now
Log In

ANT Forum

Welcome guest, please Login or Register

   

ant_dll.h ?

Rank

Total Posts: 9

Joined 2013-10-09

PM

The ANT_Device_Profile_Heart_Rate_Monitor.pdf document makes mention of the ANT_DLL.h include file. It doesn't seems like this file exist in the ANT_Windows_Library_Package_v3.2, or does it?

Are all documents online in sync with the latest libraries sources / binaries ?

     
Avatar
RankRankRankRank

Total Posts: 235

Joined 2012-08-31

PM

The latest versions of the libraries and device profiles are online. The library is more recent than the device profile.

This guidance is probably more helpful than the example in the device profile: http://www.thisisant.com/developer/ant/starting-your-project/

Hope that helps.      
Rank

Total Posts: 9

Joined 2013-10-09

PM

Thanks. That confirms my observations. It would be a good thing to have all docs synced as much as possible.

I've seen quite a few similar new comer posts on this forum that were essentially looking to achieve the same goal we have, that is, to put up a simple C++ code that get the heart rate data from a HR device. Just the "secrecy" requirement around the network keys (when using ANT+ instead of ANT) can create quite some pain to new comers. As long as we need a developer account on here to access the said documentation and sources, I don't see the purpose of sort of trying to hide the keys further... You get a dev account, you can see it. At least, the network keys which are non-zeroed should be indicated in the profile PDF documents, along with the code examples. A Non Disclosure Agreement signed by all developers is possibly more what is required here.

Anyway, back to the point...

My interest in the older examples found in the profile PDF documentation is that it was more in-line with the kind of code I wanted to implement. That is, simple linear C/C++ code without much of the multi-thread message handling infrastructure... which I don't not care about as a high-level integrator developer. We just want an, as much as possible, "Hello World" type of code interface with the ANT+ libraries. Something like this:

ANT_Data_struct MyANTData;

main()
{
Ant_Lib MyANTObject = Create_ANT_Object(some params if required here);

MyANTObject.Open(params such as USB port #, channel id, network kety etc.);

Loop while not done
{
MyANTData = MyANTObject.GetDataPage(pagenum);
}

MyANTObject.Close();

}

The thread pooling and storing data coming from the ANT device would be inside the object MyANTObject, and hidden from the high level code. By calling the GetDataPage(pagenum), the library effectively returns the next stored data page on a buffer.

That's how I though we would do it before digging in all the documentations, etc. It may be just me, but this library seems more complicated than it should for it's end-users, the application developers. Granted, it is always good to provide more low-level calls for those who want to control every details, but the developers should have the choice. Am I just misinterpreting the way the ANT Library works?

Thank you for your attention.
Regards
     
Avatar
RankRankRankRank

Total Posts: 662

Joined 2012-10-09

PM

If you want something slightly higher level (but still not quite what you are describing), please have a look at the C# demo in the library package - there are lots of comments throughout the code to help you. You still need to understand the basics of the ANT protocol and ANT messages, for which the "ANT Message Protocol and Usage" document is a great resource.

The threading is there for a reason - wireless events happen asynchronously to the serial link between the PC and ANT, and the serial link itself requires continuous polling for new messages.      
Rank

Total Posts: 9

Joined 2013-10-09

PM

Thanks for the reply. I will have a look.

I agree with you that there is a need for the asynchronous event handling, but what I'm suggesting is that it could be better encapsulated into the library as an object or something similar. It would still all be there, but handled in the background, inside the library rather than to require each developer to cut and paste code which "just need to be there" and for which they do not really have any need to use a modified version of the standard way of handling it.

Regards      
Avatar
RankRankRankRank

Total Posts: 235

Joined 2012-08-31

PM

Hi marcb,

Thanks for taking the time to lay out your feedback here.

We agree, it would ideally be the case that all of our resources are synced. The heart rate device profile is on the list for an update. It's just a question of balancing available resources.

We keep developer and adopter accounts separate so that developers wishing to work with ANT are able to access the information they need without having to sign an unnecessary usage agreement.

The Adopter agreement is only necessary for developers wishing to work with ANT+, and we have endeavoured to make it easy to find and sign the Adopter agreement.

I'll pass on your suggestion about including the network key in the device profile documents - I can see why it would be helpful for you. For now, we keep it available online together with the terms of use, so it is accessible, and we have tried to make the links to the page clear.

Moving on to your main focus wrt the library interface; the majority of the end-users of this library have been embedded developers producing sensors and purpose built display devices: generally abstraction does not help here. Application developers are often more interested in mobile applications - and the Android ANT+ Plugins follow a more abstracted approach allowing development to occur at a higher level. We have not yet seen enough demand to justify creating an abstracted layer for the main libraries.

Kind regards,

Kat      
Rank

Total Posts: 9

Joined 2013-10-09

PM

Thank you for taking the time. While I agree with you that it seems like many developers are more hardware integrators, I believe that the perceived amount of software or application developer number may be misleading. This class of developers need less in-depth reach into the libraries inner working as you mention, that is true. This being said, they do need an easy way to use the ANT/ANT+ technology if it is their intent to use it in any commercial application, be it Windows PC based or other more portable platforms. These developers need as simple way to access data sent by the hardware. Keep in mind that for every embedded developer team, there are probably ten times more applications developers that will want to connect to it. Also consider that with the new wave of bi-directional bike training platforms, more and more PC based applications will be made to provide virtual bike rides and all.

I also think that many application developers just silently "give up" and go for a competing solution such as Bluetooth enabled fitness devices (I'm not inventing it but rather reporting from a real case I'm aware of). They gave up out of frustration... I thus applaud your willingness to listen to these comments as it might actually have more impact than it seems on surface...

On the hardware side, I think ANT+ is amazing at saving battery power and such, while offering a vast list of network configuration options... But any work to make it more user-friendly for your software developers will vastly improve your penetration of the market. This may actually be the very reason why you see little demand for PC based software application development.

As a developer (for quite some years now), my philosophy is : Why make things complicated when it can be simple. This is the whole point of introducing the C++ OO programing paradigm. You need to think "encapsulation" as much as possible. When I code, I always hide anything that doesn't need to be exposed to a user of my resulting libraries. You must always think beyond your single project when dealing with developer like us... We have tens of different such libraries to mix and integrate together in a single application. If we have to dig for weeks for each of these libraries, this is months of work for us while all we really want is "get the job done" as soon as possible.

Regards