Anyone know how can a short String or byte array could be transmitted via BLE on iOS without having to pair?
According to my research the only 2 keys allowed for startAdvertise method are CBAdvertisementDataLocalNameKey and CBAdvertisementDataServiceUUIDsKey.
https://developer.apple.com/documentation/corebluetooth/cbperipheralmanager/1393252-startadvertising
I also thought I could use
CBAdvertisementDataServiceDataKey: String
A dictionary that contains service-specific advertisement data.
to attach the data but that seems like another dead end WARNING: The advertisement key 'Service Data' is not allowed?
Unfortunately, you cannot use CoreBluetooth APIs to attach data to advertisements. On iOS the CBAdvertisementDataServiceDataKey is read-only. While Bluetooth LE allows attaching service data , Apple effectively disallows 3rd party apps from doing this.
You do have a few options:
Encode your data inside a 128-bit service UUID and advertise that. You will need to reserver a byte or two in the UUID to know that it is "your" advertisement, and therefore OK to decode the data from the other byes. This full UUID will only be advertised when your app is in the foreground visible on the screen. Let it go to the background or the screen turn off, and it will no longer advertise in that form. Similarly, receiving iOS devices must also be in the foreground with the screen on. This is because iOS disallows getting background scan results without specifying the matching service UUID up front. And because you are dynamically manipulating some of those bytes, you don't know what it will be.
Do a similar kind of encoding with the 4 byte major and minor fields inside the iBeacon BLE advertisement using CoreLocation. Again, this allows you to transmit only when the app is in the foreground. Receiving, however, can happen to a limited degree in the background (for 5-10 seconds after one of your beacons first appears when combining monitoring and ranging APIs.) The big disadvantage is you only have four bytes to work with.
Advertise data by manipulating the 128-bit background BLE Overflow Area Advertisement. This technique is more advanced, but advertising works in the background. Receiving works in the foreground, and partly in the background -- you can receive if the screen is at least turned on. You can read more about this technique and access free sample code in my blog post herehttp://www.davidgyoungtech.com/2020/05/07/hacking-the-overflow-area.
Related
I have been searching through stackoverflow; however, I seem to have found various conflicting answer's to questions regarding this. Given Android 5.1.1 and iOS 8.4.1 what is the maximum amount of bytes that can be sent through a connectionless BLE service to one another. It is my base understanding that it should be 20 bytes from BLE Specficiation(actually 23); however, I have seen queries where iOS was able to push 512 and android was able to increase it's MTU.
Also if it is possible to send more than 20 bytes in a connection would they all be recognized correctly at the scanners on iOS and android with a cross-platform application when it is receiving the packet's without direct connection?
Per Apple's Best Practices for Setting Up Your Local Device as a Peripheral:
Although advertising packets in general can hold a variety of
information about the peripheral device, you may advertise only your
device’s local name and the UUIDs of any services you want to
advertise. That is, when you create your advertising dictionary, you
may specify only the following two keys:
CBAdvertisementDataLocalNameKey and
CBAdvertisementDataServiceUUIDsKey. You receive an error if you
specify any other keys.
There are also limits as to how much space you can use when
advertising data. When your app is in the foreground, it can use up to
28 bytes of space in the initial advertisement data for any
combination of the two supported advertising data keys. If this space
is used up, there are an additional 10 bytes of space in the scan
response that can be used only for the local name. Any service UUIDs
that do not fit in the allotted space are added to a special
“overflow” area; they can be discovered only by an iOS device that is
explicitly scanning for them. While your app is in the background, the
local name is not advertised and all service UUIDs are place in the
overflow area.
Note: These sizes do not include the 2 bytes of header information
that are required for each new data type. The exact format of
advertising and response data is defined in the Bluetooth 4.0
specification, Volume 3, Part C, Section 11
If you use an unregistered 16 byte service UUID, I think that's going to give you about 12 bytes of data.
Available bytes in an advertising packet will differ from available bytes in a payload packet.
As far as I can tell, there is nothing to restrict any developer from programming their beacon to use a particular UUID, major, minor or identifier.
In the event I create an iBeacon with a UUID of "foo", what is to prevent another developer of creating a beacon with the same ID and (either accidentally or maliciously) causing my app to display incorrect data ?
Have I misunderstood how iBeacons work ? Please correct me if I'm wrong.
This is absolutely true. I have both spoofed the Apple Store's iBeacons (to prove this point) and had my beacons spoofed by Make magazine for the Consumer Electronics Show Scavenger Hunt.
This is not a flaw at all. You just need to design an app that uses iBeacons so spoofing is relatively inconsequential. If you design your app so it doesn't much matter, who cares?
The specific security mechanisms appropriate to counter this depend on the app in question, but there are countless possibilities.
For the CES Scavenger hunt, for example, we simply kept an audit log with timestamps so we'd know if somebody found all the targets impossibly quickly. In the end nobody did this -- our participants were all good sports!
You can't prevent spoofing of the advertisement packet because there is no central authority that issues universal unique identifiers (UUID's). UUIDs are arbitrarily assigned to a beacon and are not actually guaranteed to be unique.
However, once you have paired your handheld with the beacon, the picture is different. You can program a beacon (or, more specifically, a beacon-like device) to generate absolutely unique information when paired, such as a one-time password or some private-key encrypted handshaking between your app and the paired beacon.
The typical process flow would be:
handset detects ibeacon broadcast, reads UUID + Major/Minor.
handset launches your app (using the didEnterRegion event).
your app requests to pair with the beacon, sends it a command to generate an encrypted response.
your app decrypts the response. If successful, display a happy face! If failure, display a sad face.
Moving forward, I suspect that most beacon systems will be implemented this way. Unless and until the iBeacon standard is updated to accommodate encryption, it will have to be a hybrid approach of ping + pair.
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.
I have been reading information on NFC but could not find exact process or sequence of steps that happens when an NFC mobile phone comes in contact with an NFC tag?
In more detail i got to know how the antenna, coil etc generate the magnetic field and how data is transferred, but i want to know
whether any handshaking happens in the first stage?
Or What data is transferred between 2 NFC enabled phones before the actual sharing of a photo or any information happens.
Thanks in advance.
For explanation purposes, lets say the actual hardware communication of magnetic field generation, etc. etc. is the hardware layer of communication.
On the android OS layer, there is something called NfcManager ( a service ) that runs in the background when you enable "Nfc" settings. This service is responsible for converting the raw byte data that is received from the below layers, which could be the kernel or the hardware layer, depending on how you look at it.
Once the service picks it up, this link should give you a basic idea as to how it is pushed into the application!
As far as 2 NFC phones go, this is not an extremely informed opinion, but im guessing from sheer experience. In the case of a data that needs to be sent below a certain quantity, there is no "pairing" that happens. It identifies the other 2nd NFC device and simply sends out data. In the case of photos or anything larger, i would assume it pairs it using Bluetooth and sends out the data.
I require a fast reliable method of sending control commands (simple data, possibly only a few dozen possible commands) to a remote system which is using a smartphone* as its onboard computer. I have deemed standard data packages used for mobile internet data transfer as too unreliable of control purposes, however I have noticed that once a voice call is initiated it is much more reliable. Has there been any development into sending data between phones across a connected call, and if not are there any known reasons a modified dialup modem in software form couldn't be used?
Furthermore, could this protocol be robust enough to send back low res video and other simple numeric data?
*Smartphone - A phone with significant processing power and ability to run custom programs (most likely with an Android based OS however am open to suggestions)
Have you tried SMS? while you won't get video data it may work for small chunks of data. Also if the small chunks are from the phone to a server, you may try sending DTMF down the line (however I've yet to see that working.
Other than that it's customised hardware.
Hmmm...this reminds me of those old TV games like Hugo...there you had a voice connection and I think the commands were given by the different tone of the key pressed from 0-9. Maybe you should try something similar.