A tiny BME node - BME280 on ATtiny85

[Nca78]

Great work shoehorning MySensors and BME280 lib in 8 K !

But CR2032 is a bit over 200mAh so the battery life will be closer to 6 months. I don't advise to skip the capacitor, and I would even put a 100uF one. CR2032 has a high internal resistance and when you draw 20+mA for sending a message the capacitor will help supply enough power and help the battery so its voltage will not fall too low.

[fabyte]

@Nca78 You are right, I mixed those numbers up with another project running on a 9V battery. The correct values are:
~ 7uA in power down state, ~25mA in transmit, which gives 20uA as mean and with 200mAh about 1 year (+).

I'm running the devices without capacitor. Would you advice to use them because it is better for battery health reasons? Because currently I don't see any negative impact, the battery seems fine with the current draw.

[BearWithBeard]

Short answer: unless you have absolutely no space left for an electrolytic capacitor, there's no reason to not use one.

Long answer: Using an electrolytic capacitor or not when running off a CR2032 was a huge question for me when I was designing my window / door sensor nodes, because I assumed that their leakage current would be higher than the whole circuit consumes during sleep, resulting in a much lower battery life. The first thing I did was soldering up some prototypes (m328p, generic nrf24), one with a good quality, branded electrolytic capacitor, one with a random chinese cap and one without one and installed all on the same door, so I could compare them. I kept them running for almost a year until recently.

Unfortunately I lost my InfluxDB instance with the recorded data, but here's the gist: The units with a capacitor didn't drain the coin cell faster than the one without. In the end, the delta between the three batteries were merely 30mV, which is nothing considering the runtime. They're still at ~3.05V. Whenever I looked at the graphs to see how reliable they were, I couldn't find any issues - if they triggered a state change, they all successfully reported the event. Then again, they were installed on the door of the same room the gateway was in.

But here's the catch: When I received my custom PCBs, I installed two sensors on the same window on the other side of the house, one with and one without a capacitor - again, to compare them, but this time in a "real world" scenario. With #define MY_RF24_PA_LEVEL RF24_PA_HIGH, which is the default setting, the node without the cap failed to reach the gateway reliably, while the other one had no problem at all. Switching to RF24_PA_LOW resulted in both units unable to communicate with the gateway, they were simply too far away. Contrary, keeping the PA level up and soldering a 100µF capacitor on, solved the reliability issues of the second node. This effect might be even more noticeable, the further the coin cell is discharged.

So yes, there is a use for buffer capacitors and no, there's no reason to fear the "large leakage current" of electrolytics, unless you use old stock from the 90s or ones of dubious quality (I posted some more information and links to literature further down in this post, if you're interested). They provide stability in case of sudden current spikes (e.g. when the radio starts transmitting), at literaly no cost. I can recommend the Nichicon UMA/UMR capacitors if you're looking for a small footprint - 6.3x5mm for 100µF 16V.

I meant to post a detailed report on this topic for a while now as a follow-up, but didn't get around to yet. Anyway, I hope this was helpful.

[fabyte]

Thanks for this detailed explanation, I will keep that in mind for the next design and plan with capacitors. Currently I have no connectivity troubles in my home (ground floor flat with garden) both inside and outside, but we will see what the situation will be at the end of battery life (PA level high).

I like your project, BTW, a lot of information and experience documented👍

[vsv78vrn]

This post is deleted!

[vsv78vrn]

Good day to you! I was able to build this project on attiny167, but ran into a big code problem. Over time, I switched to nrf52840.
The size is very small! And Power + 8dB

[pjeran]

I have seen this and was wondering if anyone has looked at the sort of new Tiny series-1 uC. up to 32K memory and a lot of nice peripherals. Good power number and low cost. For me the thing that really looks interesting is the built in RTC that runs even in sleep. This combined with Spencer Konde's megaTinyCore makes it a very interested prospect for some battery powered nodes.

https://hackaday.io/project/165881-attiny-1-series-with-arduino-support

Has there been any thought with integrating these cores into the mySensors family?

Thanks,

Paul

[fabyte]

When I started this project I had one priority in mind: Keeping it as minimalistic (and small) as possible.
This is why the design uses standard preassembled modules and a tiny ( ;) ) microprocessor. I also wanted to proof that it is possible to run the MySensors platform on the ATtiny MCU since the hardware requirements are not extraordinary. Minimalistic also means for me that I want to exhaust the given MCU capabilities and build as much as possible. This projects shows that these limited MCU is sufficient enough to work as MySensors node.
(The BME280 library is quite 'big' regarding the memory footprint. Using sensors with one-wire or just reacting to an interrupt requires even less memory and fits perfectly into 8K).

Next step is of course improving the dimensions of this sensor node. This is where it goes to working with SMD components and not THT anymore. Unfortunatly my SMD soldering capabilities are limited so I think I won't be able to solder the QFN package by hand so either I order my PCB design preassembled (could be quite expensive, does anyone know?) or I use standard modules and design a 'motherboard' to connect it with the rest of the components (which makes it bigger again).

I like the NRF5 series, but it also comes with more complexity of the hardware design (antenna matching components and so on) which is too much for me right now. But I also think the final and perfect solution would be something like Raybeacon: nRF52 on-the-go Development Kit.

Right now, I'm going small steps. 2 months back (or so) I assembled the improved version so that the PCB antenna is free from disturbances:

Next step will be a design with ATtiny in the SMD package (already ordered, as well as a couple of MLCCs in 1206 and 1210 :) )

[fabyte]

@pjeran said in A tiny BME node - BME280 on ATtiny85:

Has there been any thought with integrating these cores into the mySensors family?

I've opened an issue for Attiny support on Github but there is no reply yet.

[icebob]

@fabyte awesome job. I'm working something similar. Could you share your main program code?

[fabyte]

@icebob Sure, no thing:

// -----------------------------------------------------------------------------
// missing defines
// -----------------------------------------------------------------------------
#define SIGRD   RSIG    // Signature Row from Store Program Memory Control and Status Register
#define EIFR    GIFR    // External/General Interrupt Flag Register
#define WDTCSR  WDTCR   // WDT Control Register
// #define TCCR1A TCCR1
// #define TIFR1 TIFR
extern void serialEventRun(void) __attribute__((weak));

// -----------------------------------------------------------------------------
// Configuration
// -----------------------------------------------------------------------------

// Disable features for reduzing memory footprint
#define MY_SPLASH_SCREEN_DISABLED
#define MY_DISABLE_RAM_ROUTING_TABLE_FEATURE
#define MY_DISABLED_SERIAL

#define MY_NODE_ID          0 
#define MY_PASSIVE_NODE
#define MY_DISABLE_REMOTE_RESET

// Enable and select radio type attached
#define MY_RADIO_RF24
#define MY_RF24_CE_PIN      NOT_A_PIN
#define MY_RF24_CS_PIN      4

// BME280 settings
#define BME_CS_PIN          3
#define TINY_BME280_SPI

// Sleep Time between reads (in milliseconds)
#define SLEEP_TIME          120000

// -----------------------------------------------------------------------------
// MySensors
// -----------------------------------------------------------------------------
#include <MySensors.h>

#define CHILD_ID_BME_T    1
#define CHILD_ID_BME_H    2
#define CHILD_ID_BME_P    3
#define CHILD_ID_VOLTAGE  4

MyMessage bmeTempMsg(CHILD_ID_BME_T, V_TEMP);
MyMessage bmeHumMsg(CHILD_ID_BME_H, V_HUM);
MyMessage bmePressMsg(CHILD_ID_BME_P, V_PRESSURE);
MyMessage voltageMsg(CHILD_ID_VOLTAGE, V_VOLTAGE);

// -----------------------------------------------------------------------------
// BME 280
// -----------------------------------------------------------------------------
#define TINY_BME280_SPI_CLOCK   1000000 // 1 MHz
#include <TinyBME280.h>
tiny::BME280 bme280;

// -----------------------------------------------------------------------------
// Implementation
// -----------------------------------------------------------------------------
void setupSensor()
{

  bme280.beginSPI(BME_CS_PIN);

  // read once to erase initial values
  delay(10);
  bme280.setMode(tiny::Mode::FORCED);
}

void readAndSendSensorValues()
{
  bme280.setMode(tiny::Mode::FORCED);

  delay(8);
  while(bme280.isMeasuring())
    delay(2); //Hang out while sensor completes the reading

  send(bmeTempMsg.set(bme280.readFixedTempC()));
  send(bmeHumMsg.set(bme280.readFixedHumidity()));
  send(bmePressMsg.set(bme280.readFixedPressure()));
}

void readAndSendBatteryVoltage()
{
  send(voltageMsg.set(hwCPUVoltage()));
}

// -----------------------------------------------------------------------------
// Framework Funktions
// -----------------------------------------------------------------------------
void setup()
{
  setupSensor();
}

void presentation()
{
  // Send the sketch version information to the gateway and Controller
  sendSketchInfo("ATtiny Sensor", "1.0");

  // Register all sensors to gateway (they will be created as child devices)
  present(CHILD_ID_BME_T, S_TEMP);
  present(CHILD_ID_BME_H, S_HUM);
  present(CHILD_ID_BME_P, S_BARO);
  present(CHILD_ID_VOLTAGE, S_MULTIMETER);
}

void loop()
{
  readAndSendSensorValues();
  readAndSendBatteryVoltage();

  sleep(SLEEP_TIME);
}

// -----------------------------------------------------------------------------

Don't forget to set your MY_NODE_ID appropriatly.
BME values are sent as fixed point values and are converted to float on controller side.

[fabyte]

Last year I began with the work on the SMD version of the tiny BME node. See pictures here:

Problem was that the radio isn't transmitting very reliable and I think I broke it while programming the ATTINY (used 5V instead of 3.3V). I received a few values so I know it is working but I didn't have time to fix it properly which would mean just create a new one.

[Nca78]

@fabyte said in A tiny BME node - BME280 on ATtiny85:

(used 5V instead of 3.3V).

Usually after doing that the radio still seems to work, but it's not reliable anymore and it is gobbling a lot of power. It is quite vicious as you think it is still working, but the sensor dies quickly...

[chamroeun ou]

Hi, I try to compile your code change for Mysensors against my Attiny85 but it failed with many errors like

yHwAVR.cpp:74:2: error: 'EIFR' was not declared in this scope
  EIFR = _BV(interrupt);
MyHwAVR.cpp:93:26: error: 'WDTCSR' was not declared in this scope
  const uint8_t WDTsave = WDTCSR;
...

Please note that my environment is AttinyCore.

How is your sensors after 1 year? What is your recommendation?

[fabyte]

Hi @chamroeun-ou
please try and add the following on top of your main.cpp:

// -----------------------------------------------------------------------------
// missing defines
// -----------------------------------------------------------------------------
#define SIGRD   RSIG    // Signature Row from Store Program Memory Control and Status Register
#define EIFR    GIFR    // External/General Interrupt Flag Register
#define WDTCSR  WDTCR   // WDT Control Register
// #define TCCR1A TCCR1
// #define TIFR1 TIFR
extern void serialEventRun(void) __attribute__((weak));

[chamroeun ou]

Ok, now it works with your BME-i2c code. not enough memory maybe due to update in AttinyCore which is bigger than your version. I think memory limit is the challenge.

[chamroeun ou]

To use Attiny, i think there's a need to optimize Mysensor for it as Mysensor consumes the most space of the 8K.

[BearWithBeard]

@chamroeun-ou I think it's actually quite fascinating that you can fit MySensors in less than 5kb of memory! Consider all the things the library does behind the scenes and that this includes all the required dependencies.

Try using your BME280 on the SPI bus, which you need anyway for the transceiver. This should shave off about 800 bytes or so. It still fits on ATtinys with 8kb flash using the example sketch posted above (direct link).

Processing attiny85 (platform: atmelavr; board: attiny85; framework: arduino)
-------------------------------------------------------------------------------------
PLATFORM: Atmel AVR (3.3.0) > Generic ATtiny85
HARDWARE: ATTINY85 8MHz, 512B RAM, 8KB Flash
PACKAGES:
 - framework-arduino-avr-attiny 1.5.2
 - toolchain-atmelavr 1.70300.191015 (7.3.0)
RAM:   [=======   ]  65.8% (used 337 bytes from 512 bytes)
Flash: [==========]  97.2% (used 7960 bytes from 8192 bytes)

[chamroeun ou]

@BearWithBeard , it's not my code. it is based on @fabyte 's code. Actually, I want to use SHT30 I2C but space is the biggest challenge.

There's a NRFLite(https://github.com/dparson55/NRFLite) which I think it may save space and can also work with 2 PIN for NRF24 as its created for Attiny but it may not work MySensors without code change.

My decision now is to use Attiny167 instead but the problem now is it's not working on Mysensors. I try this approach but not work https://github.com/mysensors/MySensors/pull/1485.

[BearWithBeard]

@chamroeun-ou I'm sorry, I was under the impression that you want to rebuild the OP's project, since there was no mention of different sensors etc.

Regarding the ATtiny85: How would you have used both SPI and I2C together in the first place? Both are implemented through a single USI and have to share the same OI pins.

Regarding the ATtiny167: I don't think I have an ATtiny167 at hand currently, so I can't test if it'll actually work, but the OP's example code compiled fine for me. I just had to comment out the the external interrupt flag register redefinition (//#define EIFR GIFR), since it is implemented in the same way it is on the ATmega328P for example.

Processing attiny167 (platform: atmelavr; board: attiny167; framework: arduino)
-------------------------------------------------------------------------------
PLATFORM: Atmel AVR (3.3.0) > Generic ATtiny167
HARDWARE: ATTINY167 8MHz, 512B RAM, 16KB Flash
PACKAGES:
 - framework-arduino-avr-attiny 1.5.2
 - toolchain-atmelavr 1.70300.191015 (7.3.0)
RAM:   [=======   ]  65.0% (used 333 bytes from 512 bytes)
Flash: [=====     ]  50.5% (used 8274 bytes from 16384 bytes)

The ATtiny167 has dedicated SPI and I2C interfaces and IO pins, so it should be possible to use it as a MySensors node with an SHTC30 sensor. There's plenty of free space, too.