Hello all, may be I did not get the point of this thread, but a very similar code to measure the AVR CPU voltage is already part of the MySensors library: MyHwAVR.cpp#L289

I use it in some of my PIR sensors and it works fine. Simply call hwCPUVoltage() to get it.
This is from my code:

void sendBatteryLevel()
{
  // This calls the internal voltage measurement
  uint16_t voltage = hwCPUVoltage(); 

  // Li AAA Cell Voltage range: discharged - full 2.6V - 3.0V
  uint16_t batteryPcnt = map(voltage, 2600, 3000, 0, 100);
  batteryPcnt = constrain(batteryPcnt, 0, 100);

  // This MySensors function sends the "internal battery info" to the gateway
  sendBatteryLevel(batteryPcnt);
}

BR Immo

Hi all, @Necromant has created an interesting PR #1477 in the MySensors repo with request for comments. It is about packet transport reliability for nRF24L01+ modules and how to improve it.

I have a similar setup as in PR with gateway, repeater and about 20 sensor nodes. To make it not too easy, there are two ping-pong nodes, which constantly send each other telegrams of maximum length with life sign signal value.

I know since longer time that the main reason for lost telegrams in my setup is the collision of two nodes, each trying to send a telegram to the other. Then both repeat the telegram 15 times but both nodes have no success with it. The other node would have to be in receive mode, but instead to listen it tries to send it's own telegram multiple times - a classic deadlock.

In worst case other nodes then also try to transmit and sometimes (every few days) this causes a traffic jam on the airwaves with a longer failure of the gateway. The error light then flashes constantly and nothing works anymore.

I see two different RF24 problems which may be resolvable by the PR:

1. Occasional traffic jam on the airwaves
2. Packets lost if two nodes try to send almost simultaneously to each other

So, your comments are requested - Thank you

@skywatch Thank you for clarifying. And nice that you like my implementation

I also find it very good and helpful for beginners to show the internal battery measurement method on the "Battery Power" page from MySensors. When I started with MySensors I followed the instructions for measuring via analog pin and 2 resistors. The more simple internal measurement I discovered way much later.

BTW there are some more built in functions, e.g. for the current CPU frequency and the current free heap size. With the MYSController you can query these values from the individual nodes:

You need only to add the #define for this functionality in your Node sketch:

// Enable support for I_DEBUG messages.
#define MY_SPECIAL_DEBUG

Hi @Necromant, welcome to the forum!
BTW From your profile image is it this one?

This is a SN7440 clone from Soviet times, right?

But back to topic and your issue 1:
A delay before resending is required for sure. A wait() is not a good idea because it introduces recursion of unknown deep, depending from the users receive() implementation.

But a short delay() is possible. While delay() the RF24 is in receive mode and can actually receive the other nodes packet which has collided before.

But exponential backoff is also not a good idea, because this can become a long delay of a second or more which blocks all time the main loop. But a short random delay of some 10th ms (like mentioned by @skywatch) worked for me in my setup.

But instead of speculating, we should try out the ideas on a test setup in a comprehensible way. But we should do that outside the official MySensors repo.

I will prepare a branch with the necessary core changes in my MySensors clone repo and also create test projects. I will start with a gateway and a sensor node.

Then we can check your topic 3 with sending 4 or more packets in a row from gateway (I will use a ESP8266) to a slow 12MHz Nano clone.

Hi @Necromant, thank you for your comments regarding the RPD feature of the nRF24+.

I have done some experiments with it. The result is a new tool TrafficDetectorRF24, which is available in my MySensors.Tools repository. The tool scans a single channel and outputs the current status via a debug pin. This can be used to connect a LED or better an input of a logic analyser.

At first I tried to use the RPD feature based on the MySensors example PassiveNode.
Unfortunately, that didn't work at all for me. I then adapted the code from Rolf Henkel Poor Man's Wireless 2.4GHz Scanner for my purposes.

The detector works quite accurately (resolution approx. 140us) so that you can usually detect the transmitted telegram and the ACK response of the receiver individually:

I hope you have more success in your attempts with the RPD feature.

Hi @Steve-Parsons, I had also some trouble with reading light level after sleep. My solution is to read the sensor twice. Also you should use in setup() the one-time-mode:

lightMeter.begin(BH1750::ONE_TIME_HIGH_RES_MODE)

This is an excerpt of my battery powered garden sensor sketch.
It runs on an Arduino Pro Mini clone:

#include <BH1750.h>

BH1750 lightMeter(0x23);

void setup()
{
  // begin returns a boolean that can be used to detect setup problems.
  if (lightMeter.begin(BH1750::ONE_TIME_HIGH_RES_MODE)) {
	Serial.println(F(("BH1750 Advanced begin"));
  } else {
	Serial.println(F(("Error initialising BH1750"));
  }
}

void getLightLevel()
{
  lightMeter.readLightLevel();
  wait(20); // First measurement after sleep is wrong, take the seconde reading
  float lux = lightMeter.readLightLevel();
  if (lux >= 0.0) {
	// Round lux to 0.1
        // May be this rounding can be improved
	lux = floor(lux * 5 + 0.5) / 5;
	send(lightMsg.set(lux, 1));

	Serial.print(F("BH1750 - Light = "));
	Serial.print(lux);
	Serial.println(F(" lx"));

  } else {
	Serial.println(F("=> BH1750 Error!"));
  }
}

void loop()
{
  static uint32_t lastMillis = 0 - measurementPeriod;
  if (millis() - lastMillis >= measurementPeriod)
  {
	getLightLevel();
	lastMillis = millis();
  }

  unsigned long sleeptime = 60000ul; // 60 sec
  Serial.println(F("Sensors node - Go to sleep"));
  bool smart = true;
  sleep(sleeptime, smart);
  Serial.println(F("Sensors node - Waking up"));
}

HTH Immo

Hi @mfalkvidd, thank you for your prompt response to check with the core team. cla-assistant looks perfect.

Hope the switch will not be to complicate for your side.

Hi @Steve-Parsons,
short question: do you have applied the external pull-up resistors for the two I2C bus lines? Some modules have them built-in but others not. E.g. the Lolin Wemos shield has them already connected to power with two 4.7k resistors. See schematic for it: sch_bh1750_v1.0.0.pdf

If not, you should try this.
May be your first module is not defect, but only the resistors are missing?

Hi all,
I'd like to add, there is no need to call wdt_reset() explicitly in loop().
This already takes place before each loop() call in the MySensors library code behind function doYield():
see: MySensorsCore.cpp#L619

And hwWatchdogReset() is an HW abstraction of wdt_reset() for AVR architecture:
/hal/architecture/AVR/MyHwAVR.h#L71

My call stack from main() to doYield() is:

>	MySensorsProject2.exe!doYield() Line 650	C++
 	MySensorsProject2.exe!_processInternal() Line 74	C++
 	MySensorsProject2.exe!_process() Line 91	C++
 	MySensorsProject2.exe!main(int argc, char * * argv) Line 343	C++

Hi @Necromant, thank you for your comments regarding the RPD feature of the nRF24+.

I have done some experiments with it. The result is a new tool TrafficDetectorRF24, which is available in my MySensors.Tools repository. The tool scans a single channel and outputs the current status via a debug pin. This can be used to connect a LED or better an input of a logic analyser.

At first I tried to use the RPD feature based on the MySensors example PassiveNode.
Unfortunately, that didn't work at all for me. I then adapted the code from Rolf Henkel Poor Man's Wireless 2.4GHz Scanner for my purposes.

The detector works quite accurately (resolution approx. 140us) so that you can usually detect the transmitted telegram and the ACK response of the receiver individually:

I hope you have more success in your attempts with the RPD feature.

Hi @skywatch, from my view this would be possible, but it needs some modifications to the MySensors library.

One needs to add a field for the RF24 channel to the EEPROM fields, see:
core/MyEepromAddresses.h#L34

This field value should then be used when initialising the transport layer for the RF24 channel.

For the initialisation to take place, the simplest way would be to call hwReboot(). This can also be done remotely via an I_REBOOT message.

But that is a lot of modification. The mysbootloader that I love to use for my AVR nodes would also need an update, as it also relies on the EEPROM address layout.

Hi @necromant, thanks for your HA setup and investigations. Yes, when a message is sent to an actuator, it needs to respond with the new status for HA. If you control multiple actuators quickly one after the other it creates perfect traffic jam in the MySensors network.

Now we just have to find an algorithm how to best resolve these collisions.
Your HA project is then a perfect real-world test for the algorithm.

This is how Setting-02 looks like with my good old Saleae LA when both nodes send at the same moment:

You can see, both nodes send the message 16 times because ARD is 15 by default.
And both without success.

@Necromant You are right, an ESP8266 with WiFi may behave differently than an STM32. Unfortunately I don't have a working STM32 as gateway.

Meanwhile I created two additional test settings with gateway and two nodes, where the used gateway type is not important. The test settings are available in my repo MySensors.IssueProjects.

• Setting-02 creates a race condition of two nodes sending a message to the gateway at the same time.
• Setting-03 creates a conflict when both nodes send a message to each other at the same moment. For that one node is in repeater mode and the other node is associated to the repeater.

The approach of synchronizing the two nodes via GPIOs and a wire to send at the same moment works very well and reproducibly in Setting-02. The only problem was when all the sent messages in a row fail, that then the internal self-healing mechanism of MySensor's transport logic reinitializes the radio. To avoid this, I added logic that sends a successful message after 4 failed messages. With this the MySensors self-healing mechanism is then satisfied.

Setting-03 does not work properly yet, because the N2N logic causes every message from node to the repeater to be sent twice.

I will create an issue about this in the MySensors repo.

@Necromant said in [RFC] Improve package delivery for RF24 modules:

Another idea I thought of, would be listening if any carrier is present. (nRF24L01+ has that feature) and sending any packets only once there's no carrier + adding a random delay. This would hopefully avoid collisions, even with other things, like WiFi.

Yes, this sounds interesting. Do you think of the RPD register value (Received Power Detector) from RF24?
But it will only work with the RF24 transport drivers (like @skywatch remarked above).

Meanwhile I'm ready with the first setup to produce a reproduceable packet lost with your idea of sending multiple messages immediately one after other. The test project repo with gateway and one node is:
MySensors.IssueProjects

The MySensors core changes are in my project fork branch:
topic/mkr/issueTransportHalRetry

Unfortunately the #1477/Setting-01 solution don't produces any lost packet with ESP8266/160MHz as gateway and Nano/12MHz as node. So I would say that a fast gateway, sending multiple messages to same node in a sequence without wait() in between, is not the reason for lost packages. I have checked with up to 256 packets in a row. All perfectly transferred without any one lost.

My next try is to use two nodes which send messages at the same time to gateway. I think of somehow synchronize the nodes by a wire between GPIOs. I will let you know.

But maybe someone has a better idea for a setup which produces a packet lost for sure?

Hi @Necromant, welcome to the forum!
BTW From your profile image is it this one?

This is a SN7440 clone from Soviet times, right?

But back to topic and your issue 1:
A delay before resending is required for sure. A wait() is not a good idea because it introduces recursion of unknown deep, depending from the users receive() implementation.

But a short delay() is possible. While delay() the RF24 is in receive mode and can actually receive the other nodes packet which has collided before.

But exponential backoff is also not a good idea, because this can become a long delay of a second or more which blocks all time the main loop. But a short random delay of some 10th ms (like mentioned by @skywatch) worked for me in my setup.

But instead of speculating, we should try out the ideas on a test setup in a comprehensible way. But we should do that outside the official MySensors repo.

I will prepare a branch with the necessary core changes in my MySensors clone repo and also create test projects. I will start with a gateway and a sensor node.

Then we can check your topic 3 with sending 4 or more packets in a row from gateway (I will use a ESP8266) to a slow 12MHz Nano clone.

@NeverDie No thanks
To write a complete architecture HAL for MySensors is a lot of work. Search e.g. in the MyHwSAMD .cpp code for "TODO: Not supported!". And this HAL already exists since years!

There are other construction sites in MySensors that are more worth the development effort.

@skywatch There is also the next "Yet another Arduino with fancy hardware but poor library support" planned: Arduino Nano RP2040 Connect

Hi @NeverDie, I also like the Atmega4809. I have an Nano Every here to play with. It has 6KB RAM and 48KB flash memory. That's all nice. But software compatibility is the problem.

Looks like it needs a new HAL architecture implememtation for MySensors. When I try to build a simple MyS project with Arduino IDE I get:

~\Documents\Arduino\libraries\MySensors/MySensors.h:89:2: error: #error Hardware abstraction not defined (unsupported platform)
 #error Hardware abstraction not defined (unsupported platform)
  ^~~~~
exit status 1
Error compiling for board Arduino Nano Every.

Very sad