Mesh PA / LNA problems

RE: Mesh PA / LNA problems

ftjandra — Thu, 17 Sep 2020 15:19:41 GMT

If I want to only enable the PA/LNA for the mesh stack, but not for the softdevice it needs to toggle the 'bypass' pin on the PA/LNA chip. How would I do this?

Also, can I do the sd_ble_gap_tx_power_set(BLE_GAP_TX_POWER_ROLE_ADV, m_adv_handle, ...) at the end of the mesh_adv_data_set() function in mesh_adv.c since that is where the handle is set?

Thanks.

RE: Mesh PA / LNA problems

Hung Bui — Mon, 07 Sep 2020 08:22:22 GMT

Hi Ferdi,
Yes, correct. The mesh protocol is handled by mesh stack and the Proxy and PB-GATT are handled by the softdevice.
The mesh stack runs in the timeslot space when the softdevice gives the mesh stack controls of the radio. They have independent radio configurations.

RE: Mesh PA / LNA problems

ftjandra — Fri, 04 Sep 2020 16:42:54 GMT

Hi again,

You wrote: "Note that we have 2 systems that we need to enable PA/LNA, one is for the softdevice (GATT bearer) when you call sd_ble_opt_set() and one is for the mesh stack (ADV bearer) when you call mesh_pa_lna_gpiote_enable()."

The sd_ble_opt_set() goes with the proxy connection, correct? I.e. Mesh device to iPad. Also for provisioning.

And the mesh_pa_lna_gpiote_enable() is for communication between the mesh devices, right?

Does that mean they can be independently controlled? I.e. I only want the PA/LNA enabled for mesh communication, but not for BLE communication? The TxPower can be different as well?

Thanks.

RE: Mesh PA / LNA problems

Hung Bui — Mon, 24 Aug 2020 12:57:32 GMT

I think the best way to test PA/LNA is to test with actual longer range. Testing high power output indoor you will get a lot of reflections of the signal and can cause interference issue and as you mentioned, over-saturating.

Another option is to reduce the output power from the nRF52 to test. To change the output power, have a look at the answer by Rick Chung here: https://devzone.nordicsemi.com/f/nordic-q-a/56139/how-to-modify-tx-power-in-mesh-sdk-4-0-lpn-example

RE: Mesh PA / LNA problems

ftjandra — Wed, 19 Aug 2020 14:57:46 GMT

What makes you say that the PA/LNA isn't working? I see about a 30dBm increase in signal strength when scanning with nRF Connect.

And why test on Android without PA/LNA? Everything seems to work fine without it.

Ok, testing on Android without PA/LNA worked, as I expected. But with PA/LNA it worked too! I feel like it takes longer and I see a couple of disconnect/reconnects, but I was able to configure the app key, and publish/subscribe groups.

Android seems to behave similar to the Provisioner example, requiring a couple of retries.

On a hunch I re-installed nRF Mesh on iOS and it was able to provision and configure with PA/LNA, but again, it didn't feel as smooth as without PA/LNA.

This will definitely require a lot more testing before I feel comfortable with it.

Could it be that the signal is too strong and it's over-saturating the receiver? -25dBm should be fine though.

How do I set the TX power? Do I also have to set this in two places, BLE and Mesh?

I guess my next question is, how can I determine if it's working 100% correctly?

Thanks.

RE: Mesh PA / LNA problems

Hung Bui — Tue, 18 Aug 2020 08:29:12 GMT

Hmm, it doesn't sound to me like PA/LNA actually works.
Please try testing again with Android phone without PA/LNA.

And then try to test PA/LNA without mesh or softdevice. There is a customer made an example for the exact same module you have: https://devzone.nordicsemi.com/f/nordic-q-a/31050/controlling-a-pa-lna-sky66112-11-with-the-nrf52832-and-proprietary-protocols
Next step is to test it with the softdevice, without mesh.

RE: Mesh PA / LNA problems

ftjandra — Mon, 17 Aug 2020 20:57:32 GMT

Hi,

There are no asserts when trying to provision/configure with the nRF Mesh app (iOS). Sequence during provisioning goes like this (I am only showing relevant prints). While the app is requesting the composition data, it doesn't print out anything relevant. The DUT is still running and I can still see it advertise using nRF Connect. I also have a WDT timer that does not get invoked.

<00> t:     147444>, ble_softdevice_support.c,  106, Successfully updated connection parameters
<00> t:     281391>, mesh_gatt.c,  576, New MTU: 66
<00> t:     714815>, main.c, 1585, Successfully provisioned
<00> t:     714820>, main.c, 1580, Node Address: 0x0003

When using the provisioner example the DUT doesn't print out anything during the provisioning and asserts after the provisioner prints "Provisioning link established"

<00> t:    2570220>, app_error_weak.c,   96, Softdevice assert: 88972:0

After the assert DUT's watchdog kicks in and restarts it.

Here is the provisioner log:

<00> t:      10227>, main.c,  483, Starting application ...
<00> t:      10230>, main.c,  484, Provisioned Nodes: 0, Configured Nodes: 0
<00> t:      10233>, main.c,  486, Dev key : 534A368958599EBF4A6AA9272673D9F5
<00> t:      10236>, main.c,  487, Net key : FB9BC9BC9EE49A67E8EE781808B8A4C7
<00> t:      10239>, main.c,  488, App key : 0BA8A8B7869DF5B3AFB6DC4D1A8F1E1C
<00> t:      10242>, main.c,  489, Press Button 1 to start provisioning and configuration process. 
<00> t:     604590>, main.c,  351, Button 1 pressed
<00> t:     604593>, main.c,  274, Start provisioning procedure ...
<00> t:     604595>, provisioner_helper.c,  326, Scanning For Unprovisioned Devices
<00> t:     769005>, provisioner_helper.c,  168, UUID : D1E9C823620448C8BA0698129CC4AC23
<00> t:     769008>, provisioner_helper.c,  171, ^RSSI: -87
<00> t:     769010>, provisioner_helper.c,  177, ^URI Hash: 74F97940
<00> t:     769024>, provisioner_helper.c,  332, Stop Scanning For Unprovisioned Devices
<00> t:     769027>, provisioner_helper.c,  183, URI hash matched to ¹URI for LS Server example. Provisioning ...
<00> t:    1580059>, provisioner_helper.c,  300, Provisioning link established
<00> t:    2579259>, provisioner_helper.c,  192, Local provisioning link closed: prov_state: 3  remaining retries: 2
<00> t:    2579263>, provisioner_helper.c,  197, Provisioning failed. Retrying...
<00> t:    2579266>, provisioner_helper.c,  326, Scanning For Unprovisioned Devices
<00> t:    2698276>, provisioner_helper.c,  168, UUID : D1E9C823620448C8BA0698129CC4AC23
<00> t:    2698280>, provisioner_helper.c,  171, ^RSSI: -87
<00> t:    2698282>, provisioner_helper.c,  177, ^URI Hash: 74F97940
<00> t:    2698295>, provisioner_helper.c,  332, Stop Scanning For Unprovisioned Devices
<00> t:    2698299>, provisioner_helper.c,  183, URI hash matched to ¹URI for LS Server example. Provisioning ...
<00> t:    2723087>, provisioner_helper.c,  300, Provisioning link established
<00> t:    4894334>, provisioner_helper.c,  192, Local provisioning link closed: prov_state: 3  remaining retries: 1
<00> t:    4894338>, provisioner_helper.c,  197, Provisioning failed. Retrying...
<00> t:    4894341>, provisioner_helper.c,  326, Scanning For Unprovisioned Devices
<00> t:    4902933>, provisioner_helper.c,  168, UUID : D1E9C823620448C8BA0698129CC4AC23
<00> t:    4902936>, provisioner_helper.c,  171, ^RSSI: -86
<00> t:    4902939>, provisioner_helper.c,  177, ^URI Hash: 74F97940
<00> t:    4902952>, provisioner_helper.c,  332, Stop Scanning For Unprovisioned Devices
<00> t:    4902955>, provisioner_helper.c,  183, URI hash matched to ¹URI for LS Server example. Provisioning ...
<00> t:    4911971>, provisioner_helper.c,  300, Provisioning link established
<00> t:    5910204>, provisioner_helper.c,  192, Local provisioning link closed: prov_state: 3  remaining retries: 0
<00> t:    5910208>, provisioner_helper.c,  204, Provisioning Failed. Code: 1, Could not assign node addr: 0x0203
<00> t:    5910213>, main.c,  204, Provisioning failed. Press Button 1 to retry.
<00> t:    7142802>, main.c,  351, Button 1 pressed
<00> t:    7142804>, main.c,  274, Start provisioning procedure ...
<00> t:    7142807>, provisioner_helper.c,  326, Scanning For Unprovisioned Devices
<00> t:    7430260>, provisioner_helper.c,  168, UUID : D1E9C823620448C8BA0698129CC4AC23
<00> t:    7430263>, provisioner_helper.c,  171, ^RSSI: -85
<00> t:    7430265>, provisioner_helper.c,  177, ^URI Hash: 74F97940
<00> t:    7430279>, provisioner_helper.c,  332, Stop Scanning For Unprovisioned Devices
<00> t:    7430282>, provisioner_helper.c,  183, URI hash matched to ¹URI for LS Server example. Provisioning ...
<00> t:    8232869>, provisioner_helper.c,  300, Provisioning link established

They are about 25cm apart, but the log only shows RSSI around -85. nRF Connect shows -30.

As a hunch, I brought them closer together, about 10cm and it was able to provision successfully.

<00> t:     544973>, main.c,  351, Button 1 pressed
<00> t:     544976>, main.c,  274, Start provisioning procedure ...
<00> t:     544978>, provisioner_helper.c,  326, Scanning For Unprovisioned Devices
<00> t:     561570>, provisioner_helper.c,  168, UUID : D1E9C823620448C8BA0698129CC4AC23
<00> t:     561573>, provisioner_helper.c,  171, ^RSSI: -80
<00> t:     561575>, provisioner_helper.c,  177, ^URI Hash: 74F97940
<00> t:     561589>, provisioner_helper.c,  332, Stop Scanning For Unprovisioned Devices
<00> t:     561592>, provisioner_helper.c,  183, URI hash matched to ¹URI for LS Server example. Provisioning ...
<00> t:     568232>, provisioner_helper.c,  300, Provisioning link established
<00> t:     582557>, provisioner_helper.c,  295, Static authentication data provided
<00> t:     596571>, provisioner_helper.c,  233, Provisioning completed received
<00> t:     596574>, provisioner_helper.c,  238, Adding device address, and device keys
<00> t:     596596>, provisioner_helper.c,  251, Addr: 0x0201 addr_handle: 0 netkey_handle: 0 devkey_handle: 2
<00> t:     602534>, provisioner_helper.c,  192, Local provisioning link closed: prov_state: 2  remaining retries: 2
<00> t:     602542>, main.c,  194, Provisioning successful
<00> t:     602547>, provisioner_helper.c,  216, Provisioning complete. ¹URI for LS Server example - address: 0x0201 elements: 1
<00> t:     602552>, node_setup.c,  736, Configuring Node: 0x0201
<00> t:     602555>, node_setup.c,  632, Config client setup: devkey_handle:2 addr_handle:0
<00> t:     602559>, node_setup.c,  412, Getting composition data
<00> t:     737053>, main.c,  247, Config client event
<00> t:     737056>, node_setup.c,  421, Updating network transmit: count: 2 steps: 1
<00> t:     739830>, main.c,  247, Config client event
<00> t:     739833>, node_setup.c,  432, Adding appkey
<00> t:     765202>, main.c,  247, Config client event
<00> t:     765204>, node_setup.c,  272, opcode status field: 0 
<00> t:     765207>, node_setup.c,  470, App key bind: Health server on element address 0x0201
<00> t:     768206>, main.c,  247, Config client event
<00> t:     768208>, node_setup.c,  272, opcode status field: 0 
<00> t:     768224>, node_setup.c,  489, Setting publication address for Health server to 0x0001
<00> t:     775804>, main.c,  247, Config client event
<00> t:     775806>, node_setup.c,  272, opcode status field: 0 
<00> t:     775809>, node_setup.c,  470, App key bind: Generic OnOff server on element address 0x0201
<00> t:     778107>, main.c,  247, Config client event
<00> t:     778110>, node_setup.c,  272, opcode status field: 0 
<00> t:     778126>, node_setup.c,  523, Setting publication address to 0xC005 for Generic OnOff server on element address 0x0201
<00> t:     785558>, main.c,  247, Config client event
<00> t:     785560>, node_setup.c,  272, opcode status field: 0 
<00> t:     785570>, node_setup.c,  572, Adding subscription to address 0xC003 for Generic OnOff server on element address 0x0201
<00> t:     787815>, main.c,  247, Config client event
<00> t:     787817>, node_setup.c,  272, opcode status field: 0 
<00> t:     787820>, main.c,  174, Configuration of device 0 successful
<00> t:     787826>, provisioner_helper.c,  326, Scanning For Unprovisioned Devices
<00> t:    1100798>, main.c,  219, Node 0x0201 alive with 0 active fault(s), RSSI: -89

From 50cm, the provisioner doesn't see the DUT at all.

So I tried disabling the PA/LNA and from 25cm, it was able to provision fine and the signal strength shows much stronger at -42.

<00> t:     779434>, main.c,  351, Button 1 pressed
<00> t:     779437>, main.c,  274, Start provisioning procedure ...
<00> t:     779439>, provisioner_helper.c,  326, Scanning For Unprovisioned Devices
<00> t:     831083>, provisioner_helper.c,  168, UUID : D1E9C823620448C8BA0698129CC4AC23
<00> t:     831086>, provisioner_helper.c,  171, ^RSSI: -42
<00> t:     831088>, provisioner_helper.c,  177, ^URI Hash: 74F97940
<00> t:     831102>, provisioner_helper.c,  332, Stop Scanning For Unprovisioned Devices
<00> t:     831105>, provisioner_helper.c,  183, URI hash matched to ¹URI for LS Server example. Provisioning ...
<00> t:     838232>, provisioner_helper.c,  300, Provisioning link established
<00> t:     852880>, provisioner_helper.c,  295, Static authentication data provided
<00> t:     866656>, provisioner_helper.c,  233, Provisioning completed received
<00> t:     866659>, provisioner_helper.c,  238, Adding device address, and device keys
<00> t:     866682>, provisioner_helper.c,  251, Addr: 0x0201 addr_handle: 0 netkey_handle: 0 devkey_handle: 2
<00> t:     872229>, provisioner_helper.c,  192, Local provisioning link closed: prov_state: 2  remaining retries: 2
<00> t:     872237>, main.c,  194, Provisioning successful
<00> t:     872242>, provisioner_helper.c,  216, Provisioning complete. ¹URI for LS Server example - address: 0x0201 elements: 1
<00> t:     872247>, node_setup.c,  736, Configuring Node: 0x0201
<00> t:     872250>, node_setup.c,  632, Config client setup: devkey_handle:2 addr_handle:0
<00> t:     872254>, node_setup.c,  412, Getting composition data
<00> t:     894980>, main.c,  247, Config client event
<00> t:     894983>, node_setup.c,  421, Updating network transmit: count: 2 steps: 1
<00> t:     897226>, main.c,  247, Config client event
<00> t:     897228>, node_setup.c,  432, Adding appkey
<00> t:     902057>, main.c,  247, Config client event
<00> t:     902059>, node_setup.c,  272, opcode status field: 0 
<00> t:     902062>, node_setup.c,  470, App key bind: Health server on element address 0x0201
<00> t:     904382>, main.c,  247, Config client event
<00> t:     904384>, node_setup.c,  272, opcode status field: 0 
<00> t:     904401>, node_setup.c,  489, Setting publication address for Health server to 0x0001
<00> t:     911714>, main.c,  247, Config client event
<00> t:     911716>, node_setup.c,  272, opcode status field: 0 
<00> t:     911719>, node_setup.c,  470, App key bind: Generic OnOff server on element address 0x0201
<00> t:     914114>, main.c,  247, Config client event
<00> t:     914116>, node_setup.c,  272, opcode status field: 0 
<00> t:     914132>, node_setup.c,  523, Setting publication address to 0xC005 for Generic OnOff server on element address 0x0201
<00> t:     921732>, main.c,  247, Config client event
<00> t:     921734>, node_setup.c,  272, opcode status field: 0 
<00> t:     921744>, node_setup.c,  572, Adding subscription to address 0xC003 for Generic OnOff server on element address 0x0201
<00> t:     925241>, main.c,  247, Config client event
<00> t:     925244>, node_setup.c,  272, opcode status field: 0 
<00> t:     925246>, main.c,  174, Configuration of device 0 successful
<00> t:     925253>, provisioner_helper.c,  326, Scanning For Unprovisioned Devices
<00> t:    1234421>, main.c,  219, Node 0x0201 alive with 0 active fault(s), RSSI: -42

At 50cm, it also worked. I am not 100% sure, but I think the DUT still asserted one time without the PA/LNA.

I did try the nRF Mesh app again with the phone very close and it still did not work.

Thanks.

RE: Mesh PA / LNA problems

Hung Bui — Mon, 17 Aug 2020 15:27:13 GMT

Hei Ferdi,

Could you check the log on the device under test to see if there is any assertion ?
I suspect that the device crashed after it disable and enable softdevice again after provisioning (before configuration)

Also please try testing provisioning using ADV bearer (using the provisioner example or use PyACI) instead of using a phone. In addition please check the signal strength when you do ADV mesh bearer.

Note that we have 2 systems that we need to enable PA/LNA, one is for the softdevice (GATT bearer) when you call sd_ble_opt_set() and one is for the mesh stack (ADV bearer) when you call mesh_pa_lna_gpiote_enable().