This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Available hardware/board options to deploy a mesh network ?

Hi, I'm planning to do thesis on BLE Mesh using Nordic Semiconductor. I tried to setup a generic OnOff server using two Thingy:52s and nRF Mesh app by following the Mesh SDK documentation, and bricked those Thingy52s. I'm aware of the two github demo repos for using Mesh with Thingy52s but they're obsolete at this point. Coming to the point, are there any other hardware options(besides nrF52 DK) that work with the examples available in Mesh SDK documentation ? What about the nRF52840 dongle ?

Parents
  • What about the nRF52840 dongle

    Yes, the dongle is great for deploying stuff - but not great for developing on.

    For developing, you should get the nRF52840 Development Kit - the clue is in the name!

    For developing your mesh node code, you probably need 3 dev kits.

    Then, for deployment, you can use the dongles.

    But, as far as the actual mesh comms goes, you can use any board with an nRF52832 or 52840 on it.

  • Thanks for the pointers. Highly appreciate it. However, I've got some more questions now.

    For developing, you should get the nRF52840 Development Kit - the clue is in the name!

    Any significant advantage as opposed to developing on nRF52832 SoC with external J-Link debugger ? Is it because the examples/demos on the official documentation need not be modified when using DK ?

    For developing your mesh node code, you probably need 3 dev kits.

    Could you shed some light on it ? Client, Server and Provisioner ? What if I use NRF Mesh app for provisioning ?

    Then, for deployment, you can use the dongles.

    So, do I need to write code on DK targetting the dongles (since GPIO on dongle and DK have different addresses and such) ?

  • crypt3d said:
    Any significant advantage as opposed to developing on nRF52832 SoC with external J-Link debugger ? Is it because the examples/demos on the official documentation need not be modified when using DK ?

     This, as well as that the DK (both nRF52840 and nRF52832) can be used as a debugger itself, and that it has already mounted LEDs, buttons and headers. The nRF52840 DK is easier to use if you're planning on porting the application to the nRF52840 Dongle. 

    crypt3d said:
    Could you shed some light on it ? Client, Server and Provisioner ? What if I use NRF Mesh app for provisioning ?

     Most Bluetooth Mesh examples require at least two supported boards (client and server), as well as one provisioner (this can be a DK or the nRF Mesh mobile app). 

    crypt3d said:
    So, do I need to write code on DK targetting the dongles (since GPIO on dongle and DK have different addresses and such) ?

    Our Dongle Programming Tutorial explains very well how you can port a 10056 (nRF52840DK) example to the nRF52840 Dongle.

    Best regards,

    Simon

  • has provided excellent answers to your questions.

    One extra comment:

    do I need to write code on DK targetting the dongles (since GPIO on dongle and DK have different addresses and such)

    Yes, when writing the code you need to bear in mind that you have two different targets for the code.

    This is a common situation in firmware development (and software generally).

    The key thing is not to hard-code dependence on any particular platform, but to make this easily configurable.

    The Nordic SDK supports this by providing the various board files - which map specific board hardware to "generic" names.

    Both Segger Embedded Studio (SES) and Keil uVision provide means to do this - with multiple target "configurations" in a single project.

    If you're not familiar with doing this, I suggest that you practice on some simple projects which just use the board features like buttons, switches, and LEDs - no BLE or Mesh!

Reply
  • has provided excellent answers to your questions.

    One extra comment:

    do I need to write code on DK targetting the dongles (since GPIO on dongle and DK have different addresses and such)

    Yes, when writing the code you need to bear in mind that you have two different targets for the code.

    This is a common situation in firmware development (and software generally).

    The key thing is not to hard-code dependence on any particular platform, but to make this easily configurable.

    The Nordic SDK supports this by providing the various board files - which map specific board hardware to "generic" names.

    Both Segger Embedded Studio (SES) and Keil uVision provide means to do this - with multiple target "configurations" in a single project.

    If you're not familiar with doing this, I suggest that you practice on some simple projects which just use the board features like buttons, switches, and LEDs - no BLE or Mesh!

Children
No Data
Related