RasPI: HARDWARE FAIL: Radio not responding, verify pin connections, wiring, etc.

fjuedes commented 8 years ago

First: Thank you very much for providing this library!!! I have a couple of modules with the nRF24L01+ chip, bought them in bulk at AliExpress and am planning to use them to send sensor data from Field-Sensor devices, based on Arduino to a central hub, running on a Raspberry Pie B+. On the Arduino side everything is looking good: I am using a 33uF tantalum capacitor, directly soldered to the radio-module and all is well. On the Raspberry Pie i am experiencing something weird... I wrote a little program that does nothing more than invoking the PrintDetails function:

#include <cstdlib>
#include <iostream>
#include <RF24/RF24.h>

using namespace std;

// Setup for GPIO 22 CE and CE1 CSN with SPI Speed @ 8Mhz
//RF24 radio(RPI_V2_GPIO_P1_15, RPI_V2_GPIO_P1_24, BCM2835_SPI_SPEED_8MHZ);
RF24 radio(RPI_V2_GPIO_P1_15, RPI_V2_GPIO_P1_24, BCM2835_SPI_SPEED_8MHZ);

int main(int argc, char** argv) {
  radio.begin();
  radio.printDetails();
} // END main

After powering up everything, this program prints out:

root@raspi-dev:~/rf24libs/RF24/examples_RPi/extra# ./PrintDetails
================ SPI Configuration ================
CSN Pin          = CE0 (PI Hardware Driven)
CE Pin           = Custom GPIO22
Clock Speed      = 8 Mhz
================ NRF Configuration ================
STATUS           = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1     = 0xe7e7e7e7e7 0xc2c2c2c2c2
RX_ADDR_P2-5     = 0xc3 0xc4 0xc5 0xc6
TX_ADDR          = 0xe7e7e7e7e7
RX_PW_P0-6       = 0x00 0x00 0x00 0x00 0x00 0x00
EN_AA            = 0x3f
EN_RXADDR        = 0x03
RF_CH            = 0x4c
RF_SETUP         = 0x07
CONFIG           = 0x0e
DYNPD/FEATURE    = 0x00 0x00
Data Rate        = 1MBPS
Model            = nRF24L01+
CRC Length       = 16 bits
PA Power         = PA_MAX
root@raspi-dev:~/rf24libs/RF24/examples_RPi/extra#

... Which are the correct values, according to the nRF24L01+ datasheet from Nordic. So i assume that my wiring is correct. (And i have checked it over and over again...)

If i run the rpi-hub example this happens:

root@raspi-dev:~/rf24libs/RF24/examples_RPi/extra# ./rpi-hub
================ SPI Configuration ================
CSN Pin          = CE0 (PI Hardware Driven)
CE Pin           = Custom GPIO22
Clock Speed      = 8 Mhz
================ NRF Configuration ================
STATUS           = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1     = 0xf0f0f0f0d2 0xf0f0f0f0e1
RX_ADDR_P2-5     = 0xe2 0xe3 0xf1 0xf2
TX_ADDR          = 0xf0f0f0f0d2
RX_PW_P0-6       = 0x20 0x20 0x20 0x20 0x20 0x20
EN_AA            = 0x3f
EN_RXADDR        = 0x3e
RF_CH            = 0x64
RF_SETUP         = 0x07
CONFIG           = 0x0f
DYNPD/FEATURE    = 0x3f 0x04
Data Rate        = 1MBPS
Model            = nRF24L01+
CRC Length       = 16 bits
PA Power         = PA_MAX
Output below :
Recv: size=0 payload= pipe=3RF24 HARDWARE FAIL: Radio not responding, verify pin connections, wiring, etc.
RF24 HARDWARE FAIL: Radio not responding, verify pin connections, wiring, etc.
RF24 HARDWARE FAIL: Radio not responding, verify pin connections, wiring, etc.
RF24 HARDWARE FAIL: Radio not responding, verify pin connections, wiring, etc.

I have also tried this with another B+ and an A+ model and plenty of other radio-modules, always with the same result. Tried it with the radio module on a breadboard as well as with very short wires (5cm, 2") always the same result. What am i doing wrong? I am using

root@raspi-dev:~/rf24libs/RF24/examples_RPi/extra# uname -a
Linux raspi-dev.solarsystem.space 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux
root@raspi-dev:~/rf24libs/RF24/examples_RPi/extra#

Any hints, help and ,moral support very welcome - have already ordered a WiFi shield for the Arduino, just in case i have to abandon the Raspberry Pi all together.

Thank you very much in advance for your help.

P.S. Oh wait, my RasPian was build on a Friday 13th, maybe that explains it ;-)

Oitzu commented 8 years ago

Looks like a simple wiring problem. Double check especially the CE and CSN Pins.

fmatray commented 8 years ago

Hello, I experience the same problem.

I was running some code to wrap rf24 packets to MQTT. It was ok for several month but it went wrong after an update.Perhaps a kernel update. Looks like there is some error while reading a register in "uint8_t RF24::read_register(uint8_t reg)"

Do you have any idea ?

Thanks

Oitzu commented 8 years ago

I can only recommend to post a wiring. Or to describe the wiring. So that we are speaking about the same pin numbers i recommend to use "gpio readall" and using the BCM column to name the different pin numbers.

fmatray commented 8 years ago

The wiring never changed and it use to work.

I used this configuration for several month: RF24 radio(RPI_V2_GPIO_P1_22, BCM2835_SPI_CS0, BCM2835_SPI_SPEED_4MHZ);

This is the result of radio.printDetails() ================ SPI Configuration ================ CSN Pin = CE0 (PI Hardware Driven) CE Pin = Custom GPIO25 Clock Speed = 4 Mhz ================ NRF Configuration ================ STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0 RX_ADDR_P0-1 = 0x65646f4e32 0xf0f0f0f000 RX_ADDR_P2-5 = 0xe2 0xe3 0xf1 0xf2 TX_ADDR = 0x65646f4e32 RX_PW_P0-6 = 0x20 0x08 0x20 0x20 0x20 0x20 EN_AA = 0x00 EN_RXADDR = 0x3e RF_CH = 0x4c RF_SETUP = 0x07 CONFIG = 0x0f DYNPD/FEATURE = 0x00 0x00 Data Rate = 1MBPS Model = nRF24L01+ CRC Length = 16 bits PA Power = PA_MAX size of packet = 8

With gettingstarted, I can send a ping, receive the ping on an arduino, send back but the raspberry never read the result.

Does it help ?

fmatray commented 8 years ago

pi@titan ~ $ gpio readall
 +-----+-----+---------+------+---+--B Plus--+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 |     |     |    3.3v |      |   |  1 || 2  |   |      | 5v      |     |     |
 |   2 |   8 |   SDA.1 | ALT0 | 1 |  3 || 4  |   |      | 5V      |     |     |
 |   3 |   9 |   SCL.1 | ALT0 | 1 |  5 || 6  |   |      | 0v      |     |     |
 |   4 |   7 | GPIO. 7 |   IN | 0 |  7 || 8  | 1 | ALT0 | TxD     | 15  | 14  |
 |     |     |      0v |      |   |  9 || 10 | 1 | ALT0 | RxD     | 16  | 15  |
 |  17 |   0 | GPIO. 0 |  OUT | 0 | 11 || 12 | 0 | IN   | GPIO. 1 | 1   | 18  |
 |  27 |   2 | GPIO. 2 |   IN | 0 | 13 || 14 |   |      | 0v      |     |     |
 |  22 |   3 | GPIO. 3 |  OUT | 0 | 15 || 16 | 0 | IN   | GPIO. 4 | 4   | 23  |
 |     |     |    3.3v |      |   | 17 || 18 | 1 | IN   | GPIO. 5 | 5   | 24  |
 |  10 |  12 |    MOSI | ALT0 | 0 | 19 || 20 |   |      | 0v      |     |     |
 |   9 |  13 |    MISO | ALT0 | 0 | 21 || 22 | 1 | OUT  | GPIO. 6 | 6   | 25  |
 |  11 |  14 |    SCLK | ALT0 | 0 | 23 || 24 | 1 | ALT0 | CE0     | 10  | 8   |
 |     |     |      0v |      |   | 25 || 26 | 1 | ALT0 | CE1     | 11  | 7   |
 |   0 |  30 |   SDA.0 |   IN | 1 | 27 || 28 | 1 | IN   | SCL.0   | 31  | 1   |
 |   5 |  21 | GPIO.21 |   IN | 0 | 29 || 30 |   |      | 0v      |     |     |
 |   6 |  22 | GPIO.22 |   IN | 0 | 31 || 32 | 0 | IN   | GPIO.26 | 26  | 12  |
 |  13 |  23 | GPIO.23 |   IN | 0 | 33 || 34 |   |      | 0v      |     |     |
 |  19 |  24 | GPIO.24 |   IN | 0 | 35 || 36 | 1 | OUT  | GPIO.27 | 27  | 16  |
 |  26 |  25 | GPIO.25 |   IN | 0 | 37 || 38 | 0 | IN   | GPIO.28 | 28  | 20  |
 |     |     |      0v |      |   | 39 || 40 | 0 | IN   | GPIO.29 | 29  | 21  |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+--B Plus--+---+------+---------+-----+-----+
pi@titan ~ $

fjuedes commented 8 years ago

Hi Oitzu,

Thank you very much for your helping us with this problem. I have checked the wiring over and over again, also i have verified that the radio-modules are working fine by connecting them to one of my Arduino-boards (I have them running fine with the Uno, NanoV3 and Mega2560). The wiring list is:

| Radio | BCM | Description
+-------+-----+---------------------
|     1 |  -  | GND -> GND
|     2 |  -  | VCC -> 3.3V
|     3 | 22  | CE -> GPIO22
|     4 |  8  | CSN -> CE0
|     5 | 11  | SCK -> SCLK
|     6 | 10  | MOSI -> MOSI
|     7 |  9  | MISO -> MISO
|     8 |  -  | IRQ -> NC

Frédéric might be on to something, i should have an older image-backup of the SD card, i will try this one out _without _installing the updates, let's see.

Best regards from Houston (TX), Frank/2

fmatray commented 8 years ago

Looking on google, I found some issues with SPI drivers with linux 4.1.X but impossible to find an fix :'(

Oitzu commented 8 years ago

@fmatray any links to that? Can't find.

Oitzu commented 8 years ago

@fjuedes eh... i could be wrong... but you switched CE and CSN in your numbering. CE -> CE0 CSN -> GPIO22

fjuedes commented 8 years ago

OK, its for the BBB, but there might be something for the RPI too: https://groups.google.com/forum/#!category-topic/beagleboard/software/E2VG4uAb31o I'm going back to wheezy with kernel 3.18 and try again.

fmatray commented 8 years ago

This is a very wired issue.

This a newer version for bcm2835.c and bcm2835.h but seems to have no impact (http://www.airspayce.com/mikem/bcm2835/)

I tried to debug (old school) with some printf. I guess there is something wrong with bcm2835_spi_transfernb() called by RF24::read_register(uint8_t reg). I can't figure out if it's a parameter or something different with a driver cause I have no skill about SPI.

This is my log on Raspberry and gettingstarted example. I tried with several clock speeds, only 4MHz works, like before the bad update.

` root@titan:/opt/rf24libs/RF24/examples_RPi# uname -a Linux titan 4.1.17+ #834 Mon Feb 1 15:13:47 GMT 2016 armv6l GNU/Linux

root@titan:/opt/rf24libs/RF24/examples_RPi# ./gettingstarted RF24/examples/GettingStarted/ ================ SPI Configuration ================ CSN Pin = CE0 (PI Hardware Driven) CE Pin = Custom GPIO25 Clock Speed = 4 Mhz ================ NRF Configuration ================ STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0 RX_ADDR_P0-1 = 0xa8a8e1fc00 0xf0f0f0f000 RX_ADDR_P2-5 = 0xff 0xe3 0xf1 0xf2 TX_ADDR = 0x65646f4e32 RX_PW_P0-6 = 0x20 0x08 0x20 0x20 0x20 0x20 EN_AA = 0x39 EN_RXADDR = 0x3e RF_CH = 0x4c RF_SETUP = 0x03 CONFIG = 0x0e DYNPD/FEATURE = 0x00 0x00 Data Rate = 1MBPS Model = nRF24L01+ CRC Length = 16 bits PA Power = PA_LOW

**** Role Setup *** Choose a role: Enter 0 for pong_back, 1 for ping_out (CTRL+C to exit)

1 Role: Ping Out, starting transmission

Now sending... failed. Listening. Failed, response timed out. Now sending... failed. Listening. Failed, response timed out. Now sending... failed. Listening. `

on the Arduino RF24/examples/GettingStarted *** PRESS 'T' to begin transmitting to the other node Sent response 4294918203 Sent response 4294919407 Sent response 4294920616 Sent response 4294921820 Sent response 4294923024 Sent response 4294924236 Sent response 4294925443

fjuedes commented 8 years ago

OK, folks, i went back to wheezy with kernel 3.18: Linux raspi-dev.solarsystem.space 3.18.11+ #781 PREEMPT Tue Apr 21 18:02:18 BST 2015 armv6l GNU/Linux Installed the RF-libraries with the install.sh script, compiled the extra examples and tadaaa:

root@raspi-dev:~/rf24libs/RF24/examples_RPi/extra# ./rpi-hub
================ SPI Configuration ================
CSN Pin          = CE0 (PI Hardware Driven)
CE Pin           = Custom GPIO22
Clock Speed      = 8 Mhz
================ NRF Configuration ================
STATUS           = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1     = 0xdeadbeef01 0xdeadbeef02
RX_ADDR_P2-5     = 0x03 0x04 0x05 0x06
TX_ADDR          = 0xdeadbeef01
RX_PW_P0-6       = 0x20 0x20 0x20 0x20 0x20 0x20
EN_AA            = 0x3f
EN_RXADDR        = 0x3e
RF_CH            = 0x64
RF_SETUP         = 0x07
CONFIG           = 0x0f
DYNPD/FEATURE    = 0x00 0x00
Data Rate        = 1MBPS
Model            = nRF24L01+
CRC Length       = 16 bits
PA Power         = PA_MAX
Output below :
Recv: pipe=1, size=32, payload=Arduino #1 on COM4
Recv: pipe=1, size=32, payload=Arduino #2 on COM5
^C
root@raspi-dev:~/rf24libs/RF24/examples_RPi/extra# 
`
So it does not (yet) work together with the 4.1.18 Kernel...

I will continue Wheezy for now, but who must be informed about this issue?
That's clearly nothing within the radio-libraries, that might be a bug in the SPI-module.

Best regards from Houston (TX),
     Frank/2

Oitzu commented 8 years ago

@fjuedes great finding. Thanks for your report. :) Hm... well.. it needs some more testing to find the place to fix. Could be that the bcm2835 lib needs a fix or that we need specific device tree params to get it working. I can't imagine that the spi support in the 4.1.x kernel is generally broken and nobody noticed it.

fjuedes commented 8 years ago

Hi Oitzu,

SPI is not entirely broken, remember i was able to read the registers of the radio-chip without problems. This looks to me like a timing problem, either within the SPI-bus routines/hardware itself or between the SPI-bus and the GPIO pin. Maybe access to the CE pin is slower/faster with the newer Kernel or the SPI hardware is initialized a little different. I experienced the problem with all SPI speeds. I wish i had the necessary equipment to record the I/O lines during that event...

eflukx commented 8 years ago

@Oitzu thanks for mentioning this issue. It is indeed very similar to what I have encountered (see issue #161)

I just downgraded my kernel from 4.4 (or 4.x, I don't recall exactly) to Linux version 3.18.0-trunk-rpi2 but the problem is persistent. I could do some timing measurements on the pins directly to see if something odd is happening.

I've also tried fiddling with the device tree settings (in /boot/config.txt) of GPIO and SPI. Unfortunately to no avail, the problem remained. As far as I understand the dtree devices provide a higher level abstraction to the BCM2835 peripherals. For our use we'd probably not them (or even want then interfering) when using the bare access to the BCM2835 via the memory map.

Possibly it might be a good idea (on the RasPi at least) to switch to/support the SPI device node (/dev/spix.x) to ensure better compatibility with both future hardware and kernels.

Oitzu commented 8 years ago

@eflukx maybe you can compare it to the datasheet? https://www.sparkfun.com/datasheets/Components/SMD/nRF24L01Pluss_Preliminary_Product_Specification_v1_0.pdf Section 8.3.2

eflukx commented 8 years ago

After some testing and pondering I doubt if the error really springs from a hardware failure. Especially given that the nrf24 module is actually working, it only intermittently gives these error messages. I extended the RF24 lib a little bit, so that the error message includes a line number commit.

It turns out some timeout is overrun, which I've pinpointed it to this line in the write() method.

In my case i guess it is just the other side misbehaving (which is also a WiP in itself), so the whole hardware thing seems to be chasing a ghost.

The timeout loop waits for TX_DS bit to get set in STATUS reg. As my other device is a low power device, it sends some data and after that it goes to sleep immediately. This assumption still needs some testing but if no ACK packet is send back to the host, TX_DS is never set. From the datasheet (p . 59):

_Data Sent TX FIFO interrupt. Asserted when packet transmitted on TX. If AUTOACK is activated, this bit is set high only when ACK is received.

btw For my purpose I was hosting a (RF24 C++) subprocess in a Ruby app to establish nRF24 comms. Pretty dirty and ran into this issue, so over the weekend I've reimplemented TMRh's RF24 lib in pure Ruby. I'll post it shortly on github in case you're interested.

Update: well... here it is: https://github.com/eflukx/nrf24-ruby

TMRh20 commented 8 years ago

@eflukx Cool beans. FYI also /dev/spix.x is supported on RPi but requires a slight modification to one file, and does not perform quite as well as with the BCM lib.

WillyKirsch commented 8 years ago

Hi, I'm also getting intermittent behavior, woks aleatory...

The wiring its ok.. and the NRF24 module works perfect on an Arduino.

mostly works for a while (20 seconds maybe) and then starts to send the mesage: RF24 HARDWARE FAIL: Radio not responding, verify pin connections, wiring, etc.

Pelase help!!

fjuedes commented 8 years ago

Hi Willy, welcome to the club: So far i have not been able to find out what exactly goes wrong. I am still using Raspian 3.18.11+ - if i upgrade to the current Raspian release it breaks everything. Which Version are you currently running? (Try uname -a and post the output, please).

Best regards from Houston (TX), Frank/2

WillyKirsch commented 8 years ago

Hi Frank thank you!! I'm running Jessie Linux raspberrypi 4.1.17-v7+ #838 SMP Tue Feb 9 13:15:09 GMT 2016 armv7l GNU/Lin ux

On wheeze worked very well the problem is that I deleted the wheezy image and now it's not available...

I'm a compelte Linux/Raspbian newbie...

Best Regards from Olivos/Argentina!

Oitzu commented 8 years ago

@WillyKirsch you can find all Raspbian images here: https://downloads.raspberrypi.org/raspbian/images/ raspbian-2015-05-07 is the latest with wheezy.

Oitzu commented 8 years ago

Btw.. i'm running fine on Linux raspberrypi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux

WillyKirsch commented 8 years ago

Thank You Oitzu!!

WillyKirsch commented 8 years ago

Hi, I installed the 4.1.13+ version and intalled the libraries using the installer mentioned in https://github.com/mz-fuzzy/RF24

in this way: wget http://tmrh20.github.io/RF24Installer/RPi/install.sh
Then chmod +x install.sh Then ./install.sh

Then I make the test: cd rf24libs/RF24/examples_RPi
make
sudo ./gettingstarted
And the example worked, but when I run my script I receive This:

pi@raspberrypi:~/EMA $ sudo python EMAV200.py Traceback (most recent call last): File "EMAV200.py", line 32, in from RF24 import * ImportError: No module named RF24

my raspbian version is Linux raspberrypi 4.1.13-v7+ #826 SMP PREEMPT Fri Nov 13 20:19:03 GMT 2015 armv7l GNU/Linux

Thank You!!

WillyKirsch commented 8 years ago

Anybody?

TMRh20 commented 8 years ago

Need to build for python, see docs and issues.

WillyKirsch commented 8 years ago

Thank you!

WillyKirsch commented 8 years ago

I searched again and found this guide:

http://tmrh20.github.io/RF24/Python.html

And it worked, it's a bit confusing, there are two install procedures...

I just posted to help the next rookie that lands by here..

eflukx commented 8 years ago

It seems that we have gone a bit off topic. Any news on the resolving of the original issue yet?

btw I'm not experiencing similar problems when using the Ruby library code, regardless of the kernel version. The SPI driver module doesn't seem broken in the newer kernels (at least not in my case). Then again my code doesn't check for expiring timeouts as TMRh's C++ code does...

TMRh20 commented 8 years ago

Kernel 4.1.18+ findings:

Upgrading my RPi Model B Revision 2.0 to 4.1.18+ initially broke RF24
Simply recompiling all the libraries (RF24, RF24Network, RF24Mesh, RF24Gateway) got them all working again

Theory: Something changed in the kernel, but didn't actually break SPI

Suggestion: Run sudo make install -B from each library directory to fully recompile OR remove RF24 libraries and run the installer

@fjuedes The RF24 lib supports SPIDEV and MRAA on RPi. It might be a good idea to try them just to see if the same behavior continues. I typically run all the RF24 libs on 2 separate RPi for testing with no stability problems over long periods of time. See http://tmrh20.github.io/RF24/RPi.html

fjuedes commented 8 years ago

@TRMH I am about to give up on RPi entirely, see here: https://github.com/TMRh20/RF24/issues/232

TMRh20 commented 8 years ago

Yeah, it all seems to be part of the same issue.

A couple points to ponder: a: Power supply: If using non-pa modules, just use the RPi 3.3v power supply. Issues are not only with having enough current, but also having a smooth enough supply so as not to interfere with SPI. Capacitors can help sometimes. b: It sounds like things work fine with the examples? If so, I would suggest testing with higher layers (RF24Network etc.) OR post your code. Its complete guesswork without code. c: Going back to your original post the rpi hub example is old and not supported, so I would recommend the following steps:

Stop all RF24 programs/SPI and unplug the radio from RPi (ensures full reset of all config)
Delete all RF24 library files and rerun the installer
Run through the RF24 gettingstarted and gettingstarted_call response examples along with an Arduino
Immediately compile and run one of the RF24Network helloworld examples along with your Arduino

Results: If it works OK with the examples, then I suspect code problems. Of course if not working with known working examples, you likely have some sort of hardware issue. Again, please post your code if it works fine with the examples.

Oitzu commented 8 years ago

@fjuedes to complete TMRh20's post, if you are using a PA/LNA module, have a look here: http://blog.blackoise.de/2016/02/fixing-your-cheap-nrf24l01-palna-module/

To topic; I also installed a fresh RPi just to test this, an couldn't find any problems.

izero79 commented 8 years ago

I'm having this "hardware fail" problem also, but I'm having very weird conditions for this happening. I have Arduino that sends payload 'M' every minute to rPi. rPi sends payload 'O' to Arduino to confirm that 'M' was received.

I have written the rPi code with python and when I get the code working it works 24/7 fine many days, doesn't matter if I reboot rPi etc. But when the code breaks nothing helps (like reboot, shutdown etc). The weird thing is that the code can break even by removing/adding comment line from my python code.

Also when my code is "broken" I can run the helloworld example just fine, so it is not HW fault.

Here's the code I'm currently using:

#!/usr/bin/env python
# coding: utf-8

import time
from collections import defaultdict
from struct import *
from RF24 import *
from RF24Network import *

import sys
import datetime

global alarm_level
global sleep_cycles
global alarm_profile
global send_config
global config_queue

global radio
global network

# CE Pin, CSN Pin, SPI Speed
radio = RF24(RPI_V2_GPIO_P1_15, RPI_V2_GPIO_P1_24, BCM2835_SPI_SPEED_8MHZ)

network = RF24Network(radio)

channel = 100
interval = 500

millis = lambda: int(round(time.time() * 1000))
octlit = lambda n:int(n, 8)

# Address of our node in Octal format (01, 021, etc)
this_node = octlit("00")

radio.begin()
time.sleep(0.1)
radio.setPALevel(RF24_PA_MAX)
time.sleep(0.1)
network.begin(channel, this_node)
radio.printDetails()

alarm_level = 1
sleep_cycles = 7
alarm_profile = 0
send_config = False
config_queue = defaultdict(list)
sensor_nodes = ("01", "02")

def setalarmlevel(alevel):
    global alarm_level
    global config_queue

    alarm_level = alevel

    for node in sensor_nodes:
        if 'C' not in config_queue[node]:
            config_queue[node].append('C')
            print('Added \'C\' to config_queue[' + node + ']')

def setsleepcycles(cycles):
    global sleep_cycles
    sleep_cycles = cycles

    for node in sensor_nodes:
        if 'C' not in config_queue[node]:
            config_queue[node].append('C')
            print('Added \'C\' to config_queue[' + node + ']')

def set_alarm_profile(req_alarm_profile):
    print("Set set_alarm_profile to: " + str(req_alarm_profile))
    global alarm_profile
    profile_changed = False
    if alarm_profile != req_alarm_profile:
        profile_changed = True
        alarm_profile = req_alarm_profile
        if alarm_profile == 0:
            setalarmlevel(0)
        elif alarm_profile == 1:
            setalarmlevel(1)
        elif alarm_profile == 2:
            setalarmlevel(1)
        elif alarm_profile == 3:
            setalarmlevel(2)
    if profile_changed == True:
        for node in sensor_nodes:
            if 'C' not in config_queue[node]:
                config_queue[node].append('C')
                print('Added \'C\' to config_queue[' + node + ']')

def send_configs(node):
    network.update()
    global config_queue

    if 'C' in config_queue[node]:

        print("Send alarm_level: " + str(alarm_level) + ", sleep_cycles: " + str(sleep_cycles)+ ", alarm_profile: " + str(alarm_profile) + " to: " + str(node))
        payload = pack('<BBB', alarm_level, sleep_cycles, alarm_profile)
        type = ord('C')
        print('Sending ' + chr(type) + ' to ' + str(node) + '...')
        ok = network.write(RF24NetworkHeader(octlit(node), type), payload)
        if ok:
            print('c ok.')
            config_queue[node].remove('C')
        else:
            print('c failed.')

def send_reply(node, messageno):
    global config_queue
    network.update()
    print("send_reply to " + str(node) +" , messageno: " + str(messageno))
    payload = pack('<H', messageno)
    type = ord('O')
    print('Sending ' + chr(type) + ' to ' + str(node) + '...')
    ok = network.write(RF24NetworkHeader(octlit(node), type), payload)
    if ok:
        print('o ok.')
    else:
        print('o failed.')

lastmessageno = 0

#settings = orient.read_settings()
#setalarmlevel(settings.alarm_level)
#setsleepcycles(settings.node_sleep_cycles)
#set_alarm_profile(settings.alarm_profile)

while 1:
    network.update()
    while network.available():
        network.update()
        rfheader = RF24NetworkHeader()

        network.peek(rfheader)

        if chr(rfheader.type) == 'M':
            header, payload = network.read(32)
            alarmSensortypes = []
            tempSensortypes = []
            humidities = []
            temps = []
            alarms = []

            alarmSensortypes = unpack('<BBB', bytes(payload)[0:3])
            tempSensortypes = unpack('<BBBB', bytes(payload)[3:7])
            humidities = list(unpack('<HHHH', bytes(payload)[7:15]))
            humidities = [float(i)/100 for i in humidities]
            temps = list(unpack('<hhhh', bytes(payload)[15:23]))
            temps = [float(i)/100 for i in temps]
            batterylevel = float(unpack('<H', bytes(payload)[23:25])[0])/1000
            alarmlevel = unpack('<B', bytes(payload)[25:26])[0]
            sleepcycles = unpack('<B', bytes(payload)[26:27])[0]
            alarms = unpack('<???', bytes(payload)[27:30])
            messageno = unpack('<H', bytes(payload)[30:32])[0]

            print('\n\n------------------------------------')
            print(datetime.datetime.strftime(datetime.datetime.now(), '%Y-%m-%d %H:%M:%S'))
            print('Measurements from:', oct(header.from_node))
            print('------------------------------------')
            print('Message No: ', messageno)
            print('alarmSensortypes: ', alarmSensortypes)
            print('tempSensortypes: ', tempSensortypes)
            print('humidities: ', humidities)
            print('temps: ', temps)
            print('batterylevel: ', batterylevel)
            print('alarmlevel: ', alarmlevel)
            print('sleepcycles: ', sleepcycles)
            print('alarms: ', alarms)
            print('------------------------------------\n\n')
            send_reply(str(oct(header.from_node)), messageno)
            if lastmessageno != messageno:
                send_configs(str(oct(header.from_node)))
            lastmessageno = messageno
        elif chr(rfheader.type) == 'O':
            header, payload = network.read(2)
            messageno = unpack('<H', bytes(payload)[0:2])[0]
            print('\n\n------------------------------------')
            print(datetime.datetime.strftime(datetime.datetime.now(), '%Y-%m-%d %H:%M:%S'))
            print('Reply from:', oct(header.from_node))
            print('------------------------------------')
            print('Reply to message: ', messageno)
            print('------------------------------------\n\n')
        else:
            print('receive else: ' + str(chr(rfheader.type)))
            header, payload = network.read(32)
        rfheader = None
    time.sleep(0.75)

That code currently runs fine (12 hours -> 720 send/receives at the moment) . But if I remove this block of commented out code:

#settings = orient.read_settings()
#setalarmlevel(settings.alarm_level)
#setsleepcycles(settings.node_sleep_cycles)
#set_alarm_profile(settings.alarm_profile)

the sending of reply (payload 'O') fails every time. Actually I get 'ok' for sending, but Arduino never receives it and therefore resends the 'M' payload and after 3 attempts of sending 'O' I'm getting the "hardware fail". Then I simply undo the removal of comment block and code runs again fine over night.

For me this doesn't make any sense. Does someone has any idea what could be going on here? I'm running latest RF24 and RF24Network on Raspberry Pi Zero, also tried to downgrade kernel to 3.18.

martin-mat commented 8 years ago

@izero79 how this is related to "Hardware Fail" issue? Can you see such error message during your runs?

I think your issue is already discussed here: https://github.com/TMRh20/RF24Network/issues/83 It seems that it is still valid, so I'm reopening that.

izero79 commented 8 years ago

Yes, I get the error on sending the reply when the code is in "broken state":

------------------------------------
2016-03-30 09:57:26
Measurements from: 02
------------------------------------
Message No:  1144
alarmSensortypes:  (1, 2, 0)
tempSensortypes:  (4, 0, 0, 0)
humidities:  [63.6, 0.0, 0.0, 0.0]
temps:  [21.4, 0.0, 0.0, 0.0]
batterylevel:  2.902
alarmlevel:  1
sleepcycles:  7
alarms:  (False, False, False)
------------------------------------

send_reply to 02 , messageno: 1144
Sending O to 02...
o ok.

------------------------------------
2016-03-30 09:57:28
Measurements from: 02
------------------------------------
Message No:  1144
alarmSensortypes:  (1, 2, 0)
tempSensortypes:  (4, 0, 0, 0)
humidities:  [63.6, 0.0, 0.0, 0.0]
temps:  [21.4, 0.0, 0.0, 0.0]
batterylevel:  2.902
alarmlevel:  1
sleepcycles:  7
alarms:  (False, False, False)
------------------------------------

send_reply to 02 , messageno: 1144
Sending O to 02...
RF24 HARDWARE FAIL: Radio not responding, verify pin connections, wiring, etc.
RF24 HARDWARE FAIL: Radio not responding, verify pin connections, wiring, etc.
.
.
.

As you can see Arduino didn't receive the 'O' response for 1144 and is resending the 'M' and rPi tries to respond again with 'O' and then comes the fail. Then I readd the comment block and code runs fine again.

And yes, the TMRh20/RF24Network#83 seems to be same problem, random changes that logically doesn't change the code breaks the sending of payloads.

martin-mat commented 8 years ago

reviving this topic... I wanted to give a try to analyze this issue but found out that I don't have sufficient information. I tried to follow the original post of this issue rpi-hub example - 2 things:

what is the arduino sketch counterpart that was used for rpi_hub? I cannot find it anywhere.
I can see there: Recv: size=0 payload= pipe=3 which is kind of suspicious; if payload of length 0 is received, bad things happened (fixed recently in 2f2cb2bbbb404a26e4c21bd5b0a5e8b22128df68)

So, whoever is experiencing this issue, can you please deliver following:

.cpp code for RPi (or a reference to a particular example) causing the error
respective arduino sketch that communicated with RPi (or a reference to a particular example)
RF24 lib commit sha that you used + driver (RPi, SPIDEV, MRAA, ...)
which os version/kernel version did you use

DangerTimsen commented 8 years ago

Unfortunately I've got the same issue like izero79. It happens to me on my Raspberry Pi Zero with standard helloworld_rx on Arduino and (Python) helloworld_tx.py on Rpi Zero. It sends 3 times, then goes to Hardware fail like mentioned. The Arduino never hears a thing. I would love to try to help. I downloaded RF24 and RF24Network this morning from main branch on GitHub. Kernel Version is 4.1.19+ Receiving on the RPi seems to work fine. Sending is the problem

martin-mat commented 8 years ago

@DangerTimsen it seems that @izero79 's issue was fixed in RF24Network, discussed in https://github.com/TMRh20/RF24Network/issues/83

Does the example with the same setup (RF24 constructor params) pass/communicate when you try C++ version of example? Are you getting the failures consistently on every run? What OS distro/version are you using?

fmatray commented 8 years ago

After FD crash, I reinstalled the OS and compile again everything. The problem has not appeared this time.

DangerTimsen commented 8 years ago

@mz-fuzzy I've tried the C++ Version - and it works! The helloworl_tx is sending. I am getting "sending... failed" every time, but the Arduino is receiving. With python 2.7.11 and python 3.4.4 and helloworld_tx.py the hardware fail error is persistent. This is true for Rpi Zero an Rpi 1 B. Maybe I should try a clean install like @fmatray did.

I am using raspbian. Oh, and I confirm that I've got the version with fix from TMRh20/RF24Network#83

UPDATE: Problems, problems, problems. Now this: Traceback (most recent call last): File "helloworld_tx.py", line 13, in <module> from RF24 import * File "build/bdist.linux-armv6l/egg/RF24.py", line 7, in <module> File "build/bdist.linux-armv6l/egg/RF24.py", line 6, in __bootstrap__ ImportError: /usr/local/lib/libboost_python.so.1.60.0: undefined symbol: PyUnicode_AsUTF8String

martin-mat commented 8 years ago

@DangerTimsen the undefined symbol issue looks like mess in shared libs or python2/python3 mismatch.

"sending failed" message does not look as expected behavior. Did you try to repeat with a clean install? Also, does a simple RF24 example work without a problem?

hy565 commented 8 years ago

I've recently started facing this same problem on a Raspberry Pi 2 running Ubuntu 14.04 LTS.

The library has been working without problems for about 2 months, but suddenly I began getting this error: RF24 HARDWARE FAIL: Radio not responding, verify pin connections, wiring, etc.

I'm not sure what changed, I don't believe I have updated the library.

For some reason, disconnecting the CE pin on the nRF (BCM22/P1_15 on the Pi) allows the code to work as per normal.

I've tried using a different RPi2 with the same SD card and hardware setup - same issue.

I've tried removing the libraries with "sudo make clean", deleting the files in /usr/local/lib, cloning the latest libraries from Github, compiling them again - same issue.

I've also tried replacing the nRF module with two other unused ones - same issue.

Interestingly, running the code with a freshly installed copy of Raspbian did not give me this issue...

Can anyone suggest a possible solution, or a way to troubleshoot this?

Many thanks.

martin-mat commented 8 years ago

@hy565 would you be able to dump the image of ubuntu causing the problem into a file and store it somewhere for me? I have RPi2 lying around so I would like to check and debug.

hy565 commented 8 years ago

@mz-fuzzy I've sent you an email with a download link to the image.

martin-mat commented 8 years ago

a good point is: I was able to reproduce the error. Some of my observations, mostly confirming what @hy565 saw:

it's Ubuntu 14.4 LTS with 3.18.0-25 kernel
error happens with both RPi and SPIDEV drivers
the error is consistent, happens all time
when attempting to write: several first writes pass, it seems that even ack is received. After that, HARDWARE FAIL.
when listening, nothing is received at all. Never.
I tried to install clean Ubuntu, same kernel version. No success with reproduction, it's working.

The bad point is that I did not find where the problem is. It seems to me that it must be either something in kernel (spi/gpio) or in a way how RF24 handles spi/gpio. This seems to be much deep into kernel stuff where I don't see much :-(

Anyway, if somebody wants to check this, ubuntu image for RPI2 showing the error is available.

zdiscov commented 8 years ago

I am getting the dreaded error too after transmitting for a while... and it started happening all of a sudden on the RPi 3 ver B.

I am about to give up on this library and try to see if maniac bug's original solution can be future fitted to RPi3.

================ SPI Configuration ================ CSN Pin = CE0 (PI Hardware Driven) CE Pin = Custom GPIO22 Clock Speed = 8 Mhz ================ NRF Configuration ================ STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0 RX_ADDR_P0-1 = 0x65646f4e32 0x65646f4e31 RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6 TX_ADDR = 0x65646f4e32 RX_PW_P0-6 = 0x20 0x20 0x00 0x00 0x00 0x00 EN_AA = 0x3f EN_RXADDR = 0x02 RF_CH = 0x4c RF_SETUP = 0x07 CONFIG = 0x0e DYNPD/FEATURE = 0x00 0x00 Data Rate = 1MBPS Model = nRF24L01+ CRC Length = 16 bits PA Power = PA_MAX

**** Role Setup *** Choose a role: Enter 0 for pong_back, 1 for ping_out (CTRL+C to exit)

1 Role: Ping Out, starting transmission

Now sending... RF24 HARDWARE FAIL: Radio not responding, verify pin connections, wiring, etc. RF24 HARDWARE FAIL: Radio not responding, verify pin connections, wiring, etc. RF24 HARDWARE FAIL: Radio not responding, verify pin connections, wiring, etc.

Avamander commented 8 years ago

Nothing happens "all of a sudden" you updated something and it broke or you have not restarted your rPi+nRF (wrong settings are kept by the module).

zdiscov commented 8 years ago

Didn't update...
Very easy install process... Appeared to work immediately, post install. Restarted a few times as I was moving the RPi around.. tried to fire it back up the next day but was getting this HARDWARE FAIL error message. However, I had a fully functioning RPi ver 1 and nrf24l01+ using the old maniac bug's library.. so was trying to see if this RPi ver 3 can be used on the same code base... The ease of install this library provides would surely be missing tho :(

nRF24 / RF24

RasPI: HARDWARE FAIL: Radio not responding, verify pin connections, wiring, etc. #205