Is it possible to send some notification messages to the nearby Bluetooth devices without pairing.I have found some protocol for these - OBEX Oject Push. But am not clear whether is is feasible without pairing request .Any demo apps for reference?
Yes and no.
If you are actually talking about connecting but not pairing, then, yes.
If you are talking about no connection at all, then no.
When creating a Bluetooth connection between two or more devices the following steps are taken.
Inquiry – If two Bluetooth devices know absolutely nothing about each other, one must run an inquiry to try to discover the other. One device sends out the inquiry request, and any device listening for such a request will respond with its address, and possibly its name and other information. The closest located device is not necessarily the fastest to respond and any device that hears the call will try to respond.
Paging – Paging is the process of forming a connection between two Bluetooth devices. Before this connection can be initiated, each device needs to know the address of the other (found in the inquiry process).
Connection – After a device has completed the paging process, it enters the connection state. While connected, a device can either be actively participating or it can be put into a low power sleep mode.
• Active Mode – This is the regular connected mode, where the device is actively transmitting or receiving data.
• Sniff Mode – This is a power-saving mode, where the device is less active. It’ll sleep and only listen for transmissions at a set interval (e.g. every 100ms).
• Hold Mode – Hold mode is a temporary, power-saving mode where a device sleeps for a defined period and then returns back to active mode when that interval has passed. The master can command a slave device to hold.
• Park Mode – Park is the deepest of sleep modes. A master can command a slave to “park”, and that slave will become inactive until the master tells it to wake back up.
Two devices can be bonded together through a one-time process called pairing. When two devices are paired, they store each other’s addresses, names and profiles in memory, allowing them to automatically establish a connection as soon as they are in range of each other.
It is not possible to send OPP (or other) communication between two devices before connecting.
It is possible to send communication between two devices after connection but before pairing.
Related
I'm working on a project involving a linux embedded device with CAN bus-support.
I've noticed that if I try to send a CAN-packet without having anything attached to the CAN-bus, the transmit is automatically reattempted by the kernel an unlimited number of times. I can verify this using a scope - the same message is automatically transmitted over and over. This retransmission persists even if I shut down the process which created the message, and even if this process only ever attempts to transmit one single message.
My question is - is this normal behaviour for a linux CAN bus kernel? My worry is that if there is ever something wrong in the device, and it erroneously concludes that it is alone on the bus, the device might possibly swamp the bus making it unusable for other bus participants. I would have expected there to be some sort of retry-limit.
The device is using linux 4.14.48, and the can-chip is Philips SJA1000.
What you are seeing is likely error frames. Compliant behavior is this:
Node is active. It attempts to send a data frame but get no ACK bits set since nobody is listening to it.
It will send out an error frame, which pretty much only consists of 6 dominant bits to purposely break bit stuffing.
The controller will re-attempt to send the message. If a new attempt to send without receiving ACK is done, another error frame will be sent. This will keep repeating automatically.
After 128 errors, the node will go error passive, where it will still send error frames, but now with recessive level where it doesn't disrupt other traffic.
After a total of 256 errors, the node will go bus off and shut up completely.
This should all be handled by the CAN controller hardware, not by the OS. You might need to reset or power cycle the SJA1000 once it goes bus off. If it never goes bus off, then something in the driver code might be continuously resetting the CAN controller after a certain amount of errors.
Mind that microcontroller implementations might act the same and reset upon errors too, since that's typically the only way to re-establish communication after a bus off. This depends on the nature of the CAN application.
Short answer is yes - if ACK is the only TEM error the counter will stop at 128 and not go into BUS OFF. It will go forever. This happened to me as well and I just turned off the re-transmit function from the processor side. Not sure if that is a CAN standard function or not.
I just got a Bluetooth LE/Smart bathroom scales (Model Sanitas SBF 70). I can read data from it using the following command:
gatttool --device=(btaddr) -I
connect
Then when I stand on it, I get multiple notification messages like this:
"Notification handle = 0x002e value: e7 58 01 05 e9"
where the last two bytes are is the mass in 50g increments.
I'd like to integrate this into a few application using a TCP or UDP socket service that broadcasts these messages to any listening clients.
But after some research I have no idea what's the best way to stay connected all the time (the connection times out after a few minutes). Or alternatively to be able to re-establish a connection when the scales is used (I notice lots of activity from 'hcitool lescan' whenever someone steps on the scales).
I don't care what language / library is used. If I can push this to a TCP/UDP socket it will be trivial for other applications to consume the information.
The answer is straightforward: You don't.
Your scale is most likely battery powered. Therefore the Bluetooth communications will only be enabled for a short period of time after having measured your weight. Your application just needs to try connecting to the scale over and over (catch any "unable to connect timeouts") until you step on it. And when connected get the data from it before BLE is shut down again. In pseudo code:
while true:
while not_connected:
try to connect
receive notifications
disconnect
gatttool wrapped by the python module pygatt is perfectly usable to solve this chalenge.
In my case scale data (preceding 30 weights) is transferred after enabling indications of 3 different characteristics.
From BT snoop log below, found BLE central device and peripheral device got connected after a few loops of negotiation about
connection parameters, include connection interval, connection latency and supervisor timeout etc.
As found in bt snoop log, the connection interval will be set to 1 second, my question is:
Why not found the connection between them disappear 1 second later after they connected?
What’s the real meaning of connection interval?
As you know BLE has a pillar that is to be low energy consumption.
The main rule is turn on the radio as little as possible and turn off the radio as soon as possibile.
When a connection is established the radio signal isn't always active even when a peer want to transmit. The transmission phase has the radio turns on and off more times.
The connection interval is the time between two connection event and inside each connection event there is packets transmission.
Suppose the peer wants to transmitt 10 packets : the radio signal is on for packets transmission (max 6 packets) then turned off for a time that is the connection interval ... now 6 packets are transmitted. After connection interval, the radio is turned on to transmit tha last 4 packets and so on.
The connection interval can be from 7.5 ms and 4 s and it depends on both peers.
Of course, lesser connection interval means high baud rate transmission but more power consumption and vice versa.
Paolo.
BLE is a radio communication protocol that work in the 2.4GHz spectrum.
If you measure the radio current on a CRO, while it is in a connection, you will get a graph something similar to shown above.
The peaks indicate that radio is turned ON. Between the peaks the device is sleeping to save power.
To put it simply, connection interval is the time interval between the peaks.
Meaning it is the time for which the device sleeps after sending a packet and then wakes up to send a packet again.
This timing is synchronized between the two communication devices. It is like two people agreeing to meet at a particular time and place.
I'm working on a server architecture for sending/receiving messages from remote embedded devices, which will be hosted on Windows Azure. The front-facing servers are going to be maintaining persistent TCP connections with these devices, and I need a way to communicate with them on the backend.
Problem facts:
Devices: ~10,000
Frequency of messages device is sending up to servers: 1/min
Frequency of messages originating server side (e.g. from user actions, scheduled triggers, etc.): 100/day
Average size of message payload: 64 bytes
Upward communication
The devices send up messages very frequently (sensor readings). The constraints for that data are not very strong, due to the fact that we can aggregate/insert those sensor readings in a batched manner, and that they don't require in-order guarantees. I think the best way of handling them is to put them in a Storage Queue, and have a worker process poll the queue at intervals and dump that data. Of course, I'll have to be careful about making sure the worker process does this frequently enough so that the queue doesn't infinitely back up. The max batch size of Azure Storage Queues is 32, but I'm thinking of potentially pulling in more than that: something like publishing to the data store every 1,000 readings or 30 seconds, whichever comes first.
Downward communication
The server sends down updates and notifications much less frequently. This is a slightly harder problem, as I can see two viable paradigms here (with some blending in between). Could either:
Create a Service Bus Queue for each device (or one queue with thousands of subscriptions - limit is for number of queues is 10,000)
Have a state table housed in a DB that contains the latest "state" of a specific message type that the devices will get sent to them
With option 1, the application server simply enqueues a message in a fire-and-forget manner. On the front-end servers, however, there's quite a bit of things that have to happen. Concerns I can see include:
Monitoring 10k queues (or many subscriptions off of a queue - the
Azure SDK apparently reuses connections for subscriptions to the same
queue)
Connection Management
Should no longer monitor a queue if device disconnects.
Need to expire messages if device is disconnected for an extended period of time (so that queue isn't backed up)
Need to enable some type of "refresh" mechanism to update device's complete state when it goes back online
The good news is that service bus queues are durable, and with sessions can arrange messages to come in a FIFO manner.
With option 2, the DB would house a table that would maintain state for all of the devices. This table would be checked periodically by the front-facing servers (every few seconds or so) for state changes written to it by the application server. The front-facing servers would then dispatch to the devices. This removes the requirement for queueing of FIFO, the reasoning being that this message contains the latest state, and doesn't have to compete with other messages destined for the same device. The message is ephemeral: if it fails, then it will be resent when the device reconnects and requests to be refreshed, or at the next check interval of the front-facing server.
In this scenario, the need for queues seems to be removed, but the DB becomes the bottleneck here, and I fear it's not as scalable.
These are both viable approaches, and I feel this question is already becoming too large (although I can provide more descriptions if necessary). Just wanted to get a feel for what's possible, what's usually done, if there's something fundamental I'm missing, and what things in the cloud can I take advantage of to not reinvent the wheel.
If you can identify the device (may be device id/IMEI/Mac address) by the the message it sends then you can reduce the number of queues from 10,000 to 1 queue and not have 10000 subscriptions too. This could also help you in the downward communication as you will be able to identify the device and send the message to the appropriate socket.
As you mentioned the connections last longer you could deliver the command to the device that is connected and decide what to do with the commands to the device that are not connected.
Hope it helps
Isochronous endpoints are one way only. But single isochronous IN transmission is described in various sources (eg. here http://www.beyondlogic.org/usbnutshell/usb4.shtml#Isochronous) as one IN token packet (from host to a device) followed by one DATA packet (from a device to the host). So I see communication in both directions here. Is the token packet from the host received by the same IN isochronous endpoint which then sends the data?
What is synchronization for? HERE : http://wiki.osdev.org/Universal_Serial_Bus#Supporting_Isochronous_Transfers we read : "Due to application-specific sampling rates, different hardware clock designs, scheduling policies in the operating system, or even physical anomalies, the host and isochronous device could fall out of synchronization." But how? I understand the sequence of events like this : device fills its outgoing buffer with data, and waits for the token (some interrupt probably). Host sends the token packet, and waits for the data packet, which (I think) should arrive instantly. Sequence is repeated every frame (#F.S.) and everybody is happy. Isn't the token packet synchronizing the reply from the device?
Here http://wiki.osdev.org/Universal_Serial_Bus#SYNC_Field we read : "All USB packets start with a SYNC field which serves, unsurprisingly, as a synchronization mechanism between the receiver and the sender." So once again I ask : why to synchronize isochronous transfers in another manner than this?
All USB transactions are always initiated by the Host. E.g. for an isochronous IN transaction the Host will ask the device for the next piece of data first. This is of course a data flow to the device, but on a lower protocol level (Token Packets). So a kind of control data is send TO the device, but the meaningful data (Data Packts) is only sent FROM the device (IN direction). When you develop software for a device you can often abstract away the Bus Protocol details, because they are handled in hardware (USB device peripheral). The low level messages do not enter an endpoint. Endpoints are on a higher layer.
Consider a USB microphone: It records audio data with a very specific sample rate which is based on the local oscillator of the device. It's only a matter of time that the clock of the Host and the microphone will drift. After a few minutes a gap in the data would appear (or a buffer overflow will occur) because the microphone is recording data at a slightly different speed then the USB is expecting it (from the device's configuration descriptor). So they need some kind of synchronization.
The SYNC field is on the lowest Layer. It is for bit synchronization only and should not be confused with the synchronization for isochronous endpoints (2.)
You might want to take a look at the official USB 2.0 Specification (usb_20.pdf) instead of all the third party wikis which kind of confused you.