• State Not Answered
  • Replies 1 reply
  • Subscribers 24 subscribers
  • Views 77 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 290583
Options
nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs

Using CODED_PHY for DFU

user88603

Hi All,

We have been using NRF52 products for a few years now and currently doing an PoC of using the BLE DFU with a CODED_PHY.

Our solution does use the DFU already but as we want to be able to use the same range as the product, I'm looking at how and to what level this would be achievable when using CODED_PHY (S=8) for the DFU as well.

I could not find much information about this (just some posts about Mesh-DFU), but looking at the DFU code I did not initially see any big roadblocks so decided to give it a go. To be able to use debugging (RTT) I've grown the flash space a little and included the relevant libraries which is working well.

To make it work, I had to obviously set the advertising parameters to BLE_GAP_CODED_PHY and also change from BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED to BLE_GAP_ADV_TYPE_EXTENDED_CONNECTABLE_NONSCANNABLE_UNDIRECTED (in nrf_dfu_ble.c).

Initial testing works, i.e. I can upload a new image successfully, but was worried that a BLE_GAP_EVT_PHY_UPDATE may be issued by the DFU loader app, and it still actually using the 1MBPS_PHY. I have validated the work as following

  • Check with NRF-Connect that both the primary and secondary phy are configured as LE Coded
  • Check the debug output of the DFU to see if a PHY change was requested - none are seen
  • Compared upload time between 1MB and CODED_PHY.  CODED_PHY was significantly slower as expected
  • Tried using a phone which does not support CODED_PHY - does not work although this may not be conclusive if a PHY change happens.
  • Check the log output of the DFU app using the NRF-Logger app. - I can see there is a request for preferred phy 1MB/2MB but I don't see a response on that. (and as per my point above, no logs about this being received/actioned on the DFU).

I don't have a good BLE Sniffer to see if the packets are actually CODED or not so just wondering if someone else has tried the same, and if there are any better ways to confirm this.

Also, is there a good way to check the current configured parameters of the SoftDevice? I can't see a method to actually request this. Would the the ble_gap_adv_params_t struct that is passed to the SD at init be updated if the PHY is changed?

Thanks in advance, and happy to share some more info if required.

Cheers

J

  • 0

    Hi,

    The central device will normally not request a PHY update when the connection is established with CODED PHY as in your case (central must establish the connection using the same PHY as the secondary adv. channel). But if you do get this request during the connection, then you can always just reply with BLE_GAP_PHY_CODED to reject it:

    You can also monitor the BLE_GAP_EVT_PHY_UPDATE event. This event will be raised if the PHY is updated: PHY Update Procedure.

    I don't have a good BLE Sniffer to see if the packets are actually CODED or not so just wondering if someone else has tried the same, and if there are any better ways to confirm this.

    Just want to add that the nRF Sniffer does support coded PHY if you use it with one of the supported boards:

    Also, is there a good way to check the current configured parameters of the SoftDevice? I can't see a method to actually request this. Would the the ble_gap_adv_params_t struct that is passed to the SD at init be updated if the PHY is changed?

    A phy update will only change the link parameters for a given connection session. It will not affect your configuration of the Softdevice.

    Best regards,

    Vidar

Related
Terms of service