So you try to reinvent the NRF24 Network?
Why?
On the net I found a post on the use of addresses and some problems that may arise.
I changed the code by deleting the hex digit offending (0, 1, 2, 5, A & F).
Now the Node Id (1 byte) is encoded in 2 address bytes.
The Netword Addres is reduced to 3 bytes.
For example, 0x70 becomes 0x87 0x43.
for (i=from; i<to; i++) {
AddressEncode(i, &msb, &lsb);
address[0] = msb;
address[1] = lsb;
radio.openWritingPipe(address);
Unfortunately the problem persists,
the FOR cycle is OK when the range is [40, 90] is KO when [50, 70] ...
I think the problem is inside the RX node because it correctly sends ACK but it does not set the availability of the received data.
So I tried to replace the function radio.available()
(this checks the RX_EMPTY field of the FIFO_STATUS register)
with the function radio.whatHappened()
(this checks the RX_DR field of the NRF_STATUS register)
// while (radio.available()) {
radio.whatHappened(tx_ok, tx_fail, rx_ready);
if (rx_ready) {
radio.read(&RxFrame, 5); // Prefix size len
Serial.println("RxFrame");
}
but unfortunately once again the FOR cycle does not work.
Later I will try to insert a delay in the FOR cycle as suggested by Robin2.
In a previous test the cycle sent 50000 messages (only at 2 address nodes) without delay and without errors.
The TX Node has always received ACK and the RX Node has always printed the message.
Serial.println("Test Start");
for (i=0; i<50000; i++) {
address[0] = 0x37;
radio.openWritingPipe(address);
result = radio.write(&TxFrame, TxLen);
if (result) x37Live++;
else x37Dead++;
address[0] = 0x42;
radio.openWritingPipe(address);
result = radio.write(&TxFrame, TxLen);
if (result) x42Live++;
else x42Dead++;
}
Serial.println("Test End");
Whandall:
So you try to reinvent the NRF24 Network?Why?
There is not a fundamental reason, indispensable for not using the RF24_Network & RF24_Mesh libraries.
Here are some ideas that (currently) pushed me not to use them.
Arduino has little Ram & Storage space.
I do not need full communication between Agent-Agent but only Agent-Manager
(in the future, A-A communication can be emulated with A-M plus M-A connections).
The RF24_Network & RF24_Mesh libraries consume space and I do not need all the features they offer.
Also I do not know this libraries.
I like to have full control (when possible) of what happens inside the MCU.
Whandall:
@snico_one are you shure that there are no other nodes around that could use the same addresses?You could switch to a different channel to test for such a collision.
There are no other nodes, I'm sure.
Whandall:
On the first screenshot the configuration of the left hand node shows that you did not power cycle
the module between configuration changes (pipe 0 -> pipe 1).
Remember that the NRF keeps its register content regardless of any AVR resets,
only a power cycle brings it back to the reset state that the library is expecting on begin.
Ok, I check this case on RX_PW_P0-6, thanks
I tried this variant (different pins and baudrate, some cleanup)
#include <SPI.h>
#include <RF24.h>
#include <printf.h>
const byte pinMenu = 2;
RF24 radio(9, 10);
byte RxFrame[26];
byte TxFrame[] = "abcdefghijklmnopqrstuvwyxz";
const byte addNode0[5] = { 0x07, 0xA1, 0xA2, 0xA3, 0xA4 };
const byte addNode1[5] = { 0x37, 0xA1, 0xA2, 0xA3, 0xA4 };
const byte addNode2[5] = { 0x42, 0xA1, 0xA2, 0xA3, 0xA4 };
byte nodeId = 0x07; // 0x07 Discovery, 0x37 + 0x42 always listening
void NetDiscovery(void);
void setup() {
pinMode(pinMenu, INPUT_PULLUP);
printf_begin();
Serial.begin(250000);
Serial.print(F("Node Id: 0x"));
Serial.print(nodeId, HEX);
Serial.print(F(" - "));
Serial.println(nodeId);
Serial.println();
radio.begin();
radio.setPALevel(RF24_PA_MAX);
radio.setDataRate(RF24_1MBPS);
radio.setChannel(0x66);
radio.setRetries(10, 10);
radio.setAutoAck(true);
switch (nodeId) {
case 0x07:
radio.openReadingPipe(1, addNode0);
break;
case 0x37:
radio.openReadingPipe(1, addNode1);
break;
case 0x42:
radio.openReadingPipe(1, addNode2);
break;
}
radio.startListening();
radio.printDetails();
Serial.println();
}
void loop() {
while (radio.available()) {
radio.read(&RxFrame, 5);
Serial.println("RxFrame");
}
if (nodeId == 0x07) {
if (digitalRead(pinMenu) == LOW) {
radio.stopListening();
NetDiscovery();
radio.startListening();
}
}
}
void NetDiscovery() {
byte address[5] = { 0x00, 0xA1, 0xA2, 0xA3, 0xA4 };
byte from = 50;
byte to = 70; // OK 40 - 90, KO 50 - 70
Serial.print(F("Discovery From: "));
Serial.print(from);
Serial.print(F(" - To: "));
Serial.println(to);
for (byte i = from; i < to; i++) {
address[0] = i; // complete TX address
radio.openWritingPipe(address);
bool result = radio.write(&TxFrame, 5); // Prefix len size to 5
if (result) {
Serial.print(F("Node "));
Serial.print(i);
Serial.println(F(" - LIVE"));
}
}
Serial.println(F("Discovery END"));
Serial.println();
}
Discovery From: 50 - To: 70
Node 55 - LIVE
Node 66 - LIVE
Discovery END
and I can not reproduce your error, it just works as expected.
Added:
I have seen two bursts of spurious receives on the 0x07 node unrelated to the scanning process.
Its address pattern seems to be sensitive to false receptions, so you could try a different prefix.
I think you should make only the least significant byte variable,
that allows you to use more than two pipes at the same time, which could be handy.
A different channel would be worth a try also.
Hi Whandall, many thanks for the support.
Sorry but I do not fully understand what you say:
I think you should make only the least significant byte variable,
that allows you to use more than two pipes at the same time, which could be handy.
I use only pipe 1 for to read,
const byte addNode0[5] = { 0x07, 0xA1, 0xA2, 0xA3, 0xA4 };
const byte addNode1[5] = { 0x37, 0xA1, 0xA2, 0xA3, 0xA4 };
const byte addNode2[5] = { 0x42, 0xA1, 0xA2, 0xA3, 0xA4 };
and node addresses change only in the LSB ...
In your test what does the rx node (0x37 or 0x42) report?
You confirm that it writes "RxFrame" ?
I'm in the office right now and I can not try the code, I'll do it as soon as possible.
Interesting as you say:
Its address pattern seems to be sensitive to false receptions, so you could try a different prefix.
I do not have tools to analyze traffic (oscillator, analyzer, etc.)
Please, you can check for the presence of false receptions if you change these addresses
from: 0xA1, 0xA2, 0xA3, 0xA4
to: 0xB4, 0xC6, 0xD7, 0xE8
grazie molto
sn
snico_one:
Sorry but I do not fully understand what you say:I think you should make only the least significant byte variable,
that allows you to use more than two pipes at the same time, which could be handy.I use only pipe 1 for to read,
I would leave that scheme untouched.
Maybe you now only use one pipe (and you could use two at a time without restrictions),
but to use more than two, all but one have to share the high part of the address.
Don't build obstacles to use all of the hardware in your addressing scheme.
snico_one:
In your test what does the rx node (0x37 or 0x42) report?
You confirm that it writes "RxFrame" ?
Yes for each test - regardless of the bounds - each node reports RxFrame.
40 - 90, 40 -70, 50 - 70, 50 - 90 all print RxFrame once for each test.
snico_one:
I do not have tools to analyze traffic (oscillator, analyzer, etc.)
There is a very basic analyzer sketch Poor Man's 2.4 GHz Scanner.
snico_one:
Please, you can check for the presence of false receptions if you change these addressesfrom: 0xA1, 0xA2, 0xA3, 0xA4
to: 0xB4, 0xC6, 0xD7, 0xE8
I will try that, but the bursts occured only twice and while I was moving the node,
so it could have been an connection problem.
With that 0xB4, 0xC6, 0xD7, 0xE8 I can see the error, so it seems the pattern is significant.
From 49 to 70 works, 50 to 70 does not print RxFrame on both other nodes.
Whandall:
Maybe you now only use one pipe (and you could use two at a time without restrictions),
but to use more than two, all but one have to share the high part of the address.
yes, I fully agree with this
But for me A1-A4 is the LOW part of the address, inside code i set address[0] = 0x37.
printDetails() report:
STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 = 0xa4a3a2a137 0xc2c2c2c2c2
Maybe you refer to my previous image that may be wrong?
There is a very basic analyzer sketch Poor Man's 2.4 GHz Scanner.
Good !!! I will try it, it will surely help me
With that 0xB4, 0xC6, 0xD7, 0xE8 I can see the error, so it seems the pattern is significant.
From 49 to 70 works, 50 to 70 does not print RxFrame on both other nodes.
Strange, I thought the other way around.
0xA1, 0xA2, 0xA3, 0xA4 bad address
0xB4, 0xC6, 0xD7, 0xE8 good addreess
did you read this post?
Well, a first step was made: the problem is reproducible and does not seem to depend on the code
I'm home now and I'll do other tests...
snico_one:
But for me A1-A4 is the LOW part of the address, inside code i set address[0] = 0x37.
printDetails() report:STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 = 0xa4a3a2a137 0xc2c2c2c2c2
So for you the low part of 0xa4a3a2a137 is A1-A4?
I did some other tests (change so dynPayload, different speeds, different power settings, different addresses)
but the error persists.
I now have a setup that allows exactly one correct reception, after that the packets get acked,
but no reception is signaled to the Arduino until the next power-cycle.
Very strange, but interesting.
Whandall:
Very strange, but interesting.
Will you please post the program. I would like to try it.
...R
Shure.
#include <SPI.h>
#include <RF24.h>
#include <printf.h>
const byte pinMenu = 2;
RF24 radio(9, 10);
byte RxFrame[32];
byte TxFrame[] = "abcdefghijklmnopqrstuvwyxz";
const byte addNode0[5] = { 0x07, 'f', 'u', 'c', 'k' };
const byte addNode1[5] = { 0x37, 'f', 'u', 'c', 'k' };
const byte addNode2[5] = { 0x42, 'f', 'u', 'c', 'k' };
byte nodeId = 0x07; // 0x07 Discovery, 0x37 + 0x42 always listening
void NetDiscovery(void);
void setup() {
pinMode(pinMenu, INPUT_PULLUP);
printf_begin();
Serial.begin(250000);
Serial.print(F("Node Id: 0x"));
Serial.print(nodeId, HEX);
Serial.print(F(" - "));
Serial.println(nodeId);
Serial.println();
radio.begin();
radio.setPALevel(RF24_PA_MAX);
radio.setDataRate(RF24_1MBPS);
radio.setChannel(0x66);
radio.setRetries(10, 10);
radio.setAutoAck(true);
radio.enableDynamicPayloads();
switch (nodeId) {
case 0x07:
radio.openReadingPipe(1, addNode0);
break;
case 0x37:
radio.openReadingPipe(1, addNode1);
break;
case 0x42:
radio.openReadingPipe(1, addNode2);
break;
}
radio.startListening();
radio.printDetails();
Serial.println();
}
void loop() {
if (radio.available()) {
radio.read(&RxFrame, radio.getDynamicPayloadSize());
Serial.println(F("RxFrame"));
radio.printDetails();
}
if (nodeId == 0x07) {
if (digitalRead(pinMenu) == LOW) {
radio.stopListening();
NetDiscovery();
radio.startListening();
}
}
}
// 0xB4, 0xC6, 0xD7, 0xE8 bad 50-70
void NetDiscovery() {
byte address[5] = { 0x00, 'f', 'u', 'c', 'k' };
byte from = 50;
byte to = 70; // OK 40 - 90, KO 50 - 70
Serial.print(F("Discovery From: "));
Serial.print(from);
Serial.print(F(" - To: "));
Serial.println(to);
for (byte i = from; i < to; i++) {
address[0] = i; // complete TX address
radio.openWritingPipe(address);
bool result = radio.write(&TxFrame, 5);
if (result) {
Serial.print(F("Node "));
Serial.print(i);
Serial.println(F(" - LIVE"));
}
}
Serial.println(F("Discovery END"));
Serial.println();
}
I added a printDetails on RxFrame, but that does not give a hint.
Node Id: 0x7 - 7
STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 = 0x6b63756645 0x6b63756607
RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6
TX_ADDR = 0x6b63756645
RX_PW_P0-6 = 0x20 0x20 0x00 0x00 0x00 0x00
EN_AA = 0x3f
EN_RXADDR = 0x02
RF_CH = 0x66
RF_SETUP = 0x07
CONFIG = 0x0f
DYNPD/FEATURE = 0x3f 0x04
Data Rate = 1MBPS
Model = nRF24L01+
CRC Length = 16 bits
PA Power = PA_MAX
Discovery From: 50 - To: 70
Node 55 - LIVE
Node 66 - LIVE
Discovery END
Discovery From: 50 - To: 70
Node 55 - LIVE
Node 66 - LIVE
Discovery END
Node Id: 0x42 - 66
STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 = 0xe7e7e7e7e7 0x6b63756642
RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6
TX_ADDR = 0xe7e7e7e7e7
RX_PW_P0-6 = 0x00 0x20 0x00 0x00 0x00 0x00
EN_AA = 0x3f
EN_RXADDR = 0x02
RF_CH = 0x66
RF_SETUP = 0x07
CONFIG = 0x0f
DYNPD/FEATURE = 0x3f 0x04
Data Rate = 1MBPS
Model = nRF24L01+
CRC Length = 16 bits
PA Power = PA_MAX
RxFrame
STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 = 0xe7e7e7e7e7 0x6b63756642
RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6
TX_ADDR = 0xe7e7e7e7e7
RX_PW_P0-6 = 0x00 0x20 0x00 0x00 0x00 0x00
EN_AA = 0x3f
EN_RXADDR = 0x02
RF_CH = 0x66
RF_SETUP = 0x07
CONFIG = 0x0f
DYNPD/FEATURE = 0x3f 0x04
Data Rate = 1MBPS
Model = nRF24L01+
CRC Length = 16 bits
PA Power = PA_MAX
Node Id: 0x37 - 55
STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 = 0xe7e7e7e7e7 0x6b63756637
RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6
TX_ADDR = 0xe7e7e7e7e7
RX_PW_P0-6 = 0x00 0x20 0x00 0x00 0x00 0x00
EN_AA = 0x3f
EN_RXADDR = 0x02
RF_CH = 0x66
RF_SETUP = 0x07
CONFIG = 0x0f
DYNPD/FEATURE = 0x3f 0x04
Data Rate = 1MBPS
Model = nRF24L01+
CRC Length = 16 bits
PA Power = PA_MAX
RxFrame
STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 = 0xe7e7e7e7e7 0x6b63756637
RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6
TX_ADDR = 0xe7e7e7e7e7
RX_PW_P0-6 = 0x00 0x20 0x00 0x00 0x00 0x00
EN_AA = 0x3f
EN_RXADDR = 0x02
RF_CH = 0x66
RF_SETUP = 0x07
CONFIG = 0x0f
DYNPD/FEATURE = 0x3f 0x04
Data Rate = 1MBPS
Model = nRF24L01+
CRC Length = 16 bits
PA Power = PA_MAX
An image is better than 100 words 
Byte 0 (LSB) must vary between the various addresses 
I did some other tests (change so dynPayload, different speeds, different power settings, different addresses) but the error persists.
I agree, I have also done other tests but I always have the error.
Even with Delay(1000) in the FOR cycle (as suggested by Robin2) I always get the error.
The only difference between our tests and that to me even with the address A1-A4 the error is presented.
Very strange, but interesting.
Yes, yes very strange ... I've been losing my mind for a week >:(
The question is: does the address scheme generate the problem?
If so why does the RX node send the ACK correctly to the TX node?
If the problem is the addressing scheme, the problem must also occur on other boards (Raspberry PI for example).
I have to recover an RPI and try ...
Whandall:
Shure.
Thanks. I don't think I will get near it before Friday as I have Christmas stuff to prepare.
...R
Hi everyone.
I did other tests, this time I used a raspberry module also.
My conclusion is: the NRF24 module has problems.
Context:
- Arduino Nano with NRF24 libary by TMRh0 (c code)
- Raspberry 3B with NRF24 libary by Brian Lavery (python code)
Download Library:
https://github.com/nRF24/RF24/archive/master.zip
https://github.com/Blavery/lib_nrf24/archive/master.zip
https://github.com/Gadgetoid/py-spidev/archive/master.zip
Symptom:
The sender after sending a frame receives ACK from the recipient but this has no available data.
Test case A)
Arduino send, RPi receive
the loop "for (byte i=from; i<to; i++)"
is OK with from=40 & to=90
is KO with from=50 & to=70
Test case B)
RPi send, Arduino receive
the loop "for i in range(f, t):
is OK with f=40 & t=90
is KO with f=50 & t=70
Since different hardware with different libraries always produce the same error
I guess the problem is the NRF24 hardware module.
Following is the code for ARduino and Raspberry.
For Arduino there is only one program for TX & RX (nodeAgent.ino).
Set "nodeId = 0x07" for TX role, and "nodeId = 0x37" for RX role.
#include <SPI.h>
#include <RF24.h>
#include <printf.h>
#define PIN_MENU 2
RF24 radio(9, 10);
byte RxFrame[26];
byte TxFrame[] = "abcdefghijklmnopqrstuvwyxz";
const byte addNode0[5] = {0x07, 0xA1, 0xA2, 0xA3, 0xA4 };
const byte addNode1[5] = {0x37, 0xA1, 0xA2, 0xA3, 0xA4 };
const byte addNode2[5] = {0x42, 0xA1, 0xA2, 0xA3, 0xA4 };
byte nodeId = 0x07; // 0x07 Discovery, 0x37 & 0x42 always listening
void NetDiscovery(void);
void setup() {
pinMode(PIN_MENU, INPUT_PULLUP);
printf_begin();
Serial.begin(115200);
Serial.print("Node Id: 0x");
Serial.print(nodeId, HEX);
Serial.print(" - ");
Serial.println(nodeId);
Serial.println();
radio.begin();
radio.setPALevel(RF24_PA_MAX);
radio.setDataRate(RF24_1MBPS);
radio.setChannel(0x66);
radio.setRetries(10, 10);
radio.setAutoAck(true);
switch (nodeId) {
case 0x07:
radio.openReadingPipe(1, addNode0);
break;
case 0x37:
radio.openReadingPipe(1, addNode1);
break;
case 0x42:
radio.openReadingPipe(1, addNode2);
break;
}
radio.startListening();
radio.printDetails();
Serial.println();
}
void loop() {
while (radio.available()) {
radio.read(&RxFrame, 5);
Serial.println("RxFrame");
}
if (nodeId == 0x07) {
if (digitalRead(PIN_MENU) == LOW) {
radio.stopListening();
NetDiscovery();
radio.startListening();
}
}
}
void NetDiscovery() {
byte address[5] = { 0x00, 0xA1, 0xA2, 0xA3, 0xA4 };
byte from = 40;
byte to = 90; // OK 40 - 90, KO 50 - 70
Serial.print(F("Discovery From: "));
Serial.print(from);
Serial.print(F(" - To: "));
Serial.println(to);
for (byte i=from; i<to; i++) {
address[0] = i;
radio.openWritingPipe(address);
bool result = radio.write(&TxFrame, 5);
if (result) {
Serial.print(F("Node "));
Serial.print(i);
Serial.println(F(" - LIVE"));
}
}
Serial.println(F("Discovery END"));
Serial.println();
}
For Raspberry there are 2 script python.
txArduino.py send frame to Arduino,
import RPi.GPIO as GPIO
from lib_nrf24 import NRF24
import time
import spidev
GPIO.setmode(GPIO.BCM)
addNode0 = [0xA4, 0xA3, 0xA2, 0xA1, 0x17 ]
nodeId = 0x17
print "TX to Arduinio v0.1.3"
radio = NRF24(GPIO, spidev.SpiDev())
radio.begin(0, 17)
radio.setPayloadSize(32)
radio.setChannel(0x66)
radio.setDataRate(NRF24.BR_1MBPS)
radio.setPALevel(NRF24.PA_MIN)
radio.setAutoAck(True)
radio.openReadingPipe(1, addNode0)
radio.printDetails()
while(1):
f = 40
t = 90
TxFrame = list("HELLO")
print "Discovery From:", f, " - To:", t
for i in range(f, t):
print "TX to node", i
address = [0xA4, 0xA3, 0xA2, 0xA1, i ]
radio.openWritingPipe(address)
radio.write(TxFrame)
print "Discovery END"
time.sleep(20)
rxArduino.py receive frame from Arduino.
import RPi.GPIO as GPIO
from lib_nrf24 import NRF24
import time
import spidev
GPIO.setmode(GPIO.BCM)
addNode0 = [0xA4, 0xA3, 0xA2, 0xA1, 0x07 ]
addNode1 = [0xA4, 0xA3, 0xA2, 0xA1, 0x37 ]
addNode2 = [0xA4, 0xA3, 0xA2, 0xA1, 0x42 ]
print "RX from Arduinio v0.1.4"
radio = NRF24(GPIO, spidev.SpiDev())
radio.begin(0, 17)
radio.setPayloadSize(32)
radio.setChannel(0x66)
radio.setDataRate(NRF24.BR_1MBPS)
radio.setPALevel(NRF24.PA_MIN)
radio.setAutoAck(True)
radio.openReadingPipe(1, addNode2)
radio.printDetails()
radio.startListening()
while(1):
while not radio.available(0):
time.sleep(1 / 100)
RxFrame = []
radio.read(RxFrame, 5)
string = ""
for n in RxFrame:
if (n >= 32 and n <= 126):
string += chr(n)
print("RX Frame: {}".format(string))
I have had a few minutes to look at this. I have not tried testing the code yet, I have just been trying to understand the code and the problem.
One thing that I find confusing is the choice of nodeIDs. In the program in Reply #32 they are 0x07, 0x37 and 0x42 but in the code in the Original Post they are 0x07, 0x37 and 0x47 and the latter have the characteristic that the three low bits are the same 111
Next thing I find confusing is that @Whandall seems to say in Reply #28 that the problem only(?) arises with the 4 high address bytes of 0xB4, 0xC6, 0xD7, 0xE8 whereas @snico_one seems to say in various places that the problem arises with the bytes 0xA1, 0xA2, 0xA3, 0xA4. Which is it?
Thirdly, I am still not clear how the problem is manifesting itself. Is it the case that the Master sends a short discovery message to a slave and the slave gives a valid acknowledgement but does not appear to receive the short message?
And this (from Reply #28) "From 49 to 70 works, 50 to 70 does not print RxFrame on both other nodes." suggests to me the problem is with the Tx rather than the Rx because the Rx could not possibly know the range of addresses that are tried.
Just my 1.5 cents
...R
My code uses a different high part of the address and shows the same behaviour,
I did not try more than two high address parts.
Tx sees an acked packet, no packet is signaled by the rx node.
Some ranges work, some show that strange behaviour.
If the rx node is in this strange mode, the first packet of a normally working scan is consumed,
after that it works normal again.
I have no real idea what the reason is.
Whandall:
If the rx node is in this strange mode, the first packet of a normally working scan is consumed,
after that it works normal again.
Does that mean that in the first scan through all the addresses the Master receives an ACK but the slave does not receive the data AND if the scan is repeated (through all the addresses) the Master receives the ACK and the slave properly receives the data?
I wonder would the problem go away (or be easier to diagnose) if the slave sent a pre-loaded ackPayload containing a message that would identify the slave?
I wonder if the problem would go away with a lower transmission speed - I think I have never tried more than 250k.
If one can be certain there is NEVER an ACK from a non-existent slave even if the slave giving the ACK does not receive the first message
AND if all subsequent communication with that slave works then I think the ACK can be considered valid for the purpose of identifying the existence of the slave.
...R
Robin2:
Does that mean that in the first scan through all the addresses the Master receives an ACK but the slave does not receive the data AND if the scan is repeated (through all the addresses) the Master receives the ACK and the slave properly receives the data?
Exactly.