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

How to get data from Thingy 52 for Mesh Demo?

Hi all,

I found the demo for BLE Mesh is interesting and great for displaying the functionalities of BLE in a mesh network:

https://github.com/NordicPlayground/Nordic-Thingy52-mesh-demo

It eventually come to the question that how could I get the data from the mesh demo. (Please forgive me if I asked a basic question).

I have read FAQs from Devzone that there are people who asked about getting data, i.e. we can get RSSI in method handle_status_cb and time data (RTT) by accessing the method client_status_cb. Let's say we have for the demo the mobile app nRF Mesh and two thingys. We provision and connect the thingy with the app in a mesh network. After we reprogrammed the firmware of mesh demo for getting the data we want. How can we get the display of the data (RSSI, RTT etc.)? Do we need a raspberry pi for display? Could we export the data by somehow reprogramming nRF Mesh?

Thank you so much!

Kindly,

WHui

Parents
  • Hello WHui,

    The demo you refer to is not a very stable demo, unfortunately, and it is based on a quite old SDK. I suggest that you look into a later demo, such as this one, or even better, one of the latest SDKs for Mesh, v3.x.0.

    Basically, we don't have an example that does exactly what you want to do. Time data (RTT?) will not be real time, as the nodes in a Mesh network don't have a common timer or real time clock. RSSI values is possible to get from a message, but as you may or may not know, a received message in a Mesh Network is not necessarily received from the original transmitter, but it may be a retransmit from a node in between. Let us say that you have 3 nodes, A, B and C, and A is in range for B, and B is in range for C, but A and C is out of range. Then all messages between A and C is only heard as retransmits from B. 

    Now, since both Raspberry Pis and mobile phones don't speak Bluetooth Mesh, you would need to have a gateway node, speaking both BLE and Bluetooth Mesh. Note that both the server and client in the light_switch folder in SDK for Mesh v3.X.0 speaks both BLE and Mesh, but they only use the BLE part for commissioning. If you want to transfer information from the network to a BLE device, you must implement this in a BLE service. 

    Check out this ticket to see how you can get RSSI values from a Mesh message:

    https://devzone.nordicsemi.com/f/nordic-q-a/42545/light-switch-mesh-client-to-server-and-vica-versa-rssi-value

    Best regards,

    Edvin

Reply
  • Hello WHui,

    The demo you refer to is not a very stable demo, unfortunately, and it is based on a quite old SDK. I suggest that you look into a later demo, such as this one, or even better, one of the latest SDKs for Mesh, v3.x.0.

    Basically, we don't have an example that does exactly what you want to do. Time data (RTT?) will not be real time, as the nodes in a Mesh network don't have a common timer or real time clock. RSSI values is possible to get from a message, but as you may or may not know, a received message in a Mesh Network is not necessarily received from the original transmitter, but it may be a retransmit from a node in between. Let us say that you have 3 nodes, A, B and C, and A is in range for B, and B is in range for C, but A and C is out of range. Then all messages between A and C is only heard as retransmits from B. 

    Now, since both Raspberry Pis and mobile phones don't speak Bluetooth Mesh, you would need to have a gateway node, speaking both BLE and Bluetooth Mesh. Note that both the server and client in the light_switch folder in SDK for Mesh v3.X.0 speaks both BLE and Mesh, but they only use the BLE part for commissioning. If you want to transfer information from the network to a BLE device, you must implement this in a BLE service. 

    Check out this ticket to see how you can get RSSI values from a Mesh message:

    https://devzone.nordicsemi.com/f/nordic-q-a/42545/light-switch-mesh-client-to-server-and-vica-versa-rssi-value

    Best regards,

    Edvin

Children
  • Hello Edvin,

    thank you so much for your reply. It is very complete.

    I see. I thought that device which support BLE (e.g. Raspberry Pi) could be provisioned in a Bluetooth Mesh network and could forward or receive the messages like a relay node. I was wrong.

    If I understand you correctly, using BLE part only for commissioning means that the server and client do not forward the messages inside Bluetooth Mesh to the BLE-supporting device (while staying connected via BLE) right?

    Speaking of the gateway that speak both BLE and Mesh to connect Thingys and Raspberry, I've found online that BlueZ seems to be promising. (https://blog.bluetooth.com/bluez-on-raspberry-pi). Or do you have other better suggestions?

    Thanks again Edvin!

    Best regards,

    WHui

  • BlueZ may be one way to go. You would however need a gateway node, translating the information from Mesh to BLE. BlueZ would just act as a BLE device, and you can use pretty much anything for this. I am not very familiar with BlueZ, but you can do anything using nRF Connect for Mobile or nRF Connect for Desktop, to get started. That way, you can develop what you need before you add the Raspberry Pi into the mix.

    Now. You need a gateway node that supports BLE and Mesh. The Coexistence example from the Mesh SDK v3.X.0 is a project where developed for a DK (not Thingy by default). This is an application that you can provision, that also runs the Nordic Uart Service (NUS), that you can use to send custom text strings over BLE. 

    By default this examples checks whether the first character of a string is "1","2","3" or "4" (0x31, 0x32, 0x33 or 0x34) and sends the mesh message that corresponds to that button press on the DK (it is acting as a light switch). You should be able to port this to run on a Thingy, since the BLE part doesn't care whether the buttons are actually present, but you would probably have to do some minor changes in the project. Start by removing the preprocessor define BOARD_PCA10040 (nRF52DK) and add the preprocessor define BOARD_PCA20020 (Thingy:52).

    Please note that this application by default is not able to be provisioned by the nRF Mesh application, as this app is filtering on advertisement UUIDs. You can either use the provisioner project from the SDK, or change the advertising packets to match the light_switch\client example.

    Best regards,

    Edvin

  • Hello Edvin,

    Thank you so much for your explanation! Everything is clear for me now. I will implement the coexistence example that you've suggested.

    Best regards,

    WHui

Related