CC2652R7: Periodic advertisement waveform of broadcaster.

Hi Garvit,

Thank you for reaching out. We will take a look at this and get back to you as soon as possible.

Best Regards,

Jan

Garvit, 

Just to provide some more context for your provided screenshot of the waveform:

- The un-circled peak at the beginning and circle 6 are representing the pre- (RTOS wake-up, radio setup, XTAL guard time) and post-processing/transition to Standby (BLE stack processes the received packets and sets up the sleep timer in preparation for the next event, and then goes to Standby). 

- Circle 1 (and possibly circle 2, although I am looking into this) are showing the radio preparation state where the radio is turned on and the transition to TX occurs. 

Garvit Periwal said:

Does the peak in circle 5 represent the transmission on data channel and circle 2-4 represent transmission on primary advertising channel? Is it the right way to think about this?

Circles 3-5 in your provided screenshot are all representing transmission of advertisement packets on each of the advertisement channels 37-39, respectively. 

Garvit Periwal said:

I am not able to understand is why circle 2 (Which I am assuming is the transmission on primary advertising channel) is way higher than others

I gave my assumption above about the high spike you are seeing but am going to spend some time looking into this to get you a more sure answer. For reference in the meantime, 

you can take a closer look at the Analysis section (6.3) and Advertising Event subsection (6.3.1) and its' contained Figure 6-13 and Table 6-1 for more details!

Best regards,

Luke

Hi Luke,

Is there any update regarding your findings? 

I am still not able to understand if circles 3,4,5 are representing transmissions on primary advertising channel than where is the transmission on data channel represented in waveform ?

Thanks,

Garvit

Garvit, 

I am still working with our internal team to understand more detail about these waveforms and what you are seeing. I will give you another update once I hear back from them tomorrow morning.

Thanks,

Luke

Garvit,

It sounds like we have seen similar behavior before (spikes at the init of each adv - channel wise). However, I can't completely say it's the same scenario since I am not sure how much extra current is there.

Could you try and follow the process detailed below (except flashing your program rather than basic_ble) to retake your measurements?

Also, after following this process can you send the trace again but showing the Y axis (mA)?

Best regards,
Luke

Hi Luke,

This is the complete waveform output from energy Trace -

I am seeing similar waveform again on enlarging the peaks -

Interestingly, there is another peak of around 10 mA near it - 

On enlarging that peak - 

On the Board I have kept only 3.3v, RXD pins. I am not sure what RXD and TXD pins represent but this was suggested in application note to get accurate readings hence I removed remaining. Can you tell me where I can read about these pins function as well? 

These are the readings from energy trace - 

Thanks,

Garvit

Hi Garvit, 

Thanks for sharing the traces and measurements. I have shared them with an internal expert and will pass along their feedback as soon as they respond.

Best regards,

Luke

Garvit,

After speaking with our internal expert, I have some answers about what you are seeing. 

First, on this point:

Garvit Periwal said:

Interestingly, there is another peak of around 10 mA near it - 

This peak is due to the DCDC recharging the VDDR supply during standby. For best efficiency, during standby the system operates off of charge on the PCB capacitor on VDDR and periodically (perhaps once every second at room temperature), the DCDC is enabled and recharges that capacitor and then goes back into standby. This is described in Figure 3-1 in the app note referenced before.

For your other question regarding the first peak about 3mA higher than the other peaks, it is likely that this is being seen due to a non-RF issue. This is coming from either flash access of the simple_peripheral project or due to the SW or RF drivers. This will require a bit more testing to understand exactly why you are seeing this spike.

Best regards,
Luke

Hi Luke,

Thanks for the update. Can you also share how to interpret these waveforms in context of periodic advertisements? 

I am still wondering which part in waveform is representing the transmission on data channel. This is also making me wonder whether the device is really getting into periodic advertisement mode or not.

Thanks,

Garvit

Garvit,

Apologies for the delay in the response here. We do not have any specific documentation on the waveforms for periodic advertisements but I can put together some information that may be useful from our experts. I will get you this before the end of the week.

There are alternative debugging methods besides viewing the trace to ensure the device is entering periodic advertisement mode such as utilizing a Bluetooth sniffer to view the packets being transmitted.

Best regards,

Luke

Garvit,

Are there any specific questions you have about interpreting these waveforms besides which part specifically shows the data channel trasnmitting?

Best regards,

Luke

Hi Luke,

I am not sure if I am right in doubting this but I am just not getting the confidence that the device is getting configured in periodic advertising mode properly. I don't have a sniffer as of now to confirm what's happening over the air.  

The project has some very stringent low energy demands and I want to make sure that those requirements are meet when the device is running in periodic advertisement mode. I think once we start to see a data channel transmission peak in current waveform, average current and energy consumption values would also increase and this is my major concern. 

Thanks,

Garvit

Garvit, 

I can spend time following the weekend using a sniffer to verify the device is being configured properly. If you share your most recent project file with me, I will work on that and get back to you as soon as possible.

I understand you are looking to keep this as low energy as possible so we can also work to minimize the energy consumption of the device once we understand it is functioning properly.

Best regards,

Luke

Hi Luke,

Thanks a lot for your continuous support. 

 7532.simple_peripheral_LP_CC2652R7_tirtos7.zip

Thanks,

Garvit

Garvit,

Thanks for sharing your project! We will get back to you shortly. 

Please keep me updated on any progress on your side as well.

Best regards,

Luke

Hi Garvit,

Hope you are doing well. I will be helping you moving forward. Please give me a day to catch up on this and setup a test on the provided image. I truly apologize for any inconvenience this may cause.

Best Regards,

Jan

Hi Garvit,

I took a quick sniffer log which did show the periodic advertisements over the air:

I have also attached the recorded log: https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/PeriodicAdvertising.btt

Best Regards,

Jan

Hi Jan,

Thanks for the update. I was out of office for couple of weeks, I'll go through the details and let you know in case I have some more doubts.

Thanks,

Garvit

Hi Garvit,

No worries! Welcome back. Let me know if you have any further questions or anything I can help with.

Best Regards,

Jan

Hi Jan,

I am struggling with opening of attached periodicAdvertising.btt file. Is .btt extension inherent to the sniffer device software you are using? 

From the attached Image, I am getting the confidence that periodic advertising functionality is functioning as expected but I am still curious about the log highlighted in black box in image below. The address adjacent to ADV_EXT_IND packet is different than the assigned device address. 

Also Jan, Is it safe to conclude that the current readings produced for the periodic advertisers are correct ?

Thanks,

Garvit

Hi Garvit,

No worries! The .btt file extension is used with the Ellisys packet analyzer software. This software is available for download on the Ellisys website. You should be able to download the software and open the file on your side. The readings look correct to me. I am not sure exactly what the different address may be, but its possible this is a scan response and its addressing the scanner address.

Best Regards,

Jan