我们在下面测试了两个雪彩酸：
答：使用Connection Manager +（SDK）Monitor_fe_usb进行测试
B: test with the scan code developped based on smarttag ref design codes
both A and B run with dialog BLE USB dongle seperately to scan some BLE node which keep always advertising...
test result:
with A: by clicking "scan" button of connection manager, each time the log window can quickly(say within ~1 second printing on screen) report/print advertise data by the BLE advertising node
with B: we set breakpoint at first line within gapm_adv_report_ind_handler();
then click the run button in Keil.
each time click "run", it just take 1 seconds to 10 seconds(it just differs for each "run" to get the
广告数据扫描并停止在断点。）
in our application:
- 我们有以下配置为扫描模式配置：
空白app_scanning(空白)
{
// create a kernel message to start the scanning
struct gapm_start_scan_cmd * msg =（struct gapm_start_scan_cmd *）ke_msg_alloc（gapm_start_scan_cmd，task_gapm，task_app，gapm_start_scan_cmd）;
// Maximal peer connection
msg->mode = GAP_GEN_DISCOVERY;
// msg->mode = GAP_OBSERVER_MODE;
msg->op.code = GAPM_SCAN_ACTIVE;
msg->op.addr_src = GAPM_PUBLIC_ADDR;
msg-> filter_duplic = scan_filt_duplic_en;
msg->间隔= 10;// app_scan_interval;
msg->窗口= 5;// app_scan_window;
// Send the message
ke_msg_send(msg);
}
void app_configuration_func（ke_task_id_t const task_id，struct gapm_set_dev_config_cmd * cmd）
{
// Operation select
cmd->操作= gapm_set_dev_config;
// Device Role
cmd->role = GAP_CENTRAL_MST;
//Defined maximum transmission unit
cmd->max_mtu = 160; //APP_CFG_MAX_MTU
}
- in gapm_cmp_evt_handler(), we have below lines to make it keep scanning.
case GAPM_SCAN_PASSIVE:
案例Gapm_scan_active：
{
app_scanning();
}
We do not know what is about the connection manager "boot as Central" procedure, but the test result is so different ( the connection manager scan the node quickly...but our codes scan the node so slow...), pls suggest what is the major issue with it and how we should fix it.
谢谢！
Hello Alex, i have assined this to our local team in China to follow up with you. Best regards, JE_DIalog
Not yet fix it...
We tested below further:
Connection Manager + CM firmware Scan get advertise data quickly ( within 1~2s each scan);
Host app + Monitor_fe_usb Scan get advertise data slow ( from 1s~10s each scan ）
SPS_Host Scan get advertise data slow ( from 1s~10s each scan ).
(in the tests, we set the advertise node adv_interval to 20ms and 100ms seperately, but make no difference with the test results)
So it looks for SDK or reference design example software(Monitor, SPS), the scan is slow. for CM, it's quick.
We'd need quick scan in our application, so please help suggest what we should do.
谢谢！
It's one week past...we do would like get some help here.
in other words, we need a guidance on how to SCAN the peer broadcasting ADV_DATA within short time(say 500ms?)...or is it feasible or not?
You could try to change your scan window/interval.
扫描窗口是实际扫描的时间有多长时间，而扫描间隔是在扫描窗口的每个开始之间等待的时间长度，即扫描间隔减去扫描窗口是每次扫描之间睡眠的时间。如果设置扫描窗口等于扫描间隔，则使用缺少广告数据包的最低可能性扫描。当然，这消耗了更多的电流。
要求是扫描窗口<=扫描间隔。
Try to set your scan window to something like 50 instead of 5.
Also, the time for discovery will also depend on your advertisement interval on the peripheral. A lower advertisement interval means lower discovery times but uses more current from your battery on the peripheral.
Thank you Joacimwe...it's fixed after I set interval to 1362 and window to 1320. Pls close this ticket.
We did more tests...below parameters set in the test:
Advertise side:
-: adv_interval = 0x20; // we do not change the value 0x20 after this initialization ; we also tried 0x40, 0x100, etc.
-: cmd->op.code = GAPM_ADV_UNDIRECT;
cmd-> op.addr_src = gapm_public_addr;
cmd->intv_max = adv_interval;
cmd->intv_min = adv_interval;
cmd->channel_map = APP_ADV_CHMAP; //0x07;
cmd->info.host.mode = GAP_GEN_DISCOVERABLE;
扫描侧：
-: we tried different window/interval settings:
// msg->间隔= 10;// app_scan_interval;
// msg->窗口= 10;// app_scan_window;
// msg->interval = 1336; //APP_SCAN_INTERVAL;
// msg->窗口= 1320;// app_scan_window;
msg->interval = 100; //APP_SCAN_INTERVAL;
msg->window = 100; //APP_SCAN_WINDOW;
-: in gapm_adv_report_ind_handler(), we will cancel scanning; in gapm_cmp_evt_handler(), we restart scanning;
in most test cases (say 8 out 10 tests, we change adv data each time, so to read the scan data update ), the scan can get the adv within 1 second, but it will still need 2 seconds or more time to successfully scan the adv data.
We need each peripheral adv data update to be scanned by central within 1 second ( 500ms will be better ), pls kindly suggest any other approaches we can try to get improved? thank you.
我会更加欣赏guidance to improve...thanks!
请帮忙...谢谢！
the problem still pending...Just need factory guidance/advise, pls kindly support. Thanks!
你好亚历克斯，我将安排当地的人联系.. Br Je_Dialog