ecrampton

Awesome, thanks for the reply and the example code. My only thought on this would be in any type of ISR handler you should only be doing the bare minimum. I would hope no libraries would do a SPI transaction from inside an interrupt routine.

I should have read the beginning of this topic before asking the questions as it seems at the time of writing there was not a good way to handle that in Energia. I may be wrong, but now we should be able to use suspend() with wakeup() to get the same functionality as the c library. Is there any plans to rewrite any of this to better handle the IRQ from the nrf24l01?

Spirilis, Speaking on the use of low power and interrupts, I was curious why the energia library doesn't use the interrupts and instead polls the pins. In your C library that I have used I was able to go into a low power mode and wait for the nrf24 to wake me up. In the energia it doesn't seem to allow you do to that as easily. Is there any reason for the difference in the way you wrote the Energia library vs the C library?

I read in the ENRF24 code that AutoAck is not enabled when in 250kbps mode. Is that an implementation restriction or is that a hardware restriction? I don't remember reading that in the data sheet and I have run the pure C implementation of the msprf24 library and I feel like I was able to use AutoAck at that speed. But maybe I am missing something. Thanks.

Thanks for the reply, I will take a look!

I have played around with spirillis msp430 nrf24l01 libraries and written some simple applications using them, which is great. But now I am looking to set up a node network for sensors and actuators. I would like to have something a layer above the spirillis nrf24l01 libraries that could act as a way to either mesh network or star network the nodes. Maybe I am not searching the right things, but the best thing I have found so far is something from MySensors that seems to be Arduino only. What I like about the mysensors is that it looks to handle the networking of the nodes for you. Ar

Thanks for the replies. I was able to grab a decent power supply from work and test it. Unfortunately that didn't work. The PSU is showing a spike of 170mA I wonder if this is also a power issue with the header. In any case if I can't get these working I think my plan will be to add in repeaters as necessary and just use the standard PCB trace modules and further look into the SI24R1 modules. Thanks.

I am currently trying to extend the range of my nrf24l01+ modules. My current working setup is running a raspberry pi and a msp430g2553 (launchpad) using the nrf24l01+ with only the pcb antenna. Currently those are about 10 meters away from each other and they work great (~100% success rate) at that distance. In order to extend the range I tried to change out one of those modules with the pcb antenna and tried hooking a PA LNA to my msp430, this resulted in me only getting like a 10% success rate of packets being sent and received. I then hooked up a 3.3 regulator to supply power to the

I am sure this won't help but it seems all I needed to do to get my pi and msp430 talking without any packet loss was I just unplugged the nrf24l01 from the raspberry pi 3.3V and back in and everything seems to be happy and running now. Not sure what I may have done to it, but if all else fails power cycle...

I think I see your problem, however I am now having trouble even getting data using my GPIO interrupt on Raspberry pi. I do have a version that is just like yours without GPIO. I think I may see your problem when using the MSP430 code the payload is fixed to 32 bytes, but on the raspberry pi you have dynamic payload enabled. Try this for you Setup(). void setup(void) { // // Refer to RF24.h or nRF24L01 DS for settings radio.begin(); //radio.enableDynamicPayloads(); radio.setPayloadSize(32); radio.setAutoAck(1); radio.setRetries(15,15); radio.setDataRate(RF24_1MBPS); radio.setPALe

Have you gotten this working? The first thing I noticed on the Raspberry pi side is you are opening the RX pipe on pipe 0. From what I have read Pipe 0 isn't the as reliable for receiving its better suited to be used as a TX pipe. Unfortunately I don't have the source for where I read that at, but I would try opening a different pipe. Now I have a very similar set up to yours. I do have it working, but it seems to be dropping a lot of packets on the Raspberry pi side. I tried using GPIO to attach to the IRQ thinking there was a weird timing issue with the FIFO but that didn't help.