• State Verified Answer
  • +8 person also asked this people also asked this
  • Replies 36 replies
  • Subscribers 78 subscribers
  • Views 23024 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 129801
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

change phy in mesh

kassianson

I'm working with the nRF52840 PDK and I'm wondering how to change the PHY (preferably to CODED) in a Mesh. Has that been implemented yet? Or when can we expect this feature?

Parents
  • 0

    Although this is not yet added to the standard or supported from Nordic, I think this possibility add many new use cases where Bluetooth Mesh can be used (industrial, smart city etc).

    Would be interesting yo know if anyone tried this out? We will for sure test it as soon as possible!

    Additional comment:

    We have a real smart city use case where we are going to test mesh. The idea is exactly as you say David, we intent to start with coverage test using non coded PHY but I would be good to have the long range option at hand if needed (and I see risk for it in this case).

    BTW, nice to meet with you again, David. Been a while since we worked on Automation IO ...!

  • 0 in reply to matsublox

    The existing mesh should be capable of being used for smart city/industrial use cases as it is not so sensitive to packet losses as a connection oriented link. The nRF52840 using the 1Mbit channel for advertising and a 8dbm output power is quite capable of delivering in that direction. The longer coded phy packet is more possible to be corrupted but it does have FEC for handling some of the corrupted bits. Ideally I would go for a mesh over coded PHY if clear data is present that the existing BTLE mesh does not fit a specific usecase, this means doing range tests with existing mesh before we consider coded phy.

Reply
  • 0 in reply to matsublox

    The existing mesh should be capable of being used for smart city/industrial use cases as it is not so sensitive to packet losses as a connection oriented link. The nRF52840 using the 1Mbit channel for advertising and a 8dbm output power is quite capable of delivering in that direction. The longer coded phy packet is more possible to be corrupted but it does have FEC for handling some of the corrupted bits. Ideally I would go for a mesh over coded PHY if clear data is present that the existing BTLE mesh does not fit a specific usecase, this means doing range tests with existing mesh before we consider coded phy.

Children
No Data
Related