• State Verified Answer
  • Replies 9 replies
  • Subscribers 67 subscribers
  • Views 2828 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 233922
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE 4.2 softdevice s132

Justin

I need BLE 4.2 softdevice and SDK for PCA10056 PD board. I don't want 5.0 and restrict to 4.2.

Please let me know from where can I download the one.

Parents
  • 0

    Hello,

    I don't know whether you are aware of it, but BLE 5.0 is backwards compatible, so you don't need to restrict yourself to a strict BLE 4.2 softdevice. All the features in 5.0 are optional, and you can chose to not support any of them. If you do support some of them, but want to communicate with a device that doesn't support that feature (a 4.2 device) then they will simply not use that feature.

    The reason I don't just point to a BLE 4.2 softdevice is that there are continuous improvements and bugfixes in the softdevices, so going back to a 4.2 only softdevice may also cause some unwanted behavior.

    So I would recommend to use the latest softdevice, which is included in SDK15.3.0. If you want to, you can turn off support for High speed (2MBPS) in the project. Long range is not supported by the nRF52832. 

    If you for some other reason need to use a BLE 4.2 only softdevice, you need to use a softdevice S132 older than v5.0.0. S132v5.0.0 is the first softdevice that supports BLE5.0 (note that it is only a coincidence that S132v5.0.0 is BLE5.0).

    SDK13.1.0 is the last SDK that used S132v5.0.0.

  • 0 in reply to Edvin

    Hi Edvin,

    Thanks for looking into my case and providing valuable solution and information.

    I totally agree with you that BLE 5.0 is backward compatible. My problem is I am using Teledyne BPA600 Sniffer and it has restriction only upto BLE 4.2. We are facing other issues in the project so want to perform analysis using this sniffer. So only for the purpose of sniffer for time being want to go back to 4.2

    Else do you know features on BLE 5.0 that can be disabled so that it can behave like 4.2 and my BPA600 can work?

  • 0 in reply to Justin
    Justin said:
    My problem is I am using Teledyne BPA600 Sniffer and it has restriction only upto BLE 4.2. We are facing other issues in the project so want to perform analysis using this sniffer. So only for the purpose of sniffer for time being want to go back to 4.2

     I understand. It makes sense. Larger MTU sizes than 23 was introduced in BLE4.2, so that should also be fine as long as your sniffer supports BLE4.2. So the only things I can think of from a sniffer perspective is the PHY. BLE4.2 as only 1MBPS, while BLE5 has 1MBPS, 2MBPS and CODED_PHY (125kBPS). 

    If you are sniffing for a debugging purpose, and you don't want to port your project to an older softdevice (possibly port the entire project to an older SDK), then I can recommend the nRF Sniffer. You can use any DK as HW for this.

    But first, I would try to search for "2MBPS" in your project. Don't worry about CODED_PHY, since this is not supported by the nRF52832 HW. 2MBPS will appear in a handful of files, but I believe it is only used in ble_gap.h (at least in SDK15.3.0):

    #define BLE_GAP_PHYS_SUPPORTED  (BLE_GAP_PHY_1MBPS | BLE_GAP_PHY_2MBPS) /**< All PHYs except @ref BLE_GAP_PHY_CODED are supported. */

    Basically, unless you have done something in your project to specifically advertise or scan on 2MBPS, it will use 1MBPS initially. If you don't call sd_ble_gap_phy_update(), then the only way that the phy updates is if the other part of the connection wants to update. This you can approve or deny within the BLE_GAP_EVT_PHY_UPDATE request:

            case BLE_GAP_EVT_PHY_UPDATE_REQUEST:
        {
            NRF_LOG_DEBUG("PHY update request.");
            ble_gap_phys_t const phys =
            {
                .rx_phys = BLE_GAP_PHY_AUTO,
                .tx_phys = BLE_GAP_PHY_AUTO,
            };
            err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
            APP_ERROR_CHECK(err_code);
        } break;

    By changing BLE_GAP_PHY_AUTO to BLE_GAP_PHY_1MBPS, it will stay on 1MBPS.

    Have you tested this with your sniffer? Is it still not able to follow the connection?

  • 0 in reply to Edvin

    I am able to get the advertisement packets and can see the connection as well on sniffer. But after that couldn't see the data. I tried changing BLE_GAP_PHY_AUTO to  BLE_GAP_PHY_1MBPS but still sniffer doesn't catch data after the connection is done. Looks like there are some features of 5.0 that is blocking the sniffer to sniff and analyze the data.

    I used a board that supports only BLE 4.2 and connected to current nRF52832 having SDK 15.0. In this case I could see all the packets on sniffer. Looks like during initial negotiation the peripheral board connects with BLE 4.2 and supports only the features of 4.2 as the Central is 4.2 based.

    Looks like must be a sniffer application issue.

    I will try nordic sniffer as well. Do let me know if there is any other way tweaks by which I can make my current SDK pretend like 4.2.

    Thanks for your support. I really appreciate that.

  • 0 in reply to Justin

    Does your application use bonding?

    If the devices are already bonded, then the sniffer will not be able to sniff the exchange of keys, and will not be able to decrypt the messages, and thus not be able to follow the channel hopping. If you are using bonding, then you can try to delete the bonding information from both devices, and they will either:

    1: Exchange keys over the air, which the sniffer should be able to pick up (At least the nRF Sniffer does this. I am not familiar with the sniffer that you use).

    2: If you have to input a 6-digit key on one of your devices, you may input the same key into the sniffer (at least on nRF Sniffer).

    3: If you are using LESC, then the link is not sniffable. Are you using this?

    So are you using bonding or pairing in your application?

    Best regards,

    Edvin

  • 0 in reply to Edvin

    The application doesn't have bonding or key exchange. All these features are disabled.

Reply Children
Related