BT GPS reconnection time take some minutes
Environment:
- Android 6 (S4 mini Android 5-8, from cyanogemod up to linageos and experimental builds)
- multiple locus map versions
- iBlue 747 A+
Usecase:
- no GPS Recording
- GPS over Bluetooth
- turn dislplay off for some minutes and power on again
It does take 1-3 minutes until green message "... GPS connected ..." pops up. Normaly I try to force it to speed up by navigating to gps screen, disable GPS and enable it again. But sometimes it does find it without forcing after some minutes.
Sometimes it does show me available parings (only 1 element in list)
Is this normal as an limitation of the old BT 1.2 protocoll and the possible power saving conzepts of the GPS transmitter? I would expect that GPS transmitters are less active if they got disconnected.
Should I try to use an BT GPS app to share GPS with locus Maps instead of using locus GPS implementation?
What are the benefit of locus BT GPS instead of using a special BT GPS app?
I hope there are no details missing. Just ask me for more information.
If you want a debug log, tell me which android version you would like to support. Up to Android 7 is stable for my device.
Kind Regards
The same problem 
Good day Falco,
if some users has troubles with BT GPS in Locus Map, I usually suggest to first try one of these external applications available on Google Play. I'm not a Bluetooth master, so such app may confirm where is a problem.
So yes please, try this external app. It has an advantage that such GPS location may be shared to all apps. The disadvantage is that it won't react on the screen on/off like it does, when connected directly to Locus Map.
I'm not for some time using BT GPS with Locus, but as I remember, there should be really low delay in connecting. Definitely not something around 3 minutes.
Good day Falco,
if some users has troubles with BT GPS in Locus Map, I usually suggest to first try one of these external applications available on Google Play. I'm not a Bluetooth master, so such app may confirm where is a problem.
So yes please, try this external app. It has an advantage that such GPS location may be shared to all apps. The disadvantage is that it won't react on the screen on/off like it does, when connected directly to Locus Map.
I'm not for some time using BT GPS with Locus, but as I remember, there should be really low delay in connecting. Definitely not something around 3 minutes.
I see a problem in an external app test: I don't know if it will actually disconnect GPS on screen off. I would guess that an wakelock detect could help to get an answer to this.
If I use locus track recording, the problem should disappear but then I would need to spend more weight in batteries.
I will test another GPS receiver and I try to find an external GPS app which will disconnect on screen off. @Menion does it make sense to search for an app which handle screen power events or would this be imposible for background apps based on the API definition?
I see a problem in an external app test: I don't know if it will actually disconnect GPS on screen off. I would guess that an wakelock detect could help to get an answer to this.
If I use locus track recording, the problem should disappear but then I would need to spend more weight in batteries.
I will test another GPS receiver and I try to find an external GPS app which will disconnect on screen off. @Menion does it make sense to search for an app which handle screen power events or would this be imposible for background apps based on the API definition?
I'm worried that no app on Google Play (as I know) do not disable/enabled BT connection to external GPS based on screen on/off state. I'm not sure about it, just my expectation. Anyway it should be possible from technical point of view.
I have older QStarz BT GPS and as I test it ... after screen off/on, GPS reconnection took around 2 seconds (tried 5x).
It tooks same time on all ROMs you tried?
Also you see green "GPS connected"? Because I see "Connected to QStarz 1000XT" (you should see same except name of device).
I'm worried that no app on Google Play (as I know) do not disable/enabled BT connection to external GPS based on screen on/off state. I'm not sure about it, just my expectation. Anyway it should be possible from technical point of view.
I have older QStarz BT GPS and as I test it ... after screen off/on, GPS reconnection took around 2 seconds (tried 5x).
It tooks same time on all ROMs you tried?
Also you see green "GPS connected"? Because I see "Connected to QStarz 1000XT" (you should see same except name of device).
No I see same like you, connected to device in green after 30 to 180s
I would guess that my iBlue 747 A+ does go into a BT power saving mode for "record GPS only" if the connection drops. It does not have a hardware "record only" mode. Tomorrow I will get an QStarz Q1300 to test it.
Yes it is the same on all ROMs. The inconsistent reconnect times does support my guess. And a hard reset of the 747 A+ does help too, it will connect in 30s.
Thank you for your information. I hope to get 2-3s reconnect time with my new QStarz as well. I will update the ticket.
No I see same like you, connected to device in green after 30 to 180s
I would guess that my iBlue 747 A+ does go into a BT power saving mode for "record GPS only" if the connection drops. It does not have a hardware "record only" mode. Tomorrow I will get an QStarz Q1300 to test it.
Yes it is the same on all ROMs. The inconsistent reconnect times does support my guess. And a hard reset of the 747 A+ does help too, it will connect in 30s.
Thank you for your information. I hope to get 2-3s reconnect time with my new QStarz as well. I will update the ticket.
I found the issue. My Locus Maps Configuration set or maybe the full migration path of my Locus installation.
My 2nd S4 mini device doesn't have this bug.
Are you interested in some details to fix the migration path or to give other people better support before I remove my config an reinstall Locus Maps?
I found the issue. My Locus Maps Configuration set or maybe the full migration path of my Locus installation.
My 2nd S4 mini device doesn't have this bug.
Are you interested in some details to fix the migration path or to give other people better support before I remove my config an reinstall Locus Maps?
Good day Falco,
thank you for a testing. This is really really surprising, that some configs may affect this.
Please if you can, create a menu > more > backup manager > backup of settings. This make a complete backup of all main app settings. Then you may simply reset app settings by re-install of simple "Delete data" in application details in your system (usually under system settings > app manager > Locus Map).
I can't imagine that some settings may affect your connection times, anyway if after reset, all will work as expected, I'll gladly test your settings backup on my device.
Good day Falco,
thank you for a testing. This is really really surprising, that some configs may affect this.
Please if you can, create a menu > more > backup manager > backup of settings. This make a complete backup of all main app settings. Then you may simply reset app settings by re-install of simple "Delete data" in application details in your system (usually under system settings > app manager > Locus Map).
I can't imagine that some settings may affect your connection times, anyway if after reset, all will work as expected, I'll gladly test your settings backup on my device.
I will do it step by step.
1st step is a config reset by locus
2nd step config reset by delete app data in system app details
3nd step a app reinstall
4th step android reinstall
I will give you my test result and my broken config backup.
The problem was very consistent. I did never get a reconnection in seconds like at my 2nd device. And I did remove an recreate the BT pairings in android BT manager arround 1-3 times per day. Maybe 50-100 in total per year.
I did live with this bug for 2 years. My config is maybe 2-4 Years old.
I will do it step by step.
1st step is a config reset by locus
2nd step config reset by delete app data in system app details
3nd step a app reinstall
4th step android reinstall
I will give you my test result and my broken config backup.
The problem was very consistent. I did never get a reconnection in seconds like at my 2nd device. And I did remove an recreate the BT pairings in android BT manager arround 1-3 times per day. Maybe 50-100 in total per year.
I did live with this bug for 2 years. My config is maybe 2-4 Years old.
1st step did improve the behaivor. But I still got the non reconnecting bug in 1 of 5 cases.
"Non reconnectiong bug": devices doesn't connect anymore to BT GPS. The BT Connection is there (Blue LED starts to blink on GPS device) but locus doesn't show any GPS position or anything else
I did compare it with my working 2nd device and 20 of 20 cases did work, sometimes it takes maybe 6s instead of 2s. But it did work every time.
2nd step with delete app data didn't change anything, I got 1-2 Non reconnectiong bugs in 10 tests.
During the week I go on with 3rd and 4th step.
1st step did improve the behaivor. But I still got the non reconnecting bug in 1 of 5 cases.
"Non reconnectiong bug": devices doesn't connect anymore to BT GPS. The BT Connection is there (Blue LED starts to blink on GPS device) but locus doesn't show any GPS position or anything else
I did compare it with my working 2nd device and 20 of 20 cases did work, sometimes it takes maybe 6s instead of 2s. But it did work every time.
2nd step with delete app data didn't change anything, I got 1-2 Non reconnectiong bugs in 10 tests.
During the week I go on with 3rd and 4th step.
Well, I do still have trouble to create a stable connection or at least a state with stable reconnection success.
I use 2 different GPS Bluetooth devices, 2 S4 mini and 1 Z3 Compact.
All of them are running without any power saving mode. And to force GPS reconnection I do even use track recording with 1s recording intervall.
Sometimes I loose all satelite information permanently but still have a Green GPS even if the GPS Fix timestamp is 2 hours in the past.
Well, I do still have trouble to create a stable connection or at least a state with stable reconnection success.
I use 2 different GPS Bluetooth devices, 2 S4 mini and 1 Z3 Compact.
All of them are running without any power saving mode. And to force GPS reconnection I do even use track recording with 1s recording intervall.
Sometimes I loose all satelite information permanently but still have a Green GPS even if the GPS Fix timestamp is 2 hours in the past.
The only problem with missing reconnects is that I loose my barometric sensor statistics because currently locus can't record altitute without GPS fix
http://help.locusmap.eu/topic/altitude-change-without-gps-fix
I don't care about GPS fix, in some cases you will lose GPS fix anyway, even with a wired connection. But I care about altitude change which didn't get recordorded without gps fix :(
Would be great if we could change this. And I guess the idea sensordata record without gps fix is much more easy to implement then an unknown bluetooth connection issue :)
The only problem with missing reconnects is that I loose my barometric sensor statistics because currently locus can't record altitute without GPS fix
http://help.locusmap.eu/topic/altitude-change-without-gps-fix
I don't care about GPS fix, in some cases you will lose GPS fix anyway, even with a wired connection. But I care about altitude change which didn't get recordorded without gps fix :(
Would be great if we could change this. And I guess the idea sensordata record without gps fix is much more easy to implement then an unknown bluetooth connection issue :)
Good day Falco,
sorry to hear about some remaining complications. I'm just not perfectly sure, how may I help here.
Because there has to be known location, that will have defined altitude, what may be a usage of few same locations stored in recorded track with different distance?
Also, what about using some 3rd party apps like "Bluetooth GPS" from Google Play? Do they have an exactly same problem with disconnecting from GPS unit?
Good day Falco,
sorry to hear about some remaining complications. I'm just not perfectly sure, how may I help here.
Because there has to be known location, that will have defined altitude, what may be a usage of few same locations stored in recorded track with different distance?
Also, what about using some 3rd party apps like "Bluetooth GPS" from Google Play? Do they have an exactly same problem with disconnecting from GPS unit?
Thank you for your response.
"what may be a usage of few same locations stored in recorded track with different distance?"
The useage of same locations with different altitute values will be the posibility to calculate altitute changes over time. Or in other words, total climb hight during the trip. This value is in many outdoor activities even more importand then total track distance. And total climb calculation based on SRTM will fail if you go over bridges or if you lose your gps fix.
I am still testing the bluetooth connection, I do have corrently 100 hours of testing accrous multile device kombinations and still didn't figure out which things are causing the issue. I am done with hardware combinations and did start with software combinations yesterday.
My best runs are allways non moving runs on a static test bench.
The current run is:
Hardware not Moving: Z3 Compact + Qstart Q1300 with 30cm BT distance
Software: Locus Satelite View, Track Recording On, Display On, No Energy Safing
Currently 10 hours without problems, I will repeat it another time to prove that this kombination is stable
In worst case the error is only related to moving usecases. Because even my most easy moving test case:
Hardware Moving: Z3 Compact + Qstart Q1300 with 30cm BT distance
Software: Locus Map View, Track Recording On, Display Off, No Energy Safing
did fail after 6 hours. There are so many things going on when you are moving with active track routing, all the sensor data change, map rotation and rerendering and all the locus automation features. I did eleminate all of them with non moving tests.
After my secound 16 hours non moving test on my workbench I will go on with display off (I already did some non moving display off tests but only with pressure sensor and internal GPS and only for 2 hours bearly moving, only starecase usage for pressure tests)
Hardware not moving: Z3 Compact + Qstart Q1300 with 30cm BT distance
Software: Locus Satelite View, Track Recording On, Display Off, No Energy Safing
Then I go on with 3rd Party apps
Actually I don't belive that we could find the issue. The testsetup is so complicated and even then it takes some hours to hit the issue.
I guess it is more easy to get an GPS error indipendend altitute ascent and descent calculation like this idea: http://help.locusmap.eu/topic/altitude-change-without-gps-fix
All Tools I know are able to work with GPX files where you have multiple points with same GPS coordinates but different altitude values.
And at the end we would need http://help.locusmap.eu/topic/altitude-change-without-gps-fix anyway for example if you use a smartphone GPS solution you can lost gps fix very often but the pressurce sensor is still useable for altitute ascent and descent calculation or for display of the current altitute
Thank you for your help.
Thank you for your response.
"what may be a usage of few same locations stored in recorded track with different distance?"
The useage of same locations with different altitute values will be the posibility to calculate altitute changes over time. Or in other words, total climb hight during the trip. This value is in many outdoor activities even more importand then total track distance. And total climb calculation based on SRTM will fail if you go over bridges or if you lose your gps fix.
I am still testing the bluetooth connection, I do have corrently 100 hours of testing accrous multile device kombinations and still didn't figure out which things are causing the issue. I am done with hardware combinations and did start with software combinations yesterday.
My best runs are allways non moving runs on a static test bench.
The current run is:
Hardware not Moving: Z3 Compact + Qstart Q1300 with 30cm BT distance
Software: Locus Satelite View, Track Recording On, Display On, No Energy Safing
Currently 10 hours without problems, I will repeat it another time to prove that this kombination is stable
In worst case the error is only related to moving usecases. Because even my most easy moving test case:
Hardware Moving: Z3 Compact + Qstart Q1300 with 30cm BT distance
Software: Locus Map View, Track Recording On, Display Off, No Energy Safing
did fail after 6 hours. There are so many things going on when you are moving with active track routing, all the sensor data change, map rotation and rerendering and all the locus automation features. I did eleminate all of them with non moving tests.
After my secound 16 hours non moving test on my workbench I will go on with display off (I already did some non moving display off tests but only with pressure sensor and internal GPS and only for 2 hours bearly moving, only starecase usage for pressure tests)
Hardware not moving: Z3 Compact + Qstart Q1300 with 30cm BT distance
Software: Locus Satelite View, Track Recording On, Display Off, No Energy Safing
Then I go on with 3rd Party apps
Actually I don't belive that we could find the issue. The testsetup is so complicated and even then it takes some hours to hit the issue.
I guess it is more easy to get an GPS error indipendend altitute ascent and descent calculation like this idea: http://help.locusmap.eu/topic/altitude-change-without-gps-fix
All Tools I know are able to work with GPX files where you have multiple points with same GPS coordinates but different altitude values.
And at the end we would need http://help.locusmap.eu/topic/altitude-change-without-gps-fix anyway for example if you use a smartphone GPS solution you can lost gps fix very often but the pressurce sensor is still useable for altitute ascent and descent calculation or for display of the current altitute
Thank you for your help.
Good day Falco,
understand. Isn't, in the end, a lot easier to use internal device GPS unit that should work a lot more reliable? Mainly in case, you care primary about elevation and not horizontal GPS accuracy.
I personally used for around two years Sony Z1C device and was very satisfied with it's GPS accuracy. It was also years when I stopped to use a combination of BT GPS + mobile phone and rather started to use internal GPS + external power bank, just in case of heavy Locus usage over the whole day.
About multiple same locations: Locus also has no problem with it! If you, for example, specify "1s/1m and OR" conditions for your recording profile, Locus will really record all points, no matter if you stay or not. Anyway, there is a need that new location appears every second. What we discuss here is a situation, when new location stops "coming" into Locus Map, which is a problem.
Simple steps:
When there is no new location from GPS unit, Locus has nothing to work with. And it really does not make sense to every second send previous location when no new appear, sorry.
Good day Falco,
understand. Isn't, in the end, a lot easier to use internal device GPS unit that should work a lot more reliable? Mainly in case, you care primary about elevation and not horizontal GPS accuracy.
I personally used for around two years Sony Z1C device and was very satisfied with it's GPS accuracy. It was also years when I stopped to use a combination of BT GPS + mobile phone and rather started to use internal GPS + external power bank, just in case of heavy Locus usage over the whole day.
About multiple same locations: Locus also has no problem with it! If you, for example, specify "1s/1m and OR" conditions for your recording profile, Locus will really record all points, no matter if you stay or not. Anyway, there is a need that new location appears every second. What we discuss here is a situation, when new location stops "coming" into Locus Map, which is a problem.
Simple steps:
When there is no new location from GPS unit, Locus has nothing to work with. And it really does not make sense to every second send previous location when no new appear, sorry.
Onboard GPS is my solution, too. I thought about going even forther on accuracy with a MbientLab MetaMotionC Board which I did find at http://help.locusmap.eu/topic/please-develop-ble-barometer-support-for-altitude-correction
Plain pressure values over json for the best altitute accuracy sounds a little bit overkill. But I like the challange. I did even thought about mapping local pressurce data of weather stations to remove even the 20m weather change failure, very interesting topic. MbientLab MetaMotionC Board is maybe a project for winter ;)
But we still have usecases with loosing GPX fix which are not part of this bug but would solve the Idea http://help.locusmap.eu/topic/altitude-change-without-gps-fix
I didn't test it but are other sensor readouts GPS fix dependend as well? Like heartrate or other statistics about the activity. Imaging a road cycle tour at the coast or in the mountains where you have many tunnels. For example a famous road cycle tour arround gardasee is full of tunnels. Would be a shame if the dashboard will fail there.
Onboard GPS is my solution, too. I thought about going even forther on accuracy with a MbientLab MetaMotionC Board which I did find at http://help.locusmap.eu/topic/please-develop-ble-barometer-support-for-altitude-correction
Plain pressure values over json for the best altitute accuracy sounds a little bit overkill. But I like the challange. I did even thought about mapping local pressurce data of weather stations to remove even the 20m weather change failure, very interesting topic. MbientLab MetaMotionC Board is maybe a project for winter ;)
But we still have usecases with loosing GPX fix which are not part of this bug but would solve the Idea http://help.locusmap.eu/topic/altitude-change-without-gps-fix
I didn't test it but are other sensor readouts GPS fix dependend as well? Like heartrate or other statistics about the activity. Imaging a road cycle tour at the coast or in the mountains where you have many tunnels. For example a famous road cycle tour arround gardasee is full of tunnels. Would be a shame if the dashboard will fail there.
I guess it is a stupid power management thing because screen on test did succeed with 21 hours runtime without any gaps.
Or it is a problem related to open environment because I got only problems on tour and never on workbench. For example signals which are able to interrupt bluetooth connections.
I will go on with internal GPS test and then I do another Bluetooth GPS test with screen off.
I guess it is a stupid power management thing because screen on test did succeed with 21 hours runtime without any gaps.
Or it is a problem related to open environment because I got only problems on tour and never on workbench. For example signals which are able to interrupt bluetooth connections.
I will go on with internal GPS test and then I do another Bluetooth GPS test with screen off.
Well, I have to skip the internal GPS test because I can't even get an stable fix on the outdoor windowsill...
It is impressive to be able catch 29 satelites. But if non of them have any useable signal strengt it won't help to have such a large number...
Well, I have to skip the internal GPS test because I can't even get an stable fix on the outdoor windowsill...
It is impressive to be able catch 29 satelites. But if non of them have any useable signal strengt it won't help to have such a large number...
Good day Falco,
so to close this problem. How may I help here? Your main issue is need to record elevation values even when GPS has no signal, right? For this, I currently have no working solution, sorry. And yes, in tunnels and areas without a signal, it is a problem for Locus & generally for a track recording.
Menion
Good day Falco,
so to close this problem. How may I help here? Your main issue is need to record elevation values even when GPS has no signal, right? For this, I currently have no working solution, sorry. And yes, in tunnels and areas without a signal, it is a problem for Locus & generally for a track recording.
Menion
I still didn't find the real causer of BT connection issues. I need some weeks to narrow the failing test setups. Maybe it's related to power managenment or it's related to BT reconnection handling or some android modules do crash if they got some kind of bad BT signal.
It doesn't make it more easy to find similar problems across multible devices without knowing if all are related to the same bug or if there are more then one issue.
I guess I will create a new bug if I really can narrow it down to locus which is very unlikely to happen.
I will post some test results in the closed bug mayby I find some testsetups with stable GPS fix. Just to keep them documented.
I still didn't find the real causer of BT connection issues. I need some weeks to narrow the failing test setups. Maybe it's related to power managenment or it's related to BT reconnection handling or some android modules do crash if they got some kind of bad BT signal.
It doesn't make it more easy to find similar problems across multible devices without knowing if all are related to the same bug or if there are more then one issue.
I guess I will create a new bug if I really can narrow it down to locus which is very unlikely to happen.
I will post some test results in the closed bug mayby I find some testsetups with stable GPS fix. Just to keep them documented.
Good day Falco,
oki understand. Suggest to not to trust Locus Map app on 100% and also suggest to work with disabled optimizations as we describe here. They are able to make from using phone real hell.
Menion
Good day Falco,
oki understand. Suggest to not to trust Locus Map app on 100% and also suggest to work with disabled optimizations as we describe here. They are able to make from using phone real hell.
Menion
I guess position lost notification is a great workarround for BT connection issues because you have to deal only 0-2 times a day with it.
http://help.locusmap.eu/topic/position-lost-notification#comment-57236
Thank you for that fix, I wasn't sure if I miss the notificiation or if there was an issue. My BT failure testsetup will be a lot more easy with the next locus version.
I will focus my testing on the position lost notification, if this system will not miss any outdated GPS fixes we have a solution for all weird GPS problems at once!
Thank you for improving the notification.
By the way, Z3C battery runtime is just crazy, my first testrun did even outrun my GPS tracker batterylifetime and my second display allwaysOn BT GPS enabled testrun with USB powered GPS Tracker did run for 21 hours, that is insane!
I guess position lost notification is a great workarround for BT connection issues because you have to deal only 0-2 times a day with it.
http://help.locusmap.eu/topic/position-lost-notification#comment-57236
Thank you for that fix, I wasn't sure if I miss the notificiation or if there was an issue. My BT failure testsetup will be a lot more easy with the next locus version.
I will focus my testing on the position lost notification, if this system will not miss any outdated GPS fixes we have a solution for all weird GPS problems at once!
Thank you for improving the notification.
By the way, Z3C battery runtime is just crazy, my first testrun did even outrun my GPS tracker batterylifetime and my second display allwaysOn BT GPS enabled testrun with USB powered GPS Tracker did run for 21 hours, that is insane!
Finally I found the issue.
After 100 hours runtime I did collect enoght usecases to find similarities.
BT connection got broken if the display is off for 2,5 hours. It does not properly disconnect, it is just broken. Both of my GPS devices still tell that they are connected if android make a dirty connection break.
I could prevent this with screen turn on every 60 minutes.
I guess we have not enoght or the wrong wake locks to support android 6 or android 7 BT connections. I didn't find a third party GPS mock app with working keep alive for android 6, but did only test app "Bluetooth GPS"
Currently I try different kinds of wake device methods with tasker and secure settings to tell you how much is acutally needed to keep android 6+ from dropping BT connection.
Finally I found the issue.
After 100 hours runtime I did collect enoght usecases to find similarities.
BT connection got broken if the display is off for 2,5 hours. It does not properly disconnect, it is just broken. Both of my GPS devices still tell that they are connected if android make a dirty connection break.
I could prevent this with screen turn on every 60 minutes.
I guess we have not enoght or the wrong wake locks to support android 6 or android 7 BT connections. I didn't find a third party GPS mock app with working keep alive for android 6, but did only test app "Bluetooth GPS"
Currently I try different kinds of wake device methods with tasker and secure settings to tell you how much is acutally needed to keep android 6+ from dropping BT connection.
We are may not able to fix the dropping connection because CPU awake isn't enoght. My last try with messing with BT connection is currently running and if it does fail too, the only solution is activating screen every hour which would be the dirtiest workarround ever.
We are may not able to fix the dropping connection because CPU awake isn't enoght. My last try with messing with BT connection is currently running and if it does fail too, the only solution is activating screen every hour which would be the dirtiest workarround ever.
And here we are.
The solution for this problem: http://help.locusmap.eu/topic/create-faq-entry-for-solving-bt-sleep-issues
And here we are.
The solution for this problem: http://help.locusmap.eu/topic/create-faq-entry-for-solving-bt-sleep-issues
Good day Falco,
appreciate your interest in this problem and sharing of knowledge you've learned. I've set my colleague Michal who wrote all our manual stuff as a responsible for your new "idea" and he will take care of it. Thanks!
Jiří M. aka Menion
Good day Falco,
appreciate your interest in this problem and sharing of knowledge you've learned. I've set my colleague Michal who wrote all our manual stuff as a responsible for your new "idea" and he will take care of it. Thanks!
Jiří M. aka Menion
I did even understand one reason for "BT GPS reconnection time take some minutes"
There is an unresolveable usecase:
Result is: open and active connection (BT Transmitter is happy and tell that there is an open connection) but android is unable to send any data over api. I guess this is a bug in Android 5+ because this does happen across multible phones of different vendors. And the BT Transmitter connection indicator isn't a false positive, if you disable BT in android indicator will go off.
You can't even fix this state, you have to turn BT off and turn BT on again. Sometimes you need to reboot android because android BT manager don't find this device anymore even if you delete it.
I did even understand one reason for "BT GPS reconnection time take some minutes"
There is an unresolveable usecase:
Result is: open and active connection (BT Transmitter is happy and tell that there is an open connection) but android is unable to send any data over api. I guess this is a bug in Android 5+ because this does happen across multible phones of different vendors. And the BT Transmitter connection indicator isn't a false positive, if you disable BT in android indicator will go off.
You can't even fix this state, you have to turn BT off and turn BT on again. Sometimes you need to reboot android because android BT manager don't find this device anymore even if you delete it.
Replies have been locked on this page!