I'm running some code on the nexus one - and I am having a very strange issue. The "server" sends UDP packets out on the multicast socket that the phone is joined to. The phone receives and sends stuff to the multicast group fine, but it appears that the phone chokes when it receives a large number of packets at one time.
For example, the server will occasionally send out 80 or so 512 byte packets in one go around. The phone starts receiving the packets, but then at the 31st packet (~16KB of data) the receive hangs (indicating that there is nothing on the socket anymore.) I've done wireshark testing and stuff so I know for sure that the packets are not being lost. Even if some are being lost, it is very strange that EVERY test produces the same result --- a large amount of data gets jammed onto the socket at one time, but the socket only allows me to socket.receive() for 16KB worth of data.
I have tried socket.setReceiveBufferSize() with a variety of values (up to 1MB) -- but that doesn't seem to work. Interestingly, a call to getReceiveBufferSize() tells me that the socket should hold roughly 100KB worth of data.
If I tell the server to slow down its send method (which I cannot deploy, I can only do that for testing purposes) - everything works fine, presumably because the packets aren't jammed onto the phone's socket all at one time (ie. I tell the server to wait 1/2 a second between packets.)
Has anyone else experienced this - if so - how did you get around it? I cannot switch the application to TCP.
Thanks!
Dan
PS. The Java code works fine if I run it on a regular machine...
Nevermind - I fixed it by moving onto a closed network where there is 0 possibility for loss and weird things -- not sure what was up with the network I was on (which was supposed to be goo) - but at least it works!
Dan
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.
I'm having trouble maintaining a Bluetooth connection (from Android to a device I'm developing) for longer than a few minutes.
The scenario is:
Device is paired successfully.
Device transmits to Android for somewhere between 1-7 minutes (varies by device or possibly Android version).
Android stops receiving bytes although device is still transmitting.
So: why does Android BT stop receiving?
This is very similar to the issue/observation described in bboydflo's answer to this question:
Application using bluetooth SPP profile not working after update from Android 4.2 to Android 4.3
Some more background:
The BT device I'm working with continually emits measurement packets containing ~200 characters, once per second. I am certain that the device-side is still transmitting when the issue occurs.
This sympom happens in my app on two Android devices: an Android 5.0.1 Acer tablet, and an Android 7.1.1 Moto Play X
I've tested with an app called Serial Bluetooth Terminal. This app does not experience the same issue; the connection is stable for as long as I've tested. Therefore, this issue is probably caused by something in my application code.
I've seen various responses to Android BT questions directing the user to use asynchronous streams rather than polling for received bytes. This seems to be a red herring; if you feel that the threading model is causing a probelm in this case, please clearly describe why switching to async would resolve this issue.
I would like to pre-emptively address reasons that this question may be closed:
This is not a duplicate. There are other questions on SO about BT connections dropping (i.e. Real-time Bluetooth SPP data streaming on Android only works for 5 seconds) but this is not the same issue. I have already added a keep-alive outgoing char transmitted every 1s, and my issue remains.
I'm not asking about an issue specific to my application; at least one other user on SO has encountered this problem.
I've reviewed the Android Bluetooth documentation in detail, and I can't see any obvious reason for this to happen.
I'm not asking for an opinion; I'm asking for an objective answer as to why the bytes stop being received.
Ok, I have a partial answer for this one. First, a bit more background:
I was running the BT stream polling on a thread which executed a runnable every 2s
The buffer being used to read the stream was 1024 elements long
I had a suspicious that this might be some background buffer running out of space. So, I changed the 2s to 500ms and the 1024-length to 10024. Now, I've had about 20 minutes of connectivity without any trouble (and still going).
It would be nice to find the smoking gun for this. I initially thought that stream.Available() would be sufficient to tell if a buffer was getting filled up, but in this scenario, stream.Available() is actually returning 0 when the Android device stops receiving. So I'm not really sure which queue to check to prove that this issue is related to a buffer becoming filled.
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?
Ok, so here's my problem. I have an android app transmitting UDP packets to a PC (a java program which listens for the packets), based on user interactions with the android device. To keep things simple, let's say this is happening - the user taps the screen of the phone, and it sends a UDP packet with the coordinates of the point where the user tapped. The listener program receives and reads this packet, and outputs the string received, using System.out.println().
Now, what's happening is that the program works perfectly for the first few packets. Then it stops working, as in, the listener program on the desktop does not display any output. Now, the issue is probably with the transmission, as I have a text label on the app (for testing purpose) that displays what is being transmitted, so the transmission packet is definitely being built properly. But I have no idea on how to understand if this is a problem with sending the data (on the android device side), or receiving (on the desktop side). How can I find out what's wrong and solve this issue?
I have mostly worked with TCP transmission and all the UDP i have done are mostly Copy-Paste [:-)] or with APIs
For TCP, after transmission, I throw a debug message, which helps me to know that the transmission occurred properly. But in this case, your write will have to be blocking.
Also, you could use a Packet Tracer on your listener terminal to determine whether it is receiving the packets properly. The one I love is WireShark (I think its a fork of Ethereal). Its really easy to use. You tell it which interface to listen on and give a filter and it will list out the packets as and when they come.
However, if you are using Windows 7, you will need admin privileges.
Are you using native code or Java classes? I have tried both, and with the NDK (i.e. sockets written as C functions being called from Java) I have seen erratic behavior on the server side, mostly due to threading issues. Using the Java Socket class I have not had issues however. Moreover, if your Android app is the client, that should not be the problem. I would also use Wireshark to check whether the packets are reaching the PC.