I'm developing an offline photo transfer app using Nearby Connections 2.0. Advertising, discovery, sending byte payloads, Google sample apps(RockPaperScissors and WalkieTalkie) all work fine but I have 2 issues.
First and most importantly, after successful connection initation between devices, I send a byte payload to give 'take picture' command from advertiser device, the discoverer receives the payload and takes a photo, then sends that photo to the advertiser as a file payload. The problem occurs here, as the devices often disconnect when the discoverer sends the file payload, before even the advertiser's onPayloadReceived method is called. I tried reducing the size of the photos, to as low as 30kB's, that rarely solves the problem. When I switch devices, making the old advertiser the new discoverer and the old discoverer the new advertiser, the problem doesn't occur often, even without reducing the size of the payload (payloads around 30kb almost never give me this issue with devices being switched). The only log I get from Nearby is this:
.
First line is logged when the connection initiates, second line is logged when the devices disconnect.
Secondly, the discovery and connection initation sometimes take up to minutes, but rarely exceed 30 seconds.When they do, I get this error on log:
Both devices run on Android 6.0.1, and are on the same network. I use star strategy. The problematic device is Lenovo P1A41, other device is Lg X-screen(K500).
Could you try and run our sample apps on these devices to see whether they work as expected? We regularly transfer 10s of MB of data on Nearby Connections, so I'd like to rule out any hardware issues on the phones you're using.
BTW, which phones are you using (and which one of these is the more problematic of the 2)?
P.S. Being on the same network isn't need in Nearby Connections -- we're completely offline and P2P.
Related
My app is sending some data via bluetooth socket using Serial Port Profile, and the other device is Microchip's BM78 module.
Everything is working fine except one very particular case when testing with Huawei NEM-L21 phone. The data delivered correctly right after connection is made, or if data frames are sent frequently. But if there's a pause of 5-10 seconds between transfers, then the next transfer will get the beginning of the data blob altered. The first two blocks of approximately 650 bytes each is swapped, like if it was buffered before sending, and the second buffer gets transferred before the first one. The rest of the blob is ok.
I have no explanation for that. I've excluded BM78 issues, it's working totally ok with windows (virtual com port for bluetooth), and with a bunch of other android devices. It's only this particular phone that shows this issue.
So, is that just a bug in the phone's firmware, or there's something about bluetooth that's missed my attention? Like maybe power management options I can tweak in the phone? Anything related to Bluetooth in general?
I am evaluating Google Nearby connections2.0 more specifically evaluating the synergy effect of it. For this I am evaluating it against Wifi, Bluetooth and BLE in totally offline scenario, without any router.
Scenario
One device is advertising, all others (8 devices in total) are discovering. On successful connection, I am sending simple Files of 20B, 200B and 33KB sizes for 30 secs straight to each connected device.
I am using android Samsung S6 SM-G920F devices with android version: 6.0.1 and playservices version 12.8.74
I have following issues/questions
Q1: First of all at max 3 to 4 devices could be connected simulatenously more than this results into disconnect event of other devices. Even if only 3 devices are connected, and I am continuously sending message for 30seconds, one of them disconnected ? In simpler words, cannot sustain connectivity with any device for more than 45 secs. usually disconnection occur between 25 - 45 secs
Q2: I cannot send message/file continuously for 30 seconds like we can do with the Wifi like this
While(30sec){
bluetoothSocket.outputStream.write(bytes)
}
Because if I try to do this then I got the exception of too much work.I have to wait for the the callback in onTransferPayLoadUpdate()
Q3: If I try to send the file of 1MB or more to other peers, peer received the file successfully in onPayloadReceived callback but server/sender receive the successful status after too much delay. In my case it's between 1 mins to 5 mins after client callback. And I cannot send new file until I got the success callback on server. If I try to send it before getting the callback, nothing happens. Literally nothing. So In essence I can only send file of 1MB once then I have to resent both the devices to send another file.
This should be broken up into 3 separate questions. It helps future developers search easier. So if you get the time to do that, let me know and I'll split up my answer as well. But anyway, let's get into it!
A1: Nearby Connections has 3 separate strategies. The more limited the strategy, the more types of mediums we can use. So with that in mind, and with no router involved, P2P_CLUSTER will only use Bluetooth. It's the most general strategy, so it has the fewest mediums available.
All Android devices use mobile Bluetooth chips, which are unfortunately weak (but small and power sensitive), and that causes them to have a theoretical 7 device limit but a practical 3~4 device limit. To make things worst, that limit is eaten up by smart watches and paired headphones as well. That's why you're running into problems.
P2P_STAR and P2P_POINT_TO_POINT are both much more limited, because you can't connect in any direction. You need to choose who the host is beforehand and have everyone scan for and connect to that host. But you get the added benefit of WiFi hotspots, which have higher bandwidth and a larger number of simultaneous devices supported. I've seen 7 devices happily connected to a Lollipop device.
If you want to go beyond that, into the 10s and 100s, and a router isn't available, you'll have to build a mesh network. I can link you to examples of how to do that if you're interested. We don't offer support for that within Connections, but others have built meshes on top of us so we can point you in the right direction.
A2: Can you include a stack trace of the error you're seeing? Payload.Type.STREAM was built for continuously sending data. The other payload types should also work too, baring some rare but potential issues like BYTE payloads filling up the phones RAM.
A3: Both devices need to wait for onPayloadTransferUpdate(SUCCESS). onPayloadReceived is only a header, and means that there's an incoming file or stream but that the data hasn't been received yet. For byte payloads, we actually send the full byte payload inside the header so that's the only time data is immediately available.
Our app is used to download large amounts of data from Bluetooth Low Energy device via characteristic change notifications.
During the download process on at least one android device we are getting such errors on logcat (it gets repeated many times during the download):
E/bt_btif: bta_gattc_process_indicate, ignore HID ind/notificiation
What does the error mean and how can I fix it?
I'm using the USB host abilities of Android to communicate with my hardware. My communication is done through a CP210X usb to serial chip, and I'm using the driver provided here. My device is a Motorola Xoom running Android 4.0.3.
Everything for the most part works fine. I'm able to send any amount of arbitrary data and the device on the other side of the CP210X chip gets it just fine. We use a request/response protocol, and rarely send any more than about 200 bytes in a second. The other (device) side is able to send me data, and everything works until the amount of data it sends me is longer than 20 bytes. If it sends me 20 or fewer bytes, I receive it normally. However, as soon as the amount of data that it sends me is 21 bytes or greater, the packet never gets to me. UsbDeviceConnection's bulkTransfer never reports anything different happening, as it's return value is always -1 on timeouts anyways. My bulkTransfer timeout is 100ms, which should be plenty of time to transfer such a small amount of data.
In an effort to see if it was an issue with my CP210X chip, I swapped it with an FTDI serial to usb, and experienced the same issues. That really makes me worry that the issue I'm facing might be in the usb drivers on my device. However, I also noticed the behavior when trying it out on a Samsung Galaxy S3, so that's got me very confused.
Is there anything I'm missing or doing wrong?
I am writing an Android app (ICS 4.0.3) to discover devices and list their UUIDs.
The app does a bluetooth device discovery and when it finds a device it saves it. Once the device discovery is complete it goes back through all the devices it saved and does a fetchUUidsWithSdp() and then in a broadcast receiver prints out the UUIDs it finds.
When the app is run I get each two sets of responses each one set contains all the UUIDs on all the devices it discovered.
Is this the way it is supposed to work?
I see in the documentation that:
If there is an error in getting the SDP records or if the process takes a long time, ACTION_UUID intent is sent with the UUIDs that is currently present in the cache.
Both sets of responses come pretty quickly but I guess the first could be from cache and the second from the remote device.
The code can be found at http://digitalhacksblog.blogspot.com/2012/05/android-example-bluetooth-discover-and.html.