Return value of bool send(MyMessage &msg, const bool ack = false);

[bilbolodz]

According MySensorsCore.h function bool send(MyMessage &msg, const bool ack = false) should return " true if message reached the first stop on its way to destination"

/**
* Sends a message to gateway or one of the other nodes in the radio network
*
* @param msg Message to send
* @param ack Set this to true if you want destination node to send ack back to this node. Default is not to request any ack.
* @return true Returns true if message reached the first stop on its way to destination.
*/
bool send(MyMessage &msg, const bool ack = false);

In my case (using ACK options) it always return true regardless state of gateway (I've physically disconnected GW from USB after sensor startup/registration phase..... I'm using 2.1.1 version and RF24 transport What could be wrong?

[pjr]

Would this help? https://forum.mysensors.org/topic/3346/discussion-reliable-delivery/17

[rozpruwacz]

I had wierd behaviour with gateway on raspberry pi + nrf24 - after disconnecting the nfr module from raspberry pi the gateway was sending ack for the next message but subsequent messages were not acked anymore. Maybe nrf module sends ack by itself and energy stored in capacitors is sufficient to send one message ?

[bilbolodz]

@pjr Thank you. I'm already using software ack (and message resending after timeout) for get reliable radio transport. According hardware ack:

Hardware ack is what I get when using send(msg, true) and some other functions like present, sendSketchInfo and sendBatteryLevel

    Hardware ack is hop-to-hop acknowledgment
    Sending is a blocking function which returns true if an ack was received and false if ~70ms passed without receiving an hardware ack.
    Sending ack is handled automatically by the library(/radio)
    Receiving an ack is handled automatically by the library
    Re-send needs to be handled manually in each sketch (a while-loop with a counter counting up to maxRetries and using wait() between each resend seems to be the most common solution)

sounds nice but above statement seems to be not true in my case: after complete node registration in GW send function returns always true even GW is powered off.... I've studied source and looks that "in the lowest level of code" send function outcome comes from: drivers/RF24/RF24.cpp function:

LOCAL bool RF24_sendMessage(const uint8_t recipient, const void* buf, const uint8_t len)
{
	uint8_t RF24_status;
	RF24_stopListening();
	RF24_openWritingPipe( recipient );
	RF24_DEBUG(PSTR("RF24:SND:TO=%d,LEN=%d\n"),recipient,len); // send message
	// flush TX FIFO
	RF24_flushTX();
	// this command is affected in clones (e.g. Si24R1):  flipped NoACK bit when using W_TX_PAYLOAD_NO_ACK / W_TX_PAYLOAD
	// AutoACK is disabled on the broadcasting pipe - NO_ACK prevents resending
	RF24_spiMultiByteTransfer(recipient == BROADCAST_ADDRESS ? RF24_WRITE_TX_PAYLOAD_NO_ACK :
	                          RF24_WRITE_TX_PAYLOAD, (uint8_t*)buf, len, false );
	// go, TX starts after ~10us
	RF24_ce(HIGH);
	// timeout counter to detect HW issues
	uint16_t timeout = 0xFFFF;
	do {
		RF24_status = RF24_getStatus();
	} while  (!(RF24_status & ( _BV(RF24_MAX_RT) | _BV(RF24_TX_DS) )) && timeout--);
	// timeout value after successful TX on 16Mhz AVR ~ 65500, i.e. msg is transmitted after ~36 loop cycles
	RF24_ce(LOW);
	// reset interrupts
	RF24_setStatus(_BV(RF24_TX_DS) | _BV(RF24_MAX_RT) );
	// Max retries exceeded
	if(RF24_status & _BV(RF24_MAX_RT)) {
		// flush packet
		RF24_DEBUG(PSTR("!RF24:SND:MAX_RT\n"));	// max retries, no ACK
		RF24_flushTX();
	}
	RF24_startListening();
	// true if message sent
	return (RF24_status & _BV(RF24_TX_DS));
}

so it's from RF24 status register. I've to check how it's working on other RF24 modules. I've read that there are some comparability problems with non original Chinese clones of NRF24L01 chipset.

[mfalkvidd]

@bilbolodz just to check: are you sure there are no repeaters or other gateways within range?

[bilbolodz]

@mfalkvidd said in Return value of bool send(MyMessage &msg, const bool ack = false);:

@bilbolodz just to check: are you sure there are no repeaters or other gateways within range?

I've to check more thoroughly but rather not.