@dan-mincu good to hear you got it working. Next time please clearly stress that you are not using the mySensors library. The mySensors library handles all the sleeping for you and powers the radio down correctly.

Or, take this opportunity and start using it now!

@dan-mincu I see power consumption is a repeating topic, therefore I added a table with measurements for some of my modules here: https://www.mysensors.org/build/battery#radio-power-consumption
Maybe someone else can add some more radio types (RFM, nRF52 etc.)

@dan-mincu the pinout of the amplified modules is identical to the non amplified modules. Therefore the PA + lna are not accessible from the outside, and the nrf also doesn't actively control them.
IIRR the PA is enabled by the CE line of the module, so it is disabled in sleep mode. Still it might draw some current though, that could be what you are measuring.
I did a quick measurement on some budget pa+lna module. At max power, tx current is 65.1 mA, rx 13.7 mA and sleep current 1.1 uA.
A lot lower than yours indeed, using regular mySensors sleep() method (measured using the nrf doctor btw).

@mfalkvidd said in NRF24 transport status not initialized:

I do not know what they were intended for

Tekka's chart says it all; preHwInit() has no serial output, so can be used to e.g. initialize serial devices (some hardware might require this). Then before() is called which starts logging to serial.

@gardensheddev If you use either pin 2 or 3 you can use the MySensors sleep() method to handle all the sleeping -- so much easier.

@sergio-rius My remark on the high channel number was just to address your issue with range -- I understand it doesn't influence timing between nodes and gateway.

I've read over all your posts and have a hard time understanding where you are right now.
E.g. in your last post "as it works if debug is activated. Also Tekka Code works." That suggests there is a working solution for you, with tekka's patch and debug disabled. Is this correct?

To be able to help, could you briefly and clearly state what your exact issue is, what works and what doesn't. Preferably in a new thread, as this one seems to be derailing.

@sergio-rius said in nRF24L01+ Communication Failure: Root Cause and “Solution”:

#define MY_RF24_CHANNEL 108

Your range issues could be caused by this high channel number; clones perform worse in my experience at high channel numbers. Did you try with lower channels? (less than 90)

@flyingdomotic said in Can't even get a base Mysensors sketch to work:

Would 30 seconds be a short wait time?

For a PIR sensor I would say yes.
A PIR triggers an alarm or switches on a lamp, so usually there is no need to do this more often than once every 30 seconds I would say.
So what's the use in reporting the PIR triggers more often?

@homer I've had good results by introducing a short wait time before sleeping ; e.g use wait(30000) to ignore any false triggers from the sensor.

@danielef see e.g. the implementation of the before() method in this thread : https://forum.mysensors.org/topic/10358/solved-mqtt-gateway-based-on-arduino-uno-uno-compatible-w5100-ethernet-shield-rfm69hw-radio