Can anyone tell me what major and minor (contained within the advertisement packet of BLE signals) are used for? I've heard that it's used for differentiating signals with the same UUID, but that raises questions like "why use two" and "is that just how certain receivers use it". It would be useful to have a decent explanation of it.
As per #Larme's comment, I presume you are asking about iBeacon advertisements - these are a special use of BLE. Bluetooth Low Energy service advertisements have a different format and don't include the major/minor.
The iBeacon specification doesn't say how to use major and minor - this is defined by the people that implement solutions using iBeacon. Two numbers just gives more flexibility.
A lot of effort went into making BLE use very little power. Accordingly the iBeacon advertisement has to be quite small in order to minimise the transmission time. I guess the designers decided two 16 bit numbers was a reasonable compromise between power consumption and a useable amount of information.
A typical retail use case could use the major to indicate a store (New York, Chicago, London etc) and the minor to indicate the department (shoes, menswear etc). The app that detects a beacon can then pass this information to a server which can send back relevant information - the user's location on a map or specials for that department etc. This was discussed in the guide that #Larme linked to.
A solution that presented information on museum exhibits might just use the major number to determine which exhibit the person was near and ignore the minor number. The minor number would still be in the advertisement, of course, the app just wouldn't use it for anything.
Related
My professor recently approved our research paper which will also be used in our final year thesis. Basically our main purpose is to create a system for location tracking and attendance automation for students and staffs. We would like to use the power of bluetooth low energy modules for this project.
I have actually done quite few research about this but I am having trouble which keywords to use in order for me to filter the right answers for my question. So instead, I'll just put all my questions here.
I provided an image to further understand the concept I am talking about.
Basically, the broadcaster/advertisement mode modules are for students and staffs. While the observer mode modules are initially installed in every rooms or spaces in our building/campus.
Broadcast and Observer mode
I would like to clarify first that the location tracking is only basic, it only detects which rooms are the students and staffs located.
Here are my questions:
What is the maximum advertisement/broadcaster module can the observer module detects at the same time?
Our target is about 50 students per room, 300 students in cafeteria, will the observer module have a large amount of latency upon scanning advertisement packets?
Do we have to use different module for observer mode, or will the same module for broadcaster mode be just fine?
Since this is supposedly embedded to school IDs, we would like to use a coin cell battery, how long will it last?
According to my research, BLE range is about 100 meters, but we will be using coin cell battery, is it really possible to achieve 100m for broadcasting and observing? If it is, can we perhaps decrease it by programming?
My apologies for too much question, as this is actually our first time doing applied hardware stuffs due to pandemic. Most of our laboratories are basically tinkercad base. Face-to-face classes are allowed for only medical students for now.
A few answers:
BLE scanners can detect hundreds of distinct broadcasters at the same time. There is no hard limit, but the more broadcasters the longer it will take the scanners to detect each broadcaster.
Most BLE modules support both peripheral mode (broadcaster) and central mode (scanner) simultaneously.
Scanning 50 broadcasters in a single room will easily detect 90% of packets, so if the advertiser is going at 1 Hz it will usually take one second to detect, but sometimes 2-3 seconds of packets are missed.
The indoor range is closer to 40 meters with no walls obstructing the signal. Outdoors with clear line of sight the range is higher. Walls often block signals almost entirely, depending on materials.
A CR2032 coin cell can power a BLE broadcast at 1 Hz and max power for about 30 days.
Creating an embedded solution is cool and valid but just remember that broadcasters already exists as each and every student carries a smartphone with BLE embedded into it and your observer can be any BLE capable device from smartphone through PC with BLE dongle all the way to Arduino and alike.
Your broadcasters (or BLE peripherals as they should be called) will need an Android / iOS app and you will have to deal with working in the background without the operating system stopping your app.
Your observer (or Central in BLE language) can be any stationary PC if such exists in the class which can make development and deployment a lot easier.
I'm currently working on a project that requires gathering data from a car's wheel speed sensors(4 hall efect speed sensors). Those sensors are connected to the car's ECU responsible for ABS/ESP/Stability control etc.
In order to extract the data from the ECU i need to make a request with a specific PID(parameter ID) AND know how to decode/compute the answer in order to extract any meaningful data. Unfortunately vehicle manufacturers don't seem to make such information public.
So far i've ordered an arduino CAN BUS shield and a OBD2 to RS232 cable in order to make the physical connection.
I have tried using a specialized hardware/software(that costs more than 1500euro) capable of extracting those parameters, but unfortunately it lacks logging functions. I tried using Wireshark to sniff the PIDs called, but had no luck there either.
If you guys have any ideas, questions or suggestions, please write them down.
I'm open to criticism and know that i might be missing something important.
Thanks.
P.S. This is a university project im working on. I need data samples from the wheel speed sensors and further computing of the data sample is done with the purpose of researching car safety and behavior in dynamic road scenarios.
You can only read the OBD data from the OBD-port. The OBD PIDs are generalized in ISO/CD 15765-5. You probably find non reliable descriptions also in Wikipedia. But in order to get the other PIDs, firstly you should know that those data are heavily under control by the car manufacturers and you have to hack them. One way to find them (but very unlikely to find one!) is the try and error method.
You should access the main CAN-BUS wires and the buy a connector device so you can sniff the packets. then monitor all the packets and make a small change. Monitor it again and compare these two. Maybe maybe maybe you have a chance to find some non-safety features with this method but finding security functionalities like ABS is heavily in doubt.
UNLESS you are some sort of genius hacker who can do weird stuff! If you can do it, then call the manufacturer and show them what you have so you would likely get a nice job and salary by them!
ONCE I saw a youtube clip that a guy could control a TOYOTA (if I remember correctly) with a laptop! and also maybe you can buy such info on the dark web which I advise highly against it!
I am aware of current Ethernet Technology and it's non-deterministic behavior, due to CSMA-/CA/CD. I also see a lot of news around Time Sensitive Networking.
Could anyone briefly explain how TSN could change or enhance timing, synchronization, how is it related to IEEE 1588(PTP) etc ?
Your question is way too broad, but anyway...
First:
All Ethernet link these days are full duplex, so collision avoidance such as CSMA-/CA/CD are a thing of the past since about 15 years I would say: Ethernet is not a shared media (like is air for Wi-Fi), and there simply isn't any collision, so no need to avoid it. Did you get that "non-deterministic because of CSMA-/CA/CD" from a book or teacher? Then those would need a serious update.
(And so no, the collision risk and its avoidance mechanism is not the cause of "current Ethernet Technology and it's non-deterministic behavior", especially not with the word "current".)
Then:
About TSN (Time Sensitive Networking): TSN is just the new name for an IEEE 802 task sub-group that was first called AVB for "Audio Video Bridging", as you can see from here (2005 or 2008 to 2012):
http://www.ieee802.org/1/pages/avbridges.html
Note: The Audio/Video Bridging Task Group was renamed the
"Time-Sensitive Networking Task Group" in November, 2012. Please refer
to that page for further information. The rest of this page has been
preserved it existed at that time, without some obsolete meeting
information.
The change was made to reflect its now broader perspective: not only for Pro Audio/Video distribution use, but also to automotive, and latter industrial applications as well. So the work continues here:
http://www.ieee802.org/1/pages/tsn.html
As a result, you'll actually find most information about the fundamentals of TSN by googling "Ethernet AVB" rather than "Ethernet TSN". The wikipedia page, carefully maintained by people directly involved with the technology, is a good start:
https://en.wikipedia.org/wiki/Audio_Video_Bridging
Also, as with every technology, there is a technical side, that's the IEEE AVB->TSN group, and there is a marketing side, taking care of branding, use-cases, and (very important) certification programs to label and guarantee the interoperability of products, to have a healthy ecosystem. For AVB/TSN, this marketing side is handled by the AVnu Alliance SIG (Special Interest Group), founded in 2009:
http://avnu.org/
There too, you can find a lot of information in the knowledge base section of the web site (technologies, whitepapers, specifications, FAQs): why was it made (what is the problem to solve), how does it work, what are the use cases in the various fields it targets.
Some final words:
AVB/TSN it is not a single protocol, but rather a set of protocols, put together with possible variants according to the use case. Example: originally designed with auto-configuration/plug and play' built in (geared towards sound engineers, without the need for network engineers), its automotive profile rather use static configuration (because of reduced boot and configuration time, lesser code/hardware for reduced cost embedded devices, and you're not going to change a car networking topology nor roles of the nodes everyday anyway).
And that makes a BIG pile of standards: the base IEEE AVB standards put together, the last one published in 2013 IIRC, where already about 1,500 pages, and TSN is now expanding that. Distribution of a common wall-clock to participants, which is a prior need to synchronization, with sub-microsecond range of precision, is a big, complex problem in itself to start with . Be it with a static clock device reference ("PTP master") in IEEE 1588, and even more with a elected, and then constantly monitored and possibly re-elected GM ("Grand Master) via a BMCA (Best master clock algorithm) as in IEEE 802.1AS.
Also, all this require implementation not only in the end nodes, but also in the switches (bridges), which takes an active part in it at pretty much every level (clocking, but also bandwidth reservation, then admission and traffic shaping). So part of the standards are relevant to nodes, others to the bridges.
So all this is really quite big and complex, and going from 1,500 pages (which I once read from cover to cover) - and it's now more than that - to "briefly explain how TSN could change or enhance timing, synchronization, how is it related to IEEE 1588 (PTP) etc ?" is a bit challenging... especially the "etc" part... :-)
Hope these few pointers help though.
I'm trying to set up a practical DIY method of unlocking a garage or front door by coming into the range of a reader; even if that means standing in a specific line of sight. Essentially once I reach the garage, the ID is read and raises
I'd prefer to have passive ID's, but the reader itself would be able to have a fixed power source that doesn't need to be changed.
I've done a lot of searching on google and there are RFiD scanners that read cars to open tolls booths, but those are commercial grade products and much more expensive than anything I'm trying to make. Should I continue looking into RFiD's, or is there a more efficient method of approaching this?
Also, if my tags are active, and powerful enough, would that compensate for a low frequency reader?
You'll easily achieve to read passive tags from a distance of a few meters (up to 10m) by using any industrial UHF RFID reader (Impinj, ThingMagic, Stid, ...).
Some tags are similar to labels that can be directly stuck on the windscreen of the cars. Tags are rather inexpensive.
But in that case you will need to spend a few hundreds of dollars to buy a single reader with its antenna.
That is what makes me think that any RFID based system is an option only when the number of users of the system is quite important (i.e: check the access to a company park or to a residence).
In that case, the investment of the reader is dispatched on all the users, whereas the global investment for the tags stay low.
Background
Sweden is transitioning to a compulsory law for all business owners handling cash or card transactions, to implement/buy partially-encrypted POS (point of sale)/cash registers:
Signing and encryption are used to
securely store the information from
the cash register in the control unit.
The control system with a certified
control unit is based on the
manufacturer for each control unit
model obtaining a main encryption key
from the Swedish Tax Agency. The
manufacturer then uses the main key to
create unique encryption keys that are
placed in the control unit during the
manufacturing process. In order to
obtain main encryption keys,
manufacturers must submit an
application to the Swedish Tax Agency.
Source SKV
This has caused somewhat of an uproar among Swedish traders because of the necessitated complexity and strong encryption to be used, along with a highly sophisticated technical implementation from the shop owner's perspective, as the alternative is to buy the system from companies who have traversed the documentation, gotten their security keys and built the software and integrated it into the hardware.
So my first question is if any other countries in the world even comes close to the preciseness that the Swedish Tax Agency requires of its companies (alongside having extensive guidelines for bookkeeping)?
I'd like to hear about any other encryption schemes of interest and how they are applied through legislation when it comes to verifying the transactions and book keeping entries. Examples of such legislation could be similar to another Swedish rule; that book keeping entries (transactions) must be write-only, at most written 4 days after the occurrance and only changeable through a tuple of (date, signature of person doing it, new bookings).
Finally, what are your opinions on these rules? Are we going towards all-time uplinks for book keeping + POS systems to the tax agency's servers which verify and detect fraudulent patterns in real-time similar to the collective intelligence algorithms out there or will there be a back-lash against the increased complexity of running business?
Offhand, I can't think of anywhere else in the world that implements this strict of a requirement. However, some existing POS systems may implement this sort of encryption depending on what the definition of "control unit" is and where the differentiation between "control unit" and "cash register" lies.
The reason I say this is because many POS systems (at least the ones that I've worked with) are essentially a bunch of dumb terminals that are networked to a central database and transaction processing server. No data is actually stored in the cash register itself, so there is only a need to encrypt it on the server side (and over the wire, but I'm assuming a secure network protocol is being used). You would need to get a lawyer to interpret what exactly constitutes a "control unit", but if this can be defined as something on the server side (in a networked POS case like this) then the necessary complexity to implement such a system would not be too onerous.
The difficult case would be where each individual cash register requires a unique encryption key, whether to encrypt data to be stored inside the register itself or to encrypt data before sending it to a central server. This would require a modification or replacement of each cash register, which could indeed prove costly depending on the size of the business and the age of the existing equipment. In many countries (the US in particular), mandating such an extensive and costly change would likely have to be either accompanied by a bill providing funds to businesses (to help pay for the equipment conversion) or written in a manner more like "all Point-Of-Sale equipment manufactured or sold after {{{some future date}}} must implement the following features:". Implementing rules that place expensive burdens on businesses is a good way for politicians to lose a lot of support, so it's not likely that a rule like this will get implemented over a short period of time without some kind of assistance being offered.
The possibly interesting case would be the "old-fashioned" style of cash registers which essentially consist of a cash drawer, calculator, and receipt printer and store no data whatsoever. This law may require such systems to start recording transaction information (ask your lawyer). Related would be the case where transactions are rung up by hand, written on a paper ticket (like is commonly done in some restaurants and small stores in the US). I often find it amusing how legislation focuses on such security for high-tech systems but leaves the "analog" systems unchanged and wide open for problems. Then again, Sweden may not be using older systems like this anymore.
I'm not sure exactly what US law requires in terms of encrypted records, but I do know that certain levels of security are required by many non-government entities. For example, if a business wants to accept credit card payments, then the credit card company will require them to follow certain security and encryption guidelines when handling and submitting credit card payment information. This is in part dictated by the local rules of legal liability. If a transaction record gets tampered with, lost, or hijacked by a third party the security of the transaction and record-keeping systems will be investigated. If the business did not make a reasonable effort to keep the data secure and verified, then the business may be held at fault (or possibly the equipment manufacturer) for the security breach which can lead to large losses through lawsuits. Because of this, companies tend to voluntarily secure their systems in order to reduce the incidence of security breaches and to limit their legal liability should such a breach happen.
Since device manufacturers can sell their equipment internationally, equipment complying with these Swedish restrictions will likely end up being used in other places as well over time. If the system ends up being successful, other businesses will probably volunteer to use such an encrypted system, even in the absence of legislation forcing them to do so. I compare it to the RoHS rules that the EU passed several years ago. Many countries that did not sign the RoHS legislation now manufacture and use RoHS-certified materials, not because of a legal mandate but because they are available.
Edit: I just read this in the linked article:
Certified control unit
A certified control unit must be
connected to a cash register. The
control unit must read registrations
made by the cash register.
To me, this sounds like the certified control unit attaches to the register but is not necessarily connected to it (or necessarily unique to a register). This definition alone doesn't (to my non-lawyer ears) sound like it prohibits existing cash registers from being connected over a network to a certified control unit on the server side. If so, this might be as simple as installing some additional software (and possibly a peripheral device) on the server side. The details link may clarify this, but it's not in English so I'm not sure what it says.
These types of requirements are becoming more and more common across most of Europe (and to a lesser, but increasing, extent North America). I'm not sure exactly which Europe-based banks are moving fastest on this, but in North America one of the front-runners is First Data (who have already made available the fully-encrypted POS devices like you describe needing).
I would further postulate that most merchants will not develop systems internally that do this (due to the PCI requirements, and challenges in doing so), but will instead rely on their merchant providers for the required technology.