just found it again in \Wiced-Smart\tier2\brcm\libraries\inc\additional_advertisement_control.h
/// Allows the app to register a callback that will be invoked just before an ADV is packet is about
/// to be sent out and again, immediately after.
/// \param clientCallback Pointer to a function that will be invoked in the application
/// thread context with ADV_NOTIFICATION_READY for before ADV and
/// ADV_NOTIFICATION_DONE after ADV packet is complete.
/// \param advanceNoticeInMicroseconds Number of microseconds before the ADV the notification is
/// to be sent. Will be rounded down to the nearest 1.25mS. Has to be an even multiple of 625uS.
void bleprofile_notifyAdvPacketTransmissions(void (*clientCallback)(UINT8), UINT32 advanceNoticeInMicroseconds);
Let me just go and check that I can actually call it.
It builds when I add
APP_PATCHES_AND_LIBS += additional_advertisement_control.a
to the Makefile. I have not gotten it to work yet if you have further information about it please let me know.
I'm using it similarly as in mybeacon.
1 of 1 people found this helpful
you are on the right path. see mybeacon sample.
Playing with mybeacon I found that the callback is not called when I use undirected advertisments. Is there a way around this? For completeness here is the code:
#define HCIULP_ADV_INDIRECT 0x00
// Configure P0 as active high input to pause advertisements.
// bleprofile_configureGpioForSkippingRf(GPIO_PIN_P0, GPIO_PIN_INPUT_HIGH);
// register with LE stack to be called 2.5msec before the advertisement event
// Set TX power for advertisement packets at 4dBm
//bleapputils_changeLPOSource(LPO_MIA_LPO, FALSE, 500);
// Start advertisements
HCIULP_ADV_INDIRECT, // non-connectable undirected advertisement
160, // adv interval 100 msec
HCIULP_ADV_CHANNEL_MAP_MASK, // all channels
HCIULP_PUBLIC_ADDRESS, // int advAdrType,
HCIULP_ADV_FILTER_POLICY_WHITE_LIST_NOT_USED, // int advFilterPolicy,
HCIULP_PUBLIC_ADDRESS, // int initiatorAdrType,
NULL); // UINT8* initiatorAdr
I will see if one of the developers can respond.
what is HCIULP_ADV_INDIRECT
1 of 1 people found this helpful
I think, HCIULP_ADV_INDIRECT is the value used on ADV_PDU, PDUtype
(Host Controller Interface Upper Layer Parameter ...)
0 = connectable, undirectional, 1 = connectable, directed
why the comment there says "non-connectable undirected"? value should be 2 then?)
Helpful from Internet:
Playing with mybeacon?: a beacon has just broadcast, just Tx )no Rx and therefore no callback? It should never be able to receive, shoudn't it?
(and the advertisment PDU on a beacon should be ADV_NONCONN_IND (0010) as mention in this doc.?
0x00 might be wrong for a beacon?) - not familiar really.
Thank you very much, very helpful info. Highly appreciated.
1 of 1 people found this helpful
All my wisdom comes from here:
Also to explain why I was trying to use the bleprofile_notifyAdvPacketTransmissions() callback, I posted a message
explaining that Advertisments stop at some point in my application. I have found that the crystal start up is not the cause
for the issue I have been seeing, so I was attempting to work around it. My main goal was to run a certain advertisment for a sub-second period by using the bleprofile_Discoverable() call in a timer callback to start and stop advertisments. I wasn't able to get this to work without the advertisments failing to restart after a while.
Just a short while ago I heard about:
and I think victorz mentioned that there is a state machine involved that controls advertisments. So I'm using blecm_setAdvEnable()
now to control advertisments and don't use bleprofile_Discoverable() anymore.
Before that I tried to not stop the advertisments (because the issue went away with that) and to just modify them in advance, the callback would have helped even though I could have just changed the advertisments from the fine timer callback now that I'm thinking about it.
So ultimately I have a solution I'm happy with right now. That the undirected advertisments don't work with the bleprofile_notifyAdvPacketTransmissions() callback is not so important to me anymore. I also didn't try to hammer out a demo of the bleprofile_Discoverable() not working.
Is it this here (in wiced_sense.c) ?:
const BLE_PROFILE_CFG wiced_sense_cfg =
/*.fine_timer_interval =*/ 50, // ms
/*.default_adv =*/ NO_DISCOVERABLE, // current sensor is not discoverable
/*.button_adv_toggle =*/ 0, // pairing button make adv toggle (if 1) or always on (if 0)
/*.high_undirect_adv_interval =*/ 32, // slots
/*.low_undirect_adv_interval =*/ 1024, // slots
/*.high_undirect_adv_duration =*/ 10, // seconds
/*.low_undirect_adv_duration =*/ 10, // seconds
/*.high_direct_adv_interval =*/ 0, // seconds
/*.low_direct_adv_interval =*/ 0, // seconds
/*.high_direct_adv_duration =*/ 0, // seconds
/*.low_direct_adv_duration =*/ 0, // seconds
/*.local_name =*/ "WICED Sense Kit", // [LOCAL_NAME_LEN_MAX];
BTW: changing such struct init to C99/ANSI C syntax would be nice:
(where you can do:
member_name = value;
instead of implicit knowing on old syntax, "the member index X is ..." and heaving all initialization values in the right sequence as a must ... - quite odd)
It would be more obvious which struct member is meant, comment not so important anymore to tell you what is struct member here on X's init value, also independent if struct would be changed (re-ordered members !) ...
Could we go with more modern style of coding? --C99 on command line and C syntax in files ?
Could we code with GNU C99 language style, sometimes?
Notice that I talked about SDK2.1.1 without any WICED sense additions. Looking at the fragment you provided I would say that WICED Sense is based on one of the SDKs. In the fragment you can indeed set the Advertisment duration, however only in second granularity. Because I want to transmit data in the advertisments I would like to be able to shorten the period to possibly get a higher data rate.
I see. Sorry, not familiar, WICED/FW might answer.
(I think, I will give up to play with the kit, even all is exciting to overcome all issues, but my live time is limited)
Fortunately I'm paid for it, also I see BLE as a work in progress where we all have to push a little bit to iron out bugs. If you look at Androids BLE implementation you will find out that the situation there is similar/worse but hopefully improving.
EDIT: Oh! So you are an SE based in Irvine where Broadcom is based and have been called JT by somebody else! So is this mention
of WICED-Sense a hint that I should look there for something potentially interesting. About this life thing, I'm working on it.
Looking at my configuration:
/*.high_undirect_adv_duration =*/1, // seconds /*.low_undirect_adv_duration =*/1, // seconds /*.high_direct_adv_interval =*/0, // seconds /*.low_direct_adv_interval =*/0, // seconds
I could see why directed advertisments don't work, but I never was interested in them so much. The identical duration and maybe the small value for the undirected ones could be an issue.