1. What Is A Py File

Memsql / bench. # you may not use this file except in compliance with the License. Contact GitHub; API; Training; Shop; Blog; About. GNU Radio is a signal processing. The files used are benchmark_tx.py and benchmark_rx.py. First, input benchmark_rx python file with proper parameters.

Code: Tweak Joao Paulo Barraca's BBB/rPi version of nrf24.py: Get from github at Check your version: last line should be line 772: ' return ((250' etc We will edit from the bottom upwards, to keep line numbering stable for editing. JPB's code is admittedly tuned for Beagle Bone Black, with probable validity for rPi. These are my tweaks that make this library sing on two rPi's here. The calculated timeout of getMaxTimeout (line 770) is (empirically) premature by about 30%. Add multiplier '. 2' at end if line 772, to double the timeout.

Crude but adequate. This timeout ought never be hit if the nrf24 chip is functioning, but all software should guard against sticking in a loop! But premature timeouts as here seem to get the chip very confused. Delete lines 496 - 501 (the else: irq section). (I have removed all IRQ function for this version, as rPi would need a rethink anyway.) 3.

Remove third and fourth parameters (IRQ) 4. Add a missing line after line 466. 465 if what'rxready': 466 self.ackpayloadlength = self.getDynamicPayloadSize 467 self.ackpayloadavailable = True # needed for ack-payload 5. Add two lines after line 462: 460 what = self.whatHappened 461 462 result = what'txok' 463 if what'txfail': 464 self.flushtx; # dont fill up the tx fifo 465 # Handle the ack packet Retry count-out ('tx-fail') in ACK mode does not clear the tx buffer. We need to dump it.

Remove line 373 (irqpin) and line 370 (irqpin). In line 365 remove last parameter (irqpin) in begin.

Function printobservetx at line 299+ yields wrong value for PLOSCNT. Looking at the code, I'm not sure why, but the result is wrong. Simple pragmatic solution - put in a replacement that works: Delete lines 300-305, and replace with one line: 299 def printobservetx(self, value): 300 print 'Observe Tx:%02x Lost Pkts:%d Retries:%d'% (value, value NRF24.PLOSCNT, value & 15) 8. Delete lines 195-205 (irqWait) 9. Delete line 176 (irqpin) Alter line 175 (BBB type pin number) to 175 self.cepin = 17 10. Delete lines 17-24 (BBB configuration) Replace with these lines: 18 import RPi.GPIO as GPIO 19 GPIO.setmode(GPIO.BCM) 20 GPIO.setwarnings(False) I used BCM pin 17 as the 'CE' for RF24 module, and rPi's ce0 for RF24's 'CSN' chip select. 3.3 volts came from rPi.

There are only 3 files, the nrf24.py library and the two send/recv scripts. The mode used is ack retry with dynamic payload size and ack payload enabled (1-32 bytes transmit payload, and 0-32 bytes ack-payload. My 2 rPis have been chattering happily all overnight, minimum RF power, 2MB/s, across my 6-foot bench, not missing a beat.

What Is A Py File

I can stop the receiver and restart, and everything recovers and resumes happily. I have a working system that can only improve from here.

Now, here is my recvakpl.py. Maryus, Your question as put is difficult to answer. It's like:. I planned to fly up and walk on the moon. I didn't succeed. Where did I go wrong? What did you try?

What setup are you wiring up? What messages do you see? Some things you could elaborate on:. On the Raspberry Pi end, did the code run, or throw errors? - If you have 'printstatus' turned on, the page of status should NOT show all 0x00 or 0xFF codes, and it should verify that the NRF24L01+ is indeed a PLUS type, and succeeded in running at 2MHz. Are you trying the same scenario as the examples I used for PI - PI?

Ie, One 'sender' causing each transaction. The receive end being 'server', auto-ACK mode with ACK-Payload mode to carry back a pre-loaded package to the sender? - How did you connect an arduino end? Recall NRF24's VCC can tolerated no higher than 3.3V, not 5V. Although the logic pins can connect to arduino 5V logic.

(The ebay $2 backplate is easy way to get correct 3.3V). Did you track down the ManiacBug equivalent code for arduino and configure it like the recvakpl.py or sendakpi.py so as to complement the function (send or receive) you are trying to run on your Pi, so the two will talk? Send.png (59.7 KiB) Viewed 26003 timesluisantunes, I am not in a position currently to get at everything of my work.

However, your error message indicates that your python code is still looking at BeagleBone Black rather than changing to Raspberry Pi. So I won't go backwards to what is happening there. I'll move forward to current version I retested a few minutes ago, and it was working.

Go to and download the ZIP. You want 3 files:. libnfr24.py example-nrf24-send-rpi.py example-nrf24-recv-rpi.py The 'lib' file is the current derivative of those patches I described in that earlier post.

The two 'example' files both call that library module. What is in front of me working right now is TWO Raspberry PIs, each connected to its NRF24 like this: 8-pin connector layout: GND-VCC CE-CSN SCK-MOSI MISO-IRQ (radio - RPi) 'CE' to RPi GPIO#17 'SCK' to SCLK 'MISO' to Miso 'VCC' to +3.3 'CSN' to RPI's 'CE0' 'MOSI' to Mosi IRQ - not used, not connected One is running 'sudo python example.nrf24-send-rpi.py' Other is running 'sudo python example.nrf24-recv-rpi.py' They should both start off looking like the DIAG.PNG image, showing that NRF24L01+ has been recognised, at 2MBPS. That proves the RPi is talking with its own radio (by SPI). The non-plus NRF will show, at 1MBPS, if things are not OK, and that is the simplest test. The SEND end (PTX in NRF24 parlance) sends 'HELO' repeatedly, in auto-ack mode, with ack-payload. The PTX initiates everything. The RECV end (PRX mode) awaits packages, displays the 'HELO' (in hex) it received.

And every alternate time prepares a payload to be bundled with the next AUTO-ACK process. So the reply is seen by the PTX a transaction delayed - it arrives with the ACK sequence of the next transfer. The PRX cannot initiate a transfer, it can only set up a return package to catch a free ride on the next ACK sequence. Both forward packet payload and return payload are variable size to 32 bytes. The example files do a transfer every second or two. I do recall some earlier testing where I sped this up to allow the PTX to send pretty much as fast as it could.

It all worked fine, but of course the RPI spent time waiting for transactions to complete, because the radio.write is a blocking call. (I had taken out the IRQ functioning ).

This mode (auto-ack, ack-payload, dynamic packet size) seems to me the most useful way to use these radios (needs the PLUS version). All negotiation re package integrity and automatic retries is handled transparently by the radios. No programmed reversal of send and receive roles is needed.

(You only have to find a good way to usefully use the ack-payload function for all your reverse traffic.) That is the configuration that both example files set up. If you have only one RPi, you can possibly share SCLK, MOSI and MISO connection, and assign the second radio to CE1 and another 'CE' pin eg GPIO#18. Alter your code to match the 2 pin changes, in the line 'radio.begin(0, 17)' (ie CE0 and #17, or CE1 and #18) - Then run two instances of python code at once. I haven't tried this. (It might have SPI concurrency issues etc) Or you might try to integrate the two radio functions into a single python script as is done in the file 'example-nrf24-pair.py' (which is written for virtual-GPIO rather than RPI GPIO).

On your own here - sorry I haven't resources just now to do it that way on RPi, although it should be a short job. Or you might use one RPi and an Arduino using equivalent sketch and 'maniacbug's arduino library from which the python library is descended. (Oh yes, 'CE' in NRF24 language has different meaning to 'CE' of RPi's SPI connection.

Be careful.) This configuration (incl 2MBPS full speed) I have earlier tested successfully down through two floors of my building - didn't miss a transaction. Let us know if you get it to work.

Brian Attachments recv.png (53.72 KiB) Viewed 26003 times. Thank you for your help! I managed to be able to initialize the programs and get some (good) feedback: So I guess the Raspberry part is working. Then I tried to make it communicate with an Arduino Uno loaded with the GettingStarted example from ManiacBug library. I got this output from Arduino: Then I tried to send from Raspberry and receive on Arduino and vice versa and neither of them work. Once again, thanks mate.

PS: On a side note - I'm using a Raspberry PI B+. I was reading the library code I say a reference saying that something is different.

Could that be the reason? So you want to work the RPI against an arduino? The Maniacbug library is a good library, but its 'examples' as provided do not match the mode auto-ack/ack-payload/dyn-payload that my RPI examples use. They are not an 'equivalent sketch'. I can see you seem to be using one of the supplied maniacbug examples, or derived from. Your arduino diagnostics shows arduino radio channel 4C instead of RPI channel 60, Dyn/Feature tuned off, 1MBPS speed instead of 2MBPS, etc.

In other words, all those configuration lines in your arduino example do not match at all the RPI config. That they won't communicate is obvious.

Whatever link you are making between two devices, you need to do all the RF24 setup the same way at both ends. The RF24 is complex. All the corresponding options need to match. Now, I'm not in a position just now to retest arduino, but I DO HAVE THE CODE that I am pretty sure is what I did use. You are being the best. Yeah, I noticed the difference of speed between the two configurations but thought that (hopefully) it wasn't enough for them not to communicate. It seems like I still have a long way till understand the RF24 library.

And indeed I was using one of the exemples of the Maniacbug library (actually I was finally able to make Arduino and Raspberry communicating with each other, but using some C code and libraries and I really need it in Python to integrate with previously done code. I can't test your code right now but tomorrow I will give it a try and then tell you the results. In case anyone is still having trouble with this, I had a few hours of not getting this to work before figuring out that where the example script shown has; radio.begin(1, 0, 'P823', 'P824') it won't work on the raspberry pi which numbers its SPI as SPI0.0 and SPI0.1, and therefore tries to find /dev/spidev1.0 which is a file that doesn't exist radio.begin(0, 0, 'P823', 'P824') works for me, well once I'd seen your comment about CE not having the same meaning on RF24 as RPi - thanks for that and the rest of your work. @BLavery Thank you for putting this together!

Definitely saved me some time. I've got your example scripts up and working on my B+ and 2B. After poking around a little I quickly found I can't transmit an integer greater than 2^8. Is there a reason why I'm being limited to sending a 8 bit data packet? How would I go about sending a larger data packet, or a value larger than what can be represented with a single byte? Should I just be limiting myself to sending 0-9 as individual integers that I then later stitch together and use a stop byte to differentiate values. Code: STATUS = 0x00 RXDR=0 TXDS=0 MAXRT=0 RXPNO=0 TXFULL=0 RXADDRP0-1 = 0x 0x RXADDRP2-5 = 0x00 0x00 0x00 0x00 TXADDR = 0x RXPWP0-6 = 0x00 0x00 0x00 0x00 0x00 0x00 ENAA = 0x00 ENRXADDR = 0x00 RFCH = 0x00 RFSETUP = 0x00 CONFIG = 0x00 DYNPD/FEATURE = 0x00 0x00 Data Rate = 1MBPS Model = nRF24L01 CRC Length = Disabled PA Power = PAMIN Received: Loaded payload reply: 1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8 Received: (No return payload) As you can see, it doesn't seem to be working correctly.

I'm not too sure where the issues lays. Can anyone suggest what is the problem? Hi, I'm overseas currently, so haven;t got access to much.

From memory, the PLUS version supports several features the the non-plus does not, including optional data frequency (eg 2MHz) and (I think) the run-time variable-length packet sizing, and attaching return data to the auto-ack reply. I do remember that the code I used did make use of these features, and was specifically set up for non-plus. Beyond that, I have no answers from here. I haven't used these little boards since then. Display posts from previous: Sort.