• State Verified Answer
  • Replies 8 replies
  • Subscribers 87 subscribers
  • Views 1325 views
  • Users 0 members are here
Attachments (3) Download All
Nordic Case Info
  • Case ID: 270714
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Mesh LE Coded

ifrz

Hello everybody

I have some nrf52840-DKs and other boards with the same module and I want to create a LE Coded mesh with these boards, I am aware that the BLE Mesh standard is for BLE Legacy it's just a proof of concept as LE Coded has given us good results in the same environment. I have seen that this is something that has been commented on several times in this forum. I have tried to use the patch that is commented in this old thread but it does not seem to work for me, apart from the modifications discussed there I also changed the power, this seems to work because I see a notable difference between using RADIO_POWER_NRF_0DBM and RADIO_POWER_NRF_POS8DBM which tells me that it is changing the power even though with the regular SDK I use softdevice to change these parameters instead of modify these registers.

However with the rest of the changes it is only works without the last change but seems to be the same as I test with 2 DKs at same position and orientations and results are almost the same Coded or Legacy. If I set the last change (5th element in radio_mode_to_us_per_byte[] from 128 to 64.) gives me an error.

app_error_weak.c,  105, Mesh assert at 0x0003BB20 (:0)

This belong to the following line

nordic_sdk/sdk_mesh/mesh/bearer/src/bearer_handler.c:162 (discriminator 1)

Which is also commented here

I don't know what the problem could be, I believe I have set all correctly, maybe in newer versions of the Mesh SDK something has been changed and this patch doesn't work.

I'm testing with the mesh sensor example, the SDK version is 17.0.2 and the SDK for Mesh is 5. The code of the project is attached as well

Another doubt I have is if I understood the mesh architecture correctly, there is on one hand the communication between the different nodes of the mesh (which I try to change to Coded) and on the other hand an advertisement that through the nodes that works as a proxy it serves as an entry point to the mesh for e.g. a mobile device.

I have a One Plus 8T with which I tested long range beacon and ble uart coded and it works flawlessly. My idea was that the advertisement of the mesh should also be Le Coded to take advantage of the support of the smartphone. I didn't test it too much I tried to change in mesh_adv.c the primary and secondary PHY for Coded along with some change of buffers sizes and intervals but it didn't work, I understand that the main problem to deal with Coded is the bigger preamble and time on air of the frames. In any case this last one is secondary if it is possible to do it perfect if not I simply connect by serial another board that forward the information in beacon long range or something Le Coded that the mobile can read perfectly.

Thanks in advance

Best regards

Parents
  • 0

    Hi,

    Sorry for the late reply.

    It seems like you have been able to solve your issue? 

  • 0 in reply to Mttrinh

    Hi

    To be honest, I'm not sure. Last week I was testing in two different points with a specific orientation of the DKs and I got RSSI values between -83 and -94. When I provisioned them through a DK with the provisoner code with the changes on the libraries, I got values between -65 and -71. But I'm trying to put them again with LE 1M in the same scenario and I get the same RSSI, I tried to provision them both with the app and with the original code of the mesh SDK (I only changed the power to 8dBm in advertiser.c and scanner.c) but I see that it comes out the same. My idea is to make a comparison between the RSSI with Coded and LE 1M but it is complicated to debug it like this, it is necessary to have them in two fixed points and observe the differences, it would be good that apart from seeing the RSSI in the nodes could also see the radio mode to have no doubts.

  • 0 in reply to ifrz

    OK, I think I should approach the experiments in a different way. As I understand it, the advantage of coded is that it puts more data in the header which allows you to decode the signal over a longer distance using the same power.  In other words, for example, if in legacy you receive a packet with -98 dbm at one point and move a bit further away and don't receive anything, with coded it is possible to receive it with -105 dbm (it will depend on the sensitivity of the board). My idea is to test in places that are a bit at the limit with legacy to see if it is better received with coded but it is probably better to focus on packet reception than on rssi as it is done here.

    I don't know very well why last week I received that difference in values, it's true that humidity and those things affect the propagation, especially for centrimetric waves, but now I'm receiving those values and they are very good so it doesn't seem to be in a critical area of reception and in that case I shouldn't see any difference between coded and legacy, it may even be worse in coded, I checked this with the smartphone with examples of advertising, I guess it may be because with coded it has 8x more time on air.

    So what I would do is to reduce the power and find places where it is more at the limit and maybe measure the packets received with one or the other.  The problem is that when I test examples of the normal SDK I can see on the mobile what kind of advertising it is. For mesh I'm a bit more blind, the only thing I can do to make sure I'm using coded is to move at least one node around and see that the reception distance is greater, because the RSSI is not a reliable parameter for this case either.

Reply
  • 0 in reply to ifrz

    OK, I think I should approach the experiments in a different way. As I understand it, the advantage of coded is that it puts more data in the header which allows you to decode the signal over a longer distance using the same power.  In other words, for example, if in legacy you receive a packet with -98 dbm at one point and move a bit further away and don't receive anything, with coded it is possible to receive it with -105 dbm (it will depend on the sensitivity of the board). My idea is to test in places that are a bit at the limit with legacy to see if it is better received with coded but it is probably better to focus on packet reception than on rssi as it is done here.

    I don't know very well why last week I received that difference in values, it's true that humidity and those things affect the propagation, especially for centrimetric waves, but now I'm receiving those values and they are very good so it doesn't seem to be in a critical area of reception and in that case I shouldn't see any difference between coded and legacy, it may even be worse in coded, I checked this with the smartphone with examples of advertising, I guess it may be because with coded it has 8x more time on air.

    So what I would do is to reduce the power and find places where it is more at the limit and maybe measure the packets received with one or the other.  The problem is that when I test examples of the normal SDK I can see on the mobile what kind of advertising it is. For mesh I'm a bit more blind, the only thing I can do to make sure I'm using coded is to move at least one node around and see that the reception distance is greater, because the RSSI is not a reliable parameter for this case either.

Children
No Data
Related
Terms of service