mesh with external sensor

[edwardcchan]

Sorry I am newbie to the mesh but I want to see if there is any example I can refer for broadcasting i2c sensor data in the mesh?

Thanks very much

[trond-snekvik]

Hi there,

For sensor data gathering (over I2C or otherwise), I'd recommend you look at the Nordic nRF5 SDK. Its TWI Master library should fit your needs.

Next, you have to push this onto the mesh. I'd recommend starting with the examples, and the BLE Gateway example is the most complete one. Understand what it's doing (look at the mesh framework documentation in the docs folder), and try tweaking it to see what's happening. The easiest approach is usually to just adopt the example to fit your needs.

[edwardcchan]

Hi there, Thanks for your advise. I’ve been trying to follow Integrating the framework with existing Softdevice Applications but it is outdated and I had several steps that I cannot follow. The files in the root directory is not echoing with the document. Is the BLE gateway example in the mesh code workable for such sensor implementation? Do you have some existing code in hand so that I can try it on? Appreciated for the help!!

…

On 31 Mar 2017, at 7:58 PM, Trond Einar Snekvik ***@***.***> wrote: Hi there, For sensor data gathering (over I2C or otherwise), I'd recommend you look at the Nordic nRF5 SDK <https://developer.nordicsemi.com/>. Its TWI Master library <http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v13.0.0/hardware_driver_twi.html?cp=4_0_0_2_16> should fit your needs. Next, you have to push this onto the mesh. I'd recommend starting with the examples, and the BLE Gateway example is the most complete one. Understand what it's doing (look at the mesh framework documentation in the docs folder <x-msg://5/tree/master/docs/>), and try tweaking it to see what's happening. The easiest approach is usually to just adopt the example to fit your needs. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#173 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZklPmyX1v2Jpkxd2yMYnJo-q5diRZbBks5rrOpZgaJpZM4MvaO5>.

[trond-snekvik]

The BLE gateway is the generic minimal application with an added GATT connection. You can set whatever data you want for it.

I'd recommend a divide and conquer approach to your problem. Get comfortable with the two problems you're facing individually, before trying to send sensor data over the mesh. Once you're comfortable with the how mesh communication works, and have an I2C reader set up, you can start trying to add these two together.

[thedjnK]

Is the BLE gateway example in the mesh code workable for such sensor implementation? Do you have some existing code in hand so that I can try it on?

Yes it is, it's trivial to take an I2C example and transplant it into the BLE gateway example depending on when you want the sensor readings to be updated. For example in main() you can setup a timer which upon expiration, opens the I2C interface, exchanges commands with the I2C slave and updates the handle, then closes the I2C interface and goes back to low power mode. As @trond-snekvik said, there isn't much of a problem making a solution for this, the problem I had (and I spent days on it) was getting the I2C code working (I've came from other embedded systems where the I2C interfaces are different) and it took some time of trial and error to successfully be able to read from and write to my I2C device. If you're just reading from a sensor, look up the data sheet for the sensor, it'll show you the exact commands to send (remember that you don't use the 8-bit address for the nordic SDK, you use 7-bit addresses and it automatically adds the 0 or 1 depending on if you're reading or writing) and what the type of data you receive back should be, I would recommend using the simple normal blocking-mode I2C functinality unless you have a specific need for interrupt driven callbacks.

Remember to setup the I2C interface in your sdk-config.h file or makefile and check the error codes if you get any as they can help point you in the right direction. If you encounter an issue whereby you try reading from an address and it fails then you try again and it enters a loop in one of nordic's I2C files then it's likely you've neglected to open the I2C interface, if you try using it without opening it you won't get an error it'll just sit inside the I2C function forever.

[edwardcchan]

Thanks for the advice. Is there any way I can get those sensor reading from the mesh on PC terminal?

…

On Thu, Apr 6, 2017 at 5:22 AM, thedjnK ***@***.***> wrote: Is the BLE gateway example in the mesh code workable for such sensor implementation? Do you have some existing code in hand so that I can try it on? Yes it is, it's trivial to take an I2C example and transplant it into the BLE gateway example depending on when you want the sensor readings to be updated. For example in main() you can setup a timer which upon expiration, opens the I2C interface, exchanges commands with the I2C slave and updates the handle, then closes the I2C interface and goes back to low power mode. As trond-snekvik said, there isn't much of a problem making a solution for this, the problem I had (and I spent days on it) was getting the I2C code working (I've came from other embedded systems where the I2C interfaces are different) and it took some time of trial and error to successfully be able to read from and write to my I2C device. If you're just reading from a sensor, look up the data sheet for the sensor, it'll show you the exact commands to send (remember that you don't use the 8-bit address for the nordic SDK, you use 7-bit addresses and it automatically adds the 0 or 1 depending on if you're reading or writing) and what the type of data you receive back should be, I would recommend using the simple normal blocking-mode I2C functinality unless you have a specific need for interrupt driven callbacks. Remember to setup the I2C interface in your sdk-config.h file or makefile and check the error codes if you get any as they can help point you in the right direction. If you encounter an issue whereby you try reading from an address and it fails then you try again and it enters a loop in one of nordic's I2C files then it's likely you've neglected to open the I2C interface, if you try using it without opening it you won't get an error it'll just sit inside the I2C function forever. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#173 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZklPhFocTBgqpBsGsBFcST6qcTu2Mfkks5rtAYNgaJpZM4MvaO5> .

[trond-snekvik]

Yes, this is typically done with UART, or if you're running on a Nordic devkit or dongle, you can try Segger RTT, which is already integrated with the mesh framework.

[edwardcchan]

Thanks for your advice. Is there any guide for integrating the UART to the mesh framework? Sorry for the noob question but we have been trying out for weeks to do so but failed

[thedjnK]

@edwardcchan The UART is already interfaced with the mesh framework, check the nRF52/rbc_mesh/src/mesh_aci.c source file and you'll see how UART (it can also work with SPI) commands are received by the module and processed. If you want to send an asyncronous UART command not in response to data from the other side you can see how the mesh code does this, for example in nRF52/rbc_mesh/src/version_handler.c with code such as mesh_aci_rbc_event_handler() which then gets sent out of the UART.

I personally would recommend that you use the ACI system that the mesh already has to manipulate the UART instead of using your own UART code, that way you can leverage setting the mesh up and reading values without having to code all those functions yourself, and adding new functions/responses is trivial: the command codes go in nRF52/rbc_mesh/include/serial_command.h and nRF52/rbc_mesh/include/serial_evt.h and then you just add the case statements to the equivalent c files and process the commands as you wish.