Examples get stuck with certain kind of modules about rf24mesh HOT 26 CLOSED

UPDATE: They work if master has the same module as slaves. Basically they only work to the same kind of modules although they work fine with RF24 library examples.

from rf24mesh.

Well, I've heard of similar symptoms, and it sounds like you have some clones that are semi-compatible at least.

Have you tried a combination of nodes using a range of examples? ( gettingstarted, gettingstarted_call_response, pingpair_dyn, transfer.ino ) I would be interested to know what exactly works and doesnt work.

The main differene with RF24Mesh is that it uses multicasting, which none of the examples really uses.

To test out a multicast (no-ack payload), just change the radio.write line in gettingstarted to the following:
if (!radio.write( &time, sizeof(unsigned long),true )){

I'm curious to know if that will still work.

References:
http://nerdralph.blogspot.com/2014/11/se8r01-24ghz-wireless-modules.html
http://sigrok.org/wiki/Protocol_decoder:Nrf24l01
http://hackaday.com/2015/02/23/nordic-nrf24l01-real-vs-fake/

Without having acquired similar hardware myself, and this being open-source + free software, I'm kind of dependant on users to find ways of working around these problems for now.

from rf24mesh.

STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 � = 0xabcdabcd71 0x544d52687c
RX_ADDR_P2-5 � = 0xc3 0xc4 0xc5 0xc6
TX_ADDR = 0xabcdabcd71
RX_PW_P0-6 � = 0x20 0x20 0x00 0x00 0x00 0x00
EN_AA = 0x3f
EN_RXADDR � = 0x02
RF_CH = 0x01
RF_SETUP � = 0x07
CONFIG = 0x0b
DYNPD/FEATURE � = 0x00 0x00
Data Rate = 1MBPS
Model = nRF24L01+
CRC Length = 8 bits
PA Power = PA_MAX

STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 � = 0xabcdabcd71 0x544d52687c
RX_ADDR_P2-5 � = 0xc3 0xc4 0xc5 0xc6
TX_ADDR = 0xabcdabcd71
RX_PW_P0-6 � = 0x20 0x20 0x00 0x00 0x00 0x00
EN_AA = 0x3f
EN_RXADDR � = 0x02
RF_CH = 0x01
RF_SETUP � = 0x07
CONFIG = 0x0b
DYNPD/FEATURE � = 0x00 0x00
Data Rate = 1MBPS
Model = nRF24L01+
CRC Length = 8 bits
PA Power = PA_MAX

Module NRF chips have one thing different, one has "NRF M 1436AH" written on it one "NRF A1026FZ"
What I tested

1. pingpair_ack - works both ways
2. pingpair_dyn - works one way (length does not matter):

Node 1: Now sending length 14. Failed, response timed out.
Node 2: Got response size=14 value=ABCDEFGHIJKLMN. Sent response.
or
Node 1: Now sending length 20. Got response size=20 value=ABCDEFGHIJKLMNOPQRST.
Node 2: Got response size=20 value=ABCDEFGHIJKLMNOPQRST. Sent response.

1. GettingStarted - works both ways
2. GettingStarted_CallResponse - works both ways
3. Transfer - works both ways "Transfer complete at 44.56 KB/s. 2 of 10000 packets failed to send." and "Transfer complete at 26.56 KB/s. 207 of 10000 packets failed to send."
4. Multicast test - works both ways

from rf24mesh.

On a hunch, there are some modules that appear to need an ACTIVATE+0x53 command to enable the dynamic payloads specifically, which is what seems to be the problem.

If this is the case, the code would need to changed and re-uploaded on one of the devices only, since the other is working with 0x73.
Can you try opening up RF24.cpp with a text editor, and go to line 1212. Change it from 0x73 to 0x53

  #if defined (RF24_LINUX)
    csn(LOW);
    _SPI.transfer( ACTIVATE );
    _SPI.transfer( 0x53 );
    csn(HIGH);
  #else
    beginTransaction();
    _SPI.transfer( ACTIVATE );
    _SPI.transfer( 0x53 );
    endTransaction();
  #endif

You could also try putting both sets of commands as follows, but I have no idea how this will affect things:

  #if defined (RF24_LINUX)
    csn(LOW);
    _SPI.transfer( ACTIVATE );
    _SPI.transfer( 0x73 );
    _SPI.transfer( ACTIVATE );
    _SPI.transfer( 0x53 );
    csn(HIGH);
  #else
    beginTransaction();
    _SPI.transfer( ACTIVATE );
    _SPI.transfer( 0x73 );
    _SPI.transfer( ACTIVATE );
    _SPI.transfer( 0x53 );
    endTransaction();
  #endif

from rf24mesh.

No change. Mesh example still does not work after changing RF24.cpp. But the examples work if both Master and Slaves have the same modules.

from rf24mesh.

Hmm, In reviewing the details here, one thing that strikes me as odd is that the GettingStartedCall_Response sketch seems to work with different modules, although it too uses Dynamic Payloads.

For example, gettingstarted_call_response uses the settings:

radio.enableAckPayload();
radio.enableDynamicPayloads();     

Pingpair_dyn only uses the following:
radio.enableDynamicPayloads();

An obvious thing to try is enabling ackpayloads within the pingpair_dyn sketch to see if that makes any difference. There should be a reason why it works with call_response but not with pingpair_dyn.

from rf24mesh.

I added radio.enableAckPayload(); to pingpair_dyn. It still works in only one way but in some rare occasions it manages to receive the data. I read the hackaday article and by it's description I too have stumbled upon fake chips.

UPDATE: I tested it, two fake modules have smaller range (using the same arduinos, power supplies and code)

from rf24mesh.

Well thanks for trying.

At least now we have two very similar sketches, one that works, one that doesnt, but why?

The only other main difference between the sketches is the addressing::
byte addresses[][6] = {"1Node","2Node"};

const uint64_t pipes[2] = { 0xF0F0F0F0E1LL, 0xF0F0F0F0D2LL };

... which you could also try swapping around.

My only real suggestion at this point is to either try to break getting_started_call response by using settings similar to pingpair_dyn or try to get pingpair_dyn working by using settings similar to gettingstarted_call_response in order to identify what setting etc causes one sketch to work and the other to fail.

from rf24mesh.

I switched the addresses, the examples still work only one way. When those modules what seem fake are moved, the communication works a bit, both nodes get the same data but the data for example instead of ABCDEFG is UUUUUUU. I also commented out optional retry config from _dyn and that didn't result in any change.
update: When serial monitor is closed the communication the way it works is faster.

from rf24mesh.

I got nuthin, but here is a guy on a buffalo

from rf24mesh.

@Interneedus , can you give some more data , like
RF modules
Boards
connection pins
maybe you have interferance with the 2.4ghz channel ?

from rf24mesh.

(More information in earlier comments)
RF Modules - labelled as nRF24L01+, they look a bit different, chip text size, production date and batch numbers are different
Boards - Arduino nanos
Connection pins - wired to nanos exactly the same way
Inference - Most likely not, same kind of modules work flawlessly together.

from rf24mesh.

@TMRh20 Thanks for your help. I'll try to get myself some other modules and see if they work better.

edit: Is it possible to send forcefully data to master node without joining the mesh? (Assuming the signal reaches the master)

from rf24mesh.

Sorry, I missed your edit/question.

See: http://tmrh20.github.io/RF24Mesh/classRF24Mesh.html#a2032d5e5feabe69ecd89f937e0efafed

Setting a 'static' node (on the master) allows a node to use only RF24Network, and related functions to send data as desired, while other nodes use RF24Mesh.

from rf24mesh.

"I second this, the enhanced shock burst implementation in Si24R1 flips a single bit from the NRF24l01+ and are fully incompatible for variable sized payload use. It took me a long time to figure out why our mesh network would make two device-specific trees…"
This is a comment from the hackaday article. This might be the cause? (Although I did try replacing the lines responsible for dyn payload)

from rf24mesh.

I suspect the same issue as per here

Disabling dyn payload in the network layer may cause other problems, but the pingpair_dyn example will work if it is disabled on both devices, so that may be a good test if you haven't tried that specifically. (the response size will just always show 32)

from rf24mesh.

@TMRh20

Could you please tell me how could I send data (and disabling dyn payload) to those nodes with fake chips not connected to the mesh so that other nodes with original modules would work as intended?

from rf24mesh.

Well, the issue appears to be at the network layer, so RF24Network needs to be modified to work with static payloads if possible.

I haven't looked at all the details, but it might cause problems if you just disable the setting, depending on whether you are using payloads > 24bytes.

The real solution seems to be modifying RF24Network to support static payload sizes, but I haven't even had a chance to review the code and potential issues. Off the top of my head, this will affect fragementation/reassembly, and the payload sizes for different payload types will have to be known. When using dynamic payloads, the radio chip provides the size of each recieved payload.

tl;dr: Likely needs code changes.

from rf24mesh.

Would it be possible to add some kind of compatibility option to the RF24Mesh code so that nodes with fake chips would not use dynamic payloads but other nodes continue using dynamic payloads normally? I do too have a few fake chips, few original chips and it would be really nice to be able to use them both.

from rf24mesh.

Well kind of, but it will help me out in testing if you want to try it:

Just uncomment comment out #define ENABLE_DYNAMIC_PAYLOADS in RF24Network_config.h before compiling and loading onto Arduino.

In use you would probably need to disable dynamic payloads on all nodes, because I don't think you can mix and match dynamic /w non-dynamic nodes.

The other issue, of course, is that you need to have pre-determined payload sizes for whatever message types you are using, even for fragmented messages, because the radio cannot provide the size of each payload with dynamic payloads turned off.

Surprisingly, this seems to even work with RF24Ethernet, I assume the IP stack just drops the extra data...

from rf24mesh.

@TMRh20

I commented out the dynamic payload part and it seems that all of my four slaves connect to the master just fine but it is a bit unreliable. Master has original module, one slave has original, three have fake. Original module connects first if they are all powered on the same time.

from rf24mesh.

Would it be possible for you to add some kind of timeout to connecting to the mesh (and returning false when it fails)?

from rf24mesh.

Yup, this is kind of started since requestAddress(); will return false if there is data in the radio RX buffer waiting to be read. I'm not sure whether its best to add a default time-out period, if none specified, or to leave it as-is with the node attempting indefinitely. Any suggestions?

from rf24mesh.

There definetly should be a timeout to mesh.begin, long timeout by default and if user wishes one can reduce it, that way node could sleep until retrying or the node could resume doing its job.

from rf24mesh.

The latest changes to dev may address these issues with mixed modules. Any feedback is helpful. See #26 (comment)

from rf24mesh.

For those who are testing these modules out or trying to determine if they're fake.

This is how I tested them:

1. I made a table (and tested every combination) for basically any example. The best I think was Transfer, it highlighted the minor differences the most. For ex. packet loss with original ones stays 0 or 1 usually, but with fakes >20 is common. When a capacitor is attached the fake ones seem to work better.

For ex:

2. Look at the writing of the NRF chip. If the text is like on the right one, it's genuine most likely, if it is like the left one, it might be fake.

3. If the chip is under epoxy blob, it is fake.

I think if you buy genuine models on eBay I would love to create a list of sellers/listings who sell genuine so that there would be less headache.

from rf24mesh.