nrf24 library

[ladyada]

there's one for micropython here from the original repo

https://github.com/micropython/micropython/blob/master/drivers/nrf24l01/nrf24l01.py

There's also a RadioHead driver here
https://github.com/adafruit/RadioHead/blob/master/RH_NRF24.cpp
https://github.com/adafruit/RadioHead/tree/master/examples/nrf24

And the most popular nrf24 library in C/C++ here
https://github.com/nRF24/RF24

[uhrheber]

The nRF5 chips have a proprietary rf mode, that allows them to communicate with older chips like the nRF24.
Would it be possible to support that in the nrf port?

From the nRF5 SDK documentation:

"Enhanced ShockBurst (ESB) for the nRF5 Series is a simple, lightweight protocol, that is on-air compatible with Nordic's nRF24Lxx devices. ESB for the nRF5 Series provides a simple upgrade path for nRF24Lxx based applications."

[deshipu]

With some luck you could even make them talk to the micro:bits, which would be very cool!

[uhrheber]

The micro:bits have a python module "radio", that implements the Nordic Gazell protocol.
This is different from the nRF24 protocol, but would maybe also a nice addition. The Gazell protocol is meant to be used in star topology, using one (always powered) hub, and up to eight (sometimes sleeping) nodes.
Ideal for building your own mice and keyboards.
I just don't know how difficult it would be to port that from Micro:Bit to circuitpython.

[tannewt]

Anyone know how separate the radio stacks are in the SoftDevice? Can we have one build that can do any of them?

[ladyada]

hmm, this issue has diverged a bit. i was referring to supporting the low cost nrf24 modules that are so popular with makers, not native nrf24l01 support in nrf52 - that seems like it would be a different project altogether :)

[uhrheber]

@ladyada: Well, my suggestion would be to write a driver for nrf24l01, that uses external modules by default, but switches to the internal rf on microcontrollers that support it.

Other drivers also use hardwired functions when available, but switch to bitbanging when not.

@tannewt: The softdevices don't support the proprietary Nordic protocols, only BLE and/or ANT. But the proprietary protocols can coexist with BLE, by using timeslots.

[tannewt]

Ok, this issue will be for a driver of external nRF24 devices.

For the internal ones we have separate issues:

• OpenThread NRF52840 Openthread Support #1162
• Gazelle NRF52840 Nordic Gazell Support #1257
• nRF24l01 NRF52840 Enhanced ShockBurst Support #1258

[ladyada]

@kattni taggin' ya!

[kattni]

nRF24L01 library has been discussed here: adafruit/Adafruit_Blinka#85

@rhthomas Let's continue any GitHub discussion here. You're still welcome to ping me on Discord as well with any questions.

[rhthomas]

I've dropped the main code on my fork (finally! Took me a while to get round to it). Need to populate the README, document the code and write some examples, but the code for the library is available.

[ladyada]

nice @rhthomas when you're ready please submit a PR :)

[ladyada]

for those who want to try it out - check out @rhthomas code here!
https://github.com/adafruit/Adafruit_CircuitPython_NRF24L01/pull/1

[2bndy5]

@uhrheber I've been working on the CircuitPython support for the nRF24L01(+), and in reference to this previous post: from my understanding of the Enhanced ShockBurst protocol, it is the underlying mechanism that takes whatever info you've given it (payload, address, etc) and makes packets out of it, and then runs a logic loop for broadcasting them. That last logic loop incorporates the auto-ACK functionality that pretty much marks the transmission successful. If your radio is capable of ESB I'd say yes, since ESB is so automatic on the nRF24L01.

I'm seeing a common backward compatibility theme in Nordic chips. There's a whole page on compatibility with nRF24E1/nRF24E2/nRF2401/nRF2402 which basically turns off all the shiny features. I'm secretly holding hopes for compatibility with whichever chip Logitech uses for their unifying receivers.

[2bndy5]

I've got a stable release deployed. I cloned the community bundle, then successfully did the git submodule add ... command. Now I'm stuck. the command that @tannewt used in the picture of the last page of the sharing guide doesn't work (not sure where the build-bundle.py is located). Then I tried circuitpython-build-bundles --filename_prefix circuitpython-community-bundle --library_location libraries --library_depth 2 from the bundle's readme, but I get a Permission denied: 'C:\\Users\\ytreh\\AppData\\Local\\Temp\\tmpi__tpjc9'. I'm at a total loss. Is it because I'm using windows?

[tannewt]

@2bndy5 Ya, it could be a windows thing. Feel free to make a PR and rely on Travis to test it.

[2bndy5]

its totally a windows thing (no problems building on the raspi)... May even be a my windows thing (running Insider Preview builds). It builds ok in travis, but the rf24.mpy is not in the correct subfolder "circuitpython-nrf24l01" under lib (see the release notes). I'm currently adding another module under the same folder that will emulate BLE advertisements using the nRF24L01. Hopefully having more than one py file in the specified --library_location will keep the files where they should be.

[tannewt]

Oh, weird. @sommersoft may have an idea why it's getting move outside it's package.

[sommersoft]

Try adding --package_folder_prefix circuitpython_ to the arguments when you call circuitpython-build-tools. It defaults to include package folders named adafruit_.

This does raise a bug though. It should handle this better, than just dumping the file outside of the folder.

[2bndy5]

Should this be closed? The library requested is released and getting properly built. I even consolidated the example scripts to comply with getting built in the community bundle.

[ladyada]

yep! library is here for future wanderers:
https://github.com/2bndy5/CircuitPython_nRF24L01