Does Bluetooth classic BR/EDR enable streaming of uncompressed data. The data rate is typically 32768 bits per sec. I don't want to use the RFCOMM protocol. I'm trying to find something similar to a UDP socket. You just pour bytes in one end and they come out the other end. The data will be in packets at the application layer. It is the average data rate that is important.
If so, what protocol or profile would I use?
Related
I'm working on a project that requires BLE Serial Profile.
I have successfully implemented it, but now I'm wondering what happens when server is sending data to the client, and client wants to send data back (while server is still sending). Is this handled on the low level with a queue or something similar?
Is there any risk that messages will get lost?
Thanks for any help.
Bluetooth provides the effect of full duplex transmission through the use of time division duplex (TDD). In principle transmission and reception do not happen at the same time. So in your case there is no risk of collision (loss) of data packets.
As you can see "Central" and "Peripheral" have a window of 625us during which they transmit.
For further details you can read "Timeslot" chapter of the base band specification in Core Bluetooth specification.
https://www.bluetooth.com/specifications/specs/core-specification-5-3/
I'm doing research on different communication protocols used in Internet of Things (IoT).
I'm sending "Hello" massage from one Raspberry Pi to another,because I want to measure speed, bandwidth etc.
How could I set massage size? I would like to try sending 32 bytes massages up to 4032 bytes massages.
Edit: I'm testing MQTT, AMQP and SOAP communication protocols.
Check nats.io Benchmark and Tune NATS.
It mainly focuses on nats.io but the output could be used to bench your systems against other protocols.
Here you could find more info about how it is being used for IoT.
Regarding the message size https://nats.io/documentation/faq/#msgsize:
NATS does have a message size limitation that is enforced by the server and communicated to the client during connection setup. Currently, the limit is 1MB.
I'm new for this technology, can somebody help me to know about some doubt?
Q-1. What is the size of CoAP packet?
(I know there is 4 byte fixed header, but what is the maximum size limit including header, option and payload?)
Q-2. Is there any concept for Keep Alive like MQTT?
(It works on UDP for how much time it keeps open the connection, is there any default time or it keeps open every time when we send packet?)
Q-3. Can we use CoAP with TCP?
(Main problem with it CoAP is it works on UDP, is there any concept like MQTT QoS? Let's say a sensor publishes some data every one second, if subscriber goes offline, is there any surety in CoAP that subscriber will get all the data when it come online?)
Q-4. What is the duration of connection?
(CoAP supports publish/subscribe architecture, may be it needs connection open all the time, is it possible with CoAP whether it is based on UDP.)
Q-5. How does it discover the resources?
(I have one gateway and 5 sensors, how will these sensors connect to the gateway? Will the gateway find these sensors? Or will sensors find the gateway?)
Q-5. How does sensor register with gateway?
Please help me, I really need answer. I'm all new for these kind of things and suggest me something for implementation point of view.
Thanks.
It Depends:
Core CoAP messages must be small enough to fit into their link-layer packets (~ 64 KiB for UDP) but, in any case the RFC states that:
it SHOULD fit within a single IP packet to avoid IP fragmentation (MTU of 1280 for IPv6). If nothing is known about the size of the headers, good upper bounds are 1152 bytes for the message size and 1024 bytes for the payload size;
or less to avoid adaptation layer fragmentation (60-80 bytes for 6LoWPAN networks);
if you need to transfer larger payloads, this IETF draft extends core CoAP with new options for transferring multiple blocks of information from a resource representation in multiple request-response pair (so you can transfer more than 64KiB per message).
I never used MQTT, in any case CoAP is connectionless, requests and responses are exchanged asynchronously over UDP or DTLS. I suppose that you are looking for the observe functionality: it enables CoAP clients to "subscribe" to resources and servers to send updates to subscribed clients over a period of time.
There is an IETF draft describing CoAP over TCP, but I don't know how it interacts with the observe functionality: usually It follows a best-effort approach, it just happens that the client is considered no longer interested in the resource and is removed by the server from the list of observers.
The observe stops when the server thinks that the client is no longer interested in the resource or when the client ask to unsubscribe from the resource.
There is a well-known relative URI "/.well-known/core". It is defined as a default entry point for requesting the list of links about resources hosted by a server. Here for more infos.
Look at 5.
I am analyzing the traffic beacons generate using tshark and iptraf. I know they are mainly used to determine the proximity of a device and like any other network device the traffic generated by them must be having a header and payload information in it.
What is best way to find out the payload information though header info can be identified as to where packet is being sent etc , but how we can classify the payload and what information it contains in a beacon signal , is it the same like any other web traffic sent and receive on a network or is it different since they make use of Bluetooth ?
Any pointers regarding would be useful .
Bluetooth LE beacon transmissions are much simpler than the HTTP protocol. They are transmit only and have no real headers, although there are short segments within the transmissions called PDUs that have a similar purpose.
To see an example of a beacon transmission, see my answer here:
What is the iBeacon Bluetooth Profile
I have connected two Linux Machines using netcat over WLAN using Server-Client design. And now i am able to send and receive messages between them. On the server i use UDP socket creation :
$ nc -u -l 3333
and on the client side i connect to the port using the port number and destination IP :
$ nc -u 192.168.178.160 3333
This leads to a bi-directional connection between server and client. One couldn't tell, but i guess it is quite Real-Time.
now i want to develop the functionality and try and establish a real-time speech connection between the two sides. Recording via Microphones is also feasible through arecord commands which write the speech data to a .wav file . Transmission of the .wav file is possible, only after it has been fully recorded but this is of no use since what is desired, is a Real-Time communication. Of course the received speech signals have to be instantly played back on the other end.
Has anyone any idea how to make it Real-Time?
Fidelity means a large buffer count to preserve sound continuity despite network latency and latency variation, low sound delay approximating to real time means a small buffer count to reduce overall latency. You cannot have both.
IME, you need to keep ~250ms max. of sound buffered at both ends to maintain an illusion of 'real time' speech. This queue of buffers needs to be emptied at the fixed rate necessary to reproduce the speech and kept topped-up by the network protocol as necessary. If the network latency is too low to top up buffer pools of that size, the buffer pool has to be made larger, the queue longer and the perceived real-time performance will suffer.
The TCP/UDP issue is a red-herring on most network connections.
Just be thankful that you are not streaming video:)