In CSMA, a sender device postpones sending a wireless data while other devices send their wireless data. That is why even the UDP datagram packets are delayed on Wifi router with many mobile devices.
I am interested to finding a way of shortening the delay. With a hypothesis "Even though other devices does not lower their network usage, device A will get lesser round-trip latency if A takes lower network usage.", I did an experiment. (described below) Fortunately, my assume seems to be right by the test result.
In my guess, other interfering devices keep their networking usage so that CSMA delay may not decline, but the possibility of interfering might decline, thus the delay might be affected. But I cannot figure out the reason anymore. I am not a hardware engineer.
Is my hypothesis right? If so, what is the reason?
Devices: An Wifi router, Device A(wireless laptop) and device B(wireless laptop)
Device B: exchanges data of 10 MB/sec with another wired computer
Device A: sends ping-pong UDP packets to another wired computer
Device A:
<Server>
When receives a UDP datagram D from S via port 12345:
Send D to S.
<Client>
For every 1 millisecond:
Send 20 bytes of data to Server:12345.
Device B: just use iperf for massive traffic generation.
Test times: 5 times * minutes
The result:
Device A sends 1000 times per second: ping-pong latency is 130 ms
Device A sends 300 times per second: ping-pong latency is 40 ms
Remark: High deviation.
Related
When the device is in confirmed mode, it waits for a downlink confirmation (ACK) from the network after each uplink. If the confirmation is not received by the device, it will repeat (up to a maximum of 8 times and increasing the SF of the UL if it was lowered before) the uplink until it receives a confirmation. It may take about 30 seconds to send the 8 repetitions.
If the device does not see a confirmation and needs to send another uplink (e.g. alarm or new periodic measurement), it will send the new uplink and forget the previous one. To operate in confirmed mode, the device must be declared in confirmed mode (or ACK) on the network platform. You can activate it via the IoT configurator in the network parameters
Be aware that this operation consumes much more battery power than a traditional operation, even more, if the network quality is poor.
If the transmitter loses a lot of frames, it would be better to reposition the transmitter (if possible) or the GW (if possible) to improve the transmission rather than activating the ACK which will drain the battery faster than "expected" depending on the network condition.
Is this answer correct or not?
I use an iPhone as a peripheral to communicate with a micro controller (BLE chip in question is the BGM113). After connecting from the MCU, the MCU sends a couple of read and write requests for characteristics serially. Each request takes only a few ms in the MCU. On the iPhone side, responding to each request also only takes a few ms in the relevant methods (peripheralManager:didReceiveWriteRequests: and peripheralManager:didReceiveReadRequest:).
Still, I have roughly 500ms delay between each request. I have a support request running with the bluetooth chip manufacturer to clarify, but my gut feeling tells me that the fruity company is to blame...
Can anyone confirm such delays when reading or writing characteristics?
(more details: all characteristics are in the same service, read and write may happen on the same characteristic serially, there are several characteristics that I operate on.)
Your delay will be between 1 and 2 times the connection interval, so you set the connection interval to match your maximum delay requirement. Note that the energy consumption for the radio is linear to the inverse of the connection interval though.
I have a quick question regarding BLE packets with iOS.
Say I have an iPhone app that sends out BLE advertising packets once a second in the background. This same app is also configured to receive advertising packets in the background. Say there are 30 other devices running this same app within Bluetooth range of the original device. Is there a theoretical maximum to the amount of packets any one device can receive within a given time interval? Could the app receive and process all the advertising packets from the thirty phones, or even 100 phones? Thanks for your help!
Depends on peripheral advertising speed/interval. If you have 20 ble device around ios device and start scan.
Then first get nearest device and which devices who advertising interval is fast.
Well the BLE advertisements run at 1 MBit/s so that means one microsecond per bit.
In an advertisement packet the overhead is, on top of the advertisement data, the address of 6 bytes and then 10 bytes extra for BLE header and CRC.
If two packets are transmitted by two devices at the same time, they will interfere and possibly none of these packets can be detected at all.
With this information you should be able to calculate the rest of the Math yourself.
I am looking at speeding up the connection time between my iOS application and the peripheral.
I have looked up Apples Documentation on the subject: https://developer.apple.com/library/content/qa/qa1931/_index.html
Originally (prior to reading the doc above) I had the advertising interval set to 2 seconds to, what I had thought would be, a good compromise between power consumption and connection time. Having read the documentation further I have changed the interval to 1285 ms.
#define ADVERTISING_INTERVAL 2056 ble_obj.setAdvertisingInterval(ADVERTISING_INTERVAL);
The device is always discovered quickly by the app but the problem comes when trying to connect.
However, I have seen no increase in speed in connection time between my application and the peripheral device. Connections between the devices can take anything from 3-4 seconds up to 30+ seconds.
Is there something I am missing? Either on the peripheral or the central side?
Peripheral BT chip is the Nordic Semiconductor NRF51822.
On examining the devices advertisement packet on the Nordic Semiconductor app I can see that the advertisement interval normally varies from 1275 ms to about 1295 ms (as expected? due to the random time added to the advertisement packet)
NOTE
Have also tried with an advertising interval of 152.5 ms and am still not seeing any major improvement in connection speed. I am , obviously, seeing a marked improvement in speed of discovery
What you observe is normal. Don't expect fast connection setup with an advertising interval of more than a second.
Core Bluetooth uses a high duty scan window/interval for the initiation the first seconds. If it doesn't connect then it continues to scan with much more power restrictive parameters.
Description - How I can get the number of BLE connection in iOS.
I want to restrict a user to add more BLE sensor after a particular number of BLE connection. I want to get the number of a BLE connection a device can handle.
A connection represents state, not traffic. The count of connections will be bound by either memory or the data structures used by the Bluetooth stack to manage them, both unknown. My answer is, "As many as it can and no more."
Packets represent traffic and each is handled one at a time. From this perspective, my answer is, "One."
However, if a packet cannot be processed out of the critical paths in the chip and protocol stack fast enough to begin processing the next packet, packets can be dropped. Experience has shown these critical paths in iOS are dependent on the traffic's packet size and rate. Additionally, other devices in the area not connected to your BLE stack may be flooding the radio spectrum and causing packet collisions outside the stack. I have seen BLE traffic go to hell with an excess of 20 connections and as few as one. From this perspective my answer is, "It depends."