RF24 sends data backwards!

[natevw]

Well, I guess it's debatable but in short the datasheet for the nRF24L01+ says that data should be clocked over the SPI bus LSByte first. However this is not what RF24 does!

For RF24.cpp↔︎RF24.cpp communication, this isn't a problem since it's read back in the same order too. But because of that right now users of our code will get everything "in reverse" when talking to an e.g. Arduino :-/

Probably best to just add a special option to openPipe to handle this automatically for the user, otherwise this will be a major compatibility annoyance!

[darrylhodgins]

This wouldn't be the root cause of my inability to make RF24 on an Arduino talk to node-nrf on a Pi, would it? Hmm...

[natevw]

Could certainly be part of it. Naturally, you'll also need to make sure the channel/CRC/ack/etc. settings all match too.

I've been able to RX on the Tessel from an Arduino broadcasting (I turned auto-ack off to passively listen, since another device was sending those packets already) with mostly just a simple data reverse:

node-nrf/test-tessel.js

Line 14 in 7cf824c

Array.prototype.reverse.call(d); // WORKAROUND: https://github.com/natevw/node-nrf/issues/3

[Manawyrm]

ugh. Yeah. Such an option would really be nice.
Also: not only RF24 but also the other lib (MiRF) does this. I'm not quite sure who's at fault here, but I think this should be supported.

Also: all the addresses are reversed to (which caused my issues...).
Would you accept a pull request which adds options to the streams for reversing them?

[natevw]

Sure, would appreciate it! It should probably be an additional option on nrf.openPipe() (rather than the module or instance) in case people are talking to both Arduinos and Pi/Tessel remotes.

Odd the addresses are reversed, I thought I'd tackled that one already but maybe not tested enough. Thanks for the followup (and patience)!

[natevw]

This is implemented in 3b24f10 as part of the (currently broken) overhaul at #32. It might be possible to cherry-pick that work into master sooner, but personally I want to focus on getting the full set of improvements ready for release rather than backporting.

[nkolban]

What is the status of this fix? It looks like there was some activity 18 months ago but never made it into the master. Is this project still being maintained? Is there something we (the fans of this project) can do to assist? I see there are also some old pull requests outstanding ... are these going to be addressed?