reinhold

reinhold

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...
Arduino Pro Mini IO shield

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).

Each analog and digital pin of the Pro Mini has its own VCC and GND pins,
the board also provides its own voltage regulator, solder pins for by NRF24L01+ and RFM69H are provided (plus the 5V->3.3V XC6206 regulator),
either a tiny 55-pin breadboard or three I²C connectors can be placed on the board.
One can also use PogoPins instead of soldering the Pro Mini (or headers for it) to burn the bootloader or change fuses on the Pro Mini via the ICSP connector.

All design files are available on GitHub: https://www.openhardware.io/view/538/Arduino-Pro-Mini-IO-Shield

reinhold

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...

reinhold

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

reinhold

@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)

reinhold

(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

reinhold

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.

reinhold

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....

reinhold

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).)

reinhold

@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

reinhold

@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.

reinhold

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?

reinhold

@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).

reinhold

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:

MyBoardNRF5 with BME280 (Adafruit library), sketch adapted from the one supplied with this board
MyBoardNRF5 with BME280 using NodeManger
MyBoardNRF5 with VL53L0x using NodeManager
Custom board in Arduino IDE derived from Sandeep Mistry's generic 51822 board, with either of the above sketches

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?

reinhold

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

reinhold

@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.

reinhold

@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.

reinhold

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).)

reinhold

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.

reinhold

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?

reinhold

@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)

reinhold

@reinhold

Best posts made by reinhold

Latest posts made by reinhold