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
Related
I try to get the channel width of networks so I'm using WlanGetNetworkBssList to retrieve a list of BSS entries of the wireless networks on a wireless LAN interface but I don't see any information about the channel width. It's kinda trivial to get the channel center frequency to obtain the number of used channel and many other information but the channel width seems to be an obscure information stored somewhere in IE data blob of BSS entry structure. I managed to get some information about the width of the channel from HT and VHT Operation information elements but doesn't seem to be enough. I found on Github a python wrapper that extract info from Extension information element but it's not clear from which one since IE data blob of BSS entry structure might have more IE Extension elements.
For example I have 5 different IE Extension elements:
FF 1A 230108080E00580C2F4EC96FC927DE018F00FAFFFAFFFAFFFAFF
FF 07 24E43F003CFCFF
FF 03 272500
FF 0E 260600FFFF20FFFF40FFFF60FFFF
FF 02 252A
I found some basic information about HT Operation and VHT Operation information elements but nothing about Extension information element.
Where I can find the specifications for these information elements of AP beacon frames?
I'm analyzing some captured packets and see that for some of the packets, Wireshark displays the image below, which appears to contain several Modbus PDUs in the one TCP segment. I have searched online for answers but can't see this behavior anywhere I looked. From what I'm reading, Wireshark re-assembly gathers the different TCP segments, and so it appears this can't be reassembly.
My question is: is this behavior (i.e. having several Modbus PDUs in one TCP segment) normal and expected? If not, what is causing this problem? Is this an issue with Wireshark?
link to fullsize image
Yes - Modbus TCP runs at the application layer and supports multiple simultaneous transactions over a single connection (see page 10 of the spec). So sending:
00 01 00 00 00 06 01 03 00 00 00 01 00 02 00 00 00 06 01 03 00 01 00 01
is fine (this is 2 x "Read Holding Register" commands - note the different transaction identifiers). If this is sent at the same time it's likely the two commands will be sent out in the same packet. While this is supported (by some devices!) its not something I see often (unless performance is key its easier to process the response before sending another request).
However I don't think this is what is happening in your case. The lines you are highlighting are flagged TCP Retransmission so I'm assuming there was a connectivity issue. You can also see this in the 1s gap between the retransmitted packed and the previous request (it looks like queries are being sent every 300ms).
862.493794
862.805685 - 0.3s gap
863.117588 - 0.3s gap
864.232576 1st retransmission - 1.1s gap
You will also note that after the retransmissions there are a couple of responses that come in very close together (less than 1ms apart).
When data is retransmitted I believe (not my area so relying on this answer and assumptions!) that multiple packets may be combined. So I suspect you are seeing is:
Network connectivity issue starts
Client sends request
No response received so Client tries again (may happen multiple times)
Connectivity issue resolved
The packets sent while there was an issue are combined and retransmitted (handled by the network stack).
In no case does TCP ensure that if you send a packet of x bytes, the other end will receive the x bytes in a single packet.
It can happen that one side sends 1000 bytes and the other side receives first 800 and then 200, or two packets of 1000 and 2000 are sent and the other side receives only one of 3000.
From the received PDU, first you have to read the bytes necessary to obtain the length and then read the rest and so on to extract the PDUs
I am new in Lora, I tray to connect my Lora GW & GPS tracer LW001-BG to The things Network, & it successfully connected to TTN, but how to convert or decode the data from the GPS to latlong format?
here is the documentation http://doc.mokotechnology.com/index.php?s=/2&page_id=143
I receive data format like this 02 01 56 F8 0B 45 F4 29 32 46 and I need to convert/decode it to readable format
thanks I hope someone can help me
The payload of the message is in bytes 3-6 (for the latitude) and 7-10 (for the longitude). The first two bytes indicate how many packages there are (two) and which the current one is (the first).
The four bytes represent a 32 bit floating point value; in your example this is 2239.5210 for the latitude. This means 22 degrees, 39 minutes, and 31.26 seconds (which is the fraction times sixty).
You can see this in an on-line converter: As the byte order is lowest byte first, you need to reverse it, convert it to binary, and then check the checkboxes in the binary representation:
54 F8 0B 45 becomes 45 0B F8 56 or binary
01000101000010111111100001010110
Here the first bit is the sign, followed by 8 bits of the exponent and 23 bits mantissa. The decimal representation is 2239.52099609 and you discard all digits after the fourth to get 2239.5210 (with rounding).
Depending on how you process this data, you might be able to simply cast this to a float variable, as they are generally following the 32 bit IEEE 754 standard.
I have connected OBD2 and getting the can data (11bit 500kpbs CAN) using atmel can controller.
I get data.
Now, how do I get the mode and PIDs from this data?
For example, my data looks like this:
15164A8A-FF088B52 -- Data: 00,00,00,86,9C,FE,9C,FE,
I could see RPM changing, ignition on/off etc... on the data fields.
I don't want to use ELM chips. I need to handle the raw data directly.
HINT: All of my numbers are in HEX.
OBD2 protocol sends you responses in bytes (8 bits). responses are subdivided into header (or called ID as well) and data.
IDs are the address of the ECU and data is "response data" from ECU and it is always 8 bytes (in CAN Bus protocol?!).
8 Bytes of data will be divided into PCI (which can be one or two bytes) and values. PCI will show you what is your frame type (single, First, consecutive or flow control frame) and how many bytes are incoming.
to make it easier I make an example only for single frame:
you might send an OBD request to main ECU like this:
7DF 02 01 0C 00 00 00 00 00
7DF is ECU address for diagnose tester device.
02 is number of sending data bytes
01 is the mode (which you might be interesting in!) 01 is current data, 02 is freeze frame and etc.
0C is rpm PID.
The response from ECU would be something like (single frame):
7E8 04 41 0C 12 13 00 00 00
7E8 is the ECU that responding.
04 number of incoming data bytes.
41 the data are in response to 01 PID
0C response to this PID
12 13 are two byte in response to 0C. Please keep in mind that you have to decode these two bytes with OBD II ISO protocol. you can also find some of conversion rates on Wikipedia.
Other bytes are useless.
To make it short: you have to parse each response from ECU and try to convert the useful bytes to readable decimal value. It depends on which programming language you are using. in C/C++ the best practice in my opinion would be unsigned char which is guaranteed by compiler to be 8 bits and in JAVA it can be Byte. Moreover, try to use bitwise operators to make your life a bit easier.
By more questions do not hesitate to ask.
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.