WL1831: Effects of Send_HCI_VS_DRPb_Enable_RF_Calibration_Enhanced command

Hi Andrew,

I cannot think of any major concerns when disabling periodic calibration. However, it does look like the latest command specified does have the periodic calibration enabled:

Did the customer choose the periodic calibration mode specifically?

Thanks,
Jacob

The customer added a sequence of Send_HCI_VS_DRPb_Set_Power_Vector commands to limit the transmit power in order to simplify certification. The one shot calibration was added to "latch" the effects of these commands as the comment in the following sequence suggests.

# Run TPC calibration to update the ACW (Amplitude Control Word) to the PA
Send_HCI_VS_DRPb_Enable_RF_Calibration_Enhanced 0xFDFB, 0x00, 0x00000800, 0x01
Wait_HCI_Command_Complete_VS_DRPb_Enable_RF_Calibration_Enhanced_Event 5000, any,HCI_VS_DRPb_Enable_RF_Calibration_Enhanced, 0x00

In this case there is strong evidence that this one shot command introduces the issue we are seeing.

As the published default period is 5 minutes, I wonder if the timer is by default running but the calibration list (bitmap) is empty so normally nothing happens when the timer expires but in this case the one shot calibration has modified the calibration list so now the calibrations are now active and run on timer expiry casuing the problems we are seeing.

Do you think this idea makes sense? If it does would following the command something like

Send_HCI_VS_DRPb_Enable_RF_Calibration_Enhanced 0xFDFB, 0x00, 0x00000000, 0x01

Be helpful?

Thanks

Andrew Roca

Hi Andrew,

I'll follow up here tomorrow.

Thanks,
Jacob

Hi Andrew,

I am a little confused still on why the customer changed from the original command:

(1) Send_HCI_VS_DRPb_Enable_RF_Calibration_Enhanced 0xFDFB, 0x00, 0x00000800, 0x01

which was mentioned in the WiLink 8 HCI Commands Guide documentation to this command:

(2) Send_HCI_VS_DRPb_Enable_RF_Calibration_Enhanced 0xFDFB, 0x01,0xff, 0x00000000, 0x01

The second command (2) is actually enabling periodic calibration. Are you suggesting that the customer noticed periodic performance changes with the first command (1)? I understand the customer wants to limit output power, but I'm confused how the first command introduced performance changes every 5 minutes. The Periodic Options parameter is not even available when specifying the Mode parameter to be "Init calibration".

I would recommend the customer use (1) after setting the power vector table according to the WiLink8 HCI Commands Guide. If you can clarify if the customer experiences performance issues periodically with (1) then we can continue to debug here. Otherwise, I recommend the customer use (1).

Thanks,
Jacob

The original command was

We have a core problem that caused us to look at this. We have a location application that scans for BT beacons. 
During testing the system seemed to stop finding any other Bluetooth devices for almost exactly five minutes at a time. 
Graphing the number of Bluetooth devices found against time showed a very pronounced five minute rhythm to the number of bluetooth devices detected.   

Even if some devices continued to be found the number of Bluetooth devices deteced could dramatically change. 
With the changes all following the pronounced five minute rythm. 
  
Search for the source of this variable performace led us to the calibration timer (it defaults to a five minute period). 
We were already issuing this command to latch the new power values. 

Send_HCI_VS_DRPb_Enable_RF_Calibration_Enhanced 0xFDFB, 0x00, 0x00000800, 0x01

So this was deemed suspect. 
If we changed to calibration timer period then the rhythm of the scan variation changed to match the new calibration frequency. 

So we tried following the 

Send_HCI_VS_DRPb_Enable_RF_Calibration_Enhanced 0xFDFB, 0x00, 0x00000800, 0x01

with  

Send_HCI_VS_DRPb_Enable_RF_Calibration_Enhanced 0xFDFB, 0x01,0xff, 0x00000000, 0x01

which should set the period for the periodic calibration to infinity and this seemed to offer an improvement.
There were worries that while it worked in office conditions it might have side effects hence the original query.

There is some evidence that this scan sensitivity problem exists even without issuing the initial 

Send_HCI_VS_DRPb_Enable_RF_Calibration_Enhanced 0xFDFB, 0x00, 0x00000800, 0x01

This is still being looked at, along with some evidence that at least on our system a software reset/reboot of the system doesn't fully reset this device and it needs power cycling.

I hope this helps

Andrew

Hi Andrew,

Just to clarify, the customer noticed periodic issues even when running the standard TPC calibration?

Send_HCI_VS_DRPb_Enable_RF_Calibration_Enhanced 0xFDFB, 0x00, 0x00000800, 0x01

Andrew Roca said:

There is some evidence that this scan sensitivity problem exists even without issuing the initial

Are there any logs associated with this statement above?

Maybe advice in this thread will help.

Thanks,
Jacob

Yes the system ran the

Send_HCI_VS_DRPb_Enable_RF_Calibration_Enhanced 0xFDFB, 0x00, 0x00000800, 0x01

Command as part of its startup and then went on to show the fault indeed this is why we started to look at this.

There is a log showing the fault even without issueing the command but the engineer who generated it used a test script and I'm not convinced that a processor reset, triggers a proper reset of the 1831. At one point during manual testing the scan detect count was lower than expected after even after multiple reboot commands had been issued but it recovered back to normal levels after the systems battery had been removed for a few seconds before being replaced.

Also the PDF we have that documents these command only documents values of 0 and 1 for the first parameter (one shot or periodic) however in section 4.1.3.4

We see

HCI_VS_DRPb_Tester_Con_TX (0xFDCA)

Send_HCI_VS_DRPb_Enable_RF_Calibration_Enhanced 0xFDFB, 1, 0xFF, 0x00000000, 0x01
Disable RXRX periodic calibration
Send_HCI_VS_DRPb_Enable_RF_Calibration_Enhanced 0xFDFB, 3, 0xFF,0x00000000, 0x01
# Disable RXRX LNA (periodic) calibration
Send_HCI_VS_DRPb_Enable_RF_Calibration_Enhanced 0xFDFB, 4, 0xFF,0x00000000, 0x01

With undocumented values.

Note the default value for the periodic calibration timer is 0x1e (5 minutes) and to disable the timer the value is 0xff so by default the timer is running all the time and the one shot doesn't impact it.

I wonder about the one shot bit field 0x00000800 does this leave the transmit calibration enabled ?

Hi Andrew,

Here is what I recommend for debugging the performance issue with reduced output power:

1. Remove/comment out any references to periodic calibration

2. Follow the steps in the WiLink 8 VS HCI Commands Guide Section 4.1.3.2 to reduce the output power to the desired level (including step 5 on page 42 for TPC calibration)

3. Run the HCI_VS_DRPb_Tester_Con_TX command to test performance

4. [If applicable] Add the disable periodic calibration commands from Section 4.1.3.4 if periodic issues are still present

If you are still noticing periodic issues, we will need to move on to taking firmware and HCI logs.

Thanks,
Jacob

Another engineer is currently looking at this (I've been sending him your responses) and he was on holiday last week and is currently waiting on a custom PCB to help with testing. I will talk with him later and try and update him.

Thanks

Andrew Roca

Sounds good!

- Jacob

Hi Jacob,

I'm Andrew Roca's colleague (Andrew F). My observation is changes in the "temperature index" as reported in the response to HCI_VS_Get_System_Status correlate with degredation in performance. Both devices are using the same BTS file, which contain the following sequence:

# Run TPC calibration to update the ACW (Amplitude Control Word) to the PA
Send_HCI_VS_DRPb_Enable_RF_Calibration_Enhanced 0xFDFB, 0x00, 0x00000800, 0x01
Wait_HCI_Command_Complete_VS_DRPb_Enable_RF_Calibration_Enhanced_Event 5000, 0x00, 0xfdfb, 0x00

Send_HCI_VS_DRPb_Enable_RF_Calibration_Enhanced 0xFDFB, 0x01, 0x01, 0xffffffff, 0x00
Wait_HCI_Command_Complete_VS_DRPb_Enable_RF_Calibration_Enhanced_Event 5000, 0x00, 0xfdfb, 0x00

i.e. a single-shot TPC calibration is performed, and then I explicitly set the recalibration period to 10 seconds, don't change change the procedures bitmap (special value 0xFFFFFFFF), and don't override temperature condition. The top graph shows how the two devices (both on a desk in an air-conditioned office) see different numbers of UUIDs in each periodic scan. The devices are close enough that we'd expect a close correlation in the number of UUIDs received. "Device 1" (blue and red lines), but we can reasonably expect some deviation.

The bottom graph shows the "Temperature Index" and "Temperature Detected" data taken from the response to the HCI_VS_Get_System_Status command on the same timescale.

Observations and Questions

1. SWRU442B (https://www.ti.com/lit/ug/swru442b/swru442b.pdf) defines values 0-4 for the Temperature Index (see section 4.1.4.2). Both devices only report values 6 and 7, which are undefined. Is there an updated version of SWRU442B that defines these new values?
2. "Device 2" transitions to "Temperature Index" 6 when the "Temperature Detected" is below 30°C, whereas "Device 1" remains in Temperature Index 7. Device 1 shows a consistent and better performance. Are these two observations related?
3. Are there any known reasons why crossing between "Temperature Index" values 6 and 7 causes such a significant change in performance?

Hi Andrew F.,

I'll follow up here tomorrow.

Best,
Jacob

Thanks, Jacob.

Any updates on this? Please let me know if there's additional data you need from the HCI interface

Sorry Andrew,

I'll try to follow up tomorrow.

Best,
Jacob

Hey Andrew,

I'd stick to the temperature recommendations given in the guide you linked (which is the latest). 

Andrew Featherstone said:

"Device 2" transitions to "Temperature Index" 6 when the "Temperature Detected" is below 30°C, whereas "Device 1" remains in Temperature Index 7. Device 1 shows a consistent and better performance. Are these two observations related?

With this comment, you're suggesting that Temperature Index 7 performs better than 6? From our firmware, I can see that 6 refers to temperature regions above 20 and 7 is above 30. I'm not sure why these were left out of the document.

BR,
Jacob

Jacob B. said:

you're suggesting that Temperature Index 7 performs better than 6? From our firmware, I can see that 6 refers to temperature regions above 20 and 7 is above 30. I'm not sure why these were left out of the document.

I'm observing that toggling between temperature indexes causes more "Calibration Procedure" events to occur, and that any calibration procedure can result in significantly diminished performance.

The goal is to determine why we see significant degradation of performance following a "recalibration"

The observation suggests that the firmware works as follows (in pseudo-code):

On time expiry:
    if (current_temperature_index != previous_temperature_index) || override_temp_condition, then:
        do_recalibration_procedures()


My questions:

1. Why does "calibration" sometimes result in significantly poorer performance between one calibration and another?
2. What "procedures" (as defined in the Procedures Bitmap in section 4.1.3.1 SWRU442B) are a function of the temperature of the WL1831?
   For example, does the Transmit Power Control need to be re-run if the Temperature Index changes?

Hi Andrew,

I'll follow up next week.

Hi Jacob,

Are you able to provide an update?

Thanks,

Andrew

Hi Jacob,

This is still an open issue for us. Please can you provide any follow up information? I'm very happy to try and answer any follow up questions you might have to aid your team.

Thanks,

Andrew

Hi Andrew,

For this issue, it would be very helpful to have the firmware logs I mentioned earlier in the thread. Was the custom PCB you mentioned delivered?

I can confirm in the firmware calibration can be run based on a temperature change event, but I'm not sure exactly why calibration occurs in your case. Firmware and HCI logs would be of great help.

Thanks,
Jacob