Hey,

The mesh works fine. I wish to integrate it into my Home Automation related project. The hardware IC is nRF51822-QFAA-T. Software is Keil 5.

In the BLE Gateway example, the rbc_mesh_event_handler() has first line as : TICK_PIN(28).
Digging further, this TICK is used in many inside functions:

transport_control.c line 186: TICK_PIN(6);
rbc_mesh_common.h line 103: TICK_PIN(PIN_BIT_H); etc.

And every time it takes a "different pin number as argument".

The question is:
Are these TICKs for user debugging/LED toggling purpose or are they very crucial part of the drivers?
Alternatively, if the code says TICK_PIN(6) and I want to use pin 6 for some sensor maybe, can I comment this TICK or should I prohibit myself from using pin 6 and use pin 5?

Awaiting reply, thank you.

Srijan Dhare
Leaf Technologies Pvt Ltd

Currently whole mesh share a view of handle-value pair table. What's suggested way to send message to specified node ? My idea is to specify each node with a id and associate the id to handle. So handle 0 is for node 0, handle 1 is for node 1 ... .Any other suggestion on such purpose schema design ?

I am using Ubuntu 12.04.02 LTS(64 bit).
I have cloned the whole repo inside nRF51 SDK's examples folder.

This is the error I am getting when I am running make on Scaling_example:

Compiling file: nrf_drv_gpiote.c
../../../../../../components/drivers_nrf/gpiote/nrf_drv_gpiote.c:30:61: error: 'GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS' undeclared here (not in a function)
nrf_drv_gpiote_evt_handler_t handlers[NUMBER_OF_GPIO_TE+GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS];
^
../../../../../../components/drivers_nrf/gpiote/nrf_drv_gpiote.c: In function 'nrf_drv_gpiote_init':
../../../../../../components/drivers_nrf/gpiote/nrf_drv_gpiote.c:148:44: error: 'GPIOTE_CONFIG_IRQ_PRIORITY' undeclared (first use in this function)
nrf_drv_common_irq_enable(GPIOTE_IRQn, GPIOTE_CONFIG_IRQ_PRIORITY);
^
../../../../../../components/drivers_nrf/gpiote/nrf_drv_gpiote.c:148:44: note: each undeclared identifier is reported only once for each function it appears in
../../../../../../components/drivers_nrf/gpiote/nrf_drv_gpiote.c: In function 'pin_from_port_get':
../../../../../../components/drivers_nrf/gpiote/nrf_drv_gpiote.c:93:1: error: control reaches end of non-void function [-Werror=return-type]
}
^
../../../../../../components/drivers_nrf/gpiote/nrf_drv_gpiote.c: In function 'channel_handler_get':
../../../../../../components/drivers_nrf/gpiote/nrf_drv_gpiote.c:98:1: error: control reaches end of non-void function [-Werror=return-type]
}
^
cc1: all warnings being treated as errors
make: *** [_build/nrf_drv_gpiote.o] Error 1

Tested with Gateway example, integrate with S110 existing project under sdk 9.

I tried to test limit of MESH_HANDLE_COUNT but it failed under:

mesh_srv_init:

365│ /* add characteristics to mesh service */
366│ for (uint8_t i = 0; i < g_mesh_service.value_count; ++i)
367│ {
368│ error_code = mesh_value_char_add(i);
369│
370│ if (error_code != NRF_SUCCESS)
371│ {
372│ return error_code;
373│ }
374│ }

with error_code: 3 emitted by:
uint32_t error_code = sd_ble_gatts_characteristic_add(
g_mesh_service.service_handle,
&ble_char_md,
&ble_attr,
&ble_value_char_handles);

if (error_code != NRF_SUCCESS)
{
    return NRF_ERROR_INTERNAL;
})

I use
-D__HEAP_SIZE=2048
-D__STACK_SIZE=1024
configuration. increasing values doesn't help.

Any suggestion to push the limit of handle count ? (more than 100 ?)

Hi.
Could you implement the reset command for the application controller interface?

Regards
Nils

Hi, I've been testing some code in both the dongle PCA10031 and NRF51DK PCA10028 using gcc and OS X and everything is working great. Wonderful work! 👍

But I'm having some trouble trying to update the NRF Beacon PCA20006 Rev 1.1 with the code, even with the examples, both gateway and LED mesh. Any tips? I've been trying the DFU of nRF Master Control Panel in Android because the NRFGoStudio is not working in OS X.

(I've bee also trying to get NRFGoStudio work both through playonMac, not installing, and Windows 7 with VirtualBox, but I'm having difficulties as it's not detecting the Segger programmer of the NRF51DK and a BT4.0 dongle for DFU neither) Thanks

Has the latest change removed the previous features of adding handles and having both read and write capability on each handle? If it is changed, please, suggest a way how to get the old feature back.

A copy/paste error in timeslot_handler.c gives the timers the wrong drift window numbers, and might result in timeslots not ending in time.

I am building a project in which I need to establish peer-to-peer communication between 2 nRF51422. I came across a post which said that I can achieve that using Timeslot API. If so, how can I can use Timeslot API to setup the connection?
Or, can this project "nRF51-ble-bcast-mesh" be used directly to setup peer-to-peer communication? If so, please guide me on how to use it to setup peer-to-peer communication.

Hi Trond,

I've tested with ten nodes, and it runs quite all right though. While I've check the illstration docs, and code too. I see there is no mention about the restriction of node's number.So does it have a limination that how many nodes could be put into this mesh?

BRs.

As of now, you will have to edit/patch the rbc-library and app-timer in order to sort out a SWI-conflict.
This is an issue in general, as most of the software interrupts are being used in standard libraries/components of the SDK.

Why not try a non-commonly used peripheral as a software interrupt?
Try to use the QDEC_IRQHandler as a Software Interrupt, so that integration is easier.

Any other peripheral IRQ can be used, as long as it's not used by the SoftDevice or application.

Hi Trond,

Now there is a bigger problem. I have programmed all the nodes to update the packet every 30 seconds. Every node is given a unique 2-byte number as identity and whenever a node updates the packet, it also feeds these 2 bytes at index 2 and 3. The Gateway is calmly listening to all these packets and I am showing the "live feed" on my terminal. What I observed is, the nodes hang randomly. In an experiment with 8 nodes, as soon as I power them ON, each node's message can be seen on terminal. But slowly they start disappearing as if they are stuck (but I am sure they are not stuck, rather on debugging I found the application to rest inside arm_startup_nRF51.s at line 211). In other words, nodes work as soon as I reset them (soft or hard), but randomly their messages stop coming after some random 2-5 minutes and I am left with only 2-3 nodes still working out of 8.

Did someone experience this? What could be the problem and solution, please?

Due to one instance of uninitialized memory and one blind event clearing, the radio may enter a zombie state for the rest of the ongoing timeslot. The zombie state will make the radio appear unresponsive for some limited time, before it resumes normal operation in the next timeslot.

A fix for this issue will be rolled into the next release, but to speed things up, we've made a hotfix, published in its own branch: hotfix-issue-44

Hi,

I last used this great mesh networking code a few months ago. Since there have been a number of releases since then, I was wondering there was a history log that lists the improvements/fixes etc.

Regards,

Alex

Hi,
could you provide a short compilation instruction to get an example working on a nRF51, including what tools used and what versions?

I tried to compile it using a modified Makefile from an example of the nRF51_SDK_v6.1, which did not work because it somehow did not generate all object files. I also tried it with Keil uVision but I didn't manage to get my nRF51822 into the device database.

Thanks for any help

I think that global time is overflowing after 9.1minutes with causes
a lot of problems and no more package to be sent on the mesh.
Global time comes from RTC0->COUNTER which is a 24bit counter.
((2^24*2^15/1000)/1e6) is the number of seconds between overflows.

Hi Trond,

There are two variables in timeslot_handler.c defined as uint32_t and assigned a boolean value. Is this a bug?

https://github.com/NordicSemiconductor/nRF51-ble-bcast-mesh/blob/master/nRF51/rbc_mesh/src/timeslot_handler.c#L117

Regards,

Alex

In my project I need the mesh to be completely disabled in order to save energy. I managed decrease the current consumption down to 200uA when the mesh is inoperative by using the following function:

void timeslot_handler_deinit(void)
{
    if (g_framework_initialized)
    {
        uint32_t error;
        g_is_in_callback = true;
        g_framework_initialized = false;
        error = sd_radio_session_close();
        APP_ERROR_CHECK(error);
        radio_disable();
    }
}

However, the consumption jumps back to 500uA a few milliseconds after the mesh has been deactivated. I assume that there might be some timer event turning the radio back on. So I have been wondering if there is a better way to deactivate all the resources used by the mesh in order to improve the energy consumption.

The processing queue may currently overflow without notice, resulting in odd behavior.
Add a method for propagating this information to the application.

This could be a solution to the problem with version number ofverflow

in mesh_srv.c
old code:

/* new version */
/**@TODO: Handle version overflow */
if (version > ch_md->version_number || uninitialized)

New code:

/* new version */
uint16_t seperation;
if(version >= ch_md->version_number)
    seperation=version-ch_md->version_number;
else
    seperation=(UINT16_MAX-ch_md->version_number)+version+1;
if ((seperation<(UINT16_MAX>>1) && seperation>0) || uninitialized)

If the received version is <(UINT16_MAX>>1) more than current version then the received version is considered a new version else a previous version

Hi there!

I'm trying to add an RSSI for each rbc_mesh_event. Can you please comment if am I doing it right?

1. extend "rbc_mesh_event_t" and "packet_t" with

uint8_t rssi;
2) in the "search_callback", right after the checksum, I'm getting the rssi:
uint8_t rssi = NRF_RADIO->RSSISAMPLE;
and set on the packet:
async_evt.callback.packet.rssi = rssi;
3) so that rssi is available in the "mesh_srv_packet_process" with
uint8_t rssi = packet->rssi;
and thus can be set in the event:
update_evt.rssi = rssi;
or conflicting event:
conflicting_evt.rssi = rssi;

Also, I have tried to config NRF_RADIO->SHORTS with RADIO_SHORTS_ADDRESS_RSSISTART_Msk, but it seems is having the same result as with just RADIO_SHORTS_READY_START_Msk.

Can it be? Or should I just start it with: NRF_RADIO->TASKS_RSSISTART = 1; ?

Am I missing the point?

Thank you!
Cheers
Oleh

Hi, I notice constant disconnect, when using BLE_Gateway. In my test I have an app displaying all messages received from mesh. min_inteval is set to 100 as in example.

Could you please suggest where to hunt? :_)

thank you!
Cheers
Oleh

Hi, if I write more than 16 Byte on Mesh-Characteristic I get return code 12 <=> NRF_ERROR_DATA_SIZE in sd_ble_evt_get()
by BLE Gateway example -> main.c -> sd_evt_handler() : Line 111

Additional I can't more connect to Device again

https://github.com/NordicSemiconductor/nRF51-ble-bcast-mesh/blob/sdk-8-support/nRF51/examples/BLE_Gateway/main.c#L111-116

/**
* @brief Softdevice event handler 
*/
uint32_t sd_evt_handler(void)
{
    rbc_mesh_sd_irq_handler();

    ble_evt_t ble_evt;
    uint16_t len = sizeof(ble_evt);
    while (sd_ble_evt_get((uint8_t*) &ble_evt, &len) == NRF_SUCCESS)
    {
        nrf_adv_conn_evt_handler(&ble_evt);
    }
    return NRF_SUCCESS;
}

Eclipse-GCC-ubuntu14-64Bit-SD8-Nexus5-nRFMCP-PCA10028

When I use make on the example folder, it says target not found.
Has anyone been able to compile the examples in arm-gcc?

while i fellow the introduce 'integrating_w_SD_apps.adoc' to set the example 'ble_app_proximity' .
it works fine with softdevice s110_nrf51822_7.0.0,
when i work with 'experimental_ble_app_uart' it works fine either with 'master control panel' connect.
but if i disconnect, then it can't be scan anymore.
then i found if BLE_GAP_EVT_TIMEOUT occur and using advertising_start to start adv, something wrong in 'sys_evt_dispatch'
when i pause the project. it runs on
HardFault_Handler
PROC
EXPORT HardFault_Handler [WEAK]
B .
ENDP
i upload the proj : https://github.com/eroswade/NordicPrist.git
anyone can help

thanks

Could this library be ported to Mbed ide? It will help me so mych.

Awesome project.

Using SDK 9, S130, and Gateway example with GCC.

assert failed at /nrf_adv_conn.c:167 with error_code 12

165│ /* Set advertisement data with ble_advdata-lib */
166│ error_code = ble_advdata_set(&ble_adv_data, NULL);
167├> APP_ERROR_CHECK(error_code);
168│

trace and check value of ble_adv_data, it's mangled somewhere else so the content of ble_adv_data is not valid.

Maybe potential overflow somewhere else ?

BTW some code works fine with S110 configuration.

I am porting th mesh protocol, on my existing service but when the smartdevice is start to connect to the NRF51822, the call to mesh_srv_char_val_set() generating an NRF_ERROR_INTERNAL. I don't know why ?

I think there is not clear doc showing the procedure for SDK 8.1 with gcc only without Keil. Also, if there is an example that adds to BLE_Gateway program the functionality that transmit any updated data on UART on the GATT handle and vice versa, that would be great.

Hi Trond,

I notice the following API has been changed with no origin_addr in the new version:

uint32_t rbc_mesh_value_get(rbc_mesh_value_handle_t handle,
uint8_t* data,
uint16_t* len,
ble_gap_addr_t* origin_addr);

could you please share the reason? If it is just old documentation, can I get still the last sender address?

Thank you!
Oleh

Hey Trond,

I put one node coded with program LED_mesh (in examples) in every room of my house of two floors.
The node with BLE_Gateway (in examples) is kept in the Hall (First Floor) which connects to my phone by Nordic Master Control Panel App.

Firstly, I had to keep a (extra) node at the stairs so that it is 'the one that connects' nodes at Ground Floor to the nodes at First Floor. Kind of acts as repeater. Firstly, can this be avoided? I know BLE range practically is quite suffocating.

Secondly, when I toggle LEDs on the nodes by sending 0/1 by Nordic's App, the nodes at First Floor respond instantly, but the nodes on Ground Floor take (randomly) 1 seconds to 5 seconds to show the effect. The problem could be that the nodes at Ground Floor are connected to nodes at First floor by the repeater at stairs because if I remove that node then Ground Floor won't respond. So, can I reduce this delay of 1 to 5 seconds by changing a parameter or doing a tweak? I tried changing init_params.adv_int_ms to 10 (earlier it was 100), but doesn't make any difference, lag still there.

Hi @trond-snekvik

I was going thru the source code from your last release which I do like a lot personally and find it very modular and clean. Especially no gatt binding. But with such a great separation there is no need in SD at all... :-)

There could be a build or version with the pure NRF_RADIO usage. Of course when no SD functionality is used. This would make sense for nodes playing the rely role.

What are your thoughts on this?

Cheers
Oleh

I have ported the code over to the GCC toolchain (https://launchpad.net/gcc-arm-embedded).
This a CLI build method, not from an IDE.
There were several changes which I made, but nothing too drastic.

I would like to contribute these changes.
I would think that allowing me to create new branch, say "sdks-8-support-gcc", and allowing me to check my code into this branch would be one way.
Alternatively, I could create a project on my github account and check my changes in there.
But this would split the code base.

Can you tell me how to proceed?

I keep getting conflicts with existing functions, and those that I've managed to get included through RTE Component Classes.

I must admit, I'm still a relative noob with Keil and the RTE/PowerPacks stuff. I'm sure this is something simple.

Would really be great if there was a gcc method for compiling this library as well.
Thanks for the help!

Can dfu and Passkey support be enabled in BLE_Gateway example. Any lead into this issue would be very helpful. Thanks.

Hi Trond,

as you moved to the spec-conformat pachet format, it opens new possibilities; like transmitting and receiving custom payloads. I would like to experiment with it a bit. What would be the best place in the rbc to place such a listener of custom payload?

Thank you!

Cheers
Oleh

Writing to flash at some time (not that you do in this example!) will lead to the code ending up in the ts_sd_event_handler with the NRF_EVT_FLASH_OPERATION_SUCCESS event type.

This subsequently leads to the default case and APP_ERROR_CHECK(NRF_ERROR_INVALID_STATE); will stop execution.

I would recommend to add the clause:

case NRF_EVT_FLASH_OPERATION_SUCCESS:                                                                       
            break; 

to the code. Also the default one you might want to return actually:

APP_ERROR_CHECK(evt);

If you want me to submit a code request, feel free to ask.

Hi Trond,

in the new release there are lots of cool changes! great work!

I see the 2 bytes per length, but as we are using BLE the packet will never reach this size, what is the reason to keep 2 bytes? Could you please share your thoughts?

Thank you!
Oleh

Currently the README file states that this code is written as part of a master thesis project. I like to know who I can mention and wrote this great piece of code!

Honor to whom honor is due. :-)

Currently, I've two types of errors that are generated by sd_ble_gatts_hvx in the function mesh_srv_char_val_set when I run your code along side code that publishes services as in your BLE_Gateway example.

Those are:

BLE_ERROR_GATTS_SYS_ATTR_MISSING
NRF_ERROR_SVC_HANDLER_MISSING

If I just return NRF_SUCCESS for these two cases, the code runs (with some hiccups) in parallel with those aforementioned services.

Does this have to do with interplay between these two ways of using the radio? Sorry, that this is such a vague report.

the adv_int_ms is defined as uint8_t, shouldnt be uint32_t? :-)

adv_int_ms The minimum adv_interval for nodes in the network in millis. Must be between 5 and 60000.

We have been using the meshing functionality for a while on a diversity of chips, also the QFAA packet/variant. The evaluation kit has hardware code 003C and works fine. However, we have also older chips with hardware code 001D, but the same packet/variant, and meshing will in this case not work parallel to a connection request.

The meshing works fine, even parallel to the device in its normal broadcasting state for BLE. However, as soon as I try to actually establish a connection, there is some fault within the SoftDevice (S110).

Program received signal SIGTRAP, Trace/breakpoint trap.
Read 4 bytes @ address 0xFFFFFFFE (Data = 0x00000002)
0xfffffffe in ?? ()
(gdb) bt
#0  0xfffffffe in ?? ()
#1  <signal handler called>
Read 4 bytes @ address 0x20003F74 (Data = 0x21000011)
Reading 64 bytes @ address 0x20003F40
Read 4 bytes @ address 0x000000FE (Data = 0x47085809)

Personally, I think this might be related to some kind of product anomaly for this older chip, but do you have some idea about what it could be? It only happens on a connection request and it is very consistent. I hope you have an older chip like this somewhere, because it is then super easy to reproduce.

Of course, feel also free to test our code at https://github.com/dobots/bluenet if that is of any help in testing this scenario.

In the document at https://github.com/NordicSemiconductor/nRF51-ble-bcast-mesh/blob/master/docs/how_it_works.adoc#mesh-metadata, the data of the metadata characteristic is defined as a structure of 10 bytes, but in the code, lines 177-179, the data length is set as:

ble_attr.init_len = 9;
ble_attr.init_offs = 0;
ble_attr.max_len = 9;

Because of this, the channel is not in the meta data characteristic. Is that a bug or on purpose? If the latter, why so? Shouldn't it rather be

ble_attr.init_len = MESH_MD_CHAR_LEN;
ble_attr.init_offs = 0;
ble_attr.max_len = MESH_MD_CHAR_LEN;

Hi Trond,

I met a problem as I wanna to add a feedback function to this mesh system. Think of this, the node could be asked from nearby nodes or timed itself to put it's state message into mesh network, so user could get the state even if it's out of sight. Maybe it'll does message conficts between nodes but I think this function could be worked under some restrictions.

The question is I don't kown where should I add this feedback packet.properly. What data format is like. So I can get the message from application and send it to the user. And please give some suggestion on this function.

I have modified the BLE_Gateway example so that it transmit the updated value on the handle via UART. It has been verified to work in RBL nRF. But, the same hex doesn't work in nRF51 DK. It goes on the error loop, as understood by lighting up of LED 3. A rough LED based debugging is suggesting that it is failing inside nrf_adv_conn_init() function. Here are the modified main.c and makefile of the BLE_Gateway example.

Addition:
It should be noted that RBL nRF51822 is actually PCA10031, but the code compiled for PCA10028 runs on it. While the same code doesn't run on nRF51 DK.

Hi Trond,

When the version becomes higher than the lollipop limit, the mesh keeps repeating the update event.

the limit is set to 200, now lets assume the version is 205 and no NEW message is inputted.

    uint16_t separation = (version >= ch_md->version_number)?
        (version - ch_md->version_number) : 
        (-(ch_md->version_number - MESH_VALUE_LOLLIPOP_LIMIT) + (version - MESH_VALUE_LOLLIPOP_LIMIT) - MESH_VALUE_LOLLIPOP_LIMIT)

This gives the version == ch_md-> version_number and thus seperation = 0;

 if ((ch_md->version_number < MESH_VALUE_LOLLIPOP_LIMIT && version > ch_md->version_number) || 
        (ch_md->version_number >= MESH_VALUE_LOLLIPOP_LIMIT && separation < (UINT16_MAX - MESH_VALUE_LOLLIPOP_LIMIT)/2) || 
        uninitialized)

here the second statement

(ch_md->version_number >= MESH_VALUE_LOLLIPOP_LIMIT && separation < (UINT16_MAX - MESH_VALUE_LOLLIPOP_LIMIT)/2)

is true, thus repeating.

I have searched the code and the MESH_VALUE_LOLLIPOP_LIMIT is not used anywhere else. When the version overflows, this should be higher than the MESH_VALUE_LOLLIPOP_LIMIT right?

To fix, I believe an overflow check should be here
https://github.com/NordicSemiconductor/nRF51-ble-bcast-mesh/blob/master/nRF51/rbc_mesh/src/mesh_srv.c#L739
and to add the MESH_VALUE_LOLLIPOP_LIMIT

To solve this issue I propose:

    bool new_version = false;
    uint16_t halfway = (UINT16_MAX - MESH_VALUE_LOLLIPOP_LIMIT)/2;
    // if own ch_md->version_number (own version or:OV) is larger than the version (packet version or: PV), we accept the packet as new if the PV > lollipop and OV is BEFORE the halfway point.
    if (ch_md->version_number > version &&
            version > MESH_VALUE_LOLLIPOP_LIMIT &&
            ch_md->version_number < halfway)
    {
        new_version = true;
    }
    // if own ch_md->version_number (own version or:OV) is smaller than the version (packet version or: PV), we accept the packet as new if the OV < lollipop or if the OV > lollipop and PV is BEFORE the halfway point.
    // if the PV is over the halfway point, the own version larger than lolli is the newest
    else if (ch_md->version_number < version &&
            ((ch_md->version_number < MESH_VALUE_LOLLIPOP_LIMIT) ||
            (ch_md->version_number >= MESH_VALUE_LOLLIPOP_LIMIT && version < halfway)))
    {
        new_version = true;
    }

    if (new_version ||  uninitialized) 
{
//..... continue handling the new packet

You can condense it, but this is probably clearer to read.
EDIT: and seperately, to add the lollipop value on overflow.

I'd like to hear your thoughts on this. Did I miss something obvious?

Regards,

Alex

EDIT2: I see I mixed up the meaning of version and ch_md->version_number. I updated my code.

Hi, I noticed that enabling the meshing functionality adds a lot of power consumption (going from 20μA to 13mA). Is this the expected behaviour? Also: which settings would change the power consumption the most?
Slightly unrelated question: could you show a time line example of what a node is doing? When it broadcasts, when it's listening, maybe including normal advertising or while its connected. This would help me a lot to understand the different settings and how the meshing affects/is affected by other communication.

In nRF51-ble-bcast-mesh/docs/integrating_w_SD_apps.adoc, in Step 2: a common SWI0, a change is suggested in app_timer.c:

void app_timer_SWI0_IRQHandler(void)

deosn't work, should be:

void SWI0_IRQHandler(void)

I have a problem getting both mesh and persistent storage to work. I followed the document integrating_w_SD_apps.adoc to integrate the mesh code with the softdevice handler in order to use persistent storage. The mesh code now works with the softdevice handler, but in return, persistent storage does not work anymore.

When I try to write to the persistent storage with pstorage_update (or pstorage_store) I receive an error code 13 (timeout) in my pstorage callback handler.
If I remove the call to rbc_mesh_sys_evt_handler from my sys_evt_dispatch function, writing to storage works again, but then of course meshing doesn't work anymore.
I added some logging and noticed that I get a lot of NRF_EVT_RADIO_BLOCKED sys events. If I remove the respective case from rbc_mesh_sys_evt_handler, storage is working but mesh is not.
Same happens if I increase the TIMESLOT_SLOT_EMERGENCY_LENGTH. I either have a working storage or mesh, but not both.

Do you have any idea how I can solve this? It seems to me as if the mesh is keeping the softdevice too occupied to handle the storage calls. Can I somehow pause the timeslot handler to give the softdevice time to handle the storage calls?

Thanks in advance