How can a device identify the other devices to whom we need to send data and transfer the data to other device.
If the device1 send the data to device2, will other device say device3 near to them will receive same data?
Please read up on the whole Bluetooth story. You seem to have problems with basic concepts. Also, it would probably help to be a bit more specific in your questions for example specifying which BT version are you referring to.
For identifying the devices, each of them has a separate address. They even have human readable names. (Look at the Wiki page linked above Connection and communication) Also, during the pairing process, you should have to get to know and explicitly allow the devices which you really want to communicate with, the goal of the process is exactly to make sure to have an explicit authorization between the devices for communication.
Yes, device3 will receive the radio signals, but if not authorized, it won't be able to tell what is going on - unless it is a misbehaving device cracking the encryption... (Given the communication is actually encrypted, that is.) Reading the Security Concerns part is also useful.
Bluetooth can connect up to eight devices simultaneously. With all of those devices in the same 10-meter (32-foot) radius, you might think they'd interfere with one another, but it's unlikely. Bluetooth uses a technique called spread-spectrum frequency hopping that makes it rare for more than one device to be transmitting on the same frequency at the same time. In this technique, a device will use 79 individual, randomly chosen frequencies within a designated range, changing from one to another on a regular basis. In the case of Bluetooth, the transmitters change frequencies 1,600 times every second, meaning that more devices can make full use of a limited slice of the radio spectrum. Since every Bluetooth transmitter uses spread-spectrum transmitting automatically, it’s unlikely that two transmitters will be on the same frequency at the same time. This same technique minimizes the risk that portable phones or baby monitors will disrupt Bluetooth devices, since any interference on a particular frequency will last only a tiny fraction of a second.
So what if they interfere and there is a erroneous data, the receiving system simply discards it based on correcting bits of the packets transffered.
Bluetooth devices have a parameter or option called visibility. When you enable visibility, then the bluetooth device starts
publishing its presence within the bluetooth frequency range. This presence can then be detected by any other bluetooth device which can connect to this device when
it scans the above bluetooth frequency range.
As they use spread-spectrum frequency hopping described above they
publish data to all receivers but only the intended receiver with whom
the sender is connected will have the key to unlock the data.
Related
Nearby Share sometimes uses bluetooth to transfer the files because of which it is very slow. Sometimes it is not at all handy to transfer files that are more than 100 MB. Initially I thought Bluetooth is used only for handshaking purposes. But later I realized that the files are itself transferred via bluetooth. I'm curious to know why should the files be transferred via bluetooth when it can be transferred via wifi direct. A lot of third party apps including Google Files use wifi direct to transfer the files. So why does a built-in functionality like Nearby Share should use bluetooth. The sole purpose of Nearby Share itself is to achieve fast file transfer with wifi direct and without internet. So if the files are transferred via bluetooth there is no point in using Nearby Share.
I'm also curious to know the various modes of file transfer present in Nearby share. There are three modes: Data, Wifi Only and Without Internet. I'm really curious to know why is an internet connection required to transfer files when Nearby Share is meant for file transfer without Internet. Is it meant for handshaking purposes in Web RTC?
(Disclaimer: I work on Nearby Share)
Nearby Share will always attempt to upgrade to WiFi before sending files larger than 1MB. A grace period of 10sec is given for that upgrade before fallback mechanisms kick in and the file is sent over Bluetooth as a last resort. Even after falling back to Bluetooth, the devices will continue to attempt to upgrade to WiFi in the background, but some failures are unrecoverable and the file will fully send over Bluetooth. Note that urls and very small files will immediately send over Bluetooth.
This upgrade can fail for a multitude of reasons. Most commonly, it's a concurrency issue. The same radio is used for Bluetooth, p2p WiFi, and your normal access point connection and it must be time-shared accordingly. If all 3 want to be on different channels, you will miss messages -- it's a guarantee. If these messages are important, such as the authentication frames when connecting over WiFi Direct, then the connection will fail. If these messages are less important, they may be resent until successfully received, but it will lower throughput for the transfer such that even 5GHz WiFi can look to be as slow as Bluetooth.
Nearby Share tries to avoid this in a few ways. When regulations allow, we will attempt to start the WiFi Direct group on the same channel as the access point. This way, the phone doesn't have to timeshare (although it does have the side effect of colliding with messages from the access point. But generally, both sides will back off a random amount and retransmit, and the loss is less than the loss of multi-channel concurrency). Unfortunately, many countries do have regulations that allow certain (or all) 5GHz channels only indoors -- in those cases, the access point can be set up to utilize it but WiFi Direct cannot.
We also prefer mediums like WiFi Direct over Hotspot, as WiFi Direct commonly uses CTS2SELF frames to advertise "Do not transmit for this duration". Unfortunately it's not as straightforward a message as "I am going off channel, do not try to communicate with me" -- CTS2SELF has the side affect of quieting all communication over the access point even if it wasn't directed to the phone -- but it does get the point across.
We pause any Bluetooth activity we have control over, to reduce the need to timeshare with it. In some severe cases, where the OEM has implemented timesharing that's too aggressive, we will turn off the Bluetooth radio to forcefully interrupt Bluetooth activity, but this is disruptive and usually a bad user experience.
We may try to send the data over your access point itself instead of setting up WiFi Direct. This can avoid the MCC situation described above, but comes at the cost that the data needs to be re-encrypted (because we don't know what other devices are connected over LAN and might be eavesdropping), and it does introduce another hop, as the data needs to go through the AP even if the devices are side-by-side. TDLS helps avoid that last issue, but it has limitations (eg. it won't use 40/80/160MHz bandwidth if the AP isn't set up for it, and it'll send over 2.4GHz if the AP is on 2.4GHz).
Other possible failures include the device getting into a bad state (toggling airplane mode can help here), the Android version being too low (ideally both devices should be R+, as it's almost impossible to fix bugs on older Android OS versions, even though we try), or just bad luck.
I have been doing a ton of research on this project I want to do, probably read every SO post (bluejacking, RFCOMM, beacons, etc...) and my head is spinning.
I want to create a system at home, using Arduino (with bluetooth le) that will scan bluetooth and detect when my phone or any of my family members phones are in proximity. Whether this is a MAC scanner or simply getting the friendly name. I would also like to get the RSSI. I dont need to do accurate distance measurement but I would like to know approximately how close they are. Does anybody have any suggestions for this approach? I know I can create an app on the phone and have it become a beacon and this may be an option but I am concerned with Android, it would have to be Marshmallow 5.0 at a minimum. I would like support to be a little lower than that, like JB or KK. So, it seems like there should be a simple scan, just looking for the MAC or name. That is all I really need.
That said, the main question I have is, can you scan for and see bluetooth devices in range if they are already paired to something? Like a Bluetooth headset? I understand bluetooth is point to point but does it allow multiple connections or at least broadcast the mac or name when paired?
This question, along with any general suggestions will help me out tremendously!
Thanks!
Bluetooth Discovery from the Listener involves Listening for Bluetooth Inquiry packets(RX) and inquiry response (TX).if done continuously this will deplete the battery. Hence most devices (including Mobile Phones and Headsets) has a policy of when to be discover-able and connectable. Headsets in particular are discoverable only when they are instructed and connectable until one device is connected to it ( There are probably exceptions where the headset has the capability to be connected to multiple phones at the same time). Most Mobile Phones are discoverable only when they are in settings screen ( Android,IOS and Windows Phones), but unlike the headset case they are connectable.
so one option with the MobilePhone is to see if it is possible to connect to them after pairing once ( for example by trying a service search on the remote device and see if it returns the service attributes, this internally makes a connection and indirectly ensures the presence of the device).
if you are specific about a mobile phone which is already paired then you might need to establish a higherlayer connection ( such as SPP) with Authentication and encryption. This would force a two way check between devices to see whether they are already paired. other less secure option is to rely on the Phone (Android and IOS phones doesn't generally Allow a higher layer connection without encryption/pairing) and try to establish an SPP connection to the phone.
Another option is to use Bluetooth-LowEnergy. But Note that security in BT was superior to BLE till BTv4.1 and same on BTv4.2.
I have to exchange data between two bluetooth devices, one of them will be an Android device. For simplicity's sake you can assume the other device will be a generic linux device running bluez producing data similar to the data a fitness tracker would produce.
The scenario seems a straightforward use case for Bluetooth Low Energy. The problem i am currently running into comes from the fact that communication has to be reliable (reliable in the way TCP is reliable). This means:
no losses
no corruption of data
order needs to be preserved
no duplicates
no phantom packets
While losses are prevented at link layer level, the order for instance seems not to be explicitly preserved when working with Low Energy (using indications would probably achieve this).
Not having done a lot of work with Bluetooth I am currently overwhelmed quite a bit with the amount of options while at the same time no option seems to fit the bill nicely.
Is there a "best-practice" for setting up reliable communication between two bluetooth devices? A Bluetooth Low Energy solution would be preferable, but is not mandatory.
Once your Bluetooth connection is setup its reliable. So you don't have to be worried about data loss or corruption.
So the things you're worried about can be easily handled in your side. You'll get proper connection and disconnection callback while setting up a BroadcastReceiver for your BluetoothAdapter.
In case of any disconnection you may have to restart the procedure for connection again and once its established properly you may resend the data.
I don't know about your purpose yet, but one thing I need to mention here is, I would not recommend Bluetooth communication if you're holding the connection for long time. Some devices disconnects the connection automatically after some time if there's no continuos transmission.
Android has Bluetooth support, but it only allow to send ot receive data from stream. There is a very good sample project from Google: https://github.com/googlesamples/android-BluetoothChat . The only drawback of this sample is that it use Handler to nitify about Bluetooth events. I changed it a bit so it use another Thread and from it calls methods of interface you set, take a look at project: https://github.com/AlexShutov/LEDLights . This is ordinary Bluetooth, not BLE, hope it will help
Android's BLE stack is as good as the link layer specification. So you can use "write without response" in one direction and notifications for the other direction. Just make sure your peripheral side does not drop incoming writes.
BLE uses 24-bit CRC. for the amount of data transmitted using BLE the CRC is quite robust and the possibility of corruption is very low ( note that TCP CRC is 16bit and the Ethernet CRC is 32bit, please see http://www.evanjones.ca/tcp-and-ethernet-checksums-fail.html).
The ordering issues in wired network is a result of routing packets through different routes to the same destination ( plese see If TCP is connection oriented why do packets follow different paths?) . This is partially due to the use of sliding window acknowledgement protocol, which allows a number of packets to be transmitted before being acknowledged.In BLE there is no routing and the acknowledgement scheme is a variation of stop and wait ARQ scheme(2-bit lazy acknowledgement), this means that it is not possible to send a new packet without being acknowledged. These two factors makes the possibility of having an out of order transmission highly unlikely.
Let's say I have an Android device which supports GSM 800/900Mhz bands and I want to use it as a transmitter to remotely control a car or anything else.
Is it possible to program such a thing on Android ? Maybe using NDK ?
The purpose would be to send custom packets on these frequencies.
Thanks.
There are a lot of misunderstandings in this concept, however what you're thinking of quite nice, assuming it would be possible (which isn't :( ).
RF communication is handled EXCLUSIVELY by the modem software, which is included in the baseband binaries.
You cannot simply tap into it, and send whatever you like, since the protocol and its transport layer are very strict to comply with the GSM rules.
Also - since baseband binaries are under strict control there are very few, to none custom ones.
There are also WAY many other reasons why this is not actually possible, without lots of hackish work. Those devices are made strictly to perform on the GSM network. You could use another reciver to for example send WAP push messages (in raw form) as commands, however expect the delays to be HUMONGOUS (ie. 1second - 20 seconds) which is not viable for any kind of remote control. Same results as SMS communcation, just in an unrestricted form.
CAUTION: Using telecom broadband channel is BANNED for public use in most countries, so even if you get an external GSM bands transmitter (which actually can be done), you still would need to comply to your countries regulations.
Possibly related thread: https://electronics.stackexchange.com/questions/94668/longest-range-remote-control
is it possible to use an android phone to collect IMEIs or unique Phone IDs of phones within the same cell? Probably there is already some hack to use osmocom ... what I am looking for is an easy to work solution to scan traffic (by counting car drivers phones )
Theoretically yes but practically no.
In a normal GSM network you will expect Mobile identity IMEIsv data fields to be encoded in a message called Identity Response.
This message is sent in a encrypted channel called sdcch/8. You need to decrypt (and find) this exact message in that channel to detect the imei of a given uplink transaction.
To be able to catch an uplink data transaction you need to have a radio receiver that is listening on the uplink frequencies and you're android phone does not do that.
You were looking for an easy to work "solution to scan traffic".
What I suggest you do is try to find a phone that will give you information about the CCCH channel this is unencrypted and can contain Paging Requests with tmsi or imsi information. The tmsi is more anonymous and it gives you some kind of statistic for counting.
The "easiest" way to do this (today) is to use Nokia 3310 and the dct3 gsmtap project. Filter the pcap file using options in tshark.
There may be more accurate ways of counting cars.
Well theoretically yes, but the problem here is that you need to know how the radio interface of your android phone works and have a driver for it before you can do that.
As far as I know there are no such drivers for GNU Radio.
The other problem is that the CPU on your mobile phone is not strong enough to handle the amount of data processing needed to perform such task, it may come a day when you have quad core CPUs with lots of RAM and strong DSP support, but I don't think we are there right now.