Tag, Battery & Core Module with bcf-kit-wireless-climate-monitor

eggze · December 20, 2017, 8:17pm

Hello,

I have a question. I have Core Module, Tag Module and Battery Module, all in R1.3. I connected following tags: Lux R1.1, Barometer R1.1, Temperature R1.2 and Humidity R1.1 and R2.1.

I uploaded latest bcf-kit-wireless-climate-monitor firmware. Every tag works except Humidity. I’ve tried one by one and neither revision of Humidity tag works for me. Is there something I could “tune” in the firmware source code to make it work? I would like to reuse this older and bigger version of climate module from the beginning of the BigClown project. Is it even possible with the latest firmware?

Also I noticed that battery module reports 0.0 value even I put fresh batteries inside.

Thanks for your help.

hub.martin · December 20, 2017, 9:25pm

Hello,
the “kit” firmwares only support the sensor that comes in the kit. We choosed this way to create simplier and smaller firmware. So the kit only supports the sensors that are on the Climate Module. Please see the initialization of them in https://github.com/bigclownlabs/bcf-sdk/blob/8405d08d70cce52a5745d7a3ad48f4a96d324455/bcl/src/bc_module_climate.c#L33

In case you would like to use other humidity tags and revision, you have to also initialize them. Good example is to take a look at generic firmware where you can see that you need to pass a revision parameter. https://github.com/bigclownlabs/bcf-generic-node/blob/master/app/application.c#L204

We changed the sensor from R1 to R2 so humidity tags are a little bit tricky to deal with.

Now to the battery module. In the kit there’s a Mini Battery Module and the code only initializes this module. Do you use big battery module for 4 AAA? In this case you would also need to change initialization code, please see https://github.com/bigclownlabs/bcf-kit-wireless-climate-monitor/blob/master/app/application.c#L140

For all sensors we suggest the most universal generic-node firmware. Is there a reason why you can’t use it?
In case any other issues, it would be great to see your code so we could debug it.
Martin

eggze · December 21, 2017, 3:27pm

Ok, understand I didn’t realize that climate firmware can be used only with kit, now I know… Thanks to your hints I was able to modify bcf-sdk and bcf-kit-wireless-climate-monitor accordingly and now everything works.

I briefly checked the source code of generic-node firmware but it seems to me it’s doing more than I actually need (I don’t have LED strip & CO2). But at least I was able to find how to initialize humidity sensor properly.

So thank you, now it’s exactly as I want

For inspiration, here’s what I had to change:

hub.martin · December 22, 2017, 12:11am

You can use generic-node firmware. The sensors which are not connected just don’t send any data so don’t worry.

Regarding the SDK change you did. I would suggest to call the right API in application.c. Editing the SDK is not good idea because in the future you could not update it.

I would suggest adding to your aplication.c code initialization of the TAG with the correct parameter REVISION value. As it is done in generic. Init TAG, update interval, then set handler:

github.com

bigclownlabs/bcf-generic-node/blob/master/app/application.c#L406


else
{
    return;
}


if (i2c_channel == BC_I2C_I2C1)
{
    tag->param.channel |= 0x80;
}


bc_tag_humidity_init(&tag->self, revision, i2c_channel, BC_TAG_HUMIDITY_I2C_ADDRESS_DEFAULT);


bc_tag_humidity_set_update_interval(&tag->self, HUMIDITY_TAG_UPDATE_INTERVAL);


bc_tag_humidity_set_event_handler(&tag->self, humidity_tag_event_handler, &tag->param);
}


static void lux_meter_tag_init(bc_i2c_channel_t i2c_channel, bc_tag_lux_meter_i2c_address_t i2c_address, lux_meter_tag_t *tag)
{
memset(tag, 0, sizeof(*tag));

eggze · December 22, 2017, 9:59am

Yes, you’re right it’s not good to make changes directly into SDK. It was just a quick hack, I just wanted it to work…

Originally I thought I would copy the bc_module_climate logic from SDK into my application.js and update the part I need for humidity. I will see, once I have some time I will improve it so I can use “pure” SDK…

Regarding the SDK, do you think it make sense to have logic for particular “kit” configuration hardcoded there? To me it looked strange on the first sight. Also there are defined I2C addresses for tags inside the SDK but you than need to know them in you application because you will use them for publishing (so you have to first look inside source code of SDK to know the addresses, it was confusing for me)… Maybe it would be better to have climate module more generic or configurable. What do you think?

hub.martin · December 22, 2017, 8:15pm

Our plan in future is to create a generic firmware, which will be configurable by computer to what the node should send, when and which sensor will initiate that transmission. Right now it is not possible to create a universal implementation of for example accelerometer alarm.

One of the reason that each kit has its own project and code is simplicity. The generic-node firmware is too complex a generic for everyone to start with it or change a single thing. By creating kits with minimal firmware it should be easier to change something or improve the code a bit.

In our SDK, there is not hard-coded kit. The modules are “hard-coded” but if you take a look closer on sensor module, it’s just a wrapper for a sensors that are contained on the module.

bc_module_climate.c

bool bc_module_climate_get_humidity_percentage(float *percentage)
{
return bc_sht20_get_humidity_percentage(&_bc_module_climate.sht20, percentage);
}

bool bc_module_climate_get_illuminance_lux(float *lux)
{
return bc_opt3001_get_illuminance_lux(&_bc_module_climate.opt3001, lux);
}

bool bc_module_climate_get_altitude_meter(float *meter)
{
return bc_mpl3115a2_get_altitude_meter(&_bc_module_climate.mpl3115a2, meter);
}

What exactly do you mean by hard-coded kits?
Thanks

eggze · December 22, 2017, 9:46pm

Yes, I agree that generic but configurable firmware would be great That’s what I hope for.

I have no problem with separate project per kit. That’s actually really great. My problem was when I was searching for a place where I need to put a different revision of humidity sensor. Because I wanted to preserve the rest of the logic/code in the climate kit.

I would expect sensors, revisions and I2C addresses to be inside of the kit’s related project, not in SDK. That’s my only concern. IMHO SDK should only contain generic functions you can use in a project. Do you know what I mean?

But maybe there is also difference between a kit and a module which I cannot see.

eggze · December 22, 2017, 9:52pm

Ok, I see the difference now

The module = the physical board. In case of climate module it’s a combination of chosen sensors.
The kit = combination of several boards.

So I’m mixing things here I imagined the “climate module” in the SDK to be more generic. As an interchangeable combination of sensors either in form of “integrated board” or tag module with tags.

hub.martin · December 22, 2017, 10:05pm

You are right, for the people from “outside” BigClown the “climate module” may sound like a universal library or C module for all the climate sensors that we support.

Are all your questions answered now? Can I close the topic?

eggze · December 23, 2017, 8:25am

Yes, you can close it. Thanks

eggze · December 31, 2017, 7:19pm

FYI: I’ve done what you’ve recommended here: https://github.com/synaptiko/bigclown-nodes-firmware/blob/master/apps/climate-monitor/application.c#L152-L164

And I do not anymore use “hacked” SDK

I also created this issue based on our discussion: https://github.com/bigclownlabs/bcf-sdk/issues/161