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.

@Adam-Slowik, @JeeLet
Ok, I will give CAN-Bus a try. This is my test setup:

I will use the demo sketches from Adam's fork. Let you know how it works for me.

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

@NielBierman Thank you for pointing out that the latest TinyGSM library also supports more modern GSM chips.

I don't have a GSM module myself and no experience with it. But it would be good if you could put an issue in the MySensors GitHub repository.

It would be even better if you could post your solution with the updated TinyGSM library as a pull request to the repository development branch.

Many thanks - Immo

@mfalkvidd Yes, you are right. Acknowledge only checks the first hop. I mean the requestEcho parameter in the send function, see: API doc send().

bool send(MyMessage &msg, const bool requestEcho = false)

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.

@chabo_mq Could this possibly be an IR light barrier?

@monte Thank you for sharing, just ordered the bits.

@NielBierman Thank you for pointing out that the latest TinyGSM library also supports more modern GSM chips.

I don't have a GSM module myself and no experience with it. But it would be good if you could put an issue in the MySensors GitHub repository.

It would be even better if you could post your solution with the updated TinyGSM library as a pull request to the repository development branch.

Many thanks - Immo

Uploaded with Crome and copied from clipboard.

In logic analyser it looks like this:

Upper 4 channels are from node, lower ones are from gateway.

Close up from gateway send (4 packets):

@Adam-Slowik, @JeeLet Ok, with the both sketches it works with some limitations.
Nice work so far - thank you for contributing!

I have done some modifications in the CAN transport files.
@Adam-Slowik I would like to create a PR in your forked repo. Then we can discuss the code changes in GitHub. Would that be Ok for you - do you have time for this?

One limitation I found so far are long MyMessages. They can be up to 32 byte - which results in up to 4 CAN-Bus sub telegrams. When I send 32 byte message I observed the sub telegrams do not always arrive in send order in MyTransportCAN.cpp like this:

19916 CAN:RCV:CANH=2202010368,ID=3,TOTAL=4,CURR=0,TO=3,FROM=0
19921 CAN:RCV:LN=8,DTA0=0,DTA1=0,DTA2=3,DTA3=202,DTA4=9,DTA5=2,DTA6=0,DTA7=49
19929 CAN:RCV:SLOT=0,PART=1
19932 CAN:RCV:CANH=2202075904,ID=3,TOTAL=4,CURR=1,TO=3,FROM=0
19937 CAN:RCV:LN=8,DTA0=50,DTA1=51,DTA2=52,DTA3=53,DTA4=54,DTA5=55,DTA6=56,DTA7=57
19945 CAN:RCV:SLOT=0,PART=2
19947 CAN:RCV:CANH=2202206976,ID=3,TOTAL=4,CURR=3,TO=3,FROM=0
19953 CAN:RCV:LN=8,DTA0=56,DTA1=57,DTA2=48,DTA3=49,DTA4=50,DTA5=51,DTA6=52,DTA7=53
19960 !CAN:RCV:proper slot not found
19964 CAN:RCV:CANH=2202141440,ID=3,TOTAL=4,CURR=2,TO=3,FROM=0
19970 CAN:RCV:LN=8,DTA0=48,DTA1=49,DTA2=50,DTA3=51,DTA4=52,DTA5=53,DTA6=54,DTA7=55
19978 CAN:RCV:SLOT=0,PART=3

Sub telegram 3 arrives before 2.
I'm afraid the function _findCanPacketSlot() needs an update to handle this.
@Adam-Slowik Do you see a chance for you to update the logic next time?

Other limitation I see is the limited CAN telegram buffer of 3 packets in the MCP2515 module. I'm afraid for reliable operation with MySensors a change from polling to interrupt mode is required.
But this can be done later, after the fix for the PacketSlot logic.

@JeeLet

what do you want me to test ????

bool transportSanityCheck(void)
{
	return (CAN0.getError()==CAN_OK)
}

The "radio guy" opinion would be great.
((I'll look for possible help ). )

I'm not a "radio guy", but I think this code change looks fine. When sanity check fails then MySensors core calls transportInit() which would try to re-initialise the MCP2515 module.

In my setup with only 2 CAN modules I'm afraid this will always return CAN_OK. So no idea how to check this. May be unplug the both CAN wires?

@ueb
For me the connections according your photos are correct for ESP32.

• SDA - 21
• SCL - 22

@Adam-Slowik, @JeeLet
Ok, I will give CAN-Bus a try. This is my test setup:

I will use the demo sketches from Adam's fork. Let you know how it works for me.