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.

[Phil Young]

My code is currently based on the old Mesh SDK which was using the soft device, prior to that I was also using the timeslot API, but the timsslot API did not allow for multiple applications to be interfacing to it so I changed the code when integrating with the mesh SDK.

Now it seems I will first have to modify my code to work with the latest SDK, but that's problematic for me as all of my applications are built using the Keil environment and the mesh code does not build when using the arm compilers using cmake

Run Build Command:"D:/Tools/ninja.exe" "cmTC_bda53"
[1/2] Building C object CMakeFiles\cmTC_bda53.dir\testCCompiler.o
FAILED: CMakeFiles/cmTC_bda53.dir/testCCompiler.o
C:\Keil_v5\ARM\ARMCC\bin\armcc.exe --std=gnu99 -Wall -Wno-attributes -Wno-format -ffunction-sections -fdata-sections -fno-strict-aliasing -fno-builtin --short-enums --depend=CMakeFiles\cmTC_bda53.dir\testCCompiler.o.d --depend_single_line --no_depend_system_headers -o CMakeFiles\cmTC_bda53.dir\testCCompiler.o -c testCCompiler.c
Fatal error: C3900U: Unrecognized option '--std=gnu99'.
Fatal error: C3900U: Unrecognized option '-all'.
Fatal error: C3900U: Unrecognized option '-no-attributes'.
Fatal error: C3900U: Unrecognized option '-no-format'.
Fatal error: C3900U: Unrecognized option '-ffunction-sections'.
Fatal error: C3900U: Unrecognized option '-fdata-sections'.
Fatal error: C3900U: Unrecognized option '-fno-strict-aliasing'.
Fatal error: C3900U: Unrecognized option '-fno-builtin'.
Fatal error: C3900U: Unrecognized option '--short-enums'.
ninja: build stopped: subcommand failed.

There are no instructions on how to use the ARM compilers that I can find in the documentation.

[Hung Bui]

Just to clarify, maybe we are talking to different mesh stack here, could you find the part where the mesh stack use the softdevice for scanning /advertising mesh? In my SDK v.0.10.1 alpha we access the radio in scanner.c file. I'm not aware of any time that we changed this architecture. 

We do have examples for Keil that you can use. In the newer SDK (from SDK v2.1) we provide coexistence examples in Keil that you can integrate into nRF5 SDK. 

[Phil Young]

Yes, you are right, I was confused as I remembered changing my code because I could no longer use take control of the radio directly, so I use the Mesh stack to handle the Tx and Scanning operations, I also remember having to make a lot of changes to integrate the code in the old Mesh SDK with the BT-LE SDK since it had been created by importing part of the BT-LE SDK into  the mesh SDK and editing it so it was no longer compatible with the main BT-LE SDK and was also unable to be integrated into a C++ project because of some coding style issues.
There are no projects for the keil environment to re-build the mesh SDK so yet again I will have to creat one by reverse engineering the output from CMake, but at the moment CMake is failing the compiler test when enable_lang is called despite me using the -D TOOLCHAIN=armcc, it is picking up the Keil compilers directly but testing them with gcc arguments, I even modified the script to dump the compiler options and it dumps the correct ones for armcc, but just test the compiler with the gcc ones.

[Phil Young]

fixed by deleting and restoring the directories, seems that enable_lang had been called when I first ran the script without specifying armcc, then it created a build environment for gcc and tested that which failed. A bit crap of CMake, but it seems you cannot then change the build environment so I had to delete it.

[Hung Bui]

Hi Phil, 

I see, I think I had the same issue a bit long ago. Now you can generate the build with CMAKE and armcc ? 

If you move to SDK v2.x  or 3.x you can just reuse the Keil project we have in the co-existence examples we provided. It has all the stack libraries and dependencies. 
Regard any detailed timing, I afraid that we don't have anything other than the documentation and softdevice specification we have.