This object is in archive! 

Not record any HRM data 3.8.0 v

robot hack shared this problem 8 years ago
Solved

Hi

After upgrade to 3.8.0 version the Locus does not record any data from the BT 4.0 HRM sensor.


Regards

Rob

Replies (25)

photo
1

Good day robot,


never ending troubles with BT4 in Locus? Sorry for that.


What device are you using? Rom, Android version, rooted?, BT HRM device? Do you see a HRM value in Bluetooth manager? In dashboard?

photo
1

Hi

In fact, BT causes problems but I hope that You are able to fix them. Locus then become one of the best application :-)

My Devices:

- Samsung Galaxy Mini S5, the original version of Android 4.4.2 G800FXXU1ANL1 from dec 1 2014, no root,

- HRM sensor - Medisana Bluetooth Heart Rate Belt Bluetooth Smart made by Germany.


HRM sensor is correctly detected in the Bluetooth Manager and Locus dasboard but Locus still repeatedly informed first on the white notification box and second on the green notification box - connected the heart rate monitor. Locus again loses the connection.

Regards

Rob

photo
1

Hmm oki, are you interested in fix of this problem? I'm asking because it may be a longer run as I will need to find out, step by step, what may cause this. If you want to try to fix this, let's start with basic log created by this method http://docs.locusmap.eu/doku.php?id=manual:faq:how_to_create_debug_log , immediately after problem occur.

photo
1

Oki, I'll try tomorrow take a bug report.

photo
1

I sent You a bug raport.

photo
1

Hi, I also experience problems with HRM since 3.8.0, but not as serious as robot hack. The problem I experience is that Locus does not remember device pairings so it asks again and again which BT device I want to connect to. This means that if the connection temporarily drops during a ride, nothing is recorded until I unlock the screen and click on the device. This worked perfectly well in the last beta before 3.8.0. Hope this helps.

photo
2

Tomáš, thanks, I noticed this also yesterday, so consider it as "fixed".


Robot, where did you send a bug report? Because I do not see it anywhere ...

photo
1

Brilliant, thanks. :-)

photo
1

Hi, I sent a bug report to support.locus@asamm.com on april 22.

I ship again to the same address only in the zip archive today.

photo
1

Thanks for report. I was checking it before release of 3.8.2 version and unfortunately in log were no error. For Tomaš seems that BT 4.0 connections works also fine (as well as for me) except small re-connecting issue.


If you will have same troubles with 3.8.2 version, I'll have to create for you some special version that will print out a lot more information into log, so we will better see, what happen in your device.

photo
1

Unfortunately, I still have troubles with 3.8.2 version, but their nature is similar to version 3.7.0, and as it Tomas says, Locus many times does re-connecting HRM device. Looking at the attached chart all pits are moments when Locus re-connecting. I hope that this is a guiding you to a solution.

photo
1

robot, did it ever work for you? I don't remember having significant troubles with 3.7.0, only 3.8.0. I mean, I did have some troubles, but I don't think it's got anything to do with Locus. When I put the phone in a back pocket of my jersey, it frequently disconnects from the HRM. But I thought that's just the way the two devices and my body interact together. It never occurred to me that a different application might not have this problem. :-)

photo
1

Hi Tomas

It is the first time when I use BT4.0 sensor and smartphone to log my training. I can not exclude that the problem is on the side of the HRM sensor. I will try to do more tests on other applications to log training.

photo
1

Hi

I did a comparison of data logging Locus and Endomondo in the same workout. Endomondo logged position on average every 1-8 seconds but all the stored position include HRM data. Locus logged item every 1-3 seconds on average, but many (nearly 30% of the total) recorded position does not include HRM data. Locus did not register HRM date by a few seconds up to 3 minutes. I sent to You an email to comparison GPX files Locus and Endomondo.

photo
1

Hmm this will be complicated ...


I've just released 3.8.2.2 version of Locus Free to Beta channel, so if you find a while, please create a log with this version. There is enabled a lot more debug messages, so i hope, there will be something useful. Thanks

photo
1

Oki, but after upgrading from google play I have version 3.8.2 Locus Pro and Free. Did you mean a different place from where I can download a version 3.8.2.2?

photo
1

Did you follow steps on Google+ page for Locus Beta version? If you became beta tester, you should be able to download Locus Free 3.8.2.2 which is beta version.

photo
1

Oki, done.

photo
1

Hmm and "done" means you created and send a log somewhere? May you please tell me where?

photo
1

Hi


I sent You (support.locus@asamm.com) a bugreport caught when the Locus 3822 does not read HRM data.

photo
1

I knew it will be tough.


Log received, thank you.


I've just spend almost two hours by comparing values from logs with my code and I see no problem in Locus code. It just looks that Android service that handle connection, disconnect itself after a while, which terminate connection in Locus.


After some searching, I found this topic: http://developer.samsung.com/forum/board/thread/view.do?boardName=General&messageId=246576 , where they describe exactly same problem and well, as you may see, no answer ...


Do you know, are there any plans to official update for S5 mini to Android 5? This should help.


Interesting is, that other app like Endomonto works fine. I've found also one answer with one small suggestion that I do not use in Locus, so I'll try to implement it. But I'm not giving this a big hope

photo
1

I felt the same, because I realize the various implementation and most often come across difficult cases. I love issues in which it seems that after checking and greasing everything still something squeaks;-)


I already installed three updates for KitKat but as I've heard Samsung has announced the release Lollipop will be available in Q2 2015.


But the interesting thing is that the app Endomondo and Pulsometer store all the data. In addition, the app Pulsometer saves to each entry "OK" attribute. Maybe these applications have friendly features which after connect to the HRM forces maintaining the connection.

Anyway, still depends on me to fix the problem.

photo
1

Q2 2015 sounds good. So in worst case, we may just wait another month/two.


Please check next beta version 3.8.2.3 which will be available probably in friday. As I wrote, I did there one quite small change, so I'm interested if this make any change ... thanks

photo
1

Oki, I wait for notification.

photo
1

I tested today version 3.8.2.5, unfortunately it is worsening, Locus was not registered approximately 50% of the HRM data.

At the same time Endomondo saved 100% of data.

photo
1

Hm, that's interesting. When I tried running Strava and Locus at the same time, only one of them was able to connect to the sensor, so I had to turn it off in Locus for Strava to be able to pick it up.


Also I noticed that Strava (unlike Locus) fills the gaps with last known value so it seems like it recorded something, there just isn't any variation in the data. I know this is silly but just to be sure, you are seeing actual measured data, not just flat interpolated segments, right?

photo
1

I have no experience with Strava. But by analyzing data from Endomondo appear to be authentic.

photo
1

So, I did some tests on my S5 and problem with logging occurs when HR data records more than 2 applications. When were included Locus, Endomondo and Strava any program has not registered the correct data.

However, the quality of stored data by Strava does not look right. I confirm what observed Tomas on Strava it fills the gaps with last known value (cheating). This is evident in the charts. In addition, I made a comparison with an external recorder that records HR in open signal 5.3kHz technology. Records from Endomondo and from open signal recorder look very similar which would confirm that the Endomondo correctly writes data.

photo
1

Hmm so two applications do not record data correctly, one did.


I was testing last two days ANT+ HRM sensor and after half of hour, chart starts to have also such weird spaces without values, probably similar to what you noticed in BT LE sensors. Interesting.


I'll try to enable some logging and test it more precisely during next run.

photo
1

Hmm damn, what to do with it? I hoped that during my next trainings, this issue appear again, but everything is correct and without any unwanted spaces.


Isn't there just possibility, that sensors has some problems with measuring HRM values, when they are not perfectly connected to body? Or when their battery is low? (I was changing battery meanwhile). Just guessing ...

photo
1

I have not noticed problems with the heart signal reception because I record signal simultaneously on the clock. Another application indicated that the battery is at 60% capacity.

photo
1

Bad news. I tested yesterday Locus on long distance route. For almost 2.5 hours Locus record HR data as before with spaces. Unfortunately, after 2.5 hours of workout he stopped recording HR data at all. At the same time Endomondo recordeted all the seven hour of training.

Help me, kill me...

Files: long.png
photo
1

Kill me too please, I have no idea, what may be wrong. I downloaded Endomondo and checked it's source code (after some de-compilation) and it seems they do not use any special tools or external libraries. So it has to be some incorrectly implemented feature in Locus. But is it almost impossible to fix this issue when I'm unable to simulate this problem. I test Locus on three devices and with three HRM monitors and all works correctly for me.


So suggestion: do not use Locus for now, till in news will be info like "Fixed problems with HRM BTLE connection".


Few days ago, I've switched from SGS5 device to older Xperia Z1C, so I do some more tested during next days.

photo
1

Menion, there is no chance to murder You, who will repair Locus, Yes :-)


Anyway, I still thinking about my HR sensor because it is a combination of two devices. First device send signal via the BT 4.0 standard and second via open signal 5.3kHz technology. Maybe that's due to a combination of the devices sends data in a specific way, so Locus may not always correctly read HR data. Also, I guessing...

photo
1

Hmm you seems to have more knowledges about BT then me ;). Anyway older BT3.0, there was quite a lot of things to do. You had to read data manually, connect manually, periodically check connection and so on. So if there were any problem, there was a lot of places, where you may change and test something.


Anyway now, with BT 4.0, whole system is based on "listeners". This means, you in application just connect to certain BT device with one command and system then call certain function in your application and send a new data into this function. So everytime system receive any new data, it should call this function. And I see not much possibilities, how may I (as a developer) influence, how this works.


----


I was searching a little bit and found some sample application from Google where I found a tiny difference in their listeners code and mine. So we will see in next version, but to be true, I think this won't change anything. Give me a few days. I'll test my HRM monitors during running on another device and let you know ... I really hope this problem happen to me as well, otherwise I do not know what to do with it, damn :/.

photo
1

Welcome back

I bought a few days ago another model of a heart rate monitor and conducted several tests on Locus. The results are surprising because all the data registration was successful. The conclusion is that my old heart rate monitor Medisana has some special property of communication, which introduces distortion when recording data. It remains to pass this case to those where things do not really work properly but nobody knows why.


Regards

photo
1

Hmm so good news. Thanks for them!

Replies have been locked on this page!