Hi,
We have to enable the radio shorts in our developing multi link firmware. (We let any node connect to 3 other nodes at the max ( 1 as a slave and 2 as a master ))
We are using SDK 15 and here is the code portion of write into register.
Hi,
We have to enable the radio shorts in our developing multi link firmware. (We let any node connect to 3 other nodes at the max ( 1 as a slave and 2 as a master ))
We are using SDK 15 and here is the code portion of write into register.
Hi
Are you implementing the entire RF protocol from the ground up, or are you running some other protocol in the background?
Unless you are disabling the radio from time to time, or there is some other protocol that is also using it, I am not sure why the register would be reset.
Best regards
Torbjørn
Thanks for the reply
We are using the Fruitymesh Code and top of it our application code. Not implementing the entire protocol from the ground. The fruitymesh code is implemented by using SDK15.
Hi
You mean you are altering the Fruitymesh implementation directly, or running some other radio protocol on the side?
It is limited what support we can provide for Fruitymesh applications since this is not a software protocol that we provide, but if you have the source code available have you had a look at the code to see where the SHORTS register is accessed?
If you are planning to develop multi link firmware is there any reason you couldn't just use a standard SoftDevice itself?
They typically support up to 20 connections at the same time.
Best regards
Torbjørn
Hi
We can ignore the fruitymesh code now.
I am using SDK 17 ble_app_blinky_c and ble_app_blinky example code.
When I write the TIFS time into register (NRF_RADIO->TIFS = 50) its setting correctly but its resetting to default setting after enabled the nrf_sdh_enable_request().
If I write after enabled the softdevide its giving the softdevice error.
Hi
All the radio registers are controlled by the SoftDevice when it is enabled, and you should not try to alter any of these, as it will lead to unpredictable behavior and software crashes.
If you want to change basic radio parameters you either need to develop your own protocol from scratch, or start out with something like the ESB protocol.
Alternatively you could start out with the open source Bluetooth stack in Zephyr and make changes to that, but then you will no longer be Bluetooth compliant, and I am not sure how easy it will be to release a product in this case.
Is there any particular reason you need to change the TIFS value in the first place?
Best regards
Torbjørn