rf24boot v0.2 released!


It was a busy month, but I finally managed to find a minute and update the rf24boot. Yes, the very thing that can push firmware updates via nRF24L01 wireless modules. Along is a regular bunch of updates to rf24 library in antares. One of the big news I finally took some 20 minutes and layed out a proper programming dongle. Since I didn’t have a cheap stm32 with usb around, and stm32f103ret6 looked like an overkill for this purpose this dongle still uses avr, vusb, but has a 16M (20M is possible as well) crystal. The lengthy changelog’s under the cut, but it’s big.

First of all, flashing 28k and verifying now takes about 23 seconds in a grand total, which is a win (Was – 2 minutes). Second the stability on bad links with a lot of interference is improved. It will be slow, but it will do the job no matter what. Even if it’s on the same channel with a wireless router transmitting tons of porndata. Speaking of which… I also implemented a dumb spectrum scanning, so now rf24tool has a –sweep option, that uses the host’s gnuplot and provides you with a realtime graph of actual 2.4Ghz spectrum usage. Not only by nrf24l01 devices, but also by anything else that’s on 2.4Ghz and is transmitting. Here’s the obligatory screenshot:


The lengthy changelog follows:

  • Moar daunting READMEs for those who like to read
Programming dongle
  •      New hardware design with 16M crystal! 20M possible as well.
  •      Ultra-cheap 5×5 cm single-sided design that will cost you ~15 bucks to get fabbed somewhere at seeed.
  •      Implemented hardware packet buffering and async operation (e.g. It’s now flashes faster. Really faster!)
  •      Refactor rf24tool code and ditch all compiler warnings
  •      Code cleanup (still ugly in places, but readable at least)
  •      Implement support for multiple adaptors.
  •      Huge performance improvements
  •      Stability improvements with far nodes
  •      Brand new test suite
  •      Spectrum sweeping and plotting
  •      Do not screw up when several packets are stuck in RX FIFO at once
  •      Minor performance and size improvements


The bad news is, that a few issues popped up.

  • The new dongle proved work weird with my USB 3.0 host in my laptop, while with USB 2.0 host everything’s fine. It still requires further studies, but this might be purely vusb related. I’ll get to write a few test cases to squash that insect.
  • The underlying nrfrf24l01+ library turned out to have some minor bugs (All are worked around in the current bootloader, so you’re safe. At least for now).

The rf24 library I use is the biggest pain so far. It is my pure C port of maniacbug’s nrf24l01+ arduino library. And, like most of arduino code it is a freaking mess with 200+ forks, more than a half of them abandoned, some have strange fixes, some do not. (When people ask me why I hate arduino – THIS is one of the freaking reasons!)  And the whole rf24 library looks pretty much abandoned for now.  This is the very place I decided to take a step further and refactor the code to my liking, since a lot of obvious improvements can be made. So on my TODO list is:

  • Further refactor antares nrf24l01 library code. Namely – multiceiver support, more efficient packet queuing using hardware fifo, etc.
  • Find out why a few packets get occasionally stuck in TX FIFO in the current code.
  • Add spidev/gpiobb support to userspace apps.
  • Move part of the rf24tool code that communicates with the usb dongle to a shared library with both sync and async API, so that you can build your own linux apps that utilize nrf24l01.

Yeah, and if you want all that goodies to arrive to you FASTER, consider helping me out, since all of that stuff’s on github.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.