NRF52 timing

[Phil Young]

I'm modelling a complex system with multiple BT devices based on the NRF52 using a very detailed model of the RF.

The system is based on the NRF52 using the mesh stack to but with additional user specific packets added by my code. I need to understand the behaviour of the Rx engine when a packet is received.

After a  successful reception does it re-enter Rx mode in the same channel or switch channels, and how long will it then remain on that channel, i.e. does it reset the rx timer, use the remaining time based on when it entered rx on that channel, or use any remaining time excluding the time consumed by the packet it actually received.

Additionally what happens in the event of a failed Rx ( Framing or CRC error ), how long does it take to recover and what actions does it take.,

I have a very detailed model that models all possible RF states but need to add some more detailed timing to the state machine, so in general the timings for the latest soft device on the NRF52 would be extremely useful, e.g. how long does it take to switch channels in Tx / Rx mode, how is the dwell time managed,

The same issues apply for Tx timing, does it truncate an Rx event when a Tx is scheduled?.

All of my data is sent as advertising events.

[Hung Bui]

Hi Phil, 

If possible could you give some more information of the purpose of the RF modelling ? Do you need to qualify for a certification or something ? 

Could you tell what exact stack running on the device ? Is it a proprietary mesh or it's our BLE mesh stack ? If it's our stack, please state the version. 

If it's our BLE mesh stack, most of the mesh activity is handled by mesh stack, not the softdevice. 

[Phil Young]

It is a proprietary stack running in parallel to your BTMesh stack, under normal operation just one of the 2 stacks will be active and under these conditions I need to understand the behaviour of the proprietary stack, it would also be useful to have more precise details for the behaviour of the actual BTMesh stack when that is active. I have a model that supports a very detailed system with detailed timing for all RF activities but I need to  update the soft device state machine model to accurately reflect how it manages the RF when sending advertisement events and scanning for advertisement packets since this code is common to both the WWMesh and our proprietary stack.

[Hung Bui]

Hi Phil, 

Please be aware that the softdevice has nothing to do with mesh except for granting timeslot for the mesh stack to use the radio. 

Please state exactly which softdevice and which Mesh SDK version you are using. 

[Phil Young]

Yes, I understand that.
Currently my prototypes are based on nrf5_SDK_for_Mesh_v0.10.1-Alpha although I intend to update this.
This is using nRF5_SDK_14.0.0

[Hung Bui]

Hi Phil, 

You mentioned "sending advertisement events and scanning for advertisement packets "   Could you clarify which advertising events ? Is it mesh advertising or normal BLE advertising ? The softdevice doesn't do mesh. 

We actually don't have the numbers or statistic on how the timing on the softdevice or the mesh stack is. You would need to measure this on your own. The easiest way of measuring this is to have a look at the power consumption of the chip when running the stack. Each state (TX, RX, Idle) would have different current consumption. You can use a Power Profiler Kit for this purpose. 

[Phil Young]

As I see it the Nordic BTMesh stack uses the softdevice in the SDK to interface to the RF, all BTMesh packets are simple non connectable advertising frames tagged as BTMesh and in parallel to this I am sending / receiving my own advertising frames tagged as manufacturer specific, the BTMesh stack does not recognize these and simply passes them to my code for processing using the API hooks.

When I send a frame I call the SDK using the API to schedule it, bypassing the BTMesh stack, providing my own buffers.

But the SoftDevice is initialized by the BTMesh code since it must tell the softdevice the parameters for scanning for BTMesh packets, and it is this scan process that receives my advertising frames.

In modelling the system with various assumptions about the soft device I identified some unusual system level behaviour with certain possible modes of soft device operation ( in particular what happens following packet reception depending on the remaining scan window time), so to ensure the behaviour is suitable for my needs I need to understand  what happens following successful and failed packet reception which is of course down to the soft device, but also how does the BTMesh configure the SoftDevice in terms of ScanWindow and ScanPeriod, and also when scheduling a frame ( either BTMesh or my custom frames ) for transmission what happens in terms of timing when the soft device is scanning.

[Hung Bui]

Hi Phil,

I'm not sure from where you get that the BTMesh use the softdevice to interface to the RF? 

In scanner.c you can see that the RADIO is accessed directly. They way the mesh stack works is to request the timeslot from the softdevice so that it can access the radio directly (without using softdevice API). The mesh stack doesn't use the softdevice to do scanning /advertising. 

You may need to explain to me a little bit more on how your own mesh stack running ? How do you disable the BTmesh and start yours ? I assume it use the softdevice API to do scanning and advertising ? If you disable the mesh stack you have the full control of the softdevice. 

Also Mesh version 0.10.1 is a very old and  primitive stack we had. Note that it's not on production level and is not qualified for Bluetooth Mesh.