I am engineering two BLE devices, a central and peripheral. (Using a PSoC 4 BLE, not that it matters)
There will be a lot of these in a small space, maybe up to 8 within range, but hundreds of peripherals and tens of centrals all coming and going, with no particular rhyme or reason behind which one central/peripheral the user will want to pair at any given time.
I also have an unrelated technology that makes it very easy for the user to move a blob of data from the central to the peripheral of their choosing. I believe this will make pairing much easier in most but not all scenarios.
I figure the non-BLE blob would contain at least the central's mac address, and maybe a randomly generated pin or shared key. Because the blob can only go from the central to the peripheral, the receiving peripheral is really the only device that knows the addresses of the two devices that are supposed to connect.
However, as I understand it, peripherals can't make outgoing connections. I can't swap roles because I still need the BLE search to work the traditional way.
I can think of a lot of ways to get this done, but I'm very interested in hearing the opinion of someone who has worked with BLE long enough to know what might fit best (or if I'm wrong about some assumption).
Some constraints I'm working with:
The peripheral is battery powered.
The usual search and pair method must also still work.
My own half-baked ideas:
Make the peripheral able to be a central too, but then does that
introduce more nuances and complications?
Broadcast from the peripheral, "whoever has X mac address,
please connect to me"
Put a similar message in the advertising packet and increase advertising
rate.
Directed advertising similar to above?
You could let the "non-BLE blob" contain a static random address which the central generates. After the peripheral receives that, it starts advertising with that static random address. The central is also configured to initiate a connection to that particular static random address. Will this work?
Related
I tried looking everywhere to understand how BLE pairing works but unable to find answers. Lets say I have a small device, like a raspberry pi with a BLE dongle. What I'd like to do is to allow BLE pairing and then subsequent communication with a BLE peripheral (such as a BLE temperature sensor) using software only.
My aim is to try and see if I can control the pairing and then getting the temperature, without touching the sensor at all, so that in future, I can just remotely log into the raspberry pi, turn on bluetooth, obtain the temperature reading and then afterwards turn it off again. And in future if I need to obtain the reading again, I'll repeat the process.
So:
Can this "simple" scenario be achieved using some software based control?
If not, then which parts require manual input and then which don't?
The BLE sensor should not be in advertisement mode or broadcasting the information. It should only send the data to paired devices.
Any and all answers appreciated! :-)
Most Bluetooth low energy devices do not require pairing at all so check first that your sensors do have this requirement. If they do then you need to determine which specific pairing procedure is required. Bluetooth defines various ways to authenticate during pairing and these generally relate to the I/O capabilities of the two devices and are called Association Models. In some cases, pairing "just works" (the name of the simplest association model) and no user interaction is required. In others, say if one device has a keyboard but the other has a display and no keyboard, the second device will display a random 6 digit number and the user must key that number into the first device. All of this is defined in the Bluetooth Core specification.
In your case the pairing procedure will be defined for your sesnors in the manufacturer documentation so check there first. Not that you should only have to do this once per device, not every time you want to read the sensor.
Accessing sensor data remotely needs a gateway which I guess is what your Pi will do. The Bluetooth SIG defined a set of RESTFul HTTP APIs for exactly this purpose. See https://www.bluetooth.com/develop-with-bluetooth/white-papers
The SIG also provides a gateway developer resource for Raspberry Pi which you can download including source code which is written in node.js. See https://www.bluetooth.com/develop-with-bluetooth/developer-resources-tools
Good luck
Being somewhat of a newbie I was wondering if there is a way to hard-code something on a peripheral that would only allow a single unique central/master to connect.....?
i.e. / eg
I have the ‘simple chat’ Arduino app on a RedBearLab Blend-Micro (which is for all intensive purposes the same as a Arduino Uno with a BLE shield) and I only want one single / unique phone to BE ABLE TO connect with it and therefore work with it.
My understanding is that the GAP handles security features during a BLE connection.
Therefore, is there some way to ‘code’ the peripheral device in / below one of the following includes:
spi.h ?
boards.h ?
EEPROM.h ?
RBL_nRF8001.h (or similar) ?
Other?
Didn't quite get an answer from Restricting the BLE peripheral device to connect to only one Master
OR
Am I stuck with EVERYTHING connecting but coding the peripheral in some other way in a GATT profile (I think) to ONLY do something with a predefined unique central/master (how/where to code?).
Many thanks for thoughts in advance
Being somewhat of a newbie I was wondering if there is a way to hard-code something on a peripheral that would only allow a single unique central/master to connect.....?
Theres the "Advertising Filter Policy" as specified in the Bluetooth Core V4.0 specification. Its a Byte in the Advertising Parameters as specified in Section 7.8.5 LE Set Advertising Parameters Command.
For example the value 0x02 reads Allow Scan Request from Any, Allow Connect Request from White List Only.
Then theres section 7.8.16 LE Add Device To White List Command.
That said, if your device confirms to the Bluetooth 4.0 specification, it should support these HCI commands. However there might be functions that simplify these procedures, wrapping those HCI commands for easier use. Check the Documentation of your device for such methods.
Good Luck!
I was asked to answer this question via email. It's been almost a year since I quit working on BLE. So I only answer this question based on my memories.
Basically #dominik has it right.
If the device is freshly new, it should advertise normally (without setting the whitelist only bit), then any central device could connect and bond. Once it is bonded, you should save this bonded flag and the bonded master's bd_addr to EEPROM. If the next time the master is lost, you will advertise with that white-list-only flag set. If a new central tries to connect, you could verify if its address is the same as your master.
I don't have the BLE spec at hand and I kind of forgot a lot about BLE already. Probably the spec says somewhere that if a central sees a peripheral device is broadcasting with white-list-only flag set, it wouldn't try to connect if it doesn't recognize that peripheral device. This saves both some effort.
But a master could always initiate a connection to your peripheral device regardless the white-list-only flag. So checking if the connecting central device's address is the same as your previously bonded master is the last resort.
[Update]
I used CSR1010 chips. I remembered that the BLE stack actually allows me to insert a list of bd_addr to the white-list data structure maintained by the stack. Then, with the white-list-only flag set, the lower-level stack layer will help you filter devices that are not in that white-list without your knowing.
However, you can always filter bd_addrs from your application code.
I'm trying to understand whether its redundant for me to include some kind of CRC or checksum in my communication protocol. Does the chrome.serial and other chrome hardware communication API's in general if anyone can speak to them (e.g. chrome.hid, chrome.bluetoothLowEnergy, ...)
Serial communications is simply a way of transmitting bits and its major reason for existence is that it's one bit at a time -- and can therefore work over just a single communications link, such as a simple telephone line. There's no built-in CRC or checksum or anything.
There are many systems that live on top of serial comms that attempt to deal with the fact that communications often takes place in a noisy environment. Back in the day of modems over telephone lines, you might have to deal with the fact that someone else in the house might pick up another extension on the phone line and inject a bunch of noise into your download. Thus, protocols like XMODEM were invented, wrappering serial comms in a more robust framework. (Then, when XMODEM proved unreliable, we went to YMODEM and ZMODEM.)
Depending on what you're talking to (for example, a device like an Arduino connnected to a USB serial port over a wire that's 25 cm long) you might find that putting the work into checksumming the data isn't worth the trouble, because the likelihood of interference is so low and the consequences are trivial. On the other hand, if you're talking to a controller for a laser weapon, you might want to make sure the command you send is the command that's received.
I don't know anything about the other systems you mention, but I'm old enough to have spent a lot of time doing serial comms back in the '80s (and now doing it again for devices using chrome.serial, go figure).
I'm using Chrome's serial API to communicate with Arduino devices, and I have yet to experience random corruption in the middle of an exchange (my exchanges are short bursts, 50-500 bytes max). However, I do see garbage bytes blast out if a connection is flaky or a cable is "rudely" disconnected (like a few minutes ago when I tripped over the FTDI cable).
In my project, a mis-processed command wont break anything, and I can get by with a master-slave protocol. Because of this, I designed a pretty slim solution: The Arduino slave listens for an "attention byte" (!) followed by a command byte, after which it reads a fixed number of data bytes depending on the command. Since the Arduino discards until it hears an attention byte and a valid command, the breaking-errors usually occur when a connection is cut while a slave is "awaiting x data bytes". To account for this, the first thing the master does on connect is to blindly blast out enough AT bytes to push the Arduino through "awaiting data" even in the worst-case-scenario. Crude, yet sufficient.
I realize my solution is pretty lo-fi, so I did a bit of surfing around and I found this post to be pretty comprehensive: Simple serial point-to-point communication protocol
Also, if you need a strategy for error-correction over error-detection/re-transmission (or over my strategy, which I guess is "error-brute-forcing"), you may want to check out the link to a technique called "Hamming," near the bottom of that thread - That one looked promising!
Good luck!
-Matt
I read a lot about WiFi sensors being used to track smart phones in Retail environment. The location triangulation is done on basis that a smart phone has its WiFi turned ON, be it in connected or unconnected state.
Case 1 : WiFi turned ON but unconnected
Why should a smart phone which has its WiFi turned ON need to transmit the packets, unless the user 'scans' for nearby WiFi networks?
Case 2 : WiFi turned ON and connected
Why should a smart phone transmit any packets, unless the user is browsing the net?
In both the above cases, there is a high chance that most of the time the WiFi device does not send any packet, which means none of the WiFi sensors detect it. If that is true, then the whole idea behind WiFi sensor based triangulation in Retail goes for toss, clearly with so many companies working on this, I must be wrong. Please answer with more than a yes or no, as to which packets are generally sent in both the above scenarios.
If wifi is turned on it will periodically search for new networks. This happens even if you are already connected to one, as it allows the device to connect to a 'better' network, if available.
Scanning/network discovery can be done in two ways. First is passive when a device listens to surrounding access point's (AP) beacon frames. These are basically advertisements for their network. The second method is called active. This is the most likely explanation of how the technology you mentioned works. Active scanning is when the device sends out a probe frame asking for available APs. These are generally ones that you have associated with previously, e.g. Your home network. These probes can be listened to from nearby 802.11 (wifi) devices, therefore tracking you.
Active and passive scanning
801.11 frames
As mentioned in #AndrewLeeming answer, one of the causes for data transmission data is scanning.
It's not necessary but normally it will be performed to find a network to connect to (or a better network in case of already connected). Active scanning can be turned off for power saving reasons. Passive scanning doesn't involve transmissions, so it's irrelevant to this question.
However, the most important reason for WiFi devices to transmit packets while connected is to let the AP know that the client is still available. Otherwise the AP will drop the link after a certain period of time without activity. Additionally, the clients might be in power save mode and instruct the AP not to transmit data to them. From time to time the client will inquire the AP to see if there are any pending packets for it.
Does anyone know of a scheme whereby MODBUS addresses can be automatically set? In my situation I'll have a number of slaves power up and need some automatic way of assigning them addresses.
I know this is an old post, but I just came across this and thought I would give my answer just in case someone is attempting to do this now or in the future. If the goal is to assign a slave ID to a new slave (and you are developing the firmware for the slave devices), you can have the ID stored in a holding register that you can write a new ID to. This does require that:
You know the ID already. Maybe have all new slaves have a default ID, say ID = 1, so you know the ID beforehand.
You can only add one slave at a time and must change the ID before adding another slave to the network.
For example: Connect and power up the first slave device, which has a default ID of 1. Send a write command that will change the ID to 2 and send the master a response (using the slave ID of 1 in the response so it doesn’t timeout). Now the slave ID is 2. Next, add the next slave to the network, which it’s ID is 1. Now you have two slaves on the network with unique IDs. Just repeat as many of times that you need to.
Are you talking about SLAVE ID's? If so, that's just not going to happen... The SlaveID is vitally important for the Client to be able to address said slaves on the serial network. (RS485 serial network, presumably...).
So, there is no way to even send out a Modbus message and address it to SlaveID 1, and then somehow get that device to be SlaveID 1, because ALL of the devices would attempt to respond, in that case. Not to mention, there is NO method in Modbus to ASSIGN a Slave an ID... On the flip side of this...
Are you talking about performing some type of query to ask the slave devices which Modbus REGISTERS they have? Again, there is no Modbus way to do this, but with some code, you COULD query 40001, and if you get an error 2 back, then you know that register is not available. If you then loop through all of the registers, keeping track of which ones returned non-error, well--then you COULD do a form of "auto-configure", but... In all honesty? I would NOT recommend this, and I don't see a lot of value to even DOING this, because you not only have to know the REGISTER numbers, you have to know WHAT THE DATA IN THE REGISTER ACTUALLY MEANS!
What exactly are you trying to do anyway? Perhaps there is another way to accomplish this goal?
What you think you want: automatic Slave ID assignment in Modbus RTU.
What you actually want: constant, common Slave ID with Modbus TCP.
In a nutshell, all your Modbus Slave ID's get set to a fixed, common value and then you bridge them with a TCP stack that supports things like link-local addressing or DHCP. Then the TCP address assignment can be dynamically handled while preserving a constant SlaveID for each unit.
There are three broad options here depending on what hardware you already have:
There are commercial off-the-shelf devices (such as this) that can emulate TCP over RTU. I've not delved too deep into what they support and how well they work.
You could also add a whole ton of TCP to RTU bridges which will have built-in management for the TCP/IP layer and then use real Ethernet cabling. For a lot of devices, this could get expensive fast, but with Ethernet you have all sorts of bonus features like basically unlimited distance and improved CRCs. If you're looking to do this on the cheap, grab a dual-port Linux SBC (such as this or this) and throw mbusd (from here) on it.
If you have access to or are developing the firmware yourself, you could adapt something like uIP (simpler) or lwIP (faster) to communicate over RS-485 (UART). This would certainly be the cheapest option. Note that you should also have the ability to detect collisions on RS-485 to implement an IP stack correctly -- this involves echoing the receiver at all times and checking that the data-in and data-out match.