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

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

  • 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?

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

  • 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

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

  • Any luck with the nRF Sniffer yet?

    Is it possible to reproduce the connection that you want to sniff using a DK?

    Another thing that is supported in BLE5.0 is longer MTU in the packets (longer payload per packet, basically), but this was also available in BLE 4.2 (and even before this). However, it is not mandatory to support this. E.g. the softdevice for the nRF51 series only supports 23 bytes, while the Softdevice for the nRF52 supports 251 bytes. Maybe this is what your sniffer can't follow?

    Search for NRF_SDH_BLE_GATT_MAX_MTU_SIZE in your nRF project, and try to set it to 23, and see if your sniffer can follow then.

    Now, this would possibly start to change the behavior of your application (it may not), but if you are sending a lot of data, decreasing this variable will reduce the performance, so it might not behave as it does with NRF_SDH_BLE_GATT_MAX_MTU_SIZE = 247.

    I recommend giving the nRF Sniffer a go.

    Best regards,

    Edvin

  • Hi Edvin,

    I couldn't get through the nRF sniffer. I do have PCA10056 ad trying to use it as nRF sniffer.

    In this forum I find all broken information regarding the sniffer and I am lost in it. Can you please point me to the exact and genuine source from which I can get the nRF sniffer rolling?

    I did tried changing NRF_SDH_BLE_GATT_MAX_MTU_SIZE to 23 bytes but it still didn't work. 

    works only when the controller is at BLE 4.2. If the controller/master uses 5.0 I am not able to sniff. 

    I would definitely like to evaluate nRF sniffer if that can suffice my needs.

    Regards,

    Justin

Reply
  • Hi Edvin,

    I couldn't get through the nRF sniffer. I do have PCA10056 ad trying to use it as nRF sniffer.

    In this forum I find all broken information regarding the sniffer and I am lost in it. Can you please point me to the exact and genuine source from which I can get the nRF sniffer rolling?

    I did tried changing NRF_SDH_BLE_GATT_MAX_MTU_SIZE to 23 bytes but it still didn't work. 

    works only when the controller is at BLE 4.2. If the controller/master uses 5.0 I am not able to sniff. 

    I would definitely like to evaluate nRF sniffer if that can suffice my needs.

    Regards,

    Justin

Children
Related