esb, shockburst, running on nrf5340dk's

[mej7000]

I have 3 nrf boards connected. 2x nrf52832 and 1x nrf5340.

esb_tx is running on nrf52832(682782977)
esb_rx is running on nrf52832(682497942) & nrf5340(1050025410)

west build -b nrf5340dk_nrf5340_cpunet -p builds correctly and flashes without error

PS C:\nrf\esb_prx> west flash -d build_1
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner nrfjprog
There are multiple boards connected.
1. 1050025410
2. 682782977
Please select one with desired serial number (1-2): 1
-- runners.nrfjprog: Flashing file: build_1\zephyr\zephyr.hex
[ #################### ] 2.055s | Erase file - Done erasing
[ #################### ] 0.243s | Program file - Done programming
[ #################### ] 0.243s | Verify file - Done verifying
Applying pin reset.
-- runners.nrfjprog: Board with serial number 1050025410 flashed successfully.

esb_rx is working on the nrf52, but not on the nrf53.

... To be through, I powered down esb_tx_nrf52832(682782977) and flashed another nrf5340dk(1050077823) and programmed it to be esb_tx:

PS C:\nrf\esb_ptx> west flash -d build_1
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner nrfjprog
There are multiple boards connected.
1. 1050025410
2. 1050077823
3. 682497942
Please select one with desired serial number (1-3): 2
-- runners.nrfjprog: Flashing file: build_1\zephyr\zephyr.hex
[ #################### ] 2.044s | Erase file - Done erasing
[ #################### ] 0.235s | Program file - Done programming
[ #################### ] 0.236s | Verify file - Done verifying
Applying pin reset.
-- runners.nrfjprog: Board with serial number 1050077823 flashed successfully.

Although 1050077823 (nrf5340-esb_tx) flashed correctly. Blinky continues to run (as it already had) on nrf5340-esb_tx, which probably makes sense, but I'm not getting any kind of esb response from either (nrf52832 or nrf5340) esb-rx.

There is something I am not understanding about how to flash to nrf5340_CPUNET? Maybe it's flashing correctly, but esb needs to be called from CPUAPP to start it working?? I'm close, but missing something...

Ultimately the goal is to have a network of nrf5340's in a Star configuration. I see that there is shared memory between CPUAPP and CPUNET. I assume somehow it's used to pass data from CPUAPP to CPUNET for transmission/reception. I don't exactly understand how that works either, but I figure the first step is to get the esb Sample to work on nrf5340dk's without modification. But, if there are additional samples that target this use case I would be interested in reviewing those too.

The final configuration goal is to have the center of the star network also be running BLE-UART (so the central esb in the Star Network will relay the esb data from the nodes to a BLE app). I am assuming that there is no problem running both esb and BLE at the same time.

esb_prx_ptx.zip

[ovrebekk]

Hi Michael

mej7000 said:

CONFIG_ESB_MAX_PAYLOAD_LENGTH=64

tx_payload.length = 64;

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. 

mej7000 said:

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

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

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

[mej7000]

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...

1. I am not getting Nordic_lbs advertising.
2. There doesn't seem to be any ESB communication happening.
3. 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.

ncs-esb-ble-mpsl-demo (2).zip

[ovrebekk]

Hi Michael

mej7000 said:

It seems that --board nrf5340dk_nrf5340_cpuapp_ns doesn't work, but --board nrf5340dk_nrf5340_cpuapp works.

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

mej7000 said:

I am not getting Nordic_lbs advertising.

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? 

mej7000 said:

There doesn't seem to be any ESB communication happening.

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.

mej7000 said:

ptx appears to be sending 8 times, before generating errors.

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. 

mej7000 said:

Also, I am not committed to using 5340 if you think a single core (nrf52832?) would work easier/better?

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

[mej7000]

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? 

ovrebekk said:

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:

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

1. Data Flow: ptx(child)->prx(parent)->BLE->App
2. 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

[ovrebekk]

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. 

mej7000 said:

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? 

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. 

mej7000 said:

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. 

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? 

mej7000 said:

This Sample is brilliant and 90% of what I was looking for. Thanks!

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

[mej7000]

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...

ovrebekk said:

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? 

we have:

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

Given the above my thought was that:

1. BLE connection to App
2. Shockburst with "parent" uptime preloaded into ACK
3. "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.

[ovrebekk]

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

[mej7000]

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.

ovrebekk said:

How many devices would you typically have for each gateway?

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...

[ovrebekk]

Hi

mej7000 said:

I think (if I understand ESB correctly) I can have all communication happen on PTX0?

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. 

mej7000 said:

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

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

mej7000 said:

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?

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

[mej7000]

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.

ovrebekk said:

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.

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.