Hi Dialog,
We've done same GAP_GEN_DISCOVERY scan tests. When set the transmitted ADV packet interval great than 111 us , almost 100% ADV packets can be scanned, however, if set the packet interval to 111 us, only about 60% packets can be scanned.
Is there any way to support more shorter interval such as 50 us?
谢谢,Peter
Device:
Hi Peter Luo,
According to the Bluetooth LE core specifications, the advertising interval (advInterval) shall be an integer multiple of 0.625ms in the range of 20ms to 10485s. Can you please share the advertising interval configuration (user_adv_conf structure)?
谢谢,PM_Dialog
Hi Dialog,
Yes, according to the Bluetooth LE core specifications, you are right, but when two or more advertisers send advertising packets randomly, something will be changed.
For example,
When only one advertiser sends an advertising packet with 31 bytes payload per second, the transmitted air time is 47*8=376 us, the minimal and maximum packet interval is about 1,000,000-376=999,624 us, it's an enough time for all scanners to receive all advertising packets correctly.
When two advertisers both send an advertising packet with 31 bytes payload per second, the minimal packet interval will change to a range from 0 us to (1,000,000-376-376)/2= 499,624 us when luckily no overlying happened.
When three or more (such as 100) advertisers send advertising packets randomly, the situation becomes more complex.
Obviously, the scanner with lower packet interval (such 50 us) support will get good performance, the scanner with only higher packet interval (such as 1000 us) support will get poor performance.
In order to simulate two or more advertisers, we’ve made a DIY device, its RF radio provides a parameter to change packet interval, it can be set very short value.
We want to make an ideal cheap scanner to scan all packets without loss, and try to recover the packets with CRC error. Although some expensive SDR devices can do this very well, it is out of our consideration.
DA14xxx对我们来说是一个不错的选择,现在的112 us minimal packet interval support is also acceptable, but we still hope the RF receiver can support shorter packet interval.
谢谢,Peter
Hi Peter Luo,
I am reading again your initial post and you had mentioned that the packet interval to 111 us. What do you mean the packet interval? Do you mean the interval between the Tx of each advertising channel? Or do you mean the connection interval? How did you calculate the min and the max interval?
谢谢,PM_Dialog
Hi Dialog,
The packet interval discussed in here is a time between two continuous packets in air in a same channel (such as 37).
When our DIY device, not a standard BLE, just a simulator for a lot of BLEs in a same place at same time, transmits adv packets with a 112us interval on channel 37, the DA14585 scanner can receive almost 100% packets from DIY device. If change the interval from 112us to 111us, just 1 us decreased, the performance of DA14585 scanner drops quickly, only 60% packets can be received. Some other similar BLE under same condition, can receive almost 100% packets from DIY device even the interval was set to a value under 100us.
About min and max interval, please kindly see the attachment.
Because of some unique advantages, we still want to use DA14xxx.
谢谢,Peter
Hi Peter,
Can you please indicate how you changed the packet interval that you have mentioned? Are you using the device under DTM (Direct test Mode) and you are testing the Continues Tx in Channel #37 ?
谢谢,PM_Dialog
Hi Dialog,
Yes, we are testing the Continues Tx in Channel #37 with a user defined packet interval parameter through our self-software, the transmitted packet is standard advertising packet with 31 bytes payload.
The low-level hardware of our DIY device provides a register for definition of time interval between two consecutive packets, it includes the time needed to turn on and turn off the radio, and the time needed to keep the radio in idle status.
In order to emulate the worst situation may happened in reality, we not obey the Bluetooth specification strictly, try to set the packet interval as short as possible.
谢谢,Peter