CC2640R2F: Does removing 32khz rtc clock affects the broadcasting interval of Simple broadcaster.

Hi Ankit,

What do you mean by "facing the issue of delayed broadcasting"? You set the value at 10s and what is the value now?

Can you provide me your advertisements parameters?

Does the advertisement interval is the one you set if you keep the external crystal?

Feel free to find the TI SimpleLink Connect App on both OS Android and iOS.

TI SimpleLink Connect on Apple App Store

TI SimpleLink Connect on Google App Store

regards,

facing the issue of delayed broadcasting means ,initially it broadcasts at 10000ms or 9997ms, but after few hrs or days sometime it broadcasts at 14s, sometimes 20 seconds and so on.

i am using the simple broadcaster example as it is. just modified the broadcasting interval in simple_broadcaster.c and commented/disable the scan response data 

// What is the advertising interval when device is discoverable (units of 625us, 160=100ms)
#define DEFAULT_ADVERTISING_INTERVAL          16000//8000

static void SimpleBroadcaster_init(void)
{
	// ******************************************************************
  // N0 STACK API CALLS CAN OCCUR BEFORE THIS CALL TO ICall_registerApp
  // ******************************************************************
  // Register the current thread as an ICall dispatcher application
  // so that the application can send and receive messages.
  ICall_registerApp(&selfEntity, &syncEvent);

  // Hard code the DB Address till CC2650 board gets its own IEEE address
  //uint8 bdAddress[B_ADDR_LEN] = { 0x33, 0x33, 0x33, 0x33, 0x33, 0x33 };
  //HCI_EXT_SetBDADDRCmd(bdAddress);

#ifdef USE_RCOSC
  RCOSC_enableCalibration();
#endif // USE_RCOSC

  // Create an RTOS queue for message from profile to be sent to app.
  appMsgQueue = Util_constructQueue(&appMsg);

 // Util_constructClock(&periodicClock, SimpleBroadcaster_clockHandler,
   //                    SBP_PERIODIC_EVT_PERIOD, 0, false, SBP_PERIODIC_EVT);
  // Open LCD
 // dispHandle = Display_open(SBB_DISPLAY_TYPE, NULL);

  // Setup the GAP Broadcaster Role Profile
  {
    // For all hardware platforms, device starts advertising upon initialization
    uint8_t initial_advertising_enable = TRUE;

    // By setting this to zero, the device will go into the waiting state after
    // being discoverable for 30.72 second, and will not being advertising again
    // until the enabler is set back to TRUE
    uint16_t gapRole_AdvertOffTime = 0;

#ifndef BEACON_FEATURE
    uint8_t advType =  GAP_ADTYPE_ADV_NONCONN_IND;//GAP_ADTYPE_ADV_SCAN_IND; // use scannable undirected adv
#else
    uint8_t advType = GAP_ADTYPE_ADV_NONCONN_IND; // use non-connectable adv
#endif // !BEACON_FEATURE

    // Set the GAP Role Parameters
    GAPRole_SetParameter(GAPROLE_ADVERT_ENABLED, sizeof(uint8_t),
                         &initial_advertising_enable);
    GAPRole_SetParameter(GAPROLE_ADVERT_OFF_TIME, sizeof(uint16_t),
                         &gapRole_AdvertOffTime);



  //  GAPRole_SetParameter(GAPROLE_SCAN_RSP_DATA, sizeof (scanRspData),
    //                     scanRspData);


    GAPRole_SetParameter(GAPROLE_ADVERT_DATA, sizeof(advertData), advertData);

    GAPRole_SetParameter(GAPROLE_ADV_EVENT_TYPE, sizeof(uint8_t), &advType);


  }

  // Set advertising interval
  {
    uint16_t advInt = DEFAULT_ADVERTISING_INTERVAL;

    GAP_SetParamValue(TGAP_LIM_DISC_ADV_INT_MIN, advInt);
    GAP_SetParamValue(TGAP_LIM_DISC_ADV_INT_MAX, advInt);
    GAP_SetParamValue(TGAP_GEN_DISC_ADV_INT_MIN, advInt);
    GAP_SetParamValue(TGAP_GEN_DISC_ADV_INT_MAX, advInt);
  }

  // Start the Device
  VOID GAPRole_StartDevice(&simpleBroadcaster_BroadcasterCBs);

  Display_print0(dispHandle, 0, 0, "BLE Broadcaster");
}

Hi Ankit,

According to the Bluetooth specs : Core Specification | Bluetooth® Technology Website

Between two advertising events we have the advertising interval + advertising Delay this one could be between 0ms to 10ms.

So for instance, let's say our interval is 30ms,

- Advertisement 1 is delayed by 30ms + 2 ms

- Advertisement 2 has no delay so it's now 30ms -2ms "delay", when in reality it wasn't delayed at all, but because the previous advertisement was delayed it appears that way

Does that makes sense to you?

So after hours or day of advertising the time between two advertisements could change a bit.

To avoid this problem, you can stop and restart advertising, it should resynchronise the adverting interval.

Regards,

Hello Guillaume,

Thanks for the suggestion, can u tell me which functions to be used for stopping and restarting the advertisement and where to call these functions. i am using BLE stack with Simplelink_cc2640r2_sdk_5_30_00_03 sdk.

Hello Ankit,

It could be interesting for you to have a look at the scanning and advertising lab, even if the example are on simple_peripheral, the architecture is the same for simple_broadcast.

You should be able to start and stop advertising with the GAPRole_SetParameter() function and the define GAPROLE_ADVERT_ENABLED.
The function called to stop advertising is GAP_EndDiscoverable().

Regards,

Hello Guillaume,

i tried your above suggested method, but still i am facing the issues, packet gets delayed after few minutes. i think there is some issue in my scanning application running in my android phone. in order to check if the app is missing the packets or not i am thinking of putting a counter in the ADV packet and increment it everytime it broadcasts the packet, where should i put this counter?

Regards,

Hi Ankit,

Ok, now we need to see what's going on at the packet level. Do you have a BLE sniffer to do so?

If not, you could follow the debugging guide section debugging RF output, thus you can use GPIO to see the RF activity and if the packets are sent at the right time.

regards,

Also, let's take a step back of your initial question:

You removed the LF crystal (32kHz), but do you have another LF crystal? As the purpose of this crystal is to deal with sleep mode, here when the device is not advertising, it's in sleep mode. So it's not really a problem to have delay for advertisement, because in the worst case you'll miss one advertisement packets and find back the right advertisement interval.

I don't really know why you need to advertise for 10s specifically, but it shouldn't be an major issue for your application.

No ,i dont have the sniffer with me . Will have to use the gpio for debugging rf activity.

Earlier 32khz and 24Mhz both were used for LF and HF clocks but now, only 24Mhz crystal is used and please correct me if i am wrong, think simple broadcaster example uses internal LF for the sleep time calculation.

Yes you're right for sleep time calculation with internal clock (called RCOSC). So it shouldn't affect the adv interval to remove the external crystal. Once again what is the purpose to advertise every 10s?

And how did you calculate the time between two packets before? (say that as it could be a timer issue rather than an advertising one in your case)

regards,

my application is tire pressure monitoring, ad i am sending the pressure and temperature values to mobile app by advertising every 10seconds, so that if there is any abnormality observed in pressure and temperature values the user gets the alert every 10seconds. My custom made mobile app is using a timer to calculate the timing between 2 intervals. and i think it is not delaying the advertising packets but instead it is missing the advertising packets. because the timer is getting fresh data and the timer becomes zero as soon as the packet is received int the inertvals which are multiples of 10. for e.g if the first packet was received in 10 seconds then the timer will become zero after reaching 10 seconds value, another data packet will be received afer 30 secs,means it missed 2 packets and 3rd packet was received at 30th second. So to confirm if the packets are missed by mobile app or it is missed by the CC2640 i want to add a packet counter in my advertising packet.

Hi Ankit,

First I will forward your thread to our automotive team, they're proper expert for your application.

Fact that even if your advertisement is set with a proper 10s interval, it doesn't mean that you'll receive properly data every 10s on your central side. The central can miss the advertisement, it happens really frequently, both side (peripheral and central) are not synchronize during advertisement/scanning time, you cannot compare this to a connection event. 

So I think your behaviour it's totally normal, for advertisement at least.

regards,

Ankit

A few things to note / questions to ask. 

What are the scan settings of the scanner trying to find this advertisement?

In order to reliably see an advertisement, we recommend the scan window/interval be at least 2x of the advertising interval.  

There are 4 advertiser and one mobile app for scanning the advertisement. Advertisers mac address is whitelisted by QR code scanning at the time of installing the advertisers into tires.

mobile app is in continuous scan mode. As soon as it discovers the packet of any device it sends data to the application layer and starts scanning again. 

Hello Evan,

Thanks for the reply, yes you are correct because i added a packet counter in my advertising packet and incremented it at every advertising interval before advertising and found that the application was missing the packets.

And answer to your question why i am using the mobile application, yes i agree with you there are BLE clusters in cars. but we are using the application for customer demonstration purposes for 2 wheeler manufacturers as most of the 2 wheelers are not having BLE clusters, except the EV's.

i just want to ask one more thing, will i face this same issue with a BLE sniffer also. And should i use Simple_observer example as an aggregator that you are talking about.