We're working on an app that streams a large amount of data out via UDP for GSM-based phones. The idea is to use it while in conjunction with a voice call. If no voice call is present, things are good. However, if a voice call is active, it seems that most of the data we're sending out simply never makes it, even on HSPA+. If we enable Wifi, then everything is good.
I'm worried that this is a physics problem, rather than a phone one. I ruled out CPU contention by inserting a log statement after we send a chunk of data, and saw that it appeared plenty of times.
Is the 3G radio capable of sending data and voice simultaneously well? We tried a speed test during a voice call and saw a huge drop in bandwidth.
I've run into exactly this problem on AT&T's network in the US. They simply throttle the bandwidth while the call is in progress; whether you're on 3G or H. To see how much you're getting throttled try installing speedtest.net's app and running a speed test during and outside a call.
In the bay area I see data rates as low as 30kbit/s during a call on AT&T's network. On T-Mobile it's not throttled so much (same location). A partner in Israel tried the same test and saw only slight throttling during a call -- he was still seeing 500+kbit/s using the same phone that we tested on in the US. (The same phone that got several Mbit/s outside a call in the US.)
As the poster above points out, CDMA phones can't use data concurrently with a phone call at all (but you said GSM explicitly in your post anyway).
Yes, when you are in a call, there might be not internet connection at all. It depends on the type of network you are in. It would vary from GSM, CDMA, and also the connection type, ie. GPRS, EDGE, 3G or 4G. The 3G and upcoming 4G connections should be able to simultaneous give you network connectivity and voice calling.
Yes, the radio is capable of sending both voice and data simultaneously, but from what I understand its a limitation of the network that your phone uses. If you are on Verizon's 3g network than this is probably your problem. Below is an article that goes into some details about the differences between at&t and Verizon's networks: http://mashable.com/2011/01/11/cdma-umts-att-verizon-networks/
I don't know if this case apply to the operator you are using, but for the operators in my country, they limit the bandwidth used per phone, so if the user use calls and internet connection in the same time, you must subtract the bandwidth used for the phone call, which as i know 48 Kb/s for GSM networks(as maximum) and some of operators limits the call bandwidth for 24 Kb/s and and the total available bandwidth is 64 Kb, so the rest of the bandwidth is used for internet, and i don't know the bandwidth user for 3G networks.
BTW, some phones doesn't support phone calls and internet usage in the same time
all the information above belong to personal information able to be wrong
I do confirm the bandwith is reduced during phone calls unless you are using wifi.
This seems to come from the system, not from the operator. This because it is reported with any hardware / any operator / any country. I have searched for some official documentation regarding that but couldn't find any.
I don't think there is any way to work around that so far.
Related
I'm trying to setup a communication channel between two Android phones.
Unfortunately, Google decided to block developer access to Bluetooth adapter MAC address, effectively disabling the entire NFC to Bluetooth handover process (Simple Secure Pairing).
Side note: why? privacy/security gain is minimal to none, especially
if you randomize it! you could simply randomize it when an app requests the MAC and that's it!
This SSP process used to take roughly 1-3 seconds at max and generated great user experience.
Currently, I'm stuck with NearBy which generates a terrible user experience (who's gonna wait 10 seconds just for the initial connection?)
The only options we have left:
Improving NearBy API somehow (~10 seconds average to discover and connect! why Google, why?)
WiFi hotspot - setting an agreed-upon ID as the name, discovering and connecting (~8 seconds average)
Bluetooth - requires a popup to be approved each time, a bit faster but results in bad UX.
Internet - just use the Internet and fall back to local wireless methods (when 4G internet connects much faster than local wireless Android NearBy, you know Google has definitely failed with the implementation).
Is there some secret sauce I can pour onto NearBy to improve it, to be, at least as fast as Apple AirDrop (~4 seconds average)?
Do I have any other options I'm missing?
Thanks!
The definition of absurdity:
Two phones that are 1 meter away from each other with several direct wireless options (Bluetooth/BLE/WiFi) take an average of 10 full seconds just to connect (before data is sent).
Two phones that are 20km away from each other, communicating over cellular data (3G/4G/5G) fully connect after an average of 1.7 seconds! Even after traveling through GSM BTS, proxies, cache, firewalls, BGP routing and other filters.
Google has to do something to fix that (after they disabled the only method to make this faster, using BT SSP, handing over NFC to BT - as they disabled BT MAC address exposure).
My solution right now is to use Internet by default while simultaneously trying to connect via NearBy, as I need a fallback ready to work for some of my clients that don't have a good cellular signal.
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've read this tutorial about data transfer in a battery efficient way.
All the lessons are based on one, simple concept: polling the server is Android is battery inefficient. For this reason, Google Cloud Messaging is introduced in order to send messages from the server to the device only when needed.
There is only one problem: I'm trying to implement a "mobile cloud", so a cloud composed by mobile devices, where each device can join/leave the network with high frequency. So I need some mechanism to detect when a device is not reachable anymore. Until now, in all the works that I've seen on the topic, the only solution was to periodically ping the main server to say "Hey, I'm still alive!" from the mobile device. Obviously this solution is battery killing, but until now I've not seen/found any better solution.
Do you know any battery efficient solution for this problem?
There's no reason why pinging the server periodically (heartbeat) is necessarily wasteful of the battery/inefficient. That depends upon how frequently you need to ping, and whether your ping needs to initiate its own transmission vs piggy backing on some other transmission.
Let me explain. Battery inefficiency depends upon whether or not you are increasing the frequency or duration of the transceiver being in an active state. If the transceiver is continually active anyway, such as it is continuously exchanging data or audio, then a heartbeat adds no additional burden. If it is not active, then there will be additional energy usage but that depends upon the frequency of your heartbeat compared to how long a ping will cause the transceiver to be powered. Even then, it's probably irrelevant to your application as I suspect "cloud" means the devices are active and connected.
Let's assume that your heartbeat is such that it will increase the duration of your transceiver being active. There are still techniques you can use to decrease this impact, such as caching your beat and sending it only when it can piggy back on another transmission. Of course, such solutions depend upon whether your heartbeat is implemented in an application, OS or kernel.
I suggest you do actual tests to see if there is truly an impact on your devices.
PS I'm not saying the tutorial is wrong. It isn't. But it is addressing a broader and more general problem then what you have.
This is sort of an odd question, but I know it is possible.
I am trying to broadcast packets over a specific frequency and I want a phone running an application to pick up on these packets. The phone will not need a connection to any network to do this, but simply have it's wifi turned on. The broadcasting device does not need to get any information back from the phone and delivery of every packet to the phone does not need to be guaranteed, much like UDP.
Where do I start? Is this possible for phones without rooting them. Is there some kind of FCC regulation against doing this (over the standard wifi spectrum).
I know this is possible because it's exactly how routers tell a phone they are available to connect. Thanks in advance for any input.
I'm not familiar with iOS development although similar techniques may exist.
Without root
But requires coarse- and/or fine-grained location permission on Android
You can use WifiManager.getScanResults() to scan for wireless router broadcasts.
The network "name" (SSID) and router MAC address (BSSID) are included in the results. You could broadcast these packets and encode data into these fields.
That said, I hope your messages are short as you'll be getting 38 bytes per packet (32 SSID bytes + 6 MAC address bytes).
Yes, some MAC addresses are special or invalid, but if you're just broadcasting and not actually using them, they can still transmit the data.
With root
Depending on the wireless chipset and driver support, you may be able to put the device into "monitor mode" which gives you access to the raw packet data.
The main drawback is that there is no official support for it.
You might find some hacky ways to do this from a Google search but I wasn't able to find any universal solution that works on all (or even most) devices.
I'm currently working on an android project and I am trying to find the best way to go about setting up communication between two android phones.
One android phone will be docked on a mobile platform e.g. an R/C car. I want this phone to receive simple control signals ("forward", "backward", "left", "right", "gotoCoordinate") sent from another android phone. I also want the docked phone to be able to return status signals.
Preferably I want the communication to happen via GPRS. I'm aware of the difficulties concerning P2P-communications and I'm currently looking into "Android Cloud To Device Messaging." (http://code.google.com/android/c2dm/index.html)
I'd like to hear about your experience with Android C2DM (glad to hear about delay from transmit to receive) and your thoughts on utilizing it in my project. I'd appreciate other suggestions on how to go about this. I'm expecting to have to deal with relatively high latency using this method, but of course preferably lowest possible.
C2DM makes no guarantee about the "delivery or order" of the messages, and it is limited in the number of messages you can send (a high limit, but still a limit). It's not really for low-latency stuff like controlling an RC car. It's better for non-realtime events.
http://code.google.com/android/c2dm/
For lower latency stuff using GPRS you can setup a third party server on your own and have both phones communicate through it. I've done that for several Android apps using straight up TCP sockets and it works reasonably well (and it would be even faster/better if you went UDP). Using GPRS may still have too much latency, depending on your needs, but it's a tradeoff (it's very convenient, almost always there, other methods are not).
The ideal way to do this would be to combine whatever is available and fallback gracefully, and test the latency once connected to make sure the network is up to par, or bail out. For example, use the local WiFi network if it's available. That is to say, have both devices "register" with a third party server as they startup, then if they're both on the same WiFi just have them communicate directly (run a server on or both, and clients on one or both, get information about discovery and such from the registration). If they are not on WiFi then fall back to GPRS, but realize there will be more latency, of course. Finally, once any method has been established send some test messages to check latency.
I know this isn't really an "answer," it's more of a stream of consciousness about this, but it wouldn't fit in a comment, and I thought it might help ;).
(Full disclosure: I've worked on Android apps that connect multiple mobile devices and multiple TVs, some over GPRS, some Wifi, some directly. I work for a company (MOVL) that makes a platform for stuff like that, it's more focused on mobile-TV-mobile, but it supports mobile-mobile also. In all it's not too hard to do yourself with regular networking, the tricky part is getting the latency down and picking the correct method for each device.)