-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Address turns up on address list (Pi), doesn't connect from Arduino #25
Comments
It looks like the device is getting a valid address via RF24Mesh, but is resetting when you call the connect method. From the sounds of it, you are trying to run PA+LNA modules off a Pro Mini, which typically won't work well. You either need a power adapter to convert from 5v to 3.3v ( https://m.media-amazon.com/images/I/51mjJNPuXDL._AC_SX679_.jpg ) or you can maybe try calling Do you have any low powered radio modules to test with? |
LNA (the second arg) is more for filtering noise from incoming RX. I'm not sure if disabling it will actually be beneficial for power consumption. However, that second arg may have different behavior if using a clone of an nRF24L chip (as with the infamously terrible Si24R1). On the original nRF24L, the second arg controls LNA which should only be turned off ( |
Thanks. I have done more tests and this is not strictly a library problem. What I was able to determine is that at around a voltage (across the NRF pins) of 3.17, the address cannot be registered. At around 3.2v the address is registered, but connection doesn't happen, and above a stable voltage of 3.22v, the MQTT connection is possible. I think I will break out the voltage supply for the NRF from my current circuit and use a HT7333 3v3 LDO regulator to supply voltage to the NRF over the Pro Mini's internal regulator (It outputs 4v from a 4056 battery controller). The datasheet says it has a max output of 250mA and the NRF needs up to 120 mA so this should be OK I hope. Going off topic a bit, in terms of saving power - since I would like to run these off a 18650 battery and since the battery drains the power supply would drop below 3.17v, am trying to figure out a solution. Would increasing the send interval as well as powering the NRF down with help? The issue is that since everything is connected in a mesh, all of the units would have to wake up at the same time, is there a strategy I can look into for this? I've read from nRF24/RF24#243 that clone chips do not lend themselves well to the low-power function. Let me know if I should set up a new question for this. Thanks. Edit - I'm going to close this issue anyway as the problem seems to be with the chips and not the code |
No new issue required. Your problem seems to be power related (& there are soooo many power related threads here). If your radio module has a glob of goo (as seen in nRF24/RF24#243), then you bought one of the most notably bad clones (see RFM7x lib for empirical research). AliExpress is well-known for misleading customers about nRF24L01 modules' authenticity. Unfortunately, some authentic nRF24L(+) modules are manufactured cheaply by omitting a capacitor intended for the builtin antenna, so power supply problems are difficult to avoid.
Anything you can do to limit TXing would help conserve overall power consumption. However, powering down the radio essentially disconnects it from the network and doesn't allow for triggering IRQ upon RXing. Remember that messages getting forwarded (during calls to |
I don’t think you should ever see pipe124, the radio only has 6 pipes. This could suggest problems with your code, overrunning a buffer or something.On May 23, 2023, at 6:01 AM, Zhao ***@***.***> wrote:
Thanks, I think I have stabilised the power with a Li-Ion battery. Have been playing around with the code as the connection is still unstable am have identified a few debug messages I don't understand. Whenever I have connection issues, it seems that I am getting an issue either with a MAC send fail on pipe 124:
39481: NET message 5b 07 04 04 01 01 01 0a 80 01 01 0a 3e 64 06 40 00 00 10 00 28 00 00 45
12:44:47.043 -> 39489: MAC Sending to 00 via 00 on pipe 124
12:44:47.043 -> 39493: NET Pipe 0 on node 04 has address 1243e3e
12:44:47.043 -> 39522: MAC Send fail to 00 via 00 on pipe 124
12:44:47.091 -> 39526: NET Sending ⸮⸮�⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮:+⸮��⸮�+⸮⸮*⸮��⸮��⸮��⸮��⸮��⸮��%u: MAC FWD multicast frame from 0%o to level %u
12:44:47.091 ->
or an ACK fail on pipe 124:
12:56:51.871 -> 36306: MAC Network ACK fail from 00 via 00 on pipe 124
The setup address is:
12:47:13.745 -> setup_address node=04444 mask=07777 parent=0444 pipe=04
Would there be any point in trying a different pipe, and is an ACK from the server needed?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
I just tried it again using the default mqtt_basic.ino example and am getting the pipe 124 again
|
Will have to take a look at this behaviour later in that case. The debug stuff is kind of a mess.On May 23, 2023, at 10:38 AM, Zhao ***@***.***> wrote:
I don’t think you should ever see pipe124, the radio only has 6 pipes. This could suggest problems with your code, overrunning a buffer or something
I just tried it again using the default mqtt_basic.ino example and am getting the pipe 124 again
17:36:41.008 -> 7618: NET message 5b 07 01 04 01 01 01 0a 04 01 01 0a c5 64 06 40 00 00 01 00 2c 00 00 45
17:36:41.008 -> 7626: MAC Sending to 00 via 00 on pipe 124
17:36:41.008 -> 7630: NET Pipe 0 on node 04 has address 1243e3e
17:36:41.008 -> 7735: MAC Network ACK fail from 00 via 00 on pipe 124
17:36:41.152 -> 7739: NET Sending ⸮⸮�⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮�(⸮��⸮⸮'⸮⸮'⸮��⸮��⸮��⸮��⸮��⸮��%u: MAC FWD multicast frame from 0%o to level %u
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
The pipe value there is a HEX number. |
OK thanks. Just looked at the source, which I should have done earlier. It seems like the lowest hanging fruit is to increase |
Keep in mind that the network code runs slower with all the debugging prompts enabled. I found that RF24Mesh can have a slightly harder time connecting when the node (master and/or sibling) is spending time printing to stdout. |
One other thing to try might be to change the value in RF24Network_config.h:16, perhaps alternate between two or three addresses for each subsequent try?
I have some questions:
|
|
There is definitely something funny going on with the debug printing. If I add the following line I'm hoping this issue is just regarding the debug statements, or else we may have some sort of bug to figure out. Will dig into this soon. In either case, this happens whenever a node is trying unsuccessfully to renew its address. I still think there is basically an issue with the radios and their hardware configuration. RF24Mesh works very well with fully functional radios. |
Regarding the inaccurate debug output: It might be something with static memory (possibly specific to Linux not Arduino). When I re-wrote those debug statements, I can't remember if I tested them thoroughly on the RPi; I do remember using the revised debug statements with the python wrappers (before pyRF24 existed). |
I'm doing the debugging on an Arduino Nano. This is quite the issue, lots of potential code to go through lol. |
This will be 100%, if not partially, true. I've done more testing and there are a few scenarios. Not so sure about point 4. Possibly because not implemented well by myself.
Few other scenarios where the 124 error occurs there is no discernable reason. Possibly not enough current - untested. But above points point to possible hardware issues. I'm tempted to design my own PCB (of the NRF module) and get these made instead of buying from AliExpress etc. for future projects and for better QC. How do you both normally use these devices? Do you use the AliExpress ones or source from somewhere else or have your own PCB design - is there a point for the latter? |
I've found the best luck just getting radio modules from Amazon so that I can return them if I get some bad clones. All my PA+LNA modules are shielded with extra capacitors. |
Do you use Buck or LDO converters. Any model number you can share as I found a couple of days ago that 3v3 LDOs (from 4.2V / Li Ion) I bought from Amazon have a transient response when supplying power to the PA + LNA module. Do you use a bandpass filter for them (I assume these might be what the extra capacitors are for)?
Think you (think it was you anyway) said in previous posts you recommend 1uF right. I've been using these as close as possible to the board as you recommended. |
Yes, the radio data rate must match on all nodes in the network for the chosen data rate to work. I'd be surprised if you could get any connection between nodes that have different data rate settings because that's not supposed to work (with any radio hardware). I used these radios for RC robotics, but I haven't been doing much of that since college. I'm here now because I ❤️ coding, and I believe in maintaining my contributions. I really only get my radios from Amazon, but I have so many sitting around that I haven't needed to go shoping for new ones. AliExpress is too much of a gamble. TaoBao sounds just as bad based on other users' feedback, but I can't even browse that site because I can't read Chinese. |
Caps should be at least ~10uF to 100uf plus a ~100nf cap for filtering. I just used an AMS1117 on the latest RPi PCB. |
Oh, I've only used LDO regulators. Capacitors serve more than 1 purpose:
Its important to read the datasheet for the voltage regulators you employ (especially if making a custom PCB). I would not recommend buying regulators from Amazon because there are also known "fakes" out there. For voltage regulators, I would stick to more reputable/official sources like mouser.com or digikey.com (which links to the datasheet for every product that they sell). |
Thanks. Checked the AMS1117 datasheet and the standard application has pull down caps to ground on both VIN and VOUT. Was this all you used or did you add additional filters? The reason I ask is because I used the HT7333 in a similar setup (as per the datasheet) but am getting a transient response (voltage ripple) when supplying power to the NRF boards which seems to be from the current draw leading to a momentary drop. Otherwise for other cases the voltage is stable. Might be an Amazon dud like @2bndy5 said since they are supposed to be fine up to 250mA. Edit: Forgot to add that I had tested with more caps up to 80uF (several 10uF caps in parallel) that smoothed the ripple but didn't really help with the connectivity issues. I probably should math it out instead of doing it iteratively or try a 100uF cap. It was a typo earlier - I'm using 10uF (106 polymer) caps across the V and G of the NRF modules. |
Multiple capacitors with varying capacitance are a good thing. When filtering out noise, it is good to set a threshold for small spikes and another threshold for large spikes. |
Thanks. In rf24gateway.cpp there are these lines:
Can I replace Also please assume that I will change |
Please read Settings that must match. There isn't any reference to the RF24Gateway API there, but it gives you a good idea about how the radio's should be configured (on each end) to work properly. |
So I was able to replicate this debug printing issue without using RF24, Network or Mesh, just with the following code:
The second rows of printf with the millis() printing separated works fine... tried with %ul and %u, something about printing the millis() messes it up. Putting in a workaround for RF24Network. |
Workaround for printf issue identified in issue nRF24/RF24Gateway#25
That is all I used, and it works great. |
Some additional comments on how the Send/ACK fail 'pipe 124' error happens:
For 2, is there anything else I need to do as I have matched up the dataSpeed requirements (I think). From RF24Gateway_ncurses.cpp:321 on the Pi-side:
Edit; Received better antennas from Amazon a couple of hours ago - have tested these and they improve performance. The old antennas that could not connect whilst straightened (I shape) and not bent (L-shape) can now connect from the Pro Minis whilst straightened when the 6 dbi antennas are connected to the Pi. My caps and resistors are arriving from Farnell tomorrow so I will test these too. |
Have you added shielding to the module yet? This might just be the antenna overwhelming the device.
Nope, as long as you have the datarate set the same on both master and other devices, it should just work. Make sure you aren't setting a different channel or something else too. |
Yes, added. Its strange.
Is it enough to edit the cpp file or do I need to edit the .h files as well? Stupid question, but confirming: It is enough to call One other thing I've also found is that for the can't connect error, what also seems to help is stopping RF24Gateway_ncurses on the pi (ctrl+c), deleting dhcplist.txt, waiting a bit (as you've suggested, not 30s as I force an address renew now every time a connection is attempted), and that seems to resolve the situations some of the time. Tested the above further and it seems that the number of direct connections are restricted to 4. Quickly checked the config documents and found the definition In both your experiences, what is the maximum number of children that a Pi, say, can support? Shielding seems to stabilise things and help.. but only in edge cases - not a major contributor to disconnections. |
Yes call after mesh.begin and just the cpp fileOn May 26, 2023, at 8:29 AM, Zhao ***@***.***> wrote:
Have you added shielding to the module yet? This might just be the antenna overwhelming the device.
Yes, added. Its strange.
Nope, as long as you have the datarate set the same on both master and other devices, it should just work. Make sure you aren't setting a different channel or something else too.
Is it enough to edit the cpp file or do I need to edit the .h files as well? Stupid question, but confirming: It is enough to call radio.setDataRate(dataRate); after mesh.begin() right?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
* Workaround for printf issue Workaround for printf issue identified in issue nRF24/RF24Gateway#25 * Change all prints to print millis() separate * Only update Arduino printfs * More printf fun - Removed all the millis() printfs - Removed header.toString calls * Delete commented debugs Delete commented millis() debug statements
My main Pi runs 15-17 nodes with most reporting data every 3 seconds or so on average. This is about all the devices can handle comfortably with the overhead of TCP/IP + Mesh. The other one runs 10 nodes which are very reponsive. Deleting the dhcplist isn't really a solution, as stated before, if the radios are fully functional, the system works well with the numbers specified above. |
The printDetails() call happens in gateway.begin() so if you are setting the dataRate after begin, the setting changes after it is printed... You can call printDetails a second time, after your configuration is set, or set the datarate in begin(). |
Thanks. I also found out that specifically, for shielding, it is essential to make sure that the gap between the foil and the board at the antenna end is as small as possible. The smaller the gap, the better. In hindsight this makes perfect sense (leakage, fermi cages, wavelengths, etc. ) but yeah now even the small antennas that weren't working are now working when straight (I) instead of angled (L). |
Just FYI was going to dig into this millis()/printf issue, but trying to replicate the printf issue here results in things working properly, so I think something must have changed since this issue was opened.
The above code now works fine for me... |
Hi, I'm struggling to find a solution for this. This has some crossover with Issue #13. I am trying to get a couple of 1) nrf24l01 with the external antenna connected to an Arduino Pro Mini to talk to 2) another nrf24l01 connected to a Raspberry Pi 4. I've run the basic tests:
eg ping 10.1.1.24
but pinging the host (itself) works....10.1.1.1
As additional information, the nrf modules are connected to the VCC pin of the Pro Mini which ranges from 3.17 to 3.22V but settles at 3.17 (I don't have a scope atm, so this is just from a multimeter). The modules also have a 106 capacitor across the VCC and G inputs, close to the module (5mm away or so).
Some of the things I've tried to figure out what's going on is/are:
When I try running the stock RF24Network MQTT example (just changing pins and IP address), the code cuts off after 'connecting...' which is the connect() function. The following is displayed in the Serial Console:
I heavily commented the example to figure out where it breaks and I can only see "a" being printed to the console
I also enabling debug options as in #13 and got the following output, and the last message prior to the script looping is this:
I have no idea where to go from here, do you have any tips on what I can do to the MQTT working using RF24 Gateway please? Is using RF24mesh and writing a script to push any output to MQTT an option?
Edit: I've also tried setting
radio.setPALevel(RF24_PA_LOW);
aftermesh.begin();
as I wondered if it may have to do with the current requirements but there was no change.The text was updated successfully, but these errors were encountered: