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.
Related
I bought one of these:
https://www.aliexpress.com/item/Smart-finder-Key-finder-Wireless-Bluetooth-Tracker-Anti-lost-alarm-Smart-Tag-Child-Bag-Pet-GPS/32806261079.html
As far as I can tell it is a BLE (Bluetooth Low Energy) location tag.
I downloaded the app for it onto my iphone, and the app instantly recognised it and connected to it. The iPhone app seems to know how far away the tag is - it has a little map of the local area and says how many feet away. I was able to set the device name via the app, but I'm not sure if that set it locally or on the tag itself. The iPhone app also has a "find" button - when you press it, the tag beeps.
So I want to know how I can program this thing myself. I want to be able to identify it when it is nearby, connect to it and make it beep. I've searched for quite a while but not come up with much.
I'm assuming (wrongly/rightly?) that there is some general standard or approach for talking to these BLE location devices and carrying out the basic functions with them - but what is that standard - where is the documentation?
Does anyone have any idea how to program these BLE location tag devices?
BLE devices typically communicate using GATT, either using standard GATT services, or custom ones. The command to make it beep is probably implemented using a custom GATT service.
For finding out the distance to the beacon, typically the RSSI is used. This is a measure of the received power. It needs to be compared to the output power at the emitter. Usually beacons will put their output power in advertisement data, so it can be used without connecting to them. Here since the app is also able to send commands to the beacon, chances are it keeps a connection to it and has a custom GATT protocol to retrieve the output power.
Here is what I would suggest:
Read up on BLE, especially advertising and GATT. For instance read this for advertising and this for GATT. The full BLE spec is available here but should be used for reference and not introduction
Sniff the communication between your device and your phone. You can see this other answer of mine to get started
Replicate the communication protocol in you own app. For that you'll need to use your target platform's BLE libraries. For instance for iOS it is CoreBluetooth
I have been reading answers on stackoverflow for a while now and this is the first time I actually am required to ask a question:
I have a small sensing device (literally a black box) which is used during sporting activities and is tracking acceleration and GPS data (not necessarily with the same frequency, according to a patent from the vendor). After a session, one can connect the device to a smartphone and import the session data to view statistics.
Now I am trying to acquire the raw data to apply some own statistics onto it.
I know that the device connects to my phone via Bluetooth. So I activated the Bluetooth HCI snoop log following this tutorial:
http://www.fte.com/WebHelp/BPA600/Content/Documentation/WhitePapers/BPA600/Encryption/GettingAndroidLinkKey/RetrievingHCIlog.htm
I can then transfer the files by renaming them into .cap files on the PC and load them into wireshark. This is where it gets tricky:
I have found out, that the first connection is established via Bluetooth low energy. When the connection is established and the user has selected to download a session from the device via the app, the connection switches to a normal Bluetooth connection.
I know that the device contains a GPS and a 9-axis accelerometer including a Gyro.
Apparently the Bluetooth protocol to transfer data is the SPP protocol (https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles#Serial_Port_Profile_.28SPP.29), used to simulate a RS-232 connection.
I have attached a screenshot from wireshark showing a reassembled data packet. I do not know what it contains and the rendering from Wireshark does not make any sense to me. The frame content is displayed in the bottom most tab. The left is the raw HEX transmission, the right shows the rendered version. It neither looks like any GPS sentence (http://www.gpsinformation.org/dale/nmea.htm), nor like any accelerometer data:
The general setting is an encryption-less connection, but at some stage the host and controller try to switch to an encryption, but this never gets transmitted to the peripheral slave (as far as I can see). I am wondering how to make sense of this data, whether there is a way for me to find out whether an encryption is activated and if it is, is it logged and can I retrieve the key from this log?
Can anyone help me to figure out the data here or tell me where I can find some hints about whether it is encrypted or not?
Edit:
I have added a screenshot from the first SPP transmission packet. The packet in question and the payload are marked in black. It seems to contain some information about device and other configuration settings or initial values for the sensors at the beginning. I suspect the app and the device to have settled on a proprietary scrambling or encrypting, since there are readable values at the beginning, but not after that black box marked in the image. My suspicion is, that bluetooth encryption is not being used at all and I therefore stand no chance of decrypting the information at all? Can someone confirm or deny this suspicion?
where I can find some hints about whether it is encrypted or not?
What you see in Wireshark is the HCI interface (commands and events) between Host and Controller. Since encryption is done in the controller (see Bluetooth Core spec. Vol. 1 Part A Section 5.4.3), what you see is unencrypted data.
Can anyone help me to figure out the data here
It's hard to understand from your single screenshot. I suggest you take a look at the RFCOMM specification, Figure 6.1 in paricular:
In the Information field you should find your data.
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?
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
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.