I can't seem to figure out the relevance or importance of major and minor values in detecting iBeacons. When I register and configure my Gimbal beacon, I give it a specific set of values for UUID, major and minor, and then when I use my cordova iBeacon plugin I can detect my beacons but only if I instruct it to look for these exact parameters.
It would seem to me that only the uuid would be critical to detecting beacons. Yet they aren't detected by my app unless I match value for value each of those 3 criteria
Can anyone elucidate the relevance of the major and minor values in beacon detection and is it true that my code needs to specifically instruct the plugin to look for beacons matching all these values.
Hope this post makes sense... the iBeacon detection has so many moving parts that learning about it has tied my brain in a pretzel
The iBeacon protocol was implemented this way to ensure that each beacon would be unique. If you have a large beacon deployment (lets say in all of your stores across the country) Then you want to set the identifiers in such a way that you can id the beacons individually. An example deployment would look like this:
All beacon UUIDS: 1234...
All department stores in Boston: Major = 1
All department stores in Chicago: Major = 2
Minor can vary by aisle or section.
So then I know if I detect beacon UUID 1234..., Major 1 Minor 8 I can map it to the Boston store clothing section. This is just an example (and a kind of lame on at that) but essentially the levels of identifiers are just a greater insurance that the beacon you detect is the one you actually want.
When monitoring for iBeacons you can actually monitor at each of the different identifier levels, so you could monitor for all beacons with a UUID, all beacons with a UUID and Major, or all beacons with a UUID, Major, and Minor (which ideally would just be a single beacon)
This statement is critical:
It would seem to me that only the uuid would be critical to detecting beacons. Yet they aren't detected by my app unless I match value for value each of those 3 criteria
Using raw iOS APIs and the Android Beacon Library, supplying only the UUID will match beacons. You do not need to specify the major and minor to detect beacons. The fact that you are seeing otherwise means something is wrong with the code you are running, the framework it is using, or both.
The purpose of the major and minor are to subdivide the identifier space for logical purposes. If you then match solely on UUID or UUID and major, you can take diffrent actions depending on which beacon is detected by examining the minor value.
Related
Referring to https://webaudio.github.io/web-midi-api/#dom-midiport-id.
As an example, let's say we're talking about Synth X.
The name and manufacturer parameters of the MIDIPort would be the same across any instance of Synth X that connects.
My question is, would each individual Synth X product have a unique id parameter?
For example, my friend and I both have Synth X, would the IDs be unique?
Or is this more like a device ID? Like manufacture + name = ID? All Synth X products would return the same ID?
No, it isn't unique.
At least on Windows, these port numbers/IDs are just the enumeration order of devices. While the idea of the spec is that you can save one and re-open the same device later, this doesn't really work in between page loads in practice. (Which, is really unfortunate!)
Taking this another step further, the OS doesn't really know how to uniquely identify the device either. Even in the case of USB, the device descriptor doesn't always have a unique ID. It's common for cheaper devices to all be programmed with the same serial, or no serial at all.
Currently i am thinking for a functionality for devices which has to rely on identification of unique devices. Currently i am thinking to keep device name also in that list as a measure to identify uniqueness of device.
My question is : Will ever be a case ever that a manufacturer has two product having same vid, different pid but same name ?
If you're trying to uniquely identify specific devices, use the VID, PID, and serial number if available. This will allow you to sometimes tell two instances of the same device apart, like two flash drives or USB serial adapters.
I wouldn't use the device name -- if the VID and PID of two devices are the same, the devices will almost always have the same name, so using it is unlikely to make much of a difference.
Will ever be a case ever that a manufacturer has two product having same vid, different pid but same name ?
This is a slightly different question. Yes, this will happen sometimes, typically in situations where a product name is somewhat generic. (For instance, a manufacturer of flash drives will probably have many different devices all with their VID and the name "USB Flash Drive", but different PIDs.)
The Wikipedia page https://en.wikipedia.org/wiki/Universally_unique_identifier states that in version 3 (and therefore presumably 5) of the UUID spec: "Six bits are replaced by fixed values"
I am working on an iPhone app that utilises the NSUUID class. My client has asked for the ability to declare his own small fixed set of chars within the full UUID string. From what I have read thus far, I don't think this is possible - for just loads for understandable reasons - however I am obliged to ask whether there is a way, so that I can answer/deflect his questions with surety.
So is there or not, please?
Thanks in advance.
Is it possible? Of course; but unless your client's iPhone app lives in an alternate universe, perhaps your client's iPhone app would be better served by sticking to the versions described by the RFC 4122 variant.
It might be helpful to sit down with your client and explain the uuid layout. You might consider using Mahonri Moriancumer's UUID and GUID Generator and Forensics to demonstrate UUID options.
Update: In thinking this through a bit more, there is a way to add a signature to generated UUIDs...
Consider the version 1 UUID structure (RFC 4122 variant). For this type of UUID, the last 12 digits represent the MAC address of the computer's ethernet card that generated the UUID.
If you were to get the MAC address from a specific ethernet card (even an old, obsolete one), and then destroy the card, you could be assured that no other computer will ever generate a UUID (v1) using that ethernet card's MAC address ever again. Then you could use that MAC address as your "own small fixed set of chars within the full UUID string".
Then, just write your own UUID v1 generator that uses this mac address as the last 12 digits of the UUID. The rest of the UUID digits could comply with the v1 spec. The resulting generated UUIDs would be fully complient with the v1 spec, and could be identified (as a set) by the last 12 digits.
According to http://docs.unity3d.com/ScriptReference/SystemInfo-deviceUniqueIdentifier.html, SystemInfo.deviceUniqueIdentifier
It is guaranteed to be unique for every device (Read Only).
If you delete and reinstall your application, this value will change. How can it guarantee that there isn't another iPhone in the world that happened to generate the same identifier?
(I know that the identifier is pretty long so it is quite unlikely for this to happen - but I'd like to know why)
As the description says, it's typically some form of device ID, set by the vendor:
iOS: on pre-iOS7 devices it will return hash of MAC address. On iOS7
devices it will be UIDevice identifierForVendor or, if that fails for
any reason, ASIdentifierManager advertisingIdentifier.
Windows Store
Apps: uses AdvertisingManager::AdvertisingId for returning unique
device identifier, if option in 'PC Settings -> Privacy -> Let apps
use my advertising ID for experiences across apps (turning this off
will reset your ID)' is disabled, Unity will fallback to
HardwareIdentification::GetPackageSpecificToken().Id.
Even if these values were random, they come out in the same format as a GUID with 32 hexadecimal characters (128bits). The number of possibilities is rather large.
From Wikipedia:
The total number of unique such GUIDs is 2^122 (approximately 5.3×10^36). This number is so large that the probability of the same number being
generated randomly twice is negligible; however other GUID versions
have different uniqueness properties and probabilities, ranging from
guaranteed uniqueness to likely duplicates. Assuming uniform
probability for simplicity, the probability of one duplicate would be
about 50% if every person on earth as of 2014 owned 600 million GUIDs.
I ordered a bunch of NFC tags from a Chinese supplier (I know, red flags) with the promise that they will serialize my tags as instructed so it will work w/ our software and avoid serial duplicates. (Our software uses the tags' serial numbers, not the content.)
Now the thousands of NFC tags arrived and it seems they have disregarded the proper serialization, and worst, half of the darn thing are duplicates (completely unusuable for our purpose!)
So now I'm in a hole :(
So is there a software that can change NFC Tag's serial number?
Tag chip is NTAG203
No, the anti-collision identifier (UID, "serial number") of genuine NTAG203 chips cannot be changed. That serial number is permanently burned in during the manufacturing process. However, there are tags available (typically from Chinese suppliers) that behave similar to MIFARE Ultralight (and derivates like NTAG203) and permit changing the UID using special commands.
Note that genuine NTAG203 chips never have duplicate UIDs. If manufactured by NXP, they always have unique IDs. So if you encountered duplicates, its likely that those are counterfeit tags.