Device A and Device B advertising some measurement data every 10 Seconds. Every hour Device A has to exchange some data with Device B. So on Device A I change the role to a Master - scan for Device B - connect to Device B - exchange Data - change role back to advertiser.
In average it needs 5 sec for the Scan and 10 sec for the connect.
Is it possible the connect directly (the BD address is always the same) without the scan ?
I have to save battery energy on both devices us much as possible.
Keywords:
Device:
you can call the direct advertising mode function.
check in sdk5 , you can set the BD address in
static const struct directed_advertise_configuration user_directed_advertise_target_address_conf = {
/// BD Address of device
.addr = {0x1,0x2,0x3,0x4,0x5,0x6},
/// Address type of the device 0=public/1=private random
.addr_type = 0
};
Thanks,
I still need the possibility to see the advertising data (measurements) by other hosts and the direct advertising will hide it to others (as far as I know).
On the scope it looks like that during the scanning the first advertising triggers the connecting and the second advertising does the connection.
Perhaps a scanning white list will help to avoid the second delay or is the white list only a filter ?
Hi R.Ganter,
The connection sequence doesn't require two advertising messages in order to estalish a connection, after the central gets the first advetising message it responds with a connection request and you should not see any advertising after the connecion request from the central is sent. Regarding the white list on a central, it limits the advertising indications at the application level depending on the db address of the advertiser.
Thanks MT_dialog
Hi MT_dialog
A test with a minimal modified DSPS v_5.150.2 sps_host project shows that the connection is delayed by one advertisement !
My slave device 80:EA:CA:67:05 is advertising every 4 sec.
The central 80:EA:CA:67:06 needs to receive the first advertisement to change from scanning to connecting (only listening and no 2.4 Ghz TX activity) and one advertising later it send out the connect to the slave.
I tested it several times with a Scope, RF power meter, and with a BLE sniffer.
modification in "user_device_host.c" :
void user_on_adv_report_ind(struct gapm_adv_report_ind const * param)
{
// if(!memcmp(¶m->report.data[3], USER_ADVERTISE_DATA, USER_ADVERTISE_DATA_LEN))
if(!memcmp(¶m->report.adv_addr.addr, "\x05\x00\x67\xCA\xEA\x80", 6)) //!RG!
{
arch_printf("Connect with %02x %02x %02x %02x %02x %02x",
param->report.adv_addr.addr[5],
param->report.adv_addr.addr[4],
param->report.adv_addr.addr[3],
param->report.adv_addr.addr[2],
param->report.adv_addr.addr[1],
param->report.adv_addr.addr[0]);
app_easy_gap_start_connection_to_set(param->report.adv_addr_type, (uint8_t *)¶m->report.adv_addr.addr, MS_TO_DOUBLESLOTS(USER_CON_INTV));
user_gapm_cancel();
}
}
Hi.
Directed advertising does just mean that the advertisement packet includes the target address. Each scanner will filter away advertisement packets that are directed that does not match its own address.
If you have set up the procedure to first be scanning and once you find your peripheral, then initiate a connection, then that will require two advertisement packets. A connect request can only be sent in direct response to an advertisement packet. If you have code in the CPU that handles the advertisement packet and then switch to initiating state, that code will take too long and the advertiser has already gone back to sleep since it didn't receive anything in response to its advertisement packet.
如果你想联系的人,只有一个乱发广告tisement packet you need to skip putting the master into scanning state and instead directly go to the initiating state, i.e. start connect directly and don't start scan. Since you always connect to the same peripheral, this should be the way to go.
Note that scanning and initiating a connection are both energy-consuming states. For both of those, you have to define a scanning window and scanning interval that defines how often and how long the radio will be active listening for incoming advertisement packets. While the radio is active, it consumes 5 mA. If you have an advertisement interval of 4 seconds, the expected time the scanner must have its radio on before it finds the advertisement packet is 2 seconds. If you know that the peripheral will always be nearby, there is no point having the scanning window smaller than the scanning interval in order to trying to save energy. You will rather use the same amount of expected energy but instead waste time.
当广告,收音机必须只有几个milliseconds to send its three advertisement packets and then it will sleep rest of the time, so advertising consumes way less energy than scanning. With that in mind, depending on your setup, if you would like to save energy on your master you should have a shorter advertisement interval on the peripheral. Since you do this every hour, device A should know when an hour has passed and the device B probably will start trying connect to A. That way A can use a shorter advertisement interval when an hour has passed. But of course, if you are OK with the master have to have its radio on for approximately 2 seconds every time it wants to connect, you can continue to have an advertisement interval of 4 seconds...
Thank's a lot for the detailed description.
So YES is the answer for my initial question.
After changing the role to master I connect directly without a scan. In average it will take 1/2 the advertisement interval. To balance the average power consumption between device A (advertiser) and B (master) I calculated the optimum advertising interval = 3.8 sec:
Qadv = 10 uAs // Consumption per advertising event
Iscan = 5000 uA // Current consumption for scan
Tadv = ? // advertising interval
Tscan = 3600 s // average time between scans = 1 h
Msc = 0.5 // relation = scan-duration / adv-interval
Average advertising current (device A) = Qadv / Tadv
Average scanning current (device B) = Iscan * Tadv * Msc / Tscan
Tadv = SQRT ( (Qadv * Tscan) / (Iscan * Msc) ) = SQRT ( (10 * 3600) / (5000 * 0.5) ) = 3.8 sec
So device A has an additional current of 10uAs / 3.8s = 2.63 uA
and device B 5000uA * 3.8 * 0.5 / 3600 = 2.64 uA