My question is not related to the software, but to the technology. I think BLE is the solution to my system, but I am not sure how it works, how the pairing works.
I am projecting a system with 4 devices, each one with some sensors.
Devices A1 and A2 have same sensors, they are independent each other and read different data. If one of them read a critical value, it makes a noise.
Devices B1 and B2 have same sensors, they are close and are dependent each other. I mean, I need to know if the value of B1 is higher than B2 or viceversa. The device with the higher value makes a noise.
---- ------------ ----
|A1| ------> |smartphone | <----- |B1| <--|
---- ------------ ---- |
^ ^ |
---- | | ---- |
|A2| ----------| |----------- |B2| <--|
---- ----
These devices are all close by each other, and will synchronize later, just at the end of the day, to a smartphone to store all the data read.
How can I make the connectivity among sensors and smartphone?
I need to make communicate B1 and B2, to know who has the higher value.
Then I need to make communicate all of them to a smartphone to collect data.
Is one chip Bluetooth Low Energy for each device enough ? Can I use the same chip to communicate between devices, and with the smartphone (in different moments) ?
I am not sure about the pairing process... should I need to associate and disassociate devices to the smartphone each time? Or it's better to have B1 as master with 2 chips BLE, one for the smartphone and one to communicate do B2?
BLE requires that one device be a server, the other the client, in order to establish a connection. You cannot have a server talk to a server, or a client talk to a client. However, devices can implement both server and client protocols.
If B1 and B2 are identical, and they only implement either server or client interfaces, then they cannot talk to each other. If you have design control over B1 and B2, you can design them to implement both server and client protocols and then automatically talk to each other to update each one on who has the higher value. However, I wonder why you need to have them talk to each other at all - why can't the smartphone get both B1 and B2 values, then decide which to keep? It could then also send a command to B1 or B2 to make the noise.
A single BLE chip can manage many connections, since BLE connections are very temporary (and, if the internal software supports it, it may be able to handle multiple simultaneous connections).
If the decision about which I would have B1 and B2 simply include their measurement data in their advertising packet, and then have both listen to the others advertising packets. In this case, there is no need to establish any negotiated connection at all - each device is just running a BLE "nearby devices" scan continuously. Then, when the smartphone comes by, they can each establish a negotiated connection with the phone independently and upload their data.
Related
I want to implement a P2P protocol in C for personal education purposes.
What would be the protocol with the shortest specification that is still used today?
I have already implemented a web and IRC client and server.
I agree with Mark, that point to point over a serial link would be a good exercise.
In particular, I would recommend the following programme of stuff...
Implement basic transmission over a "Serial Port" (using RS-232 if you have some Arduinos/embedded processors lying around, or using a null modem emulator if you don't (see com0com on Windows, or this on linux/mac).
I.e. send lower case letters from A->B, and echo them back as upper case from B->A
Implement SLIP as a way to reliably frame messages
i.e. you can send any string (e.g. "hello") and it is returned in upper case with "WORLD" appended ("HELLOWORLD").
Implement the "Read Multiple Holding Registers" and "Write Multiple Holding Registers" part of the Modbus protocol, using SLIP to frame the messages.
I.e. you have one follower (slave) device, and one leader (master) device. The follower has 10 bytes of memory that are exposed over modbus with the initial value "helloworld".
Just hard-code the follower / leader device Ids for now.
The leader reads the value, and then sets it to be "worldhello".
At the end of this you would start to have an understanding of the roles of network layers, ie:
The physical layer - Serial/RS-232
A "link layer" of sorts - SLIP
An "application" layer - Modbus
Serial. The answer is serial. You're not going to get any leaner than simple RX/TX communication but you'll lack a lot of convenience methods. If you want to explore more than simple bidirectional comms, I2C or modbus open up a lot of options.
I'm dealing with the following challenge. In my system, there are two devices. Tags and anchors. Tags have BLE module with the transmit power 0dBm and not Long Range feature (BLE 4.0). Anchors have BLE module with transmit power over 8dBm and Long range feature (BLE 5.0).
I want tags to only receive some commands. Bi-directional communication is not necessary. This way, I can utilize the transmit power of anchor (8dBm) and thus quite bigger range, if tag with 0dBm is only receiving.
I read something about Observer/Broadcaster principle, where connecting is not necessary. But somehow devices have to agree on what frequencies should they hop on, the step and so on.
I'm asking, is it possible for device to only receive commands without previous negotiation with the sender?
Thank you very much for help. I'm beginning with BLE standard and there is a lot to learn.
Yes, it is possible to send data via adverts/scanning only. This way, there's no connection that needs to be established, and therefore no connection parameter negotiation takes place. As for the frequency hopping agreement - this happens via the baseband (in other words you will not deal with this in the software yourself) and is generally not applicable for advertising/scanning (these happen on 3 frequency channels only and therefore it is likely that the observer will catch what the broadcaster is broadcasting).
However, keep in mind that because you are broadcasting/advertising the data as opposed to directly sending it, that data can be received by any observing/scanning BLE devices which is not desired for safety/security/privacy purposes.
For more information on BLE communication, I recommend the links below:-
Getting Started with Bluetooth Low Energy
Is it Possible to Send Data with BLE Broadcast Mode
I'm implementing a LIN protocol on a Linux SBC that transmits over a UART. I don't have time to develop a complete LIN stack, so I'm just implementing a frame structure for messages as defined by the protocol. The problem is that the protocol requires a "Break" field which makes the slave devices on the bus listen. This field consists of zeros for 13 bit-times. Any ideas how to send zeros 13 bit-times over UART, when serial data transmission requires complete bytes?
Per Wiki:
LIN (Local Interconnect Network) is a serial network protocol used for
communication between components in vehicles. The need for a cheap
serial network arose as the technologies and the facilities
implemented in the car grew, while the CAN bus was too expensive to
implement for every component in the car. European car manufacturers
started using different serial communication topologies, which led to
compatibility problems.
If you would have paid attention at class you would have known that:
Data is transferred across the bus in fixed form messages of
selectable lengths. The master task transmits a header that consists
of a break signal followed by synchronization and identifier fields.
The slaves respond with a data frame that consists of between 2, 4 and
8 data bytes plus 3 bytes of control information.
You should just send an echo of 0x0000 following by CR/LF.
I want to broadcast several BTLE beacons, preferably from a single bluetooth LE radio dongle.
Instead of buying multiple dongles, would it be possible to "pulse" say 5 UUID, major and minor broadcasts very quickly - every second or even half second on loop so that it would appear there were 5 beacons to a device?
I imagine it would depend on the scanning rate of the handset and other factors... but could it theoretically work?
Yes, you can do this. On iOS devices, I have only been able to switch identifiers once per second, making it only practical to simulate transmitting two iBeacons simultaneously without getting CoreLocation exitedRegion callbacks.
See: Can I broadcast multiple ibeacon signals from only one bluetooth? and how
Other BLE capable devices may allow faster switching.
I am designing an information kiosk and need a BT application which can automatically push a file to the nearest BT enabled device assuming that this would be the phone of the person currently standing in front of the kiosk.
Is there any other ways of doing this except by checking the RSSI (Received Singal Strength Indicator)?
Do all Bluetooth stacks support accessing this property?
How accurate is RSSI as the basis for the decision to which device to push to? Can it be that other phones which are further away from the kiosk can emit a stronger signal than the signal coming from the phone of the guy standing right in front of the kiosk?
Not all stacks support RSSI.
There's an alternate way: the device who first answers to Inquiries should have a stronger signal.
Your guess is true, it only depends on signal strength, not distance.
Also, the device with the stronger signal is not necessarily the one which answers first, since implementations of the protocol are different among devices. Thus you would have to test all target devices separately.