I have implemented a receiver within my app that continually searches using Bluetooth and updates the server every 10 seconds with the available devices. One piece of information it returns is the RSSI value of the device. The code I use to get this value is:
node.Rssi = intent.getShortExtra(BluetoothDevice.EXTRA_RSSI, Short.MIN_VALUE);
So this seemed to work fine at first, using my test phone (Galaxy S4) I got expected values such as -75 or -88. However I have now tried a different phone shown in the link below:
http://www.amazon.co.uk/Waterproof-smartphone-Dustproof-Shockproof-Capacitive/dp/B00EZNSUPU/ref=pd_sim_sbs_ce_3?ie=UTF8&refRID=0YYHYTW6J2AVZK7DJJDJ
(Sorry if I'm not allowed to post this here, I'm not 100% on the rules, if there's a problem I'll happily remove it)
When using this phone with the same build of my app, the values for the RSSI range from 150-200.
Does anyone have any idea why this might be happening? Another problem I'm having with the phone is that when Bluetooth is on my Wi-Fi connection will eventually disappear, again this doesn't happen with my Galaxy S4. Is this test phone really that bad? Or am I missing something..
Related
I have an Asus P00A tablet (Android 7.0, API24) on which the BLE stops after some hours. (This affects any BLE app, not just my app using Android Beacon Library). Apps start working again if I manually switch off BLE then switch it back on.
The BluetoothMedic auto-fix system did not work for my tablet. It runs every 15 minutes but does not find a fault and so does not "power cycle" the Bluetooth. However, I hacked the BluetoothMedic class, adding this:
public void cycleBluetooth(Context context) {...}
and attached this to a button. I find this will restore BLE functionality. So I wondered what would happen if I unconditionally reset the BLE every 15 minutes. I added:
public static final int ALWAYS_RESET = 4;
and then call medic.enablePeriodicTests(context, BluetoothMedic.ALWAYS_RESET);
and add code inside BluetoothTestJob.onStartJob() which then calls BluetoothMedic.cycleBluetooth(). This behaves as expected and so far my app has run perfectly for 18 hours.
I am interested in any advice, such as:
1 Are there any tests other than the two in BluetoothMedic that I can run to detect that my tablet's Bluetooth has stopped? (I am happy to experiment).
2 Any comments on the hack I describe above? Should it be OK to unconditionally reset the Bluetooth every 15 minutes?
3 If the Bluetooth is reset ("power cycled") then is the rest of the Android Bluetooth Library OK with this? That is, will it carry on with monitoring and ranging that has been previously set up, or does the application code need to set take any action to get things going again? Note that this would apply to resets by the existing enablePowerCycleOnFailures() code as well as my ALWAYS_RESET hack above. (Maybe there are some crashes that could happen if the power cycling came at the wrong time?).
4 Could I suggest adding a callback so the application can learn if the Bluetooth has been cycled? Perhaps as a parameter to enablePowerCycleOnFailures()
5 I understand that background activities can be stopped by the OS, especially with Android 8. Would this also affect the regular 15 minute tests set up by enablePeriodicTests()?
The Android Beacon LIbrary's BluetoothMedic, as currently built, relies on the operating system's error code returned by a scan failure (or an advertising failure) to decide if the bluetooth stack is in a bad state warranting a power cycle.
For scans, if the onScanFailed callback is called with an error code of SCAN_FAILED_APPLICATION_REGISTRATION_FAILED which has the value of 2, the module considers it worthy of a power cycle..
For advertisements, if the onStartFailed callback is called with an error code of ADVERTISE_FAILED_INTERNAL_ERROR which has a value of 4, the module considers it worth of a power cycle..
These values were determined via experimentation, witnessing that on some devices, once an error callback is called with these values, bluetooth on the device would not work again without turning it off and back on. You can see the discussion of this in this thread.
You may want to see if there are other error codes on the Asus P00A that indicate a problem worthy of cycling bluetooth. To do this, wait for a failure, and see if attempts to start scanning call the onScanFailed callback with a distinct error code. If such error codes exist, this would be a better solution than cycling power to bluetooth regularly, as cycling power to bluetooth does break BLE GATT connections and the operation of bluetooth classic functions like speakers. The Android Beacon Library itself recovers from these power cycles just fine, although it will obviously not detect beacons until bluetooth is back on.
Because the BluetoothMedic uses the Android Job Scheduler for periodic tests, it is not affected by background limitations on Android 8+.
If you are interested in augmenting these functions in the library, please feel free to open an issue in the Github repo, and issue a Pull Request if you have code to share.
People! I thought to include it in original question but didn't.
WHILE VOTING, YOU ARE ALLOWED TO COMMENT WHY DID YOU VOTE?
Please use it to enable learners get theirs things done and convey their thoughts/issues to others better way. Not everyone knows what you think. Thanks
In Short:
I need to synchronize clocks of two Android Phones (placed close to each other OR not; both cases) with each other AND with up to an accuracy of a few milliseconds (10, 20 ms max).
Either sync the clocks
Or get an offset of one from the other
What I am Doing:
I have a developed app that I am using to measure different GSM network statistics. I am using telephony manager to get three states (OFF-HOOK, IDLE, RINGING). Phone A calls phone B. Both phones are running an app that is saving the time-stamps with regards to the states mentioned above. After making many calls I export the time-stamps in a data file and analyze them to get different network stats.
What is my Issue:
I have to cross-match the time-stamps to get stats. Now the problem is that if the phones' clocks are not synced then I will not be able to get exact stats (e.g. how much time it takes to get phone B in ringing state after phone A initiates a call?).
What I have Tried: So far I have tried to sync clocks with NTP, GPS or atomic clock. I have used ClockSync (Android app) to get offset of both phone clocks from atomic clock. The issue is that this offset depends on RTT of network packets from my phone to server. I gives my difference of up to 100 ms when I check offset two times (tap refresh two times consecutively). The offsets at both phones can lead to error of up to 200 ms which is unacceptable for me.
All other syncing apps/methods have same issue.
Possible way forward: (What I think). I may develop an app that
takes the time-stamp at phone A
transfers that to phone B via Bluetooth or WiFi (connected to same router),
B then compares that time-stamp with its own clock, calculates offset,
And I run my original app, run experiments and,
Use the offset to correct time-stamps before processing data
Your Comments/Suggestions: How to do it? And comments on the method described in last part..
I am facing quite a peculiar problem.
I am programming on Android to get a reading from a BLE Blood pressure monitor(A&D UA 651). I am able to get the reading from the device on certain devices(galaxy S6, Note 2, Droid Turbo), but on other devices(like the Oneplus One, HTC Desire 810) etc, I am able to connect to the BP monitor, but cannot get a reading from it.
I followed the tutorial posted by Android here.
Write now, I am using setCharacteristicNotification() to alert me of any changes in characteristics. I am also writing the correct descriptor using:
descriptor.setValue(BluetoothGattDescriptor.ENABLE_INDICATION_VALUE);
mBluetoothGatt.writeDescriptor(descriptor);`
Here's the kicker. I've noticed that on the devices where I am not alerted of a change in the characteristic value, if I put a breakpoint inside the callback
onDescriptorWrite(), I am able to get the reading.
The status value in the callback is always 0 (irrespective of whether I can read the value on the characteristic or not.)
This lead me to thinking that I should induce a delay in this callback, but this seldom works.
If anyone has faced this issue before, please let me know. I've been stuck on this issue for quite some time now.
Thanks!
I have connected my android application with bluetooth OBD device. Now, on running commands like vehicle speed,rpm,ambient air temperature,I m getting the desired and right response but when I hit the distance command(0131\r) ,I am again getting the response NO DATA.
Please help me in solving this.
Unfortunately according to the SAE J1979 spec, vendor support for pretty much every single PID is optional. Commands, such as 0100\r\n give you an indication of which PIDs are theoretically supported by your vehicle, but whether an ECU will respond or not is completely vendor and vehicle dependent (and sometimes also depending on temporary/environmental conditions).
Alright here's the deal. I got two Galaxy Nexus phones both with bluetooth enabled.
I've written a bluetooth connection management app that I use for device discovery and connectivity. It also outputs all the available UUIDs the devices can support.
Looking from http://www.bluetooth.org/Technical/AssignedNumbers/service_discovery.htm the following standard UUIDs are exposed from Galaxy Nexus devices.
0x1116 - NAP
0x112f - PBAP (Phonebook Access Profile)
0x111f - HFP (Hands free)
0x1105 - OPP (Object Push Profile)
0x1112 - HSP (Headset Profile)
0x110c - AVRCP
0x110a - A2DP
I am trying to connect via the OPP profile (UUID 00001105-0000-1000-8000-00805F9B34FB) and push objects (files) between the devices. I've gone though the entire Android API documentation on how to discover, pair/bond (threading etc.) and manage all bluetooth connections. I've managed to successfully connect and talk to a legacy board device via the SPP (0x1101) profile.
However, when I try to use socket.connect() between the two galaxy nexus phones, the pairing dialog shows up and I click Pair button on both devices. After that, I immediately get a Connection Refused IOException. Note that after pairing has occurred once I never get asked again which makes sense since the secure link is cached.
If I can't connect to these standard profiles using these standard UUIDs why are they exposed? How can I connect from my app to any of these profiles and interact with them? Is it because my app is not somehow trusted? What's weird is that even the Share functionality on Android does not work at all either. Is this something completely broken on Android?
Please avoid giving me hints to use the "well known UUID SPP one 0x1101" like the docs say. This is not what I want. I have a fairly good understanding of how this stuff works and I am looking for a real solution or explanation of the problem.
I've seen the typical "reflection" solution but I do not understand why is this still a problem on Android? Why do people use reflection to make this work? Can we file a bug on Android to fix this?
If those UUIDs are standard any app should be able to connect and interact with them. Why is this an issue and why do I get this exception?
Thanks in advance.
UPDATE
So for some reason the object push in the Android system started working. I actually attempted to connect via my app and it was not working. Then, I went to the Contacts app and tried to share a contact which magically worked. Then, I went back to my app and it now it works...wow. That is very weird and there must be an explanation to this.
I ran into this same issue and managed to find a solution that worked for me.
In my case I using three different test devices (Nexus 5, Galaxy S4, Note 2) and for some reason, the Note 2 wouldn't connect to my Bluetooth module yet the other two would.
The reasoning I've found is that Bluetooth drivers vary, and slightly different connection methods are needed to create a connection between different devices.
The three methods I use are called 'Secure', 'Insecure' and 'Reflection method'/'hax'.
switch(connType)
{
case Secure:
tmpSocket = device.createRfcommSocketToServiceRecord(_uuid);
break;
case Insecure:
tmpSocket = device.createInsecureRfcommSocketToServiceRecord(_uuid);
break;
case Hax:
Method createSocket = device.getClass().getMethod("createRfcommSocket", new Class[] {int.class});
tmpSocket = (BluetoothSocket)createSocket.invoke(device, Integer.valueOf(1));
break;
}
In my case, the Secure mode worked for both the Nexus 5 and Galaxy S4 however it didn't work for the Note 2.
After some testing I discovered the Note 2 only works using 'Insecure' mode, so to cater to this, I basically attempt a connection and cycle through the different modes if necessary. When attempting a different connection mode I simply prompt 'retrying connection'. So, if the connection fails using secure, then I will attempt using Insecure and then using the reflection method.
I haven't run into the case where one of these three methods haven't worked.
Have you tried using a nonstandard profile? i.e. a custom UUID just for your app. This will also help you know your are (most likely) only connecting to your own app rather than some other app that is registered with the same profile.
From my experience, Bluetooth pairing is very buggy for the first pair attempt. However, using a custom UUID helps this somewhat.
The reflection method (I think) was originally an attempt to fix a bug with a specific device, however I think some people found success in using it elsewhere as well. The device was called the Spica or something similar.
As one of the comments also posted, I would also try connecting again after failing.
Basically write code that plans to fail the first attempt, but then the code tries to connect again in 5 seconds if there was a failure.
These are imperfect solutions but Bluetooth implementation on Android is also imperfect (IMHO). Hope that helps
EDIT
Based on the question update and comments:
I agree something is definitely buggy. Part of the problem I think is the BT drivers vary and each has a different BT stack with different quirks. I also found a question that makes use of both the reflection method AND custom UUID, AND other standard methods. This seems extreme to me but it does cover the most ground. Unfortunately as app developers we have no control over the low level stack/code/drivers.
I have found with my two Bluetooth sharing apps that the first pairing is always tricky.
I'm glad to know it's not just me.