I'm wondering what the minimum input voltage is. The description only says max. 6.5V input voltage from the battery, but does not say what the minimum is. Both the nrf24l01+ as well as the atmega328P work with 3.3V, so if I use three AA batteries, that should be fine, right? I suppose using two AA batteries is not enough?
@Omemanti, thanks for the pointer. Unfortunately, this seems to be a hardware problem of the NRF52* boards, not of the NRF51822-04 that is used in NeverDie's board.
Is there any way to find out which peripherals are enabled while the nrf51 is sleeping? I tried googling and also looked at the openocd documentation, but couldn't see any reference to reading out the which peripherals are turned off and which are running while the nrf is in deep sleep. (I'm using a cheap Chinese ST-link V2 dongle to program the nrf via SWD).
Hi,
What is the power consumption you get with this board and i2c sensors? I built several boards and measured the consumption using a INA219 sensor (lowest resolution is 0.1mA). Without any I2C sensor initialized, it shows a power consumption well below 0.1mA (i.e. it always shows 0.0), but as soon as I use an I2C sensor, the consumption during sleep increases to 0.3mA, which drains the battery faster than desired for a battery node...
I tried it with several different implementations / sensors, and always got the same result:
Is there anything special I need to do to get power consumption with i2c sensors down to the desired single-digit-µA-range during sleep?
Yes, 1.27mm pitch should be possible with pogo pins (I have never done them myself, though).
You need to buy the smaller pogo pins (diameter 0.68mm). Some examples by other hackaers can be found e.g. at
@user2684 Right, thanks for pointing this out. I mixed up the child name that was sent to the controller (which can be changed by e.g.
void before() {
...
doorLeft.children.get(1)->setDescription("Door Left");
doorRight.children.get(1)->setDescription("Door Right");
node.before();
}
) and the sensor's _name field, which is printed to the debug output. That "DOOR" debug output cannot be changed without subclassing. But as this is just debug output, it's just a minor nuissance.
@iteafreely I don't think there is a limit of one sensor per type, not even for interrupts like door sensors. You just need to make sure you are using different pins and different child ids for the two magnetic sensors. I'm using 8 analog sensors (MQ-... gas sensors) on eight different pins on the same node and it works just fine.
Of course, if you need some interdependence on what the two magnetic sensors report, then you must follow @user2684's suggestion of creating a custom sensor (a C++ class derived from an existing sensor class).
But if you simply want two independent magnetic sensors (for each of the ends of your sliding door), then you can simply create two instances of SensorDoor on two different pins (here pins 3 and 4) and different hardcoded child_id (1 and 2 in this case):
SensorDoor doorLeft(node,3,1);
SensorDoor doorRight(node, 4,2);
Unfortunately, both of them will report to the gateway with name "DOOR" (and there's no way to change it without subclassing SensorDoor), but they will have a different child_id 1 and 2 to distinguish the two values sent by the node.
You can then use your smart home controller to handle the two door sensors like one.
If you insist on connecting the analog sensors to the arduino and switch to a software I2C implementation on non-hardware I2C pins, you might simply extend the SSD1306Ascii library. It currently has classes for the SSD1306 over the AVR hardware i2c, another class for generic Wire implementations (not tailored to atmel chips; e.g. I'm using it on nrf51822), and the SPI devices.
Looking at the SoftwareI2CLibrary docs, it appears that they even provide a Wire interface (SoftWire.h), so you might even get away with the SSD1306AsciiWire class for the OLED.
If that does not work, you'll have to write your own software I2C implementation for the SSD1306Ascii class (e.g. takt SSD1306AsciiWire, rename it to SSD1306AsciiSoftI2C and adjust it to use the SoftwareI2C library for all I2C communication).)
Another idea might be to connect all analog sensors to I2C Analog-digital converters like the ADS1115:
https://www.aliexpress.com/store/product/I2C-ADS1115-16-Bit-ADC-4-channel-Module-with-Programmable-Gain-Amplifier-2-0V-to-5/324775_32903062908.html
As you can hook up multiple devices to the same i2c bus, simply attach the OLED and two of those ADS1115 boards (apparently you can assign up to 7 different I2C addresses to the ADC boards...) to the I2C bus.
I've been running the Ethernet gateway (port 5003) on my raspi without issues for several months now.
@kkanedaa It looks like the development version finally works with your nrf module. Regarding the MQTT connection refused: Are you sure your MQTT broker does not need a username and password?
@gohan I'm using the SSD1306Ascii library, which does not use a display buffer and does not support graphics, only text. The drawback is that to prevent screen flickering, you have to manually clean each line of text to the EOL. Otherwise letters that are not overwritten by new text will not be cleared. See my PR for NodeManager how it works. With my approach, there is absolutely no screen flicker, the display updates properly and the memory requirements are minimal (the library docs say its 53 bytes)
Today I finished the coding for my prototype of a laser distance sensor (intended to measure the water level for my automatic in-door flower watering pump). The sensor is connected via I²C and has sleep pin.
The most work was implementing support for the VL52L0X laser distance sensor and for my 128x64 OLED display to NodeManager (PRs submitted as https://github.com/mysensors/NodeManager/pull/244 and https://github.com/mysensors/NodeManager/pull/245).
The OLED is really useful when prototyping sensor nodes. Out of the box, my NodeManager OLED implemention will display the values of all attached sensors without any coding. Simply create the DisplaySSD1306 after all other sensors, and the OLED will pick up and display all sensors automatically...
Once everything works, of course the OLED is not desired for the water level sensor running on batteries...
@user2684 Thanks for the spreadsheet with your memory footprints. Are these the sketch size and the free memory that the compiler reports? Or do you measure them when running the sketch (i.e. including all dynamically allocated variables in SRAM)?
Also, one problem you don't seem to have covered is heap fragmentation. Particularly your new List class seems to be prone to heap fragmentation with a large number of sensors: each time a sensor is added, the list needs to re-allocate the memory for its pointers. The old memory will be released, but it will remain as a hole in the memory, where new variables might be allocated. However, the next time you add an element to the list, the new pointer array can probably not re-use some of those freed holes.
I'll provide a PR (https://github.com/mysensors/NodeManager/pull/247) that adds an allocateBlocks(count) method to the List, which can be used in the sketch and in the sensor's onSetup methods to pre-allocate the required sized. In turn, the _preAllocBlocks member does currently not serve any purpose, and I don't think it's really required functionality. In my eyes, it's more important to ensure that at a certain moment the required memory is allocated. It is not neccessary to keep a minimum nuber of blocks allocated at all times.
For a node with 10 physical sensors (and maybe one or more built-in sensors), this will save at least 22 bytes (1,1% of total SRAM!) and probably reduce heap fragmentation by quite a bit.
Another are where >22 bytes can be saved is the power manager. None of my nodes makes use of the power manager, yet each sensor needs to keep a (null) pointer to a power manager. Providing a compiler #define NO_MODULE_POWER_MANAGER can exclude everything PowerManager-related from compilation and save one pointer per sensor and node, i.e. with 10 sensors you'll save another 22 bytes (1,1% of total SRAM!) I'll provide a PR for this, too: https://github.com/mysensors/NodeManager/pull/248
Apart from that, I simply stripped down the SensorMQ class and removed all configurability for my own use (don't worry, I won't submit this as a pull request... it is simply meant to squeeze the sketch onto the pro mini with the boards that I have already built).
BTW, the SensorConfiguration is no problem as far as SRAM is concerned (it just adds the normal SRAM footprint of a Sensor instance): It has no class members of its own. Only the flash size is considerable, but for me this is not the issue, I'm running out of SRAM.
@nca78 Two more things popped up with the latest development version of NodeManager:
node.setSleepSeconds(5); node.setReportIntervalMinutes(10); would be the correct way to setup NodeManager to take measurements every 5 seconds, but only report it every 10 minutes to the network. Unfortunately, Sensor::loop(MyMessage* message) seems to immediately return without measurement if the reporting timer has not elapsed. Somehow I don't understand that logic. Why have different sleep and reporting intervals when measurements will only be taken at reporting intervals anyway? I would expect measurements to be taken with the sleep intervals (e.g. to calculate an average over the whole reporting interval) and report back to the network using report intervals.
@nca78 Thanks for the suggestion to use the blue pill STM32 boards. I haven't thought of it (I only looked at the ESP8266, but that has only one ADC). I have a few lying around here, but never got around to trying them, as I first need to burn the bootloader. It looks quite promising, but the boards are huge, so I'll need to enlarge my PCB...
The need for a 5V->3.3V regulator is no issue, as the NRF24 already needs 3.3V. The 5V analog level of the MQ sensors will need some converter (the analog ADC inputs are marked as non-5V-tolerant...), but then in turn I can get rid of the voltage dividers for the PMSA003. The larger issue seems to be the connection of the nrf24, which takes away 4 ADC pins, so there are only 6 ADC pins left, while I have 8 analog sensors 
Still, for now I have the PCBs with the ProMini, so I'll try to strip down the Sensor or SensorMQ classes for my own use.
@user2684 Thanks a lot for the architecture change, which makes a lot of sense conceptually.
Unfortunately, it appears to use more memory than before. I'm working on an air quality board with eight MQ sensors, an MH-Z19 CO2 sensor and a Plantower PMSA003 particulate matter sensor. In previous development versions (1.7-dev, before today), the eight MQ sensors and the MH-Z19 worked fine, but now after your big merge of #229 the sketch appears to run out of memory after adding the child of the sixth MQ sensor. Do you see any chance to optimize for memory?
Old sketch (using a previous development version of NodeManager, without the PMSA003; 155 bytes left after all nine sensors are fully initialized): https://github.com/open-tools/NodeManager_GasSensor/tree/master/NodeManager_GasSensor
New sketch (using the latest version of NodeManager, plus a PMSA003): https://github.com/kainhofer/NodeManager/tree/GasSensor
That sketch runs out of memory with the sixth MQ sensor (I added debug output with free memory at a lot of spots). Of course, I have commented out the PMSA003 completely to have a correct comparison.
FWIW, the sketch is for this board: https://github.com/open-tools/NodeManager_GasSensor/blob/master/images/IMAG2267.jpg
Finally got the PCBs from AllPCB.com (cost 5 Euros and took a total of 7 days from order submission to free DHL delivery to Europe!!!) for my own MySensors Arduino Pro Mini prototyping board. Unfortunately the soldering iron broke during my assembly, so it's not fully finished and I couldn't test it yet, either...
This board is inspired by the Nano IO shields that are offered on AliExpress and improves it further for my needs (and switched to the Pro Mini instead of the Nano).
All design files are available on GitHub: https://www.openhardware.io/view/538/Arduino-Pro-Mini-IO-Shield
@neverdie For Austria the threshold for import tax (=VAT substitute, 20%) is 22 Euros (value of the goods, excluding shipping and insurance costs) and for additional customs duties it's 150 Euros.
(I know this post is off-topic regarding the original request... Sorry for that)
If your concern is mainly about connecting the radio to the arduino, then I can warmly recommend one of those "Arduino nano IO shields":
https://www.aliexpress.com/item/For-arduino-Nano-Terminal-Expansion-Board-Adapter-IO-Shield-Electronic-Circuit-328P-w-XBEE-nRF24L01-Socket/32841357885.html
You just plug in the nrf24l01 (I'm using a small adapter PCB to use the SMD version with the pin header) and the nano and you are ready to go. Also comes with a connector for a 9V power adapter (which I needed for the gas sensors drawing 100+ mA). It also has the four pins for I2c (VCC, GND, SCL, SDA) and Serial (GND, VCC, Tx, Rx) next to each other, and it provides +5V and GND together with each in-/output pin.
To make prototyping even easier, I unsoldered (or broke off) the small female pin headers for the xbee and used two-sided duct tape to add a tiny breadboard instead (where I simply plugin in I2C devices like an OLED or a sensor):
https://www.aliexpress.com/item/7pcs-Mini-55-Points-Breadboard-Solderless-Prototype-Tie-point/32661906252.html
Hi nca78, nice idea to implement a MiLIght bridge shield. Did you get the PCB back from the fab and try the shield? Does the board work properly? Do you plan to add a description of the board and some code?
Thanks, Reinhold
For the mysensorization of my air humidifier, I'm trying to interface the arduino with the 24V circuit of the humidifier.
I have some rought schematics in mind, but as I have practically no experience designing electronic cirvuits, I have no idea whether there are better solutions. So I desperately need some input from someone with more knowledge in circuit design. I would be very thankful if you could give me some feedback on my schematics as detailled below.
Basically, the questions are how to best convert 24V to 5V/3.3V to power the arduino, whether a MOSFET is the best way to emulate a button press and whether voltage dividers are the correct approach to detect a button press and a burning LED.
The humidifier has the following items that I'm interested in:
The PCB of the humidifier is mainly covered by a large motor, so tapping directly into the microcontroller is not an option (which is also covered by the motor; I can only see the last few characters: 1933, so it is probably a PIC16F1933). However, the control panel (with control buttons, LEDs and also the 24V power jack) is connected through a 10-pin ribbon cable, where I can easily place my own pcb. The ribbon cable provides +24V, GND, and the control buttons connect directly to GND, while the leds connect to +24V. Here's the schematic of the humidifier's existing control panel and the existing connector, where I want to interface:
What I am interested in:
All lines of the cable run a voltage of up to 24V (some have ~19-20V measured with a multimeter), so I can't directly feed them into the Arduino.
So, my issues now are:
If I measure the voltage at the lines using the arduino, how can I make sure not to influence the existing circuit of the humidifier?
Is it safe to use the GND from the 24V all through my own mysensors PCB with arduino pro mini, nrf24l01+, etc. and only transform +24V to +5V? Or is it better to directly transform to 3.3V and use the 3.3V of the pro mini?
My current idea is to simply use a linear voltage regulator like the L78M05:
Or should I better use a step-down converter (a little more expensive, more parts, harder to route on the PCB) even though the arduino will never, ever use the 3A:
Do you think this will produce a proper power supply for the arduino? I'm afraid to try it out without first getting some second opinions, as this is my first hardware-design project, and I don't want to destroy either my humidifier or the arduino+nrf24...
As a button press of the existing hardware buttons simply means connecting to GND, my idea was to use a simple MOSFET transistor (that can handle 24V) parallel to the existing hardware button, i.e.
PIN_PWR would be connected to e.g. the D3 pin of the pro mini.
Would this work to trigger a Power button press from the arduino?
Would you use this transistor or a different transitor? Or would you even recommend optocouplers to cleaner separate the 5V/3.3V circuit of the arduino from the 24V of the humidifier?
As far as I can see, this simply means checking wether the corresponding wire goes to GND. As the internal microcontroller must observe this line, too, I suppose there is some pull-up already in place, so my idea was to simply use a voltage divider from 24V to ~5V to feed the line into the arduino:
Again, PIN_OPEN is a digital pin (D4) of the arduino.
Is using a voltage divider the correct approach here? Or are there better ways to detect BTN_OPEN going from high to GND?
What would be good values for the voltage divider's resistors? I thought of 470k for R2 and 2.2M for R1 (=> 4.22V from 24V).
Is there anything I can do to minimize interference with the internal button press detection of the humidifier? No idea, how the internal circuit works and how the PIC16F1933 detects the button press, in particular, I have no idea about existing pull-ups and other components.
Strangely, the LEDs are connected to +24V (with a series resistor), so I suppose they are turned on by the internal MC by putting the corresponding pin low.
Does this mean that I can detect a burning led similar to the way I detect the button press? I.e. using a voltage divider and then simply piping into an input pin on the arduino (no pullups needed, obviously):
What worries me here is that this basically means I have only the LED, the 10k resistor (on the existing control panel of the humidifier), and the two resistors of the divider in series between +24V and GND, so basically just the LED and a large resistor (10k + ~2-3M). Is this really a good approach?
Any better idea how to detect whether any of the LEDs is on?
What do you think about this project? Are my approaches working at all, and are there better solutions to the issues at hand?
Of couse, I'll make the whole project available on openhardware.io, once I get it working...
Thanks,
Reinhold
@GertSanders Am I missing something, or wouldn't two 3V batteries in series fry the atmega and in particular the nrf24 with 6V?
The bootloader burning issue was indeed a problem with the crystal: It seems that the atmega328p that I bought on aliexpress came with the fuse set to external crystal, so they worked fine on all boards with an external crystal, but this stamp-sized node didn't react because the internal oscillator was disabled in the chip. I had some 16MHz SMD crystal lying around, soldered jumper wires to them and manually held them to pins 7 & 8 of the atmega328p while trying to burn the bootloader. That's quite delicate as the pins are so small, but it works astonishingly well.
As boards I used the "MiniCore atmega328" board that allowed me to select the internal crystal and also lower the black-out voltage.
With the external crystal held to the atmega's pins, I was able to properly burn the bootloader and activate the internal oscillator. Now, the board seems to work just fine.
The only issue is that I just realized I don't have any CR1632 batteries. I suppose CR1620 will also work, but that a shorter battery life?
Thanks again,
Reinhold
@GertSanders Thanks for the response.
I had already used the nano to install the bootloader on the linbus analyzer and linbus injector boards, so apparently the nano can be used with the ArduinoISP sketch. I also tried re-installing a bootloader to another nano via the ICSP pins and it worked.
I also tried building my last PCB for your stamp-sized nodes without the wireless module installed, but I get the exact same behaviour. (You are right, it's not so far-fetched that the radio module might interfere with the bootloader installation, since the ICSP header also just breaks out the SPI headers. On the other hand, the slave select for the nrf24l01+ is not pulled low by the arduinoISP, so it should not interfere on the SPI bus...).
@alexsh1
I already tripple checked my wiring (even tried switching MISO/MOSI), but I can't find any problem. In fact, only with this very wiring do I get the "Expected signature for ATmega328P is 1E 95 0F" error message, as only with this wiring, the signature is different from 0x000000. Here's the verbose log of the bootloader burning:
Strangely, I do not get the same signature when I try to burn the bootloader again (0x040404 => 0x0e0808 => 0x080808; 0x820202 => 0xc10101 => 0x820202).
So it seems that communication is somehow possible, but only garbage is observed.
FWIW, I'm using the "Arduino Pro or Pro Mini" (like I did with the linbus boards) with processor ATmega328P (3.3V, 8MHz).
The only difference I can see between the working linbus and nano boards and this stamp-sized node is that the linbus boards have an external crystal, while this stamp-sized node appears to use the internal crystal of the chip. Can this be the difference?
It seems @kalina is using the 10nF, 1µF + 10µF combo in his designs, so it's not neccessary for him to add them to the adapter. Still, other designs (or manually wired nodes) do not always have the capacitors, so it would be nice to have the pads on the adapter in case one wants to add the capacitors directly with the wireless module.
@NeverDie Thanks for spotting the typo, edited my post correspondingly.
Hi, thanks for designing an adapter that includes both the "normal" and the PA+LNA versions of the SMD NRF24L01+. Any reason why you don't include any decoupling capacitors? Typically, a 100nF and a 4.7 to 47µF capacitors between VCC and GND are recommended...
I'm using emc2cube's adapters (https://www.openhardware.io/view/297/SMDnRF24_adapter, https://github.com/emc2cube/SMDnRF24_adapter/tree/master/PA_LNA) and they are really great, but they are designed only for the "normal" and only for the PA+LNA versions, so your adapter is even better.
Also: Any reason you are "wasting" a lot of space on the board? I suppose you wanted to make the adapter the same width as the DIP nrf24l01+? Since the smd versions are smaller, you can still align one edge with the original size, align the smd nrf24l01 with that edge and make the board smaller on the other side (i.e. align both edges with the SMD nrf24l01+), i.e. align the width of the adapter with the width of the smd modules. emc2cube does this and the adapter feels much more natural than a board that is larger than the smd nrf24l01...
@GertSanders,
Thank you for the nice, small design. I'm trying to build one myself, but I'm running into issues burning the bootloader using the ArduinoISP sketch on an Arduino Nano (328). Looking at the schematics, the pins of the ICSP header (from left to right, if the headers are facing you) are:
Reset => Pin 10 of Nano
SCK => Pin 13 of Nano
MISO => Pin 12 of Nano
MOSI => Pin 11
VCC => VCC on Nano
GND => Gnd on Nano
I set the board to Arduino Pro or Pro Mini in the Arduino IDE, selected Arduino as ISP and tried to burn the bootloader, but there always is the error message:
avrdude: Expected signature for ATmega328P is 1E 95 0F
Double check chip, or use -F to override this check.
Error while burning bootloader.
Any idea what's wrong?
I built two copies of the board, and I get the same message with both. (mirroring the connectors of the ICSP header doesn't work, either).
Thanks a lot!
FWIW, some weeks ago I ported the MH-Z19 code (the serial interface, by default connected to digital pins 6 and 7) to NodeManager for use in my own little gas detection node (MH-Z19 and four MQ-... sensors). The MH-Z19 code is included in the 1.6 release of NodeManager, so if you are using NodeManager for your nodes, the MH-Z19 sensor should be really easy to set up and use.
Okay, finally got the original nrf24l01 SMD modules with the square chip visible... As exptected, things work just fine now, so the culprit of my issues was really the incompatible/fake "nrf24l01" SMD modules with the epoxy blob. If you want to use normal nrf24l01+ modules together with this smd gateway, DO
NOT USE the smd module with the epoxy blob, as they won't work.
Using only the fake SMD modules might work, too, but mixing the fake modules with real ones does not work.
After some more googling, I think I found the cause of the issue: I bought some cheap SMD version of the nrf24l01 on aliexpress.
Apparently, that SMD version with the epoxy blob is a cheap knock-off that does not really include a genuine nrf24l01 chip, but only a similar chip. While the board is pin-compatible and API-compatible to the nrf24l01, the over-the-air data frame format is apparently NOT compatible with the real NRF24L01+ chip:
So, no wonder my smd gateway is not communicating (or rather unable to understand the communication) with the nodes that use real nrf24l01+ modules.... Guess I'll have to wait for the real, non-blob nrf24l01 SMD modules, which I also ordered a while ago and which should arrive any day now....
@emc2 Thanks for this awesome tiny piece!
I just built a copy of this RPI<=>nrf24l01 SMD gateway for my raspberry Pi. Unfortunately, while the RPi seems to properly detect the transceiver, but it never receives anything from my nodes (mysgw built from current development branch, with the exact configure line given at openhardware.io
root@raspi:/home/pi/MySensors# ./bin/mysgw -d
mysgw: Starting gateway...
mysgw: Protocol version - 2.2.0-beta
mysgw: MCO:BGN:INIT GW,CP=RNNG--Q-,VER=2.2.0-beta
mysgw: TSF:LRT:OK
mysgw: TSM:INIT
mysgw: TSF:WUR:MS=0
mysgw: TSM:INIT:TSP OK
mysgw: TSM:INIT:GW MODE
mysgw: TSM:READY:ID=0,PAR=0,DIS=0
mysgw: MCO:REG:NOT NEEDED
mysgw: Listening for connections on 0.0.0.0:5003
mysgw: MCO:BGN:STP
mysgw: MCO:BGN:INIT OK,TSP=1
After that, there is simply no output and the serial console of my sensors also do not indicate any connection.
If I instead attach a "normal" (i.e. non-smd) nrf24l01 module with jumper wires to the same SPI port on the RPi, then full communication is possible:
mysgw: Listening for connections on 0.0.0.0:5003
mysgw: MCO:BGN:STP
mysgw: MCO:BGN:INIT OK,TSP=1
mysgw: TSF:MSG:READ,1-1-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
mysgw: TSF:MSG:BC
mysgw: TSF:MSG:FPAR REQ,ID=1
mysgw: TSF:CKU:OK,FCTRL
mysgw: TSF:MSG:GWL OK
mysgw: TSF:MSG:SEND,0-0-1-1,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
mysgw: TSF:MSG:READ,1-1-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
I also tried to build a second of these tiny smd gateways, but I get exactly the same issue...
Do I need to change anything in my nodes' code to make them talk to this smd gateway and replace my "big", wired nrf24l01 with this smd gateway?