Mesh LE Coded

RE: Mesh LE Coded

ifrz — Tue, 08 Jun 2021 10:03:28 GMT

Well these results are more convincing.
I think this is a clear confirmation that I am using coded which I think is not related to the way I provisioned them, probably due to a different particular error.

devzone.nordicsemi.com/.../ble_5F00_P2_2D00_na.pdf devzone.nordicsemi.com/.../ble_5F00_P1_2D00_na.pdf

It shows how at -15 and -12 dBm with coded it receives many more packets (at -12 it doesn't lose any) while with legacy it only received 1 at -15 and lost 57% at -12. This is also interesting for some energy harvesting projects where we have modules running at -40 dbm.

The point is that I was quite confused by the RSSI of the DK, I'm not a telecom expert but bluetooth has an operating range where you move away a bit and it drops considerably but then stays there as you move away (arround -80,-90 dBm) and this is something I've seen on nRF5x based boards as well as other bluetooth modules, but with the DK the RSSI seems more linear, maybe it's calculated differently? I know that the main difference in the range is due the PA/LNA module of the DK because the pcb antenna is not a big deal either. It is curious that the sensitivity for 1M is only -95 dBm according to datasheet.

In any case this part was the urgent one. I'm going to mark it as solved and I'll continue with the second part, depending on the progress I get I can comment it here.

RE: Mesh LE Coded

Mttrinh — Tue, 01 Jun 2021 14:33:25 GMT

Hi,

Yes, I guess it is probably better to focus on packet reception rather than relying on RSSI. Like you said is not really a reliable parameter as it depends of a lot of factors in your environment(like radio interference, signal/multi-path reflections, and loss in the antenna layouts).

On another note, like you mentioned above long range/Coded PHY is not supported in the mesh specification. The idea with a mesh network is that you should be able to cover more ground by adding more nodes to the network. By using the relay feature you can get a longer range.

RE: Mesh LE Coded

ifrz — Mon, 31 May 2021 19:43:44 GMT

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.

RE: Mesh LE Coded

ifrz — Mon, 31 May 2021 15:33:48 GMT

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.

RE: Mesh LE Coded

Mttrinh — Mon, 31 May 2021 10:06:08 GMT

Hi,

Sorry for the late reply.

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

RE: Mesh LE Coded

ifrz — Sun, 30 May 2021 21:46:43 GMT

Ok I think I know what my problem was, initially I wasn't sure that the radio_mode parameter was set only when provisioning the module, I thought it could be changed after provisioning it, at least with the power it seems to be possible. So for convenience I used the Android app nrf mesh to provision the nodes, obviously the app doesn't deal with phy coded. But after reviewing the sample code of the mesh sdk provisioner I saw that it used these libraries that are modified with the patch so I used another DK to provision the nodes again and it seems that now I can see an improvement in the RSSI.

I guess the next step is try to set the advertising type of the mesh as Coded to see if I can communicate directly with the smartphone instead of connecting another board by serial to work as a bridge for the smartphone.

RE: Mesh LE Coded

ifrz — Thu, 27 May 2021 21:06:10 GMT

Ups silly of me, I just noticed that I had the following code wrong in broadcast.c that's why it didn't work when I made the last change of the patch.

I have this

static inline ts_timestamp_t time_required_to_send_us(const packet_t * p_packet, uint8_t channel_count, radio_mode_t radio_mode)
{
    static const uint8_t radio_mode_to_us_per_byte[RADIO_MODE_END] =  {8, 4, 32, 8
                                                            #ifdef NRF52_SERIES
                                                                           ,4, 64
                                                            #endif
                                                                           }; //128
    uint32_t packet_length_in_bytes = BLE_PACKET_OVERHEAD(RADIO_MODE_BLE_1MBIT) + p_packet->header.length;
#ifdef NRF52_SERIES
    if (radio_mode == RADIO_MODE_BLE_2MBIT)
    {
        packet_length_in_bytes += RADIO_PREAMBLE_LENGTH_2MBIT_EXTRA_BYTES;
    }
#endif
    uint32_t radio_time_per_channel = RADIO_RAMPUP_TIME +
                                      (packet_length_in_bytes * radio_mode_to_us_per_byte[radio_mode]) +
                                      RADIO_DISABLE_TO_DISABLED_DELAY_US;
    if (radio_mode == RADIO_MODE_NRF_62K5BIT)
    {
        //__LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "long range preamble\n");
        packet_length_in_bytes += RADIO_PREAMBLE_LENGTH_LR_EXTRA_BYTES;
    }
    return (BROADCAST_SOFTWARE_OVERHEAD_US + USR_SOFTWARE_OVERHEAD_US + radio_time_per_channel * channel_count);
}

I put the "if" of RADIO_MODE_NRF_62K5BIT after set the radio_time_per_channel if I put the "If" before this variable works without error with 64 but no futher improvement in range

RE: Mesh LE Coded

ifrz — Thu, 27 May 2021 19:59:48 GMT

devzone.nordicsemi.com/.../3821.files.zip