Channel Sounding with Two Antennas: Data Dropouts after Adding Second Path (2 antenna)

[witc]

Hi,
can you please help me with configuring ras_initiator for channel sounding when using two antennas on the initiator and one antenna on the reflector?
I am starting from the basic ras example, where only one antenna path (A1_B1) is used by default. If I keep just one antenna, everything works fine.
But when I add a second antenna path, the behavior becomes unstable:

• At first, I get results with similar period as with one antenna.

• But after some time, the results start "dropping out" – I get almost no data, and I see messages like:
  app_main: Ranging data overwritten 656
  Then nothing for a long time, and suddenly I get one result like:
  Distance estimates on antenna path 0: ifft: 0.999505,...
  Then again nothing for a long time.

This is what I changed for two antennas, but maybe it is not enough:
in main.c:
.tone_antenna_config_selection = BT_LE_CS_TONE_ANTENNA_CONFIGURATION_A2_B1,
in prj.conf:

CONFIG_BT_RAS_MAX_ANTENNA_PATHS=2

CONFIG_BT_CTLR_SDC_CS_MAX_ANTENNA_PATHS=2

CONFIG_BT_CTLR_SDC_CS_NUM_ANTENNAS=2

// increasing buffer from 1920
CONFIG_BT_CHANNEL_SOUNDING_REASSEMBLY_BUFFER_SIZE=3840

also in overlay I edited RF switch, but not sure how it works - could not find the source code where the RF switch is swithed, is that correct?

cs_antenna_switch: cs-antenna-config {

        status = "okay";

        compatible = "nordic,bt-cs-antenna-switch";

        ant-gpios = <&gpio0 3 GPIO_ACTIVE_HIGH>,  // ANT1 control - P0.03

                    <&gpio0 2 GPIO_ACTIVE_HIGH>;  // ANT2 control - P0.02

        multiplexing-mode = <0>;  

    };

I am using an RF switch (AS179-92LF) that has two control pins.
To switch the RF path, the pins must always be in opposite logic states (one is HIGH, the other is LOW).

Thank you very much for any help.

[witc]

Actually, the results do not come in a regular interval – sometimes there are long gaps and it is not stable at all. Even with only one antenna, it maybe works a bit better at the start, but after a few seconds the results become even more unstable. Even though I think my hardware is good, at a distance of 1 meter the results often drop out and are not stable. I set the CS parameters mostly by guessing, because I do not know how to make it more robust, but I did not see any big improvement compared to the default settings. My hardware is a custom board and HOLYIOT-24005 with nRF54L15 – both behave almost the same.
I use ncs 3.0.1

[Amanda Hsieh]

Hi, 

Can you share the rest of your parameters? Adding multiple antenna paths to channel sounding means the controller produces more data, which in turn means the devices need to exchange more data over GATT to produce distance estimates. If there isn't enough time to transfer the data before more data is produced, the new data will overwrite the old.

Here are two things to try:

• increasing the procedure interval
• increasing CONFIG_BT_RAS_RRSP_RD_BUFFERS_PER_CONN

but not sure how it works - could not find the source code where the RF switch is swithed, is that correct?

We've decided to make this part of the controller open-source, here: https://github.com/nrfconnect/sdk-nrf/blob/95a5a55be764e2dc756a43ce7b485ac3a978d65e/subsys/bluetooth/controller/cs_antenna_switch.c#L4, but it looks like you're already using it correctly, so no need to look at the code.

witc said:

My hardware is a custom board and HOLYIOT-24005 with nRF54L15 – both behave almost the same.

Is it possible to test with the nRF54L15DK?

Regards,
Amanda H.

[witc]

Hi Amanda,

Thank you. 

Amanda Hsieh said:

Is it possible to test with the nRF54L15DK?

If I know there is only 1 antenna, but for comparison it would be OK.

Amanda Hsieh said:

If there isn't enough time to transfer the data before more data is produced, the new data will overwrite the old.

What do you mean? Isn't it more likely that due to e.g. bad RF conditions (interference, high latency, poorly designed HW..), it is not possible to read the step data from the reflector? Or I don't understand what you mean by short time - because my code is practically the same as your example ras_initiator - it doesn't do anything extra, so the CPU can't be extra busy because of me.

...but it is quite possible that the problem is with the custom HW, and the RF conditions are not completely ensured correctly

Thanks for now, I'll keep testing.

[Amanda Hsieh]

There is a ring buffer in the ranging service that contains step data. If it gets new data locally, it overwrites the old and can produce this log message. This is all open source in the SDK, and if you want to look more closely at what's going on, you can simply enable debug logs.

It seems you are clearly not using the samples out of the box since you've made all the modifications. So I recommend you start by trying the things I suggested above.