SDK UART coexistence example problem

RE: SDK UART coexistence example problem

Marte Myrvold — Mon, 19 Oct 2020 11:51:19 GMT

Hi Marry,

[quote user="Marry"]What do you mean by this?[/quote]

BLE and Bluetooth Mesh work differently, so things like how the network is set up (BLE is one-to-one communication, different provisioning, etc.), the services (mesh models vs. GATT Services), and the stacks are different. You can check out this case which discuss this a bit.

[quote user="Marry"]Do you think this is a good idea? Do you have other suggestions of what I should take care of? [/quote]

As I stated, it's a lot of work to do combine BLE and mesh. However, it's a case of "you shouldn't do it if you don't have to" and not "you shouldn't do it at all", so it's possible to do so. It just requires some work and you need to know what you're doing and be aware that you risk degrading the mesh traffic.

If you only wanted to turn on/off the light, I would recommend using the mesh light switch example directly, but you can also see if it's possible to implement what you can do in that example. I recommend you read about mesh models. Models define the behavior and communication formats of all data that is transmitted across the mesh. There are several different models in the SDK, for instance the generic OnOff model, which is used to set the OnOff value. I don't know what characteristic you want to implement in the Blinky example, but it could be that you find something to use for it in one of the models. You can read about mesh models here, and you can find the API for mesh models here.

Best regards,

Marte

RE: SDK UART coexistence example problem

Marry — Mon, 19 Oct 2020 05:45:39 GMT

Hello Marte!

[quote userid="92402" url="~/f/nordic-q-a/65991/sdk-uart-coexistence-example-problem/274872#274872"]as they are two different protocols[/quote]

What do you mean by this? 🙂

[quote userid="92402" url="~/f/nordic-q-a/65991/sdk-uart-coexistence-example-problem/274872#274872"]unless necessary[/quote]

It is indeed kind of necessary for my use case to use the mesh, because I'd like to have a lot of such relays, to extend the range. And the information would travel without a specific destination from one end to another; instead, when a phone is in nearby, it would receive the notification immediately. (from my understanding, that's when I would use a mesh topology).

[quote userid="92402" url="~/f/nordic-q-a/65991/sdk-uart-coexistence-example-problem/274872#274872"] one node that has both BLE and mesh[/quote]

- Yes, that is exactly what I had in mind. And this is why I am trying to add the Blinky part into the Mesh Client part. My approach would be to add a characteristic to the mesh client code, with the same properties as the Blinky example. This BLE Characteristics tutorial gave me this idea.

Do you think this is a good idea? Do you have other suggestions of what I should take care of?

Thank you!

RE: SDK UART coexistence example problem

Marte Myrvold — Wed, 14 Oct 2020 11:47:51 GMT

Hi Marry,

It's not recommended to combine BLE and mesh unless necessary, as they are two different protocols, and therefore it's a lot of work to get them to work together, and you also risk a worse connection on the mesh side. If you were to combine them you would need one node that has both BLE and mesh, and that node would have to switch between the two protocols in order to communicate with both the mesh and BLE devices. If you want to use mesh, you should instead use mesh examples on all devices and then implement the functionality for toggling the light, such as in the Blinky example, yourself.

However, if using mesh is not important to you, I would recommend you take a look at the BLE Relay example instead. As stated in the documentation, the example acts as a relay that receives values and passes them on. The example uses a sensor as peripheral and a collector as central, but you should be able to get it to work with BLE blinky.

Best regards,

Marte

RE: SDK UART coexistence example problem

Marry — Tue, 13 Oct 2020 15:02:17 GMT

Thanks Ms. Marte Myrvold! You are indeed helpful!

As a matter of fact, I will ask one further question, since you seem to understand my questions very well. My goal for some good weeks/months has been to implement the Blinky Application and to extend its range. After doing some trials, I came to the conclusion that one solution could be the following:

- On one end: phone with the Blinky Application, receiving notifications from an nRF52840 far-away

- On the other end: an nRF52840, sending notifications (via the button push)

- In between: Nordic Thingy:52 devices, loaded with the mesh example. Because when they are configured as servers(aka LEDs), they relay the messages, so that's very convenient, for my purpose of extending the range :)

Now, my question is the following: how should I integrate these two functionalities? The Blinky for the end-devices and the mesh for the middle devices?

If I load them separately, then the Nordic Thingy:52 devices do not relay the messages. And this is normal, because for the relaying, the group addresses are assigned from the phone first. Whereas for the Blinky Application, we do not assign any address; the phone just scans for the board and then connects to it.

I hope that I presented my problem as clear as possible.

Thanks a lot and I wish you a great day!

RE: SDK UART coexistence example problem

Marte Myrvold — Tue, 13 Oct 2020 13:22:57 GMT

Great that you managed to get it to work!

Good luck with your development, and don't hesitate to ask if you happen upon any new problems. 🙂

Best regards,

Marte

RE: SDK UART coexistence example problem

Marry — Tue, 13 Oct 2020 13:10:41 GMT

UPDATE: I build successfully the project.

I just restarted SES, the laptop etc. Thanks a lot for your help, I'm looking forward to the next challenge 🙂

RE: SDK UART coexistence example problem

Marry — Tue, 13 Oct 2020 13:01:04 GMT

Hello! And thank you very much for the quick reply!

I tried with SDK16 and I have the same error unfortunately - and it persits for every project in the Mesh folder. Very strange.

[quote userid="92402" url="~/f/nordic-q-a/65991/sdk-uart-coexistence-example-problem/274627#274627"]SDK Mesh v4.2.0 and SDK v16.0.0[/quote]

I have the same set-up as you. I wonder if I missed other setting from SES. But from my perspective, it should be fine.

RE: SDK UART coexistence example problem

Marte Myrvold — Tue, 13 Oct 2020 12:18:29 GMT

Hi Marry,

The examples in nRF5 SDK for Mesh v4.2.0 are built for nRF5 SDK v16.0.0, so I can't guarantee that they'll work with v17.0.2. When I tested the coexistence example I used SDK Mesh v4.2.0 and SDK v16.0.0, and it worked, so switching to 16.0.0 might fix your problem.

If you want to use v17.0.2 you should look at the release notes for v17.0.2 as well as the migration guide in order to figure out what was changed between the two releases. Someone had a similar problem when trying to build an example built for v17.0.0 with v17.0.2, so you could try out the solution by Simon to that problem, which can be found here.

Best regards,

Marte

RE: SDK UART coexistence example problem

Marry — Tue, 13 Oct 2020 11:47:17 GMT

Hi Marte Myrvold! I have some updates and a question about my progress.

I installed SDK Mesh 4.2.0 and SDK 17.0.2, so that I can run the nRF52833 example.

Unfortunately I get this error and it happens for all projects in my newer Mesh folder.

Do you have any idea why this happens? It's an unmodified version, downloaded from the official website.

As a note, I have included the correct path from Options - Building - global macros. 🙂

Thank you in advance!

RE: SDK UART coexistence example problem

Marry — Thu, 08 Oct 2020 13:53:18 GMT

Hi!

Thank you, again extremely helpful answer! The only difference is that I was using SDK Mesh version 3.2.0. And there was no support for this board. But now I had a look over the newer version and I see that they support nrf52833_xxAA. I will try this now, thank you!! 🥇

RE: SDK UART coexistence example problem

Marte Myrvold — Thu, 08 Oct 2020 13:34:24 GMT

Hi Marry,

I'm happy to help!

If you're programming light_switch_client_nrf52832_xxAA to your nRF52833 DK you will get problems, as that project is for the nRF52832, and should be used if your board is a nRF52 DK. Instead, you should use light_switch_server_nrf52833_xxAA, which is for the nRF52833 DK. The hardware and layout of the DKs are different, so the buttons and LEDs are connected to different GPIOs, and as such, the buttons and LEDs on the nRF52833 DK will not work as expected with a project for another DK. For instance, LED 1 is P0.13 on the the nRF52833 DK, while on the nRF52 DK LED 1 is P0.17. If you want to, you can find the tables for the buttons and LEDs here and here for the nRF52833 DK and nRF52 DK respectively.

Thank you, and have a great day yourself!

Best regards,

Marte

RE: SDK UART coexistence example problem

Marry — Thu, 08 Oct 2020 12:31:18 GMT

Hi Ms. Marte Myrvold and thank you very much for the complete and well documented answer!

I have not answered so far, because I have been waiting for another Development Board, to try the set-up which you proposed. 🙂

So my setup is now: 3 Development boards, from which 2 are nRF52840 and one is nRF52833. Unfortunately, it seems more difficult than I thought, to run the mesh on the nRF52833.

I loaded the light_switch_client_nrf52832_xxAA project and it does advertise in the nRF Mesh App 🆗so it looks like to code is successfully flashed and the board is responsive. However, neither the button (for the client code), nor the LED (for the server code) are responding. I have a guess that it may only be a problem of I/O routing, that is solvable from the code.

Do you have an idea how I could make this?

Thank you very much and I wish you a nice day! 🌞

RE: SDK UART coexistence example problem

Marte Myrvold — Thu, 24 Sep 2020 10:05:24 GMT

Hi,

I'm sorry for the late reply. I had to test this example myself and it took some time.

The guide can be a bit confusing when it comes to the last part with the light switch example, but I will try to explain the process here.

You need two DKs, one for the light switch server example and one for uart coexistence example.
Build and flash the light switch server example as explained in the guide for the example on one of the DKs.
Instead of flashing light switch client to the second DK, you should instead flash the SDK uart coexistence example to it, after following the guide for the example (copying the ble_app_uart_coexist folder to examples/ble_peripheral in nRF5 SDK etc.)

I just tested that this works. However, I used the provisioner example in the nRF Mesh SDK instead of the Mesh app as it fixes everything with provisioning so you don't have to do it manually, which you have to do with the nRF Mesh app. In order to test it with the provisioner example like I did, you should do the following:

Build and flash light switch server and uart coexistence on two DKs as explained above.
Build and flash the provisioner example on a third DK. I did not have to change or do anything with the example for it to work as intended.
Turn on the three DKs and press button 1 on the provisioning board in order to start the provisioning process.
When LED 1 on the provisioning board remains lit steadily for a few seconds, all available boards have been provisioned and configured, and you can start testing the example.
Open nRF Connect app on your phone and connect to NORDIC_UART (which is the uart coexistence board)
Simulate button presses on the uart coexistence board by sending a number (1-4) to it using the nRF Connect App. You will then see the LEDs on the light switch server board are turned on and off. For example, sending 1 will turn on LED1, and 2 will turn it off. You can also check that this is the same as when you press buttons 1 and 2 on the uart coexistence board.

I hope this helps you understand how to test this out.

As for the question about the uart coexistence example not working with the nRF Mesh App. This is because the nRF Mesh app does provisioning over GATT, since smart phones don't support provisioning or Mesh activity over ADV. However, the uart coexistence example does not use GATT (both GATT proxy and GATT provisioner bearer are disabled). This is likely because the example is a combination of mesh and BLE examples, so you already have BLE+mesh there, and the the GATT proxy functionality will make it so you kind of get an additional instance of BLE. You could try to implement GATT provisioning and functionality in the example yourself, but I don't know if it will work, and I wouldn't recommend it.

Best regards,

Marte

RE: SDK UART coexistence example problem

Marry — Tue, 22 Sep 2020 10:51:06 GMT

I see in this post that "SDK UART coexistence example does not work with nRF Mesh APP. You need find some other provisioning ways..." - So, I wonder: is this true ❓

Could you test this project successfully ❔

RE: SDK UART coexistence example problem

Marry — Tue, 22 Sep 2020 10:00:27 GMT

Ms. Marte Myrvold, is it possible that I did not do the last step from the coexistence example correctly?

I just replaced the .hex file:

Is there some other trick? Thanks!

RE: SDK UART coexistence example problem

Marry — Mon, 21 Sep 2020 13:33:20 GMT

Hi Ms. Marte Myrvold,

I sucessfully built the SDK UART coexistence example and now I am trying to test it - but I am not successful.

What I'd like to do is to :

1. First connect to the nRF board with the nRF Mesh App (then assign it with some address). And afterwards,

2. Check the UART functionality by sending some data from the phone to the board. And visualise that with putty.

Unfortunately, none of the steps works. I cannot connect with nRF mesh from the phone. And also in the nRF connect, I cannot find the option for writing into a characteristic, which should send the message to the board and then see it with putty.

Maybe the Mesh Proxy Data In should be the answer for step number 2. However, nothing pops up in putty, so I would say that the board does not receive this message.

Do you have any idea how to debug this problem?

Thanks in advance!

RE: SDK UART coexistence example problem

Marte Myrvold — Thu, 17 Sep 2020 12:30:19 GMT

Hi,

Great to hear that you managed to solve the problem yourself!

Yes, with the coexistence examples you have to copy the example folders to the nRF5 SDK folder and build it from there, as you did.

There's also a guide about integrating mesh into nRF5 SDK examples here, which can be useful if you experience any new problems. However, with the coexistence examples, I don't think you should have to do everything under "Including nRF5 SDK for Mesh functionality in an nRF5 SDK example", as the files and folders should already be included. At least they were when I tested the example earlier.

Hope you're able to run the example without any problems now.

Best regards,

Marte

RE: SDK UART coexistence example problem

Marry — Thu, 17 Sep 2020 12:05:43 GMT

Problem solved.

Solution: the project needs to be run from ...\nRF5_SDK_1530\examples\ble_peripheral\ble_app_uart_coexist\pca10040\s132\ses (not from the Mesh folder).

RE: SDK UART coexistence example problem

Marry — Thu, 17 Sep 2020 11:41:50 GMT

Hi. Trying to build the example (did not do any modification), these errors occur:

The problem is that the components folder does not even exist in the Mesh folder, but rather in the other one (SDK folder). And the global macros in SES are defined as:

SDK_ROOT=C:\SESProj\nRF5_SDK_1530

MESH_ROOT=C:\SESProj\nrf5_SDK_for_Mesh_v320

Do you have any clue why this happens? Thanks.

RE: SDK UART coexistence example problem

Marry — Wed, 16 Sep 2020 13:40:47 GMT

Ok, I get it, thank you.

RE: SDK UART coexistence example problem

Marte Myrvold — Wed, 16 Sep 2020 13:31:51 GMT

Hi,

The Output folder in .../pca10040/s132/ses/ and all the files in it are generated when you build your project. Try building the ble_app_uart_coexist example in SES. The folder, and then also the .hex file, should be then generated, and you should be able to find the file.

Best regards,

Marte