Sensor example

[Rewbert]

Hi,

So the IoModule is quite restricted in what it can do. I don't mind writing a SensorModule of my own, but are there any examples of using sensors with/on a nrf52840dk board to be seen anywhere? I saw something that might be related in FruityHalNrf.cpp but it is quite a large file that feels a little overwhelming.

Thanks!

[mariusheil]

Hello,

yes, the IoModule cannot do a lot. We have some sensor samples, but cannot open source these due to the nature of most of the used drivers. You can however easily use examples from the nRF SDK as FruityMesh builds on top of that. The StatusReporterModule is doing battery measurements, which is basically a sensor.

Yes, the FruityHalNrf abstracts everything that is platform specific, so it is quite big.

Marius

[mariusheil]

Hi, we expect to be working on an example firmware for the ruuvi tag in January. If that works out as intended we will release a sample. In the meantime, you should be able to integrate any driver you like by simply adding it to the build. It works the same as if you were integrating a driver with the Nordic SDK. The sdk_config is available in the Github project as well.

[leonwilly]

I find myself in this situation also. I am developing an advanced individual room HVAC zoning system. My house is the prototype (using 433mhz sensors currently) and I just received custom PCB's with the NRF52811 with an array of sensors for the final product. I am working on the firmware right now. I know the range won't be an issue in my house, but I worry in future installations I might run into excessive radio noise or building materials that reduces the range. Having a mesh (relay) builtin would resolve this issue. I have scoured Github and Google for examples of using FruityMesh with sensors and have come up short. I am at a point where I either continue without this feature and address it later in an update or implement FruityMesh from the beginning. It would be fantastic if you had a bare Sensor / Beacon example to use as reference. Thanks

[mariusheil]

Hi, have you managed to get FruityMesh running on this chipset? We do not officially support it as it is quite memory constrained. You have to use the S140 SoftDevice to have central and peripheral support but the latest version takes around 150kb of the flash memory and you will surely need around 40-50kb for FruityMesh. Being limited to 192KB of flash and 24kb of RAM will make it very tough for you to develop your application. You will also not be able to update the firmware.

As for the sensors, we will try to publish some examples / tutorial / .... in the near future. Do you have any specific sensor in mind?

[leonwilly]

Marius, I should of said thank you first for developing this and choosing to publish it as open source. the sensors were supposed to be populated with the NRF52832 but i decided I wanted long range support. Unfortunately the PCB had already been manufactured but luckily wasn’t populated. The NRF52840 didn’t come in the package layout required for the PCB instead of scrapping I elected to try the NRF52811. I knew the memory constraints would be an issue. I planned to circumvent this by transmitting raw sensor values and doing the calibration / conversion / calculations on the gateway. Version one of this sensor contains a gyro / accelerometer for motion. An ambient light sensor, microphone, pressure sensor, temperature and humidity. The idea is the sensors are mounted on the inside door of the room. I will fuse the data from the microphone / ambient light and motion sensor to determine room presence. Also using the light sensor I will attempt to estimate the affect of solar radiation to preemptively heat / cool the room. The pressure sensor tracks the change in pressure do to increase air flow. But the sensor will simply transmit the data on a 10 second interval accept for motion data which will advertise immediately.

…

On Mon, Jan 18, 2021 at 1:31 AM Marius Heil ***@***.***> wrote: Hi, have you managed to get FruityMesh running on this chipset? We do not officially support it as it is quite memory constrained. You have to use the S140 SoftDevice to have central and peripheral support but the latest version takes around 150kb of the flash memory and you will surely need around 40-50kb for FruityMesh. Being limited to 192KB of flash and 24kb of RAM will make it very tough for you to develop your application. You will also not be able to update the firmware. As for the sensors, we will try to publish some examples / tutorial / .... in the near future. Do you have any specific sensor in mind? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#161 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AECM5CQULQZTLIZQDD2ZUIDS2PPU3ANCNFSM4UTFBA4A> .

[mariusheil]

Have you checked if the nRF52833 is available in your packaging?

[leonwilly]

I will change the PCB after the prototype on the next run. I initially purchased 30. Maybe I can revisit this when the time comes. I do have a 58240 & 58232 board I could test it on though. I also could port this over too the Apache NimBLE framework which allows you to only compile what you need unlike the soft device. I have a parallel development going on that framework to compare power drain. It compiles to about 86kb of flash with debug information. They support Mesh and Bluetooth 5.0.

…

On Tue, Jan 19, 2021 at 7:00 AM Marius Heil ***@***.***> wrote: Have you checked if the nRF52833 is available in your packaging? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#161 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AECM5CVBE47XHTGO5JVEUE3S2V67FANCNFSM4UTFBA4A> .

[mariusheil]

Just as a follow up to this ticket. we are currently working on open sourcing a small project that can be used with ruuvi tags, this will still take a few weeks until we can make it public but work is ongoing.

[leonwilly]

Excellent news! I might attempt to port this to MyNewt NimBLE in hopes of reducing memory usage with unused soft device features. Do you foresee any reasons it wouldn't be doable?

…

On Thu, Jan 28, 2021 at 8:29 AM Marius Heil ***@***.***> wrote: Just as a follow up to this ticket. we are currently working on open sourcing a small project that can be used with ruuvi tags, this will still take a few weeks until we can make it public but work is ongoing. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#161 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AECM5CXWMYGKWCONKHHTWWTS4FYDPANCNFSM4UTFBA4A> .

[mariusheil]

Hi,

porting it to NimBLE will most likely work but I would guess that there will be quite a lot of work involved until everything is ported. We have ported FruityMesh to another chipset internally and I can tell you that the FruityHal is nicely portable, but it will take some time.

[leonwilly]

Marius, Okay since I have the beacon firmware working with the NRF SDK without mesh I'll get started on porting it. Thanks, Gabe

…

On Thu, Jan 28, 2021 at 2:20 PM Marius Heil ***@***.***> wrote: Hi, porting it to NimBLE will most likely work but I would guess that there will be quite a lot of work involved until everything is ported. We have ported FruityMesh to another chipset internally and I can tell you that the FruityHal is nicely portable, but it will take some time. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#161 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AECM5CROSM5FWUTGQKWNIYDS4HBHTANCNFSM4UTFBA4A> .

[mariusheil]

Hello, I'll close this as there has not been any more feedback. Feel free to reopen it.