ANT Forum

Dear all at Dynastream,

In my android ANT app I'm using a CHANNEL_PROOF_PERIOD of 164 (5 ms circa) cause i'm controlling 10 ANT devices with success. I'm using the tablet as a master and the devices as slaves. Now the problem is that with new Android 7 all the communication is slower. I've seen also that sometimes when the tablet is doing some background activity (not related to my app) it is even slower and not usable.

I've noticed also the ANT radio service it is outputting so many log lines (This is with the ANT settings app with logging == false!):

03-17 11:39:53.960 3222-4155/? D/AntHalService: mJAnt.ANTTxMessage returned status: SUCCESS
03-17 11:39:53.960 3222-4155/? V/AntHalService: ANTTxMessage: Result = 1
03-17 11:39:53.960 3222-4155/? V/AntHalService: ANT Tx Message end
03-17 11:39:53.975 3222-3422/? V/AntHalService: ANT Tx Message start
03-17 11:39:53.979 3222-3422/? D/BluetoothSocket: getOutputStream(): myUserId = 0
03-17 11:39:53.979 3222-3422/? D/JAntJava: ANTTxMessage: exiting

This probably is slowing down more the execution, is there a way to rebuild the ANT radio app without log? Is there something else i can do?
Our customers is complaining a lot and i need to fix that issue asap.
Also, I'm looking to the source code you provided on your GitHub and it seems that logging on "D/AntHalService" means it is a DEBUG version of the pre-installed app. Is this possible?

Thanks
Max      

Hi,

Any luck on this?

Thanks
Max      

Hi Max,

Which phone vendor are you seeing this on? The ANT HAL Service is typically modified, compiled and installed in a custom build by that particular manufacturer.      

Dear Harrison,

Thanks for your reply!
I saw this in many Samsung devices: SM-T710, SM-T713, SM-T810, SM-T813, SM-T715 and SM-T580.

I've checked the source code on your github repo and those log lines are also there.

Max      

It looks like they've accidentally built the debug version of the service rather than the release version. Unfortunately, it's the manufacturer who holds the signing keys, so the manufacturer will have to correct the issue.

I advise reporting this to them and they will hopefully be able to fix this in a later update. In the meantime, we can only suggest that you try to do some performance profiling and try to pull back the channel period you are using. A channel period of ~200Hz is fairly aggressive and is likely dominating much of the radio time over other protocols running on the chipset.      

Dear Harrison,

I understand and i know that this is something that has to be solved on the vendor side but it will be great if you can contact them since i’m representing my company but you’re stronger representing Dynastream. Can you?

Thanks
Max      

Of course you only need to introduce myself then we'll discuss whitout bother you. You can use my mail saved with my account on thisisant.com

Thanks!