I want to put custom data, like User ID, into advdata of iBeacon packet. Is it possible? If so, how can I get the data. CLBeaconRegion seems not to have the advdata property.
Please take a look the great sample of iBeacon below. https://github.com/suwa-yuki/BeaconSample/blob/master/BeaconSender/BeaconSender/BSViewController.m
As far as I can see, I may put custom measuredPower into the advertisement data. Can I use this property as a custom variable? I mean I want to put UserId into the measuredPower property. Does it affect RSSI or other things?
Thanks,
You can put any bytes into an iBeacon advertisement that you wish, but iOS severely limits which of these bytes you can read. If you need to use iOS to read these data, you only have four bytes of bluetooth advdata you can change that will be readable by iOS. If you only care about reading the bytes with other operating systems (OSX Mavericks, Android, Linux) then this is not a problem.
To explain the limits of iOS, it helps to take a look at the advdata of a typical iBeacon advertisement, which looks like this:
4C 00 # Company identifier code (0x004C == Apple)
02 15 # iBeacon advertisement indicator
e2 c5 6d b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 # ProximityUUID
00 00 # Major
00 00 # Minor
c5 # The 2's complement of the MeasuredPower
iOS does not allow you to access the raw bytes of the advdata shown above using its CoreBluetooth APIs. (See here for more details.) If you use the iBeacon ranging functions of CoreLocation, you can read the ProximityUUID (16 bytes), Major (2 bytes) and Minor (2 bytes) out of the advdata. The MeasuredPower that is set in the code example you mentioned is NOT directly readable in iOS. It simply is used as an input to the algorithm used to estimate distance from the RSSI. (See here for details.) Changing the MeasuredPower in the advertisement will affect this distance estimate, but you can not reliably determine the actual MeasuredPower value. So you cannot use it as a custom variable.
As described above, an iBeacon advertisement also includes a 16-byte ProximityUUID. But the iOS CoreLocation APIs don't let you see any iBeacon advertisements unless you specify the matching ProximityUUID up front. So it really isn't any use as a custom variable.
What can you use as a custom variable? The two values you can use for custom variables are the Major field and the Minor fields. Each of these is two bytes and if you tell iOS CoreLocation to range all iBeacons that have a given ProximityUUID, you will get ranging updates telling you the Major and Minor values for each, and you can encode any data in these fields you want. To access these, use simply read the values like this:
-(void)locationManager:(CLLocationManager *)manager didRangeBeacons:(NSArray *)beacons inRegion:(CLBeaconRegion *)region {
for (CLBeacon *iBeacon in iBeacons) {
// write code here to do something with iBeacon.major and iBeacon.minor
// which each will have values from 0-65535
}
}
All of the above is an iOS-only restriction. Other platforms let you see the full bytes of the advdata, so you can use any of the bytes you want as custom variables. If you still want them to be recognized as iBeacons, however, you should leave the second two bytes (the iBeacon advertisement indicator) alone.
For custom variables, the best practice is to use lookup table to tie the standard iBeacon identifiers (ProximityUUID, Major, Minor) to data fields. This lookup table can be embedded in your app, or it can use a web service like Radius Networks' ProximityKit to do do this automatically.
Full disclosure: I am Chief Engineer for Radius Networks.
Related
I need to work on a Bluetooth hardware and need to send the bytes data. I know the format but not sure about the last byte:-
[0x6E,0x01,0x00,0x24,0x93]
The last byte is the - byte5(verify). The preceding bytes add up, but I am not sure how value 93 came up.
Is there any specific logic that needs to be added for this.
I am unable to understand the CANopen Protocol. I am aware of the working of CAN and how a CAN frame looks like. A CAN data or remote frame contains the Start of Frame , Message Identifier Field, DLC, RTR , Data(Payload), CRC , ACk fields, etc. I am aware that the CANopen standard utilizes the CAN bus to send the CAN messages. However , the way in which a CANopen's CAN frame looks is different where it contains a COB ID+Node ID in the Message identifier field and in the payload field , it contains object dictionary related information. I would like to ask the following questions therefore:
How are the object dictionaries defined. I am aware that it is a
table containing an ID , sub ID, Datatype information about the data
it contains , the manufacturer information for the respective data
entry , etc . Are they all hard coded as an m*n multidimensional
array in the software stack?
I am confused with the terms transmit PDO and Receive PDO. Is it similar to CAN data frame and CAN remote frame ?
What is PDO mapping and how can i identify which object ID in the object dictionary is mapped to which object ID in the PDO mapping
table. Both use the same terms Object ID ?
I am actually very new to CANopen and i have asked these questions based on my initial understanding. I was unable to find a detailed explanation in the CiA website.
Thank you in advance
Krishna
It is not so easy to understand it!!
CanOpen is a communication between Master (client) and Slave (server).
An device like a sensor is a Slave.
The slave has an OD (object directory). The manufacturer provides all informations about it. Ex. if i want to read the temperature, its location is at adress 0x2040 at sub index 00. Then the master (our system) needs to make this request. To do this, you need to configure the device by sending some request (with SDO) in order to change the TPDO1 mapping (0x1A00) and TPDO1 communication parameters (0x1800). And be able to receive by the device the temperature. The device will not work alone.
SDO (read/write) allows OD access entries. Ex. change the TPDO1 mappings.
PDO is the output/input to the device once operational.
There is NMT Master commands to put the device in operational mode or to send a SYNC or Heartbeat. Depends what the device needs?
Ex. 080h 00 : SYNC send by master
280h 06 E5 EF 02 00 00 00 : response of device by TPDO2
000h 02 01 1F : put the device with ID = 1F in operational mode
If you want a good example device POSITAL FRABA absolute rotary encoder with can open interface.
Hope this will help you a little bit!!!
I am integrating an iOS app with a Bluetooth chip.
I am trying to understand the differences between a constant BLE connection and an iBeacon notifications in terms of the protocol.
So I am able to connect to the chip and send/recieve data from/to iPhone.
To communicate , you need 3 things :
name
service UUID
characteristic UUID (to write and read from).
Then, when you want to register to a region of an iBeacon, you also need a UUID of the characteristic, but also major/minor values.
Thing is, all iBeacon apps will not detect this type of broadcast- the one I use for communication.
So, whats basically the difference in the protocol? what if I keep advertising the same service/char I use for regular communication? is it good also for beacon push notification ? apparently not- but whats the different?
Also, I have 2 hardware chips, both will not let you set a major/minor values, but only to update the characteristic to notify a new value to subscribers which is hex (not an integer like major/minor) - is that equivalent to an iOS push notification by iBeacon detection ??
Difference between constant BLE connection and Beacons
A "constant BLE connection" is a connection, two devices pair with each other.
A BLE iBeacon device does not know about other devices. It simply broadcasts a certain signal frequently. Other devices can than listen to this signal and evaluate the signals strength to estimate how nearby the sender might be.
"Is it equivalent to Push Notifications?"
No.
Major & Minor
The major number (2 bytes) is used to group a related set of beacons. For example, all beacons in my flat will have the same major number, while the neighbour uses his own. That way the application know in which specific flat the application is.
The minor number (2 bytes) is used to identify the actual beacon. Each beacon in my flat has a different minor number, so that you know where within my flat the application is.
" value to subscribers ... is hex ... not an integer"
An hexadecimal is an integer.
HowTo
You need to insert a specific set of bytes into the optional manufacturer specific Data field (your "new value" for subscribers).
According to this site, you need the following values:
ID (uint8_t)
Data Length (uint8_t) - The number of bytes in the rest of the payload = 0x15
128-bit UUID (uint8_t[16]) - The 128-bit ID identifying the Beacons manufacturer
Major (uint16_t) - The major value
Minor (uint16_t) - The minor value
TX Power (uint8_t) - This value is used to try to estimate distance based on the RSSI value
Example from this site:
0x02 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 00 00 00 00 C8 00
0x02
0x0008
1E 02 01 1A 1A FF 4C 00 02 15 Manufacturer
00 00 Major
00 00 Minor
C8 00 Power
I have a bunch of questions concerning Timing Advance in GSM :
When is it defined ?
Is it the phone or the BTS who's in charge of defining it's value ?
is it dynamic, does it depends on certain situations ?
Let's say that I figured out a way to get the exact value of the Timing Advance (GSM Layer 1 Transmission level) from the phone's modem :
In order to verify my solution, I'm supposed to put my phone over and over in a situation where he have to use/change the Timing Advance while I log its value...
How can I do that ?
Thanks
In the GSM cellular mobile phone standard, timing advance value corresponds to the length of time a signal takes to reach the base station from a mobile phone. GSM uses TDMA technology in the radio interface to share a single frequency between several users, assigning sequential timeslots to the individual users sharing a frequency. Each user transmits periodically for less than one-eighth of the time within one of the eight timeslots. Since the users are at various distances from the base station and radio waves travel at the finite speed of light, the precise arrival-time within the slot can be used by the base station to determine the distance to the mobile phone. The time at which the phone is allowed to transmit a burst of traffic within a timeslot must be adjusted accordingly to prevent collisions with adjacent users. Timing Advance (TA) is the variable controlling this adjustment.
Technical Specifications 3GPP TS 05.10[1] and TS 45.010[2] describe the TA value adjustment procedures. The TA value is normally between 0 and 63, with each step representing an advance of one bit period (approximately 3.69 microseconds). With radio waves travelling at about 300,000,000 metres per second (that is 300 metres per microsecond), one TA step then represents a change in round-trip distance (twice the propagation range) of about 1,100 metres. This means that the TA value changes for each 550-metre change in the range between a mobile and the base station. This limit of 63 × 550 metres is the maximum 35 kilometres that a device can be from a base station and is the upper bound on cell placement distance.
A continually adjusted TA value avoids interference to and from other users in adjacent timeslots, thereby minimizing data loss and maintaining Mobile QoS (call quality-of-service).
Timing Advance is significant for privacy and communications security, as its combination with other variables can allow GSM localization to find the device's position and tracking the mobile phone user. TA is also used to adjust transmission power in Space-division multiple access systems.
This limited the original range of a GSM cell site to 35km as mandated by the duration of the standard timeslots defined in the GSM specification. The maximum distance is given by the maximum time that the signal from the mobile/BTS needs to reach the receiver of the mobile/BTS on time to be successfully heard. At the air interface the delay between the transmission of the downlink (BTS) and the uplink (mobile) has an offset of 3 timeslots. Until now the mobile station has used a timing advance to compensate for the propagation delay as the distance to the BTS changes. The timing advance values are coded by 6 bits, which gives the theoretical maximum BTS/mobile separation as 35km.
By implementing the Extended Range feature, the BTS is able to receive the uplink signal in two adjacent timeslots instead of one. When the mobile station reaches its maximum timing advance, i.e. maximum range, the BTS expands its hearing window with an internal timing advance that gives the necessary time for the mobile to be heard by the BTS even from the extended distance. This extra advance is the duration of a single timeslot, a 156 bit period. This gives roughly 120 km range for a cell.[3] and is implemented in sparsely populated areas and to reach islands for example.
Hope this Answer the question:)
It's defined everytime the BTS needs to set the define the phone's transmission power, which happens quite often.
It's the core system (BTS in GSM) who totally in charge of defining it's value.
It's very dynamic, and change a lot. Globally, the GSM core system is constantly trying to find the exact distance between the BTS and the MS, so it constantly make a kind of "ping" to calculate it. The result of such operations is generally not that accurate since there are a lot of obstacles between the mobile and the BTS (it's not a direct link in an open space).
Such operations happens a lot, so use your smartphone. Simply.
Where are the differences between the CBUUID and the NSUUID object?
I have seen to fill the scanForPeripheralsWithServices with both objects in different cases... Apple expect an CBUUID object so I would prefer to use this type or?
My example:
let MY_SERVICE_UUID = CBUUID(string: "hdl83h6sd-gl95-bn4f-37gd-jd73hd0tn8za")
func scanForPeripheralsWithServices(serviceUUIDs: MY_SERVICE_UUID,nil)
An NSUUID is a 128 bit number that is used to uniquely identify objects, types and other items. It can be accessed as bytes or is commonly used in a string form - 68753A44-4D6F-1226-9C60-0050E4C00067. The class includes methods for creating both random UUIDs and instances initialised with a specialised value.
Bluetooth also uses 128 bit identifiers for characteristics and services. The Bluetooth SIG has defined many "well known" services and characteristics. These are represented as a 16 bit value which is combined with the Bluetooth base UUID to get the full 128 bit value.
The CBUUID methods are aware of these well known values and can automatically transform the 16 bit values into their 128 bit equivalent. A CBUUID can also be initialised with a 128 bit value if you aren't using well known values (I.e. You have created your own private services and characteristics)
For example initialising a CBUUID with CBUUID(string:"180F") is ok (this is the battery service) but NSUUID(string:"180F") would fail because it needs all 128 bits.
When working with Core Bluetooth you will use CBUUID for services and characteristics. An NSUUID is used for the peripheral identifier since that is just a MAC with no special values defined.