esb, shockburst, running on nrf5340dk's

RE: esb, shockburst, running on nrf5340dk's

Yaxit — Fri, 10 Jan 2025 14:09:54 GMT

Hi, I'm also interested in the coexistence of BLE and ESB, were there any developments in the last year? I think I read somewhere that this is supported, but I have not found anything other than this thread.

Cheers

RE: esb, shockburst, running on nrf5340dk's

ovrebekk — Fri, 05 Apr 2024 08:19:39 GMT

Hi Mike

What if you try to send 20 bytes only, rather than 64? Does it work fine then?

Since I only used the LBS sample in the example I didn't bother configuring the BLE stack for extended data length or ATT MTU, which is probably why you are having issues getting larger notifications to work.

Could you try to copy the configuration from a different example I worked on recently, which is set up for high throughput?
You will find the relevant appcore config here and the netcore config here.

Best regards
Torbjørn

RE: esb, shockburst, running on nrf5340dk's

mej7000 — Thu, 04 Apr 2024 11:30:57 GMT

Hi Torbjørn,

I am hoping you can help me with the ble-esb-mpsl-demo. I saw that you updated it yesterday. I upgraded to nRF Connect SDK v2.6.0 to match the requirements.

You code worked exactly as expected. It's the lbs part that is a problem for me. Instead of the boolean from the button, I need to relay the esb_rx data as it arrives directly to BLE so I needed to modify that part of the code. It is close to working... The attached image shows what I changed and where I think the problem is.

Standard esb_tx is already setup in my custom application. I don't believe it makes a difference, but I am using the standard esb_tx sample as the sender not the esb_tx from your demo. I think that is why I am getting the "Counter" warning.

I never need esb_tx and BLE to run at the same time. I only need esb_rx and BLE to timeslot.

removed all nrf5340 files for my own clarity, I'm using nrf52840dk board.
copied lbs.c and lbs.h into the project so that I could modify/replace: bt_lbs_send_button_state()
adjusted CMake to reflect file changes
commented out CONFIG_BT_LBS and CONFIG_BT_LBS_POLL_BUTTON

when I press the button I now call "bt_lbs_send_button_state_2()" with a pointer to a data array. I receive the mock data array over BLE as expected.

However, if I use the esb_callback function to call "bt_lbs_send_button_state_2()" I get the "No ATT channel for MTU...etc..." problem.

Calling "bt_lbs_send_button_state_2()" directly from within the esb callback caused a kernel panic so I added a workqueue.

As always, you help is greatly appreciated!

devzone.nordicsemi.com/.../6303.ncs_2D00_esb_2D00_ble_2D00_mpsl_2D00_demo.zip

RE: esb, shockburst, running on nrf5340dk's

ovrebekk — Mon, 04 Mar 2024 15:30:21 GMT

Hi Mike

Good to hear that you got it working 🙂

I can see that the CONSOLE_HANDLER configuration selects (enables) the interrupt driven driver here. I assume this is why it prevents the async based code from working properly.

Best regards
Torbjørn

RE: esb, shockburst, running on nrf5340dk's

mej7000 — Fri, 01 Mar 2024 11:15:45 GMT

Hi, Thanks. Enjoy the weekend!

You are correct in that all I really want to do is pass a ~64 byte length to/from BLE (and relay those 64byes to/from shockburst). I had considered adapting bt_lbs, but initially thought incorporating peripheral_uart would be easier... I'll look at adapting bt_lbs.

In the meantime I've determined that either one of these settings prevent the callback function working correctly. Commenting out both of those and BLE UART works as expected, but I am unsure of why they're a problem.

CONFIG_CONSOLE_HANDLER=y
CONFIG_CONSOLE_GETCHAR=y

*** Booting nRF Connect SDK v2.5.1 ***
[00:00:00.000,518] <inf> main: ESB PRX BLE Multiprotocol Example
[00:00:00.000,549] <inf> peripheral_uart: Initialize Bluetooth UART
[00:00:00.000,854] <err> peripheral_uart: Cannot initialize UART callback

devzone.nordicsemi.com/.../ncs_2D00_esb_2D00_ble_2D00_mpsl_2D00_demo_2D00_per_2D00_uart-_2800_3_2900_.zip

RE: esb, shockburst, running on nrf5340dk's

ovrebekk — Fri, 01 Mar 2024 08:52:17 GMT

Hi Mike

I am taking an early weekend so I won't have time to look into this today unfortunately. I will test your code on Monday and see if I can spot the issue.

As a side note, the only real difference between the LBS service used in my sample and the NUS service is that the former configures the characteristics as 1 byte length while the later uses variable length characteristics. You could quite easily configure one to be similar to the other.

Do you actually need the UART functionality from the peripheral_uart example, or is it only the BLE functionality that you want to use?
If yes, couldn't you just remove all the UART related code from the app_bt_uart module?

The way I like to structure these examples is to have the app_bt_xxx modules handle Bluetooth related functionalities only. Any code interfacing sensors or other interfaces should run either from main.c, or from another module.

Best regards
Torbjørn

RE: esb, shockburst, running on nrf5340dk's

mej7000 — Thu, 29 Feb 2024 21:25:06 GMT

Hi, It's the PRX. I'm focusing on getting the BLE UART working at this point.

[00:00:00.000,518] <inf> main: ESB PRX BLE Multiprotocol Example
[00:00:00.000,518] <inf> peripheral_uart: Initialize Bluetooth UART
[00:00:00.000,823] <err> peripheral_uart: Cannot initialize UART callback

CONFIG_UART_ASYNC_API=y is set in the prj.conf file and everything compiles without error.

CONFIG_BT_NUS_UART_ASYNC_ADAPTER wasn't in the prj.conf file, so it looks like it's not being used anyway. Enabling CONFIG_BT_NUS_UART_ASYNC_ADAPTER=y, caused a compile error so I took that out. It doesn't look like it's enabled in the peripheral_uart sample either. I tried taking the file out completely, but that didn't make a difference.

	if (IS_ENABLED(CONFIG_BT_NUS_UART_ASYNC_ADAPTER) && !uart_test_async_api(uart)) {
		/* Implement API adapter */
		uart_async_adapter_init(async_adapter, uart);
		uart = async_adapter;
	}

Peripheral_uart sample works as a standalone. At this point I think everything from the peripheral_uart sample has been incorporated, unchanged, into the demo. The Demo compiles fully, but there still seems to be something in the way I combined it with the demo that is causing "Cannot initialize UART callback". But since there are no errors I don't know what to change or where to look?

I attached the code. It builds fine for 52832 or 52840.

devzone.nordicsemi.com/.../ncs_2D00_esb_2D00_ble_2D00_mpsl_2D00_demo_2D00_per_2D00_uart-_2800_2_2900_.zip

RE: esb, shockburst, running on nrf5340dk's

ovrebekk — Thu, 29 Feb 2024 14:46:27 GMT

Hi Mike

The UART async adapter is an optional module that you only need if you are planning to use a CDC ACM (USB) comport, it is not necessary if you are using a physical UART. You can read more here. In other words I would just remove this altogether if you don't actually need it.

The set ballback function typically fails when the UART ASYNC API is not properly enabled. Are you sure that CONFIG_UART_ASYNC_API is properly enabled in the configuration?

Is it the PTX sample, PRX sample or both that you are struggling with?

Best regards
Torbjørn

RE: esb, shockburst, running on nrf5340dk's

mej7000 — Wed, 28 Feb 2024 15:51:47 GMT

Thanks! I'm still figuring Kconfig out and I understand what you mean with the app.overlay. I should have at least recognized the files existing in the peripheral_UART sample. I missed that one...

I have (4) 52840dk boards that should be delivered today. In the meantime I added app.overlay to the demo-per-uart sample to accommodate the 52832. That allowed it to compile fine.

However, I had warnings/errors in the prj.conf, uart_async_adapter and app_bt_uart files. I couldn't figure out how to fix that so I moved uart_async_adapter and app_bt_uart into the src folder, adjusted cmake, and all the errors went away in the c and the prj.conf files.

I assume I needed to do more with either kconfig or cmake to get those files to work in the common folder, but I couldn't figure it out with the files in the common folder.

I've gotten to 0 Errors/0 Problems in the compile. It seems very close, but I'm getting "<err> peripheral_uart: Cannot initialize UART callback".

Given that this is the unmodified UART sample that runs fine as a stand alone, there must be something in the configuration that is still holding it back?

It was problems with the "callback" that forced me to move the files out of "common" and into "src".

devzone.nordicsemi.com/.../ncs_2D00_esb_2D00_ble_2D00_mpsl_2D00_demo_2D00_per_2D00_uart.zip

RE: esb, shockburst, running on nrf5340dk's

ovrebekk — Wed, 28 Feb 2024 08:51:27 GMT

[quote user="mej7000"] Packet length will be ~50bytes, so I'm guessing about <300µs transmission time. As long as I'm within a few ms I should be good. I'm sure there will be refinements once the system is working.[/quote]

The transmission time is not an issue, since it is relatively constant. You just add this time to the timestamp you receive before you update the local time, to compensate.

The question is the delay between uploading the ACK payload and it actually being sent, I would expect this delay to be much more random, and as such you will not be able to compensate for it.

But lets cross that bridge when we get there 😉

[quote user="mej7000"]I zipped the entire demo, with my additions, if it helps to look at it. I tried to follow your example for directory structure and to not modify anything I didn't have to.[/quote]

It is possible for a project to define local Kconfig parameters that only exist for this particular project. These are defined in a file called Kconfig located in the root folder, and since you don't have these parameters in your project the build will fail. Simply copying the Kconfig file from the peripheral_uart sample into the ptx and prx sample folders should fix this. If there already existed a Kconfig file in these projects you would need to merge them.

Also, the peripheral_uart sample needs a chosen node called nordic,nus-uart in the device tree, which is included in a file called app.overlay. In the case of the ptx and prx samples I would recommend adding this to the board specific overlays located in the board folder.

I have attached a modified version of your example with these things fixed for the prx sample, and I can now build it (I didn't test the functionality though, I will leave that with you). I tested it based on the 52840DK board, you might have to make some additional changes to have it work for the 52DK:

devzone.nordicsemi.com/.../ncs_2D00_esb_2D00_ble_2D00_mpsl_2D00_demo_2D00_nod_2D00_mod.zip

To look over all the changes I did you can just open the git bash and check the diff.

Best regards
Torbjørn

RE: esb, shockburst, running on nrf5340dk's

mej7000 — Mon, 26 Feb 2024 23:55:17 GMT

You make a great point. As development unfolds it's good to know I have the option... There will be redundancy in with the timestamp ACK responses every 5-10 seconds. Network traffic won't be much, but I do need to handle any occasional collisions. Packet length will be ~50bytes, so I'm guessing about <300µs transmission time. As long as I'm within a few ms I should be good. I'm sure there will be refinements once the system is working.

I basically have the child (ptx) done and now it's time to circle back to the "parent" (prx). The parent relies heavily on your "ncs-esb-ble-mpsl-demo" as that is the node to split BLE and ESB duty.

I made very minor additions to get LED2 to toggle (just to indicate successful BLE write). Compiled and everything works as expected.

What I need to do now is replace the "peripheral_lbs" with "peripheral_uart" so that I can receive ESB rx_payload and relay it out over BLE and also push BLE data/commands out through ESB tx_payload.

As always I am open to suggestions, but I've been trying to add "peripheral_uart" (which was compiled and working as a stand alone) to your ncs-esb-ble-mpsl-demo. "../common/uart_async_adapter.c" seems to be fine added to the CMakeList file, but if I add "../common/app_bt_uart.c" to the CMakeLists file I get compile errors that I don't understand.

Is my approach sound or is there a better way of modifying your demo to use peripheral_uart? I also tried removing peripheral_lbs, but that didn't work any better.

I've also loaded the prj.conf file with everything from peripheral_uart. Just that alone didn't cause any compile problems, but I noticed that even in the original demo there are warnings about missing CONFIG's that clearly exist in the prj.conf file (I don't fully understand why I am getting those warnings in the original demo, but it seems to be working correctly)

I zipped the entire demo, with my additions, if it helps to look at it. I tried to follow your example for directory structure and to not modify anything I didn't have to.

../common/app_bt_uart.c is commented out in the CMakeList file, so that it compiles correctly, but uncomment that and you get the following errors.

target_sources(app PRIVATE
src/main.c
../common/app_bt_lbs.c
../common/uart_async_adapter.c
# ../common/app_bt_uart.c
)

...

-MT CMakeFiles/app.dir/C_/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c.obj -MF CMakeFiles\app.dir\C_\nrf\ncs-esb-ble-mpsl-demo\common\app_bt_uart.c.obj.d -o CMakeFiles/app.dir/C_/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c.obj -c C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c
In file included from C:/ncs/v2.5.1/zephyr/include/zephyr/toolchain/gcc.h:92,
from C:/ncs/v2.5.1/zephyr/include/zephyr/toolchain.h:50,
from C:/ncs/v2.5.1/zephyr/include/zephyr/sys/time_units.h:10,
from C:/ncs/v2.5.1/zephyr/include/zephyr/sys/util.h:615,
from C:/ncs/v2.5.1/zephyr/include/zephyr/devicetree.h:25,
from C:/ncs/v2.5.1/zephyr/include/zephyr/device.h:12,
from C:/nrf/ncs-esb-ble-mpsl-demo/common/uart_async_adapter.h:22,
from C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:10:
C:/ncs/v2.5.1/zephyr/include/zephyr/device.h:85:41: error: '__device_dts_ord_DT_CHOSEN_nordic_nus_uart_ORD' undeclared here (not in a function)
85 | #define DEVICE_NAME_GET(dev_id) _CONCAT(__device_, dev_id)
| ^~~~~~~~~
C:/ncs/v2.5.1/zephyr/include/zephyr/toolchain/common.h:132:26: note: in definition of macro '_DO_CONCAT'
132 | #define _DO_CONCAT(x, y) x ## y
| ^
C:/ncs/v2.5.1/zephyr/include/zephyr/device.h:85:33: note: in expansion of macro '_CONCAT'
85 | #define DEVICE_NAME_GET(dev_id) _CONCAT(__device_, dev_id)
| ^~~~~~~
C:/ncs/v2.5.1/zephyr/include/zephyr/device.h:211:37: note: in expansion of macro 'DEVICE_NAME_GET'
211 | #define DEVICE_DT_NAME_GET(node_id) DEVICE_NAME_GET(Z_DEVICE_DT_DEV_ID(node_id))
| ^~~~~~~~~~~~~~~
C:/ncs/v2.5.1/zephyr/include/zephyr/device.h:228:34: note: in expansion of macro 'DEVICE_DT_NAME_GET'
228 | #define DEVICE_DT_GET(node_id) (&DEVICE_DT_NAME_GET(node_id))
| ^~~~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:62:36: note: in expansion of macro 'DEVICE_DT_GET'
62 | static const struct device *uart = DEVICE_DT_GET(DT_CHOSEN(nordic_nus_uart));
| ^~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:53:23: error: 'CONFIG_BT_NUS_UART_BUFFER_SIZE' undeclared here (not in a function)
53 | #define UART_BUF_SIZE CONFIG_BT_NUS_UART_BUFFER_SIZE
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:67:22: note: in expansion of macro 'UART_BUF_SIZE'
67 | uint8_t data[UART_BUF_SIZE];
| ^~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c: In function 'uart_cb':
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:55:26: error: 'CONFIG_BT_NUS_UART_RX_WAIT_TIME' undeclared (first use in this function)
55 | #define UART_WAIT_FOR_RX CONFIG_BT_NUS_UART_RX_WAIT_TIME
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:160:32: note: in expansion of macro 'UART_WAIT_FOR_RX'
160 | UART_WAIT_FOR_RX);
| ^~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:55:26: note: each undeclared identifier is reported only once for each function it appears in
55 | #define UART_WAIT_FOR_RX CONFIG_BT_NUS_UART_RX_WAIT_TIME
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:160:32: note: in expansion of macro 'UART_WAIT_FOR_RX'
160 | UART_WAIT_FOR_RX);
| ^~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c: In function 'uart_work_handler':
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:55:26: error: 'CONFIG_BT_NUS_UART_RX_WAIT_TIME' undeclared (first use in this function)
55 | #define UART_WAIT_FOR_RX CONFIG_BT_NUS_UART_RX_WAIT_TIME
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:222:60: note: in expansion of macro 'UART_WAIT_FOR_RX'
222 | uart_rx_enable(uart, buf->data, sizeof(buf->data), UART_WAIT_FOR_RX);
| ^~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c: At top level:
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:577:1: error: expected identifier or '(' before '{' token
577 | {
| ^
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:39:19: error: 'CONFIG_BT_NUS_THREAD_STACK_SIZE' undeclared here (not in a function); did you mean 'CONFIG_WFA_QT_THREAD_STACK_SIZE'?
39 | #define STACKSIZE CONFIG_BT_NUS_THREAD_STACK_SIZE
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/ncs/v2.5.1/zephyr/include/zephyr/sys/util.h:232:28: note: in definition of macro 'ROUND_UP'
232 | ((((unsigned long)(x) + ((unsigned long)(align) - 1)) / \
| ^
C:/ncs/v2.5.1/zephyr/include/zephyr/kernel/thread_stack.h:223:21: note: in expansion of macro 'Z_KERNEL_STACK_SIZE_ADJUST'
223 | sym[Z_KERNEL_STACK_SIZE_ADJUST(size)]
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
C:/ncs/v2.5.1/zephyr/include/zephyr/kernel/thread_stack.h:260:9: note: in expansion of macro 'Z_KERNEL_STACK_DEFINE_IN'
260 | Z_KERNEL_STACK_DEFINE_IN(sym, size, __kstackmem)
| ^~~~~~~~~~~~~~~~~~~~~~~~
C:/ncs/v2.5.1/zephyr/include/zephyr/kernel/thread_stack.h:339:41: note: in expansion of macro 'K_KERNEL_STACK_DEFINE'
339 | #define K_THREAD_STACK_DEFINE K_KERNEL_STACK_DEFINE
| ^~~~~~~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:652:1: note: in expansion of macro 'K_THREAD_DEFINE'
652 | K_THREAD_DEFINE(ble_write_thread_id, STACKSIZE, ble_write_thread, NULL, NULL,
| ^~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:652:38: note: in expansion of macro 'STACKSIZE'
652 | K_THREAD_DEFINE(ble_write_thread_id, STACKSIZE, ble_write_thread, NULL, NULL,
| ^~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:558:13: warning: 'configure_gpio' defined but not used [-Wunused-function]
558 | static void configure_gpio(void)
| ^~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:513:25: warning: 'nus_cb' defined but not used [-Wunused-variable]
513 | static struct bt_nus_cb nus_cb = {
| ^~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:462:36: warning: 'conn_auth_info_callbacks' defined but not used [-Wunused-variable]
462 | static struct bt_conn_auth_info_cb conn_auth_info_callbacks;
| ^~~~~~~~~~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:461:31: warning: 'conn_auth_callbacks' defined but not used [-Wunused-variable]
461 | static struct bt_conn_auth_cb conn_auth_callbacks;
| ^~~~~~~~~~~~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:233:12: warning: 'uart_init' defined but not used [-Wunused-function]
233 | static int uart_init(void)
| ^~~~~~~~~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:79:29: warning: 'sd' defined but not used [-Wunused-const-variable=]
79 | static const struct bt_data sd[] = {
| ^~
C:/nrf/ncs-esb-ble-mpsl-demo/common/app_bt_uart.c:74:29: warning: 'ad' defined but not used [-Wunused-const-variable=]
74 | static const struct bt_data ad[] = {
| ^~
[116/227] Building C object zephyr/arch/arch/arm/core/aarch32/CMakeFiles/arch__arm__core__aarch32.dir/fatal.c.obj
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: 'C:\ncs\toolchains\c57af46cb7\opt\bin\cmake.EXE' --build 'C:\nrf\ncs-esb-ble-mpsl-demo\prx\build52832'
PS C:\nrf\ncs-esb-ble-mpsl-demo\prx>

devzone.nordicsemi.com/.../ncs_2D00_esb_2D00_ble_2D00_mpsl_2D00_demo-_2800_3_2900_.zip

RE: esb, shockburst, running on nrf5340dk's

ovrebekk — Mon, 26 Feb 2024 10:42:48 GMT

Hi Mike

You could allocate the pipes any way you see fit, certainly. But there is something to be said for the "if it works don't fix it" reasoning as well, if you have a working system already you might just stick to that 🙂

When preloading an ACK with a timestamp do keep in mind that you might not know exactly when the next packet will come from a PTX, and as such how much delay there will be in the process of preparing the timestamp and it being received by one of the PTX's. This will introduce some inaccuracy in the timesync.

I am guessing you don't need microsecond level of synchronization though, and that you can accept a bit of error.

Best regards
Torbjørn

RE: esb, shockburst, running on nrf5340dk's

mej7000 — Sun, 25 Feb 2024 19:04:13 GMT

Thanks! That makes it much clearer. Pipes are different from what I thought, but I feel good that the design should work. I am planning on using the ptx HW_ID as part of the data packet for the iOS App anyway. It sounds like that might be useful for ESB addressing as well.

[quote userid="2116" url="~/f/nordic-q-a/107827/esb-shockburst-running-on-nrf5340dk-s/470168"]Another advantage of the pipe system is that the PRX can pre-load ACK payloads for the different pipes in advance, so that whichever PTX sends data to you next will get the correct ACK payload in return.[/quote]

This is super interesting. I hadn't considered using different responses on different pipes. I've preloaded the ACK with a timestamp and that works really well. It may make sense to have a "timestamp" pipe, a "data" pipe and a "command" pipe... there might be something really useful I can do with that.

RE: esb, shockburst, running on nrf5340dk's

ovrebekk — Thu, 22 Feb 2024 08:42:16 GMT

[quote user="mej7000"]I think (if I understand ESB correctly) I can have all communication happen on PTX0?[/quote]

Yes, you can have multiple (more than 2) devices communicating over the same pipe without issue as long as only one device is in PRX mode, or you disable ACK. If you have multiple devices in PRX mode and use ACK then you will run into issues where multiple devices are sending ACK's at the same time, which will lead to unpredictable behavior.

In your case it sounds like this should work fine since only the parent node will be in PRX mode.

Please note that you can get issues with this method if the PTX's send data very often, and you don't have any way of synchronizing them in time to avoid collisions.

[quote user="mej7000"]So the children can share the same pipe address? (ie. uint8_t base_addr_0[4] = {0xE7, 0xE7, 0xE7, 0xE7};)[/quote]

They can all share the same address, yes, but please don't use the default 0xE7 address in production 😉

[quote user="mej7000"]One hesitation is that I don't fully understand "pipes". It looks like the pipe is like a GHz channel and that PRX can monitor up to 8 pipes/channels at the same time? [/quote]

A pipe is just an abstraction of an address. Essentially the radio receiver can look for up to 8 different addresses simultaneously when decoding the incoming data stream, and it can then report to the application from which pipe the packet was received. Historically this feature was used mostly with a single PTX pr pipe, but like mentioned before it is possible to have multiple PTX devices all transmitting to the same pipe.

The advantage of only having 1 PTX pr pipe is that you don't need any other identifying markers in the payload to differentiate the different PTX's. When multiple devices are sharing pipes then you need to include some additional information in the payload to keep them apart, but in your case you probably need this anyway since you will have up to 30 devices talking to one 'parent'.

One comment to your diagram: Another advantage of the pipe system is that the PRX can pre-load ACK payloads for the different pipes in advance, so that whichever PTX sends data to you next will get the correct ACK payload in return. In order to make this system look at some part of the payload instead of the pipe to send the correct ACK payload the ESB protocol will need some changes.

Same if you want to include an accurate timestamp in the payload, this would require some modifications to the protocol as well.

Best regards
Torbjørn

RE: esb, shockburst, running on nrf5340dk's

mej7000 — Wed, 21 Feb 2024 10:36:51 GMT

Thanks. I'm convinced ESB is the correct solution for the network, and BLE is required for the App connection. Using the Ack to sync the parent time and child times works really well.

[quote userid="2116" url="~/f/nordic-q-a/107827/esb-shockburst-running-on-nrf5340dk-s/469976"]How many devices would you typically have for each gateway?[/quote]

This question just came up yesterday. I think I have it worked out, but I want to make sure I have this correct... I have one "Parent" (BLE/ESB-PRX) and many (~30) children (ESB-PTX).

I think (if I understand ESB correctly) I can have all communication happen on PTX0? Because Child nodes communicate directly with the Parent (never child to child), but the Parent always communicates (timestamp or command) as a "Broadcast" to the children. So the children can share the same pipe address? (ie. uint8_t base_addr_0[4] = {0xE7, 0xE7, 0xE7, 0xE7};)

One hesitation is that I don't fully understand "pipes". It looks like the pipe is like a GHz channel and that PRX can monitor up to 8 pipes/channels at the same time? Which is potentially very useful for me as long as that doesn't actually mean I am limited to only 8 PTX "children". That would be a disaster for me...

RE: esb, shockburst, running on nrf5340dk's

ovrebekk — Wed, 21 Feb 2024 10:02:12 GMT

Hi Mike

Accurate time synchronization is certainly a reason to chose ESB over BLE. When running Bluetooth the link layer will take care of packet timing, retransmits etc, and the delay between uploading the data and receiving it on the other side will be very erratic.

Very short latency is another bonus of the ESB protocol, you have more control of packet timing, and in theory you can send a packet and receive an ACK in less than a millisecond.

How many devices would you typically have for each gateway?

If performance is very critical you would probably get a more robust solution by having two nRF devices on the gateway (one for BLE and one for ESB), but this would obviously increase the BOM and the hardware complexity. The higher the number of sensors the smaller the impact would be on the total system cost, relatively speaking.

The range is a bit of a concern, it is hard to guarantee up to 200m of range over 2.4GHz, since these signals are heavily affected by environmental factors (in particular humidity/water, and metals).

Also, low power and low latency is a challenging combination of factors. If the sensors need to respond immediately to commands it means the radio needs to be available most of the time, which means you are looking at an idle current close to the radio peak current (around 5mA in RX).

One advantage again to ESB is that you are able to tune the protocol if you have more power available on one side of the link (such as the gateway in your case). But if you need very low latency in both directions then your hands are tied in this regard, since the sensors will not be able to sleep for long.

Best regards
Torbjørn

RE: esb, shockburst, running on nrf5340dk's

mej7000 — Mon, 19 Feb 2024 11:08:07 GMT

Thanks! I just discovered what dk_buttons_and_leds.h is and that I couldn't find dk_leds_init(), but you beat me to it! 🙂 Yesterday, I did a device tree overlay and got the LED working, which will be useful for my custom PCB eventually.

This isn't a silly question at all and is the reason we are migrating gen2 of this project to Nordic. I would love to get your opinion...

[quote userid="2116" url="~/f/nordic-q-a/107827/esb-shockburst-running-on-nrf5340dk-s/469414"]Maybe a silly question, but couldn't you just use BLE for all the links? Make one device a concurrent central/peripheral, and use this as a relay between the phone and the other device? [/quote]

we have:

Network of devices (beam break sensors)
Must maintain strict (ms) timing synchronization between devices
Must resync regularly
Sensors must respond immediately to random events (<=1ms)
Sensors must be capable of receiving commands from App
Beam break and HW_ID data to be reported to an App
npm1300 fuel gauge data, etc to be reported to App
Network range <=~200m
Battery operated, low power, etc.

Given the above my thought was that:

BLE connection to App
Shockburst with "parent" uptime preloaded into ACK
"child" sending actual or dummy data to get current parent uptime

I chose the above because I was concerned that BLE wouldn't have the range and/or the speed to reliably support the communication and clock sync requirements?

That's kind of the thinking thus far, however I would love explore any alternative ideas.

RE: esb, shockburst, running on nrf5340dk's

ovrebekk — Mon, 19 Feb 2024 09:09:19 GMT

Hi Mike

That's a weird issue on the phone side, I am not sure what might be going on there. You could see other devices in LightBlue? Could some filters be enabled?
Clearly it's a hint you should be using the nRF Connect app instead of LightBlue 😉

All the Bluetooth functionality is covered by the app_bt_lbs.c file, which is basically just a slightly modified copy of the main file from the lbs sample. The idea is to extend app_bt_lbs.c and app_bt_lbs.h with whatever functions you need in order for the application to interface with the Bluetooth connection. Right now there is only an init function, but typically you would want some functions to handle data send/receive, advertising start/stop and so forth.
It seems I removed the reference to dk_leds_init(), which is probably why LED's don't work. If you try to call this either inside app_bt_init() or inside your main function I would expect LED's to be updated by the app_bt_lbs.c module.

[quote user="mej7000"]I am curious about this. Yes, I did read that, but I can't find esb_peripherals.h in my local repo or on yours. Am I doing something wrong? [/quote]

No, this is one of the SDK files, not one of the project files. You can find it in the nrf/subsys/esb folder in the SDK.

A quick tip to find files in VS Code is to press ctrl + P, and type the name in the text box.

[quote user="mej7000"]I would think that would make a killer Nordic Sample/Solution for a lot of users. I have done something similar with ESP32 using UART peripheral. [/quote]

Maybe a silly question, but couldn't you just use BLE for all the links? Make one device a concurrent central/peripheral, and use this as a relay between the phone and the other device?

[quote user="mej7000"]This Sample is brilliant and 90% of what I was looking for. Thanks! [/quote]

I'm very happy to hear you found it useful 🙂

I hope to have some time eventually to clean it up a little, make the app_bt module a bit more full featured, and remove the need to change the SDK files directly.

Best regards
Torbjørn

RE: esb, shockburst, running on nrf5340dk's

mej7000 — Sat, 17 Feb 2024 10:25:05 GMT

I reflashed a nrf52832 and still didn't get the BLE advertising. As I have done in the past, I was using LightBlue, but switched over to nRF Connect (which automatically upgraded to the latest version). "Nordic_MPSL_LBS" showed up in the list. I switched back to LightBlue thinking LightBlue was the problem and "Nordic_MPSL_LBS" showed up there as well! I killed all the apps and reflashed the 52832 and it showed up right away in both. I can't seem to get it not to work!

It's not entirely clear why it started working, but now I can't break it, so something seems to have resolved my problem. Makes no sense to me that one App upgrade would make a difference, but that was the only change I recognized...?

The LED's don't respond at all, neither in Advertising nor on ButtonPress, but the Button1 seems to notify its status over BLE. ESB data is exchanged between two 52832's (monitored in serial). I see what you mean that although the two are working there is no connection between BLE and ESB data.

I am curious about this. Yes, I did read that, but I can't find esb_peripherals.h in my local repo or on yours. Am I doing something wrong?

[quote userid="2116" url="~/f/nordic-q-a/107827/esb-shockburst-running-on-nrf5340dk-s/468866"]

Did you make the change in esb_peripherals.h as mentioned in the log?

Essentially you need to replace SWI0 with SWI3 in this file:

[/quote]

This Sample is brilliant and 90% of what I was looking for. Thanks! Switching to nrf52 did seem to make it easier, but that is probably because I am still figuring out how to work the nrf53.

My goal now is to send data and commands through BLE and a ESB star network

Data Flow: ptx(child)->prx(parent)->BLE->App
Command Flow: App->BLE->prx/ptx(parent)->ptx/prx(child)

I would think that would make a killer Nordic Sample/Solution for a lot of users. I have done something similar with ESP32 using UART peripheral.

What you provided already has been invaluable and gets me very close to what I need. If you have any more suggestions or guidance on getting to my ultimate goal please let me know. thanks, mike

RE: esb, shockburst, running on nrf5340dk's

ovrebekk — Wed, 14 Feb 2024 14:46:36 GMT

Hi Michael

[quote user="mej7000"]It seems that --board nrf5340dk_nrf5340_cpuapp_ns doesn't work, but --board nrf5340dk_nrf5340_cpuapp works.[/quote]

Yes, the nrf5340dk_nrf5340_cpuapp_ns board hasn't been tested and is unlikely to work properly.

[quote user="mej7000"]I am not getting Nordic_lbs advertising.[/quote]

The device will advertise a different name, as set in prj.conf:

CONFIG_BT_DEVICE_NAME="Nordic_MPSL_LBS"

You can't see this device either?

[quote user="mej7000"]There doesn't seem to be any ESB communication happening.[/quote]

Did you make the change in esb_peripherals.h as mentioned in the log?

Essentially you need to replace SWI0 with SWI3 in this file:

/** The ESB event IRQ number when running on an nRF5 device. */
#define ESB_EVT_IRQ        SWI3_IRQn
/** The handler for @ref ESB_EVT_IRQ when running on an nRF5 device. */
#define ESB_EVT_IRQHandler SWI3_IRQHandler

I hope to find a better way to fix this in a future update. Now that I think if it maybe I can undef and redefine these somehow in the application files, to avoid having to change the SDK files.

[quote user="mej7000"]ptx appears to be sending 8 times, before generating errors.[/quote]

The application FIFO is 8 items large, which is why it appears to work 8 times. In reality none of the messages are being sent, which usually means there is no PRX enabled to pick up the packets. Alternatively it could be an issue if you didn't change the SWI definition as mentioned above.

[quote user="mej7000"]Also, I am not committed to using 5340 if you think a single core (nrf52832?) would work easier/better?[/quote]

Using the nRF52 series is definitely easier. Unless you have a need for the additional performance or peripherals of the nRF5340 I would recommend sticking to one of the nRF52 devices.

If you still can't find the issue based on my input above I will take a look at your build and see if I can spot the issue.

Best regards
Torbjørn

RE: esb, shockburst, running on nrf5340dk's

mej7000 — Tue, 13 Feb 2024 11:25:12 GMT

Thanks. Here is what I found with the BLE/ESB demo.

I flashed peripheral_lbs sample to the 5340 to make sure I understood the sample. peripheral_lbs worked as expected. I could both read btn1 and set led3.

C:\nrf\ncs-esb-ble-mpsl-demo:
It seems that --board nrf5340dk_nrf5340_cpuapp_ns doesn't work, but --board nrf5340dk_nrf5340_cpuapp works.

I included a screen shot and rezipped the demo, although I didn't modify anything I did do 3 nrf5340 builds, so in case I did something wrong there...

I am not getting Nordic_lbs advertising.
There doesn't seem to be any ESB communication happening.
ptx appears to be sending 8 times, before generating errors.

Also, I am not committed to using 5340 if you think a single core (nrf52832?) would work easier/better? Ultimately, all I need to do is have one "parent" in the network that relays ESB data to a BLE peripheral and to the App. The "child" nodes will only run ESB in a star topology. In the past (other hardware) I have used a proprietary protocol with one device additionally running a BLE UART to pass data to the App.

nrf52832

I had better luck with nrf52832 builds. ESB communications happened right away, but I am still not getting any BLE advertising. I included my version with both 5340 and 52832 builds.

devzone.nordicsemi.com/.../ncs_2D00_esb_2D00_ble_2D00_mpsl_2D00_demo-_2800_2_2900_.zip

RE: esb, shockburst, running on nrf5340dk's

ovrebekk — Mon, 12 Feb 2024 20:22:45 GMT

Hi Michael

[quote user="mej7000"]

CONFIG_ESB_MAX_PAYLOAD_LENGTH=64

tx_payload.length = 64;

[/quote]

Looks good. tx_payload.length can be changed from payload to payload, but should be no larger than CONFIG_ESB_MAX_PAYLOAD_LENGTH. The data buffer will be sized according to the CONFIG_ESB_MAX_PAYLOAD_LENGTH parameter.

[quote user="mej7000"]

It looks like I just need to flash the following and counter data moves from ptx->prx->BLE?

flash app_netcore to 5340 cpunet(s)
flash prx and ptx to the cpuapp(s)

[/quote]

There is no link between the ESB and BLE functionalities in the current example, any ESB -> BLE link would have to be added. The BLE functionality is just a straight port of the peripheral_lbs sample in the SDK.

Otherwise I agree with your summary 🙂

Best regards
Torbjørn

RE: esb, shockburst, running on nrf5340dk's

mej7000 — Mon, 12 Feb 2024 09:21:00 GMT

"CONFIG_CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING was assigned the value y, but got the value n. Missing dependencies: SOC_SERIES_NRF52X"

...

[quote userid="2116" url="~/f/nordic-q-a/107827/esb-shockburst-running-on-nrf5340dk-s/468246"]For larger payloads this macro can't really be used, you would have to assign data to the tx_payload.data[] buffer in some other way. [/quote]

Thanks. I was surprised to see the macro limited to 63 and feared I was misunderstanding something.

As a test I did the following, which seems to work fine:

CONFIG_ESB_MAX_PAYLOAD_LENGTH=64

tx_payload.length = 64;

I think I am ready to start with the BLE/ESB sample.

[quote userid="2116" url="~/f/nordic-q-a/107827/esb-shockburst-running-on-nrf5340dk-s/466507"]You will find a separate sample for the nRF5340 netcore, while the prx and ptx sample can be built either for the nRF5340 appcore, or for one of the nRF52 devices. [/quote]

It looks like I just need to flash the following and counter data moves from ptx->prx->BLE?

flash app_netcore to 5340 cpunet(s)
flash prx and ptx to the cpuapp(s)

RE: esb, shockburst, running on nrf5340dk's

ovrebekk — Fri, 09 Feb 2024 14:37:26 GMT

Hi Michael

Can you confirm that the issues with the CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING configuration occur when you're building for the nRF5340?

It seems this configuration is only supported for the nRF52 series, not the nRF53. I will need to check what the recommended way is for enabling this on the nRF53 side and get back to you.

[quote user="mej7000"]I would think that ESB_CREATE_PAYLOAD would need to support up to 252 characters, but maybe I am misunderstanding?[/quote]

The ESB_CREATE_PAYLOAD macro is just a convenience macro for easily defining a static payload in the code. It uses another macro under the hood to handle a dynamic number of arguments (for the data bytes), and this macro is limited to 63 input variables.

For larger payloads this macro can't really be used, you would have to assign data to the tx_payload.data[] buffer in some other way.

Best regards
Torbjørn

RE: esb, shockburst, running on nrf5340dk's

mej7000 — Wed, 07 Feb 2024 18:57:50 GMT

Thanks. I was able to compile successfully. However it generated the following warning...

"warning: The choice symbol CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING (defined at
drivers/clock_control/Kconfig.nrf:51) was selected (set =y), but CLOCK_CONTROL_NRF_K32SRC_XTAL
(defined at drivers/clock_control/Kconfig.nrf:37) ended up as the choice selection. See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING and/or look up CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING in the menuconfig/guiconfig interface. The Application Development Primer, Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful too."

I don't really understand what the setting actually does and I couldn't find an explanation anywhere... closest I found was this in devzone:

"Since you are using an oscillator instead of a low frequency crystal, try configuring the oscillator to EXT_FULL_SWING or EXT_LOW_SWING(depending on the oscillator)."

I also found these alternatives settings:

# CONFIG_CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING=y
# CONFIG_CLOCK_CONTROL_NRF_K32SRC_EXT_LOW_SWING=y
# CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
# CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y

It seems CLOCK_CONTROL_NRF_K32SRC_EXT_FULL_SWING is related to the type of clock source and that XL2 floating is not a problem... Can you help me understand what these options are for?

Also, (from the ptx sample) is this the best way to define the payload?

static struct esb_payload tx_payload = ESB_CREATE_PAYLOAD(0,

0x01, 0x00, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08);

based on the ptx sample it appears that if I want a payload of char[40] I would have to do the following:

static struct esb_payload tx_payload = ESB_CREATE_PAYLOAD(0,

0x01, 0x00, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A,

0x01, 0x00, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A);

And, if ESB_CREATE_PAYLOAD .payload - "Comma separated list of character data to put in the TX buffer. Supported values consist of 1 to 63 characters." What happens if your ESB_MAX_PAYLOAD_LENGTH is longer than 63, like 128?

CONFIG_ESB_MAX_PAYLOAD_LENGTH=128

config ESB_MAX_PAYLOAD_LENGTH

int "Maximum payload size"

default 32

range 1 252

help

The maximum size of the payload.

I would think that ESB_CREATE_PAYLOAD would need to support up to 252 characters, but maybe I am misunderstanding?