nRF24L01+ Communication Failure: Root Cause and “Solution”



  • Project Background

    First, some background information on the project. We had prototyped an arduino and nRF24L01+ based sensor board using mysensors and home assistant. The main goal of this board was whole home temperature, humidity, and light level monitoring. The prototype was built from stand alone protoboards, breadboards, wires, etc. It worked great, so we decided to make a custom PCB that would have a socket for the arduino pro mini, a socket for the nRF24L01+ boards, and all of the other circuitry (sensors, power supply, etc).

    Image 1: Sensor Board! (Resistor for scale)
    0_1559701732624_DSC_4767.jpg

    Problem

    After building up a number of the “New and Improved!” custom PCBs, we noticed that some of them just didn’t work very well. We could read the data from all the sensors via the arduino, but they would fail in one of a few ways:

    • Not present with the gateway / Nothing seemingly happens.
    • Present but have terrible “message loss”. The original behavior was intermittent updates from the sensors board. To determine our “message loss” we created a debug program that would send a finite number of messages from the sensor board with an ack request and wait for the ack with a time out. The final “message loss” was (number of messages sent ) - (number of messages ack’d).

    Initial observations and debugging (in no particular order of desperation).

    • More bulk capacitance on the nRF24L01+ board. No luck. (BUT THE FORUMS PROMISED)
    • Changing power source (Batteries, Benchtop, etc) didn’t change behavior.
    • Changing the nRF24L01+ on our gateway (Raspberry Pi) didn’t change behavior.
    • A “problem” sensor board got “better” when we swapped out the nRF24L01+ board. (AHA! It must be the questionably authentic nRF24L01+ boards we ordered). So, we built a sensor board with a header socket so we could quickly screen/test all of our nRF24L01+ boards. This was ineffective and led to confusion (Wait, I thought you said this nRF24L01+ board worked?) as some nRF24L01+ boards worked in the screening unit, but then didn’t work in their final sensor board.
    • Changing distance between sensor boards and gateway didn’t change anything in a meaningful or coherent way.
    • Accidentally holding our thumb on the antenna changed the behavior. (Hey, wait, what just happened? It’s working! Wait.. no it isn't’.. What?)
    • Changing the data (symbol) rate of the nRF24L01+ board changed the behavior, but didn’t fix anything.
    • Changing the SPI speed also changed the behavior, but didn’t fix anything.
    • Changing the channel on the nRF24L01+ board helped at one person’s house but not other project member’s houses.
    • Manipulate ground planes on sensor board near antenna. (dremeled away).
    • Using the previously mentioned sensor board with a header socket, we observed that almost any nRF24L01+ board worked when cabled (~6 inches) rather than directly plugging into the sensor board. (BUT WHY?????)

    {A year, a kid, and job changes later}

    Eventually, we decided the project had languished long enough. Enough sleep had been lost! We were going to figure out this problem!

    How

    Throwing stuff at the wall to see what stuck wasn't working, so we decided we needed to get serious and capture the wireless data. We borrowed a software defined radio (SDR) to capture the 2.4GHz spectrum with the intent of first demodulating the signal to see if that showed the smoking gun (It did but we didn't realize it at the time).

    Image 2: Demodulated Signal (Hey, that looks like a digital signal!)
    0_1559701980778_Carrier Startup.bmp

    Now that we can see the data to train on, we can decode the nRF24L01+ packet to see what’s going on. Specifically, the goal was to see if a packet was “good” or “bad” and our criteria for a “Good” packet was the Cyclic Redundancy Check (CRC) passing. (See image below).

    Image 3: Decoded NRF24L01+ Packet with CRC Check.
    0_1559702168258_nRF24L01_Packets.png

    Full of excitement and curiosity, we wielded our newfound RF power to decode the MySensors Payload as well (see Image 4 below) This didn’t prove to be very helpful for debug purposes, but it was interesting.

    Image 4: Decoded Mysensors Payload
    0_1559702307036_MySensors_Message.png

    Now that we can see “passing” and “failing” packets, we know we are on the right track. However, we need to measure the transmission “quality” beyond just pass/fail. Since the transmission is just binary data (using Frequency Modulation) we can parse the data to assemble the data Eye pattern (Image 5 below).

    Image 5: Impressively “Bad” data Eye pattern
    0_1559702381443_Original EYE.bmp

    I think I found the problem… But what is causing the Eye to close (good data Eye patterns are wide open in the middle)? Also, sometimes I get really good looking data Eyes! What is going on?!? Let’s have a closer look at a bad transmission. Images 6 and 7, shown below, are single transmissions taken from the multiple transmissions, previously shown in image 2.

    Image 6: A closer look at a single “bad” demodulated transmission (Wow, that’s bad!)
    0_1559702428757_Bad Continuous Transmission.bmp

    Image 7: A closer look at a single “good” demodulated transmission (That looks perfect! How is this the same board?)
    0_1559702454385_Good Continuous Transmission.bmp

    Comparing Images 6 and 7 is very interesting, we might be looking at the root cause here. The bad transmission looks like it has an “other” digital signal riding on top of it. What is going on during the nRF24L01+ transmission?

    We decided to grab a bus analyzer and record communication on the SPI bus during a transmission (see Image 8 below).

    Image 8: A Bus Analyzer capture during transmission (Wait a minute! That looks familiar!)
    0_1559702513350_DataBusCapture.jpg

    It seems strange that the SPI bus is constantly active during transmission. What is MySensors doing? Grab the shovel...

    Digging into the RF24.cpp file shows the RF24_getStatus() function called continuously at line 326. This pumps the SPI interface (sends 0xFF) to read the status register of the nRF24L01+ and see if the transmission is complete.

    A snippet of code from Github (“MySensors\hal\transport\driver\RF24.cpp”) shown below starting at line number 321

    Code Snippet 1

    // go, TX starts after ~10us, CE high also enables PA+LNA on supported HW
    	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:TXM:MAX_RT\n"));	// max retries, no ACK
    		RF24_flushTX();
    

    We have found our smoking gun!

    “Solution”

    But wait! Don’t we need to check the transmission status? The answer is: kind of, but not like this. Ideally, the nRF24L01+ signals the gateway/sensor when transmission is finished and transmit success/failure can be determined by checking the transmission status. (Alternatively, you could just place a time delay after TX Enable that waits the max duration of your transmission and retries. However this is application dependent, and may not fully resolve the issue if you have many retries).

    A way that this could be achieved is through the use of the handy IRQ (Interrupt Request) line on the nRF240L01+. MySensors can make use of the IRQ line, however it does so in a different way than we want. MySensors uses the IRQ to signal the message handler to pull received messages from the nRF24L01+ internal FIFO to prevent overflow. This can be important for high traffic networks but sadly doesn’t help our situation.

    We decided to look at the datasheet (Image 9 below) for the nRF24L01+ for potential solutions and found a workaround.

    Image 9: Snippet from nRF24L01+ datasheet describing what the IRQ line can be attached to
    0_1559703016382_nRF24L01_Datasheet.png

    Great! TX_DS (TX Data Sent) and MAX_RT (Max TX retries reached) are the two flags we want to monitor to remedy our issue. It so happens, the IRQ line is setup to respond to these flags by default already! However, MySensors does not listen to the IRQ line during transmission (as shown in Code Snippet 1). So, let’s fix that!

    Below you can see the code with our “fix”.

    Code Snippet 2

    // go, TX starts after ~10us, CE high also enables PA+LNA on supported HW
    	RF24_ce(HIGH);
    	// timeout counter to detect HW issues
    	uint16_t timeout = 0xFFFF;
    	do {
    		//RF24_status = RF24_getStatus();
    		RF24_status = hwDigitalRead(MY_RF24_IRQ_PIN);
    	} while  (RF24_status && timeout--);
    	//}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_status = RF24_getStatus();
    	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:TXM:MAX_RT\n"));	// max retries, no ACK
    		RF24_flushTX();
    

    With the fix shown above, we recaptured transmissions from the same hardware shown in Image 5. Look how nice that data Eye pattern is! (as shown in Image 10 below).

    Image 10: Data Eye pattern with transmission IRQ fix
    0_1559703369150_Improved EYE.bmp

    WOW! That is an unbelievable improvement! Thankfully, all those “bad” or “questionable” sensor boards now work like a charm! They all successfully complete presentation and have very low message loss. Sadly, our custom PCB did not pin out the IRQ line so we had to solder a wire from IRQ to an unused pin.

    Image 11: Workaround wire
    0_1559703466787_Sensor_Rework.png

    Also, out of the 20ish nRF24L01+ boards all but one are the “clones” with the Shockburst bit inversion. So, this problem may not be as pronounced on genuine or “better clones”. However, it is generally good practice to quiet or mute unnecessary digital communication during transmit/receive if possible.

    HALP

    We are hardware folk by trade and things like ‘GitHub’ or “software best practices” are not our forte. (For Example, using a bus analyzer to sniff the SPI lines was much easier than digging into the code stack). If somebody was so willing, submitting this fix (or hopefully a better one!) would be great.


  • Mod

    @odritter interesting analysis and fantastic writeup. I'll have to learn more about looking at data Eyes, seems like a very useful tool.

    The placement of the nrf's antenna on the board is very unusual. Most boards have the antenna away from surrounding conductive material (see https://www.openhardware.io/view/4/EasyNewbie-PCB-for-MySensors for example)

    How are the SPI lines placed on the board? Do they pass close to the antenna? or close to any other line that is not driven, which passes close to the antenna?



  • this is great info, this could potentially help a lot of people on this forum



  • @odritter - Superb write up and sleuthing! - Thanks for sharing the results and findings.

    Do you believe that the interference is caused internally in the nrf24 chip due to spi activity during tx mode, or possibly power rail 'ringing' due to the spi being used at the same time as Tx is happening? - I would guess the former, but at such low voltage and currents strange things can happen.... 😉



  • @mfalkvidd Hello! I am one of the other "we" mentioned in this post. I don't have access to the layout files at this moment, but I checked the Gerber files and none of the SPI lines are routed under (or near) the antenna. They are also not routed near any other lines that route under the antenna.

    "The placement of the nrf's antenna on the board is very unusual." Bad

    Yeah..... In our original goal/planning for this sensor board, we were going for a tight footprint that would sit inside a 3D printed enclosure easily and didn't think about the antenna being parallel to the PCB underneath it. Once we started having issues, we used a dremel to remove all the copper we could from the board below the antenna, but that didn't change the behavior we saw.

    Technically, we did that dremel experiment on a different board (we made two different designs) that was showing the same issue. Below, you can see an image of that experiment.

    0_1559746475298_IMG_20170306_192556064.jpg



  • @skywatch I don't know for sure where the interference is happening. I do know it isn't due to power supply bounce (at least on a board level) as I placed a variety of low ESR ceramics caps directly on the nRF board pins with zero change.

    My guess is the interference is primarily internal to the chip but I believe there is also a board level interaction somewhere (based on observed changes during experimentation). I did experiment slowing down the SPI lines coming from the Arduino board (series resistor with shunt cap at the Arduino pin) and it seemed to help a little bit but nowhere near the improvement with complete SPI muting. I would have done the same thing on the nRF board itself for MISO but the line pitch on that board is beyond my patience (and shaky hands). If SPI muting isn't a viable option for you for some reason, more experimentation might be needed to determine exactly where the problem is occurring.



  • @odritter Thanks - I have already put your changes into my RF24.cpp and will try it out later on.


  • Mod

    @odritter What puzzles me is that the interference in image 6 apparently isn't always present (see image 7), although the behavior of the MySensors stack is always identical (see image 8 and the matching code snippet 1).
    Do you see a pattern when it is present and when not?

    Also, switching to using the nRF24 interrupt line will break MySensors for a lot of (existing) boards, that don't have the IRQ line connected.
    So, if we decide to add a silent period to the stack, we also need a non-IRQ implementation based on e.g. a delay.


  • Mod

    Yes breaking the sketches for 90% or more of MySensors users (since non-irq is the default setup) would be very bad. But we should be able to use irq in case the user has defined MY_RF24_IRQ_PIN (just like we already do for RX).


  • Admin

    Here is a modified RF24 stack with (among other little changes) a waiting period and no IRQ line (as @Yveaux suggested) for testing: https://github.com/tekka007/MySensors/tree/OptimizedRF24polling

    @odritter

    Using the previously mentioned sensor board with a header socket, we observed that almost any nRF24L01+ board worked when cabled (~6 inches) rather than directly plugging into the sensor board. (BUT WHY?????)

    Is this setup referring to image 7?



  • Great info, and very well written!!! Thanks for sharing.



  • @Yveaux To be clear, I realize my code snippet "fix" would break anyone who doesn't already have the IRQ hooked up. This is where we are asking for a contributor more experienced with generalizing to the MySensors library and looking for #defines or such to play nice.

    As for what is different between image 6 and image 7 I admit our description in that section gets a little hand wavy for brevity. Image 7 is an auto-ACK from the nRF24L01+ ShockBurst where Image 6 is an outgoing message. You can see evidence of this in image 3 where outgoing messages (like image 6) have a payload (containing MySensors info) and auto-ACKs have no payload (shown as a grey'd out array).

    Once I saw that the hardware transmission can be pristine it started me thinking what was so different between a normal message and an auto-ACK. SPI communication.

    A word of caution reading too much into early debug steps mentioned (just before image 2). We decided to include these to give background information on what kinds of troubleshooting steps we tried. Some were tried out of sleep deprived desperation and what appeared to "fix" the problem at the time may have only modified the conditions that didn't work. We were not into "rigorous testing mode" at this point in time. We were blindly stabbing in the dark hoping something would work. Additionally, these early debug steps were done without any knowledge of other spectral content in the environment. Once we started using the SDR we observed the spectrum first and moved the nRF channel in a clear and free band to ensure our measurements were only of the nRF boards.



  • @tekka I peaked at the delay you added to the RF24.cpp file. It looks like your calculation is not considering auto-ACK unless I am missing something. I have given some thought to what I think needs to be considered to completely avoid all possible transmissions. See below

    optimal delay with ShockBurst = TX state transition delay + (nRF packet length * DataRate + auto-ACK timeout) * (ACKretries + 1)
    optimal delay without SB = TX state transition delay + nRF packet length * DataRate

    The problem I ran into doing a static delay is that the delay time can get quite large if considering ACK retires making the system very slow. Reducing the amount of polling should help interference even if all SPI communication isn't avoided during every possible transmission. I would definitely prefer the IRQ line used if defined and if not then use a delay (either with or without retires in mind).


  • Mod

    @odritter said in nRF24L01+ Communication Failure: Root Cause and “Solution”:

    it started me thinking what was so different between a normal message and an auto-ACK. SPI communication.

    And the all important fact that the ack message on air comes from the receiving node, instead of the sending one.
    My gut feeling tells me you are masking a hardware (design) flaw with software. If it helps in your case, good for you, but I'd like to understand it completely before absorbing it in the stack.



  • @tekka I have been testing this (2.3.2b) on a node for the last 9.5 hours and so far no problems.

    I will probably flash the GW with this today and see how that goes, not expecting any issues though! 😉

    One question though..... Does this 'fix' also apply to when the nrf is in Rx mode as well? If there is no spi activity during Rx then I guess it's a moot point. But I'd be interested in the answer.



  • This post is deleted!


  • @yveaux I agree this fix may be covering up a problem in our design. As @mfalkvidd mentioned in his post we did put the antenna in an unusual location (not ideal). So it is entirely possible our problems are caused by the antenna placement, nRF clones, or something else entirely. However, we believe we are not alone in the issues we encountered or any design flaw we made.

    That being said, constantly polling during TX transmission should be avoided as it is unnecessary. MySensors can calculate how long a transmission should take and hold off for a least the first (or all possible) transmission(s). Implementing a delay should be minimal risk and can only benefit. Implementing the IRQ is more involved to implement properly and higher risk (though I think worth it).



  • @skywatch This fix only applies to the TX for three reasons.

    1. Our method for measuring transmission quality can only observe TX (not RX) so we would need a different way to assess RX
    2. TX timing is well known from start to finish so muting the communication while it is happening is relatively straightforward. RX is a different story
    3. MySensors already implements IRQ for RX and likely already gains whatever benefit there is to be had limiting communication during RX (though I didn't look into this extensively to confirm)

    I am open to ideas on how to assess the RX side if anyone has any suggestions. However for us, implementing the IRQ fix for TX made our boards go from barely working to working like a champ!



  • @odritter Thanks for the clarification! - I learn something new (again)... 🙂

    My question was based on the fact that if enough energy is present in the spi signal to imprint on the Tx output, then it would be even worse for the Rx side as the levels of signal received would be much lower than anything transmitted.


  • Mod

    @odritter said in nRF24L01+ Communication Failure: Root Cause and “Solution”:

    constantly polling during TX transmission should be avoided as it is unnecessary

    There is no mention in the nRF24L01+ datasheet of (potential) issues caused by SPI transfers during TX, so where is your statement based on?



  • @yveaux I would be happy to provide our schematic and layout details if you think it would be helpful in identifying the hardware design flaw we made. If there is something we could do to fix this with a board change, that would be interesting to know/consider. (Especially if it ends up being mistake that is commonly made by others using who are also using the nRF24 Board).

    Alternatively, it could be an issue with our specific nRF24L01+ boards. While we did order some from Amazon and some from AliExpress, out best guess is that they are all counterfeit/clones. If you know of a source where we could order a board that in confidently authentic, that would be an interesting experiment as well.


  • Mod

    @ben036 I would certainly like to have a look at your design files.

    You could give Ebyte modules a try : https://forum.mysensors.org/topic/9668/cdebyte-s-new-nrf24-modules-are-great-and-cheap
    I have very good experience with these, and are probably using authentic nrf24's



  • @yveaux

    I've uploaded our Eagle PCB files as well as a few PDFs/PNGs of the schematic/layout for quick viewing.

    > > > Files Here < < <

    Thanks for the tip on the other nRF24 board to try.



  • @yveaux My statement is based on the assumption that everything can interfere with your desired signal. It's just a matter of how much. It's very possible that genuine nRF boards are less susceptible to the interference we have shown. However, all the nRF boards we have are suspected clones so I do not have a way to direct compare clone vs genuine (unless we purchase from the Ebyte link you provided).

    I have provided a link below to a public application note I came across that provides some background information on sources of interference and how it impacts your desired signal/receiver. Unfortunately it gets very technical at times and assumes a large amount of base RF knowledge so its usefulness may be limited. Nonetheless, I thought I would share if anyone was interested.

    Testing and Troubleshooting Digital RF Communications Receiver Designs

    The nRF uses a sampled IF receiver as described in section 1.2.2 and similar
    to what is shown in figure 4. Section 3.2.2 covers some interfering signals but mostly talks about more complex modulation schemes than the nRF uses.

    I went back and did an additional experiment using only our Gateway and the Software Defined Radio (SDR) to measure interference on something other than our sensor PCB.

    My setup:
    Gateway=RaspberryPi 3 with cabled nRF24L01+ hanging out in free space
    SDR=USRP B210 with 2.4GHz Vertical antenna
    Gateway and SDR placed about 2 feet apart in the middle of a room

    Gateway transmitted 16 packets for both graphs. The only difference between the two graphs: upper graph constantly polls TX status where the lower graph uses the IRQ line to wait for completion. The physical hardware setup was unchanged between the two measurements.

    TX Status Polling
    0_1559888632431_Raspi_noIRQ.png

    IRQ Wait
    0_1559888676328_Raspi_wIRQ.png

    These data Eye patterns were taken with a single nRF board (in contrast, the Eye patterns included in the original post are a composite of 10 different nRF boards)



  • @skywatch said in nRF24L01+ Communication Failure: Root Cause and “Solution”:

    @odritter Thanks for the clarification! - I learn something new (again)... 🙂

    My question was based on the fact that if enough energy is present in the spi signal to imprint on the Tx output, then it would be even worse for the Rx side as the levels of signal received would be much lower than anything transmitted.

    It certainly is possible the Rx side could be even worse. However, it strongly depends on where the interference is coming in. For instance, if the interference happened before the Low Noise Amplifier (LNA) then it would very likely be just as bad or even worse. However, if the interference happened after the LNA it may not have anywhere near as much impact since the signal should be much larger. Though, if the interference impacted the digitization (not really shown in the block diagram explicitly) then it would likely have a significant impact.

    Thinking about the TX side of things, the interference is very likely occurring before the modulator (to the left of the PA) since I can "see" the SPI interference with the SDR after it has been demodulated. I have included the nRF block diagram from the datasheet below for reference.

    0_1559890399466_nRF Block Diagram.png


  • Plugin Developer

    @yveaux said in nRF24L01+ Communication Failure: Root Cause and “Solution”:

    @odritter What puzzles me is that the interference in image 6 apparently isn't always present (see image 7), although the behavior of the MySensors stack is always identical (see image 8 and the matching code snippet 1).
    Do you see a pattern when it is present and when not?

    Also, switching to using the nRF24 interrupt line will break MySensors for a lot of (existing) boards, that don't have the IRQ line connected.
    So, if we decide to add a silent period to the stack, we also need a non-IRQ implementation based on e.g. a delay.

    Indeed, the RF Nano has no connected IRQ pins (and uses the NRF24 non-plus version..).

    Although it may be unrelated, it's fascinating that this is another instance of MySensors being 'too fast', and 'needing a delay' to work better.


  • Mod

    @alowhum said in nRF24L01+ Communication Failure: Root Cause and “Solution”:

    MySensors being 'too fast', and 'needing a delay' to work better.

    Let's not jump to conclusions too fast!

    So far there's only measurement data of one case where reducing SPI traffic during TX appears to reduce noise; this makes it very likely that the issue is hardware related (SPI lines run directly below the nRF24 board, the nRF24 board is placed next to the Pro Mini SPI lines (pins 10-13) and nRF24 modules are of questionable origin).
    The fact that increasing the distance between nRF24 and board by jumper wire improves the transmission success rate is a clear indication this issue is hardware related.

    Still, reducing potential disturbances during transmission and reception is important, especially if all MySensors users can potentially benefit from it with no or minimal penalty.

    The MySensors stack however needs to support different hardware variations, with and without IRQ line connected.
    The TX case with IRQ connected is trivial to solve, when IRQ is not connected is less trivial IMHO.
    When using nRF24 with hardware ACK the actual TX time is not known upfront due to potential retries; we can only calculate a lower and upper bound.
    Always silencing SPI communication for the upper time bound makes the node slow, shorter wait times require polling the nRF24 over SPI, thus introducing potential disturbance. The patch by @tekka reduces the polling rate and limits the upper bound (the number of hardware ACK retries), still it delays the TX time compared to the latest 2.3 release implementation.
    Another solution could be limiting the SPI clock rate during the TX polling time, which also potentially improves RX polling.

    As always, there is no one size fits all solution 😉

    @odritter MySensors Core team has a number of SDRs and genuine nRF24's at their disposal. Do you have a description how to derive the eye pattern so others can replicate your setup?


  • Plugin Developer

    @Yveaux Point taken.

    I also agree that it should still work on non-IRQ scenario's, as that's pretty much my scenario now that I switched to the RF Nano.

    Out of curiosity: what would be 'slow' in this scenario? Are we talking milliseconds? Hundreds?

    And could this issue be related in any way?


  • Mod

    @alowhum said in nRF24L01+ Communication Failure: Root Cause and “Solution”:

    Out of curiosity: what would be 'slow' in this scenario? Are we talking milliseconds? Hundreds?

    As always; it depends on a number of things, e.g. radio bitrate, maximum number of retries, message length. I would have to do some calculations to get an indication.

    And could this issue be related in any way?

    No. I suspect #941 and #1134 are related.


  • Hardware Contributor

    @alowhum
    for older nodes, it would need retrocompatibility, but imho, when you get started in MySensors, it's bad hardware choice to not connect the radio irq signal. It's also mentioned in MySensors doc it's better to use it.

    Why someone wouldn't like better communication for his HA??
    to be precise why someone in 2019 would like to use nrf24+low 328p ? 👹 😄

    With irq events instead of always-polling, you get queue management for messages. And also smoother processing, better states sync, more reactive just in time, not delayed or at the wrong moment, using resources only when needed.

    So,to start out on the right foot , I would strongly advice people/newcomers to connect irq when possible, and for new nodes (it's mandatory for rfm69).



  • @yveaux I can certainly provide details for others to replicate. For completeness I am including details beyond just Eye diagram creation. See below

    My setup:

    • nRF24L01+ (clone)
      ** #define MY_RF24_PA_LEVEL RF24_PA_HIGH
      ** #define MY_RF24_DATARATE RF24_250KBPS
      ** #define MY_RF24_CHANNEL 30
      ** #define MY_RF24_IRQ_PIN 4
    • SDR: USRP B210 with 2.4GHz vertical antenna
      ** 5MHz bandwidth centered at 2.43GHz (for channel 30)
      ** Eye diagrams require oversampling to build a meaningful eye. I would recommend a minimum 10x oversampling if possible (5MHz BW at 250KBPS yields 20x)
    • Processing:
      ** Capture waveform with desired transmission (my setup can't trigger on anything specific, so I looked at signal power to trim down the record)
      ** Detect and remove carrier frequency offset - I used "0xAAA8" as a sync word
      ** Perform FM demodulation normalizing to expected frequency shift (±160kHz at 250KBPS)
      ** Find the center of the eye - this is done by looking for the location with the highest correlation to the sync word (or can be manually found)
      ** To build the Eye diagram, "chop" up the waveform at the crossing points which are located at ±(0.5*OversampleRate) samples from Eye center (±10 samples in my case)
      ** Overlay resulting waveforms on top of one another to form the Eye diagram

    See image below for demonstration. Dashed red lines are where the waveform should be chopped:
    0_1560009090106_DataTrainChopping.png

    I used LabVIEW with the Modulation Toolkit to perform my measurements. I can provide my code if helps though I suspect you probably use GNU Radio. I can provide additional details if something isn't clear or I left something out.

    What metric do you currently use to measure link quality?


  • Mod

    @odritter said in nRF24L01+ Communication Failure: Root Cause and “Solution”:

    I suspect you probably use GNU Radio.

    That's correct. To be frank, I was hoping for a simple gnu radio script that I could just run to get the pattern out. There is manual work and LabVIEW involved (which I do not have access to) so it would take some experimentation to get the same results.

    Thanks for your description though!

    At the moment I don't have a way to measure signal quality accurately for nrf24. Of course there's the transmission retry counter, but I found that in general it either requires a few retries at most or goes up to the maximum and fails.


  • Plugin Developer

    @scalz said in nRF24L01+ Communication Failure: Root Cause and “Solution”:

    Why someone wouldn't like better communication for his HA??
    to be precise why someone in 2019 would like to use nrf24+low 328p ?

    While I get your point, in my case there were a number of reasons:

    • A Chinese Nano is 2 euro. A good radio is 3 euros. An expansion board that connects them is 1,50 euro. That's a total of 6,50 for the 'starting point' of all my nodes. And then it uses a old fashioned mini USB connector. If I upgrade to a Nano with micro-USB connector costs increase at least a euro or the RobotDyn version.
    • An RF Nano is 3,5 euros, and a basic Nano Expansion Board is 1 euro. That's a total of 4 euros.

    That's almost half the price. And if you use a lot of them in workshops, it adds up.

    But wait, there's more.

    • The RF Nano + board forms a smaller package so it can fit in a smaller housing. It's all-in-one nature means it's less complicated (I give workshops)
    • It's less fragile (eByte modules are thin and stick out).
    • The RF Nano has a micro USB connector which everybody already has cables for. And the cables are ubiquitous and cheap.

    I understand the RF Nano version has less range (doesn't support 250KBPS), doesn't have its IRQ pin connected and is 'fake'. But... it works just fine.

    In case you were asking "why not use NRF52/4": it's not beginner friendly.
    In case you were asking "why not RFM69": there is no cheap beginner friendly version (preferably one where you can just connect Dupont wires too, with lots of 5V and GND pins).


  • Plugin Developer


  • Mod

    @odritter I rebuilt my SDR/GnuRadio setup and did a few initial measurements:

    0_1560162061720_9e054479-326f-4ac4-a952-bea7952e6e1e-image.png

    Although the on-air data is clearly visible, the samplerate (2.4MHz) to create a usable eye pattern is just too low I'm afraid.
    My setup is a cheap RTL2832U RTL-SDR dongle, with BT-281 downconverter, as described here: http://blog.cyberexplorer.me/2014/01/sniffing-and-decoding-nrf24l01-and.html , no match for your USRP B210 ☹



  • @scalz

    That would mean IRQ on pin 2 (pro-mini or nano)?
    Could be a wire-bridge for a lot of my boards I think... 🤔


  • Mod

    @boozz said in nRF24L01+ Communication Failure: Root Cause and “Solution”:

    That would mean IRQ on pin 2 (pro-mini or nano)?

    2 or 3, and it should work for other interrupt pins too (yet untested).



  • @yveaux

    Ok, great! I presume it requires me to set this pin somewhere in the #define section? Could you hint me what variable is used for that in the config section? I guess the MY_RFM69_IRQ_PIN is not the proper one.

    About the other interrupt pins: That's an interesting one. I only know of pin 2 and 3 being the interrupt pins on a pro-mini / nano. Is it possible to use other pins for that? If so, how to achieve that?


  • Mod



  • @mfalkvidd
    Thanks!
    I guessed something like that, but couldn't find it in the API section


 

287
Online

8.5k
Users

9.4k
Topics

98.7k
Posts