For a research project, I must work on the design of 3G/WiMAX Access Point (AP) protocols. I have access to 2 Android smartphones.
Android devices can become WiFi hotspots for other devices, allowing WiFi tethering.
In this scheme, does the Android devices behave like a regular WiFi AP (like the one present in your home WLAN) or does it just forward the connection from the AP it is connected to ?
Similarily, is there a way of turning one of my smartphone into a 3G/WiMAX AP, so that the other can connect to it as if it was a 3G/WiMAX tower ? If so, can you provide some references and resources that would allow to do that ?
EDIT:
Ok so the keyword is "AP mode", it is a mode available in some Wireless Network Drivers like ath9k, bcm but is absent from most others. It is used to turn the device into an AP (or more accurately a simulated one).
The answer of the first question "Does it behave like an AP?" is Yes: the Android device can behave exactly like an AP (management frames, ack, etc.) AND internaly it forwards the connection from the real AP.
The answer to the second question "Can we turn it on ?" is "It depends on your wireless driver, and thus on your wireless card". Some drivers (ath9k, bcmon) have the options, some others don't. You will have to search for your network card name and check it out.
In my case, I wanted to change the behaviour of on AP (by modifying the driver / kernel), but found out that my driver is a firmware (and proprietary). I ended up adding an USB Wifi adapter that is supported by the driver ath9k (open-source driver for Atheros chipsets).
It behaves like a 'regular' AP, taking into account that both Android and WiFi are constantly evolving and hence the definition of regular may be a moving target.
You can test the behaviour by finding a location with no 2G/3G/4G etc coverage and run a local network with your phone as the AP for multiple devices. An long distance flight for example (where devices on flight laws allow...).
For testing I am not aware of any free or open source 3G network elements yet, but there are some 2G open source projects it might be worth you looking at:
http://openbsc.osmocom.org/trac/
http://openbts.org
The former has definitely mentioned plans for an open RNC (3G access point) but it is not clear what stage these are at.
Turning a smartphone into a 3G access point (RNC) is definitely not going to be just a matter of developing an app. Given the hardware is probably all there, I am sure it is technically possible if you are prepared to write a lot of low level software, but I think you would probably find it much easier to look at the approaches the above project have taken and see what their plans are for 3G.
Related
I have a photo-taking Android app (written in React Native, but I can add native modules if need be) that pairs with a gallery-type app on the user's computer (written in Electron with React). The number of photos can be large (we've had upwards of a thousand photos at a time), and they need to be transferred, uncompressed and uncropped, to the computer app. I need a reliable way to do this without routing the data through the Internet first.
Things I've tried
Node USB: Looks like a good library, but is unusable without installing a driver on the user's computer. The driver then appears to replace the default Windows USB driver, and the phone becomes inaccessible through normal means (opening a file explorer in Windows). Perhaps there's some way to switch drivers "on the fly", using the driver only while transferring photos, and then switching it back out for the system driver once we're done?
ADB: This is the original solution I tried, and it does exactly what I need it to, with two dealbreaking problems: for one, the phone needs to have Dev Mode enabled, and for two, ADB doesn't seem to recognize all devices (we've had a lot of trouble getting it to work with an LG V20, for example). The ideal answer to this question would be something like ADB without those two issues.
WiFi routing: we connect the phone to the same WiFi network as the host computer, use WebSockets to handshake IPs through the Internet, and then initiate a direct connection over the WiFi network. If I cannot find any other solutions, this will likely be the one I'll go for. The biggest problem with this option is the relatively large amount of manual setup required. Our users don't tend to be very technically savvy, and I don't know how reasonable it is to assume they will have WiFi in their home. At any rate, this cannot be the only option for transfer. Further, transferring gigabyte(s) of photos over the wireless network will cause a slowdown for everyone on the same network.
Tether routing: we tether the phone to the computer, and initiate a direct connection much in the same way as in the above step. The downsides to this method are that only phones with SIM cards can activate tethering (not all of our phones have SIM cards, as connectivity isn't their primary purpose for our needs), plus all of the other traffic on the computer will now be routed through the phone, which would be bad for customers' data caps who do have SIM cards. Additionally, there is no way to programmatically turn tethering on, there is only the ability to bring up the tethering menu; it's not too big a dealbreaker, but the other two very much are.
Bluetooth: Generally meets my requirements, but the data transfer rate is far too low, being an order of magnitude below WiFi.
WiFi Direct: I did not actually try this, because I could not find a working way to have the PC accept the WiFi Direct connection. It promises exceptional speeds, but there are no modules or libraries that I've found that would help me enable it.
SD Card: The lowest of the low tech methods, just save everything to the SD card and have the client take the card out and plug it into their computer. Would hands-down go with this, except for the need for a SD card port (guaranteed neither for the client's computer or their phone).
The obvious: manual drag and dropping required files from the phone to the PC. This is how we do things now, and it's fraught with problems. Text files have the last 15-20 characters cut off from them, for some reason, during transfer; many of the photos on the device do not initially show up due to the known issue with MTP not forcing a media rescan on the phone; and users sometimes drop files in the wrong places, leading to unnecessary support calls. This method surely needs to be replaced.
I've been searching for a solution for this problem for two months now, and it's hard to believe that nobody has had a use case for Android like this. It's been made clear that USB communication between Android and PC is non-trivial, I'm sure there are programs that do that, Windows to start off with. Yet try as I might, there are no solutions that work out of the box. Has anyone dealt with an issue like this before? What were your solutions? How would you approach this problem?
When downloading large files on Android it is recommended to use Download Manager, it supports a lot of native features like the progress bar, and notification, also the download task will be handled by OS, and more efficient.
React Native Fetch Blob library support this feature
You dont really need to route the data through the internet.
You can just exchange meta data through the internet:
Extend your desktop app with folder-import functionality (Plug your phone normally via USB, brose to the folder, import).
When you execute this process, let it notify a webservice of some sort (push notifications? Im no phone-app dev.) with which files the desktop-app has imported from which device (ids, filenames, ...) and the phone gets this meta data and can continue its process of whatever it is doing!
Obviously the best solution is a communication channel over USB. Until you figure that one out, you could implement it temporarily this way!
The Output voltage from an USB port is 5v, and it can't be changed, isn't it?!
But what is the maximum amperage that I can drain from a smartphone?
It depends on the battery, hardware or is limited by the OS?
There is difference between Android/iPhone/otherOS phones?
Can I control the output amperage with an App? And if the phone is rooted?
Important example what is the maximum amount of current that can provide Iphone 6 from USB?
The official maximum on current provided on USB 2 OTG port is 500mA and minimum is 8mA when the port is in Host mode.
Source http://www.usb.org/developers/onthego/otg1_0.pdf #2.5
The USB 2.0 specification allows the voltage output from a USB port to be anywhere between 4.40 V and 5.25 V, but it is typically 5 V.
While you could construct a USB port that has a different voltage, you should probably not do that because a normal USB device you plug into that port could malfunction or be damaged. It's unlikely that your phone provides a feature for changing the voltage of your USB port.
The USB specification allows devices to draw 100 mA from a USB port before they have reached the "configured" state (see Chapter 9 of the USB specification for more information about USB device states). Once the device is configured, it can draw more current, as long as it doesn't exceed the amount of current specified in its configuration descriptor.
If your phone does not get the device into the configured state by default, it might be possible to write an app to do it, thus allowing your device to draw more than 100 mA without violating the USB specification.
Not sure what you're trying to achieve...
An iPhone 6 can provide some (limited) power to devices plugged into its lightning port (it doesn't have a USB port).
There are cables that connect the phone to a host computer (or charger) over USB, but you're not going to get power out of the phone that way (only power into the phone).
A lightning connector uses active electronics inside the connector's cable to get the phone to assign functions to the different pins.
Moreover there's authentication involved, preventing you from making anything yourself for it without apple's involvement. You'd need to join the MFi program to get the needed documentation.
There's an NDA involved, and Apple is notorious about such things, so you're unlikely to find much reliable and/or verifiable info on the Lightning conector till you join the program.
See also here.
A list of USB standards and their voltage/current ratings is shown on wikipedia
The Nexus 5X and 6P seem to be the first phones to support power delivery via USB Type C connection: Link
However there is conflicting information on how well this is implemented.
Your goal of a 3A output current seems to be possible with USB-PD, but it would appear that no smartphones are currently supporting this.
Important example what is the maximum amount of current that can provide Iphone 6 from USB?
An iPhone with a Camera Connection Kit will limit you to 100 mA. If you connect a device that claims more than this in its descriptors, or tries to draw more than this, it will get cut off with an error:
As reported by this iPhone 6 and 6 plus may be able to supply a current of about 1 Ampere at the voltage at which they get charged. Though I can't be very sure about it unless the specification of the USB drive used are provided.
3A of currents seems to be way too much. If it would have been possible, they could have used it to charge mobile phones faster (I don't know if they do use 3A chargers or not, but this can be seen on their charger at the output tag ).
I would have not done such an experiment until and unless I was very sure about it.
Disclaimer : What ever experiment you do, you it do at your own risk. In the above answer I have just tried to explain what I would have done and have provided reason to back that.
Amperage drained from the power supply is proportional to these factors:
1- The net device's impedance(including battery and other feeder circuits).
2- Device's internal current limiter.
3- Power supply's maximum current limitation.
power supplies usually provide less amperage than it is dictated by the device. If they provide more of, their constant voltage, i.e. 5V, drops below its standard. Therefore, the limitation is posed by the supplies in the first place.
Devices, provide you with another current limiter to lower the risk of using failure of nonstandard power supplies. I'm not sure whether you can change the maximum threshold of internal current delimiter to drain more power or not, but I'm sure you can not change it in your power supply.
I'm trying to use two phones in my car as a reversing camera: one being the camera and the other being the viewer. I have the software but the problem is I can't get it to work using two phones. I can get it to work using a third phone as the hotspot gateway. The problem seems to be I can't seem to communicate with any app running on the device running the hotspot yet they all have the same ip range. One machine is running a http server accessing the camera (similar to "IP webcam" app) and one is running software accessing the web server (in this case a web browser). There is no internet component. I assume this is being blocked because of some sort of security feature. I see no technical reason why it can't work.
I have tested this using HTC one, HTC DesireHD, Samsung galaxy camera and other various friend's phones so it seems to be consistent across android. Not an odd feature of some type of phone. Android 5 has not helped either. If it is a security feature do I need to root the device running the hotspot to overcome it? Any pointers to discussions on this subject would be very helpful.
I have searched many similar threads but most are discussing tethering issues or connecting through to the internet. Not sure what keywords to use. I have also tried "Hotspot control" app which did not work although I don't think it relates to this issue.
e.g How to make two android devices to communicate through TCP This has the right title but then goes on about NAT translation which is not related. Others go on about DNS. Just a simple DHCP server (which the hotspot has) and a router?
So in essence this is simply getting a local tcp/ip network set up between two android devices so apps can talk to each other. I would have thought this was quite straight forward. Hotspot is almost there as a solution.
I had a brainwave and solved my own problem at least on my HTC one (and I think before the 5.01 upgrade which would have been kitkat).
When in "settings" select "more" under "Wirelesss Networks".
Then under "Mobile network sharing"->"Portable Wifi Hotspot" click the menu button at the top and select "Advanced".
Then click LAN Settings:
Here we select the ip address of the host (i.e this mobile) and the "Starting IP" for the DHCP server for devices connecting in. It seems to choose zero (last in group of 4 numbers used for the ip address) for the mobile running the hotpsot and and then, presumably, 10 for the starting address of connecting machines. However, it seems only addresses from starting address onwards can see each other so the simple fix is to change the ip address of the host to a number greater than 10. I chose 200 and all worked. My camera can connect to the phone and the two can talk.
However, on my Galaxy camera (model EK-GC100) running 4.1.2 (Jelly Bean) these addresses can't be configured. It also doesn't allow a hotspot to start if a sim card isn't inserted. It seems to think there is no other reason to use a hot spot other than for tethering. Just another in the list short sighted design features that cost almost nothing to implement.
Unfortunately it would have been better if the camera device is running the hotspot. Oh well not a major issue as I wouldn't use a galaxy camera for a car reversing camera.
I'm trying to make an app on an Android device that will control an application on an iPad or Android tablet. (I'm testing with an Samsung Galaxy S2 and an iPad 2).
The application is pretty simple for now. When one selects a colour on the Android mobile, that colour displays on the tablet device.
The question is, how to connect the two devices. Just now I've verified that I can pair the two devices using Bluetooth. Also, the Samsung has a "Kies" Wifi Direct feature (which I don't understand fully), that allows the iPad to connect to the Galaxy as a wifi hotspot.
The connections are there, but I don't know if either protocol can be used to actually get the apps to talk to each other to get the control I'm looking for.
Should I be using Bluetooth, Wifi, or something else?
And in whichever case, how?
My opinion is that you should not stick so much around the physical medium used for connectivity either is WiFi or Bluetooth. You should abstract this aspect, in both cases you will be using sockets (I'm speaking about Android), if it's Bluetooth you will be using Bluetooth Sockets, if it's WiFi: TCP sockets. You could have a intermediate layer that abstracts the type of connection and through a factory to use either Bluetooth or TCP.
Bluetooth - http://developer.android.com/guide/topics/wireless/bluetooth.html
For WiFi you should study if P2P would help.
You will need two applications:
- one on the tablet - the server which listens for commands from the client (change color, do this or this)
- second on the smartphone - the client which sends commands.
I've built a few apps that do exactly that between iPhone and iPad. But the principle is the same. I used Bonjour networking. It's just a fancy name for ZeroConfig networking between devices. It's written originally by Apple but it's open source so there should be Android support out there for it too. Really simple and easy to work with.
If you already have a working connection then you already have the first half of your answer, that said you should really consider implementing a solution that uses a variety of connection types, WIFI, Bluetooth, etc.. The question I think you are really asking is how to pass data and messages between the apps once you have the connection.
There are a lot of ways to accomplish this. You could implement your own lightweight message passing system. If you haven't done this before it is more complicated than it originally seems, especially as you would be required to implement the system for each OS you end up using.
Should I be using Bluetooth, Wifi, or something else?
It depends on what situations you want your program to work in.
Bluetooth can provide a direct connection between your devices. A potential issue with bluetooth is that it has a limited range. If you're devices need to be far away from each other, you may want to go with wifi. Otherwise, bluetooth could work great.
If both devices are connected to the internet, you can make them talk to each other through there. The advantage of this approach is that it doesn't matter how far apart your devices are as long as they're both online. A disadvantage is that you'll have to figure out how to find the tablet's ip address before you can talk to it. This is actually a HUGE disadvantage because it can be quite problematic if both of your devices are not on the same wifi. You could have the user type in the destination ip address, but you'll have problems getting it to work if the user is behind a router (which will almost always be the case). The point is, it gets hairy.
If both of your devices are on the same wifi, you can use ZeroConf AKA bonjour (like Dancreek said) to figure out what ip address you need to send info to. I've previously used a library called jmdns (easy to find with google) to implement zero configuration networking. It's good because the user doesn't have to worry about ip addresses... it's intuitive for the user.
And in whichever case, how?
Networking is a pretty big topic, so I can't expand on this question to much. Short answer is, it depends on what method you choose. Search for some tutorials and start by getting one of your devices to send something as simple as an int to the other.
I want to facilitate video-calling from the android device to another android device. My question is that can i connect the android WiFi device with the android WiFi device without any use of internet connection. I want to use it just like the Skype. is this possible or not? if it is possible then how can i implement it...can i get some code snippets as well???? Please give me link to download that app
First, your idea works completely different from Skype, which is completely dependent on a functional Internet connection for its core functionality.
Second, while you could create an ad-hoc WiFi network betweeen two Android devices, their range will be the limiting factor:
WiFi is intended as a short-range wireless medium. There's a reason nobody wanted the 2.4 GHz band (and therefore it is unlicensed): there's a significant noise and signal loss on these frequencies, noticeable even at short range.
Moreover, wireless equipment in mobile devices is engineered for power efficiency - which translates to lower broadcast power when compared to on-the-grid devices.
Also, the antennae in such devices are omnidirectional - this is rather useful for normal use, but again lowers your available broadcast power
Even if you had huge, high-quality directional external antennae connected to each device, pointing very precisely at each other (btw that also means each of them is stuck in one place; see e.g. this for a dish size calculator), you'd need to make some pretty drastic changes to their networking stack, as the latency inherent in long-distance comms will screw up TCP/IP pretty badly.
Even so, the setup would be very brittle, dependent even on the weather (water vapour absorbs significant amount of power in that part of the spectrum).